扩展 Codex CLI 不是买一台巨大的机器，而是让每个 agent 都足够无聊、隔离，并且在跑偏时容易停下来。
我们经常看到同一种失败：一个成功的 Codex session 变成三个，再变成六个，然后一台 VPS 里全是半成品分支、藏起来的 tmux pane，以及没人看的日志。修复方式是设计扩展形状，而不是靠英雄主义。
从扩展单位开始
扩展的单位应该是一个 agent runner：一个工作目录、一个分支、一个任务、一条日志流。如果两个 agent 共用同一个 checkout，它们迟早会互相覆盖，或者在混合状态上跑测试。
# keep each runner boring and observable
export CODEX_WORKDIR=/srv/agents/$AGENT_NAME
export CODEX_BRANCH=agent/$AGENT_NAME/$TASK_ID
export CODEX_LOG=/var/log/office-claws/$AGENT_NAME.log
export CODEX_TIMEOUT_MINUTES=90它看起来简单，是因为它本来就该简单。在增加更多 VPS 容量之前，每个 runner 都要回答四个问题：
- repo checkout 在哪里？
- 哪个分支拥有这个任务？
- 日志写到哪里？
- 谁有权停止它？
慢慢增加并发
最便宜的扩展错误，是在知道瓶颈之前就运行太多 agent。Codex CLI 工作通常会撞上四种限制之一：测试时的 CPU、构建时的 RAM、安装依赖时的磁盘，或者 agent 完成后人类 review 的能力。
| Stage | Good default | Watch first |
|---|---|---|
| 小 repo、轻量测试 | 每台 2GB VPS 跑 1-2 个 agent | RAM 和 swap |
| 带 build 的 Web app | 每台 2GB VPS 跑 1 个 agent | build 时间 |
| 重型 monorepo | 每台 4GB+ VPS 跑 1 个 agent | CPU 和磁盘 IO |
| review 很重的流程 | agent 少于 reviewer | PR backlog |
Office Claws 会把这些显示在 desktop app 里，而不是让你记住哪个终端属于哪个任务。你自带 DigitalOcean 账号时，Self-Hosted 保持 $4.99/月；如果希望我们管理 VPS 侧，Managed 从 $14.99/月开始。
按风险拆分工作
不要把同一个 prompt 复制给五个 agent 来扩展。真正的扩展，是给每个 agent 不同的风险画像。
一个可靠模式是：
- Safe lane — 文档、测试、小型重构、依赖清理。
- Medium lane — 有明确验收标准的功能分支。
- Risky lane — migration、auth、billing、deploy scripts，以及任何需要慢 review 的内容。
把高风险通道放在最安静的 runner 上。给它更长的 timeout、更少的并发邻居，并在接触 production-shaped 代码前加入人工 checkpoint。
知道何时增加另一台 VPS
更大的 VPS 有用，直到它变成共享爆炸半径。我们更喜欢在隔离比纯速度更重要时，增加另一台小 runner。
在这些情况下增加容量：
- 测试被无关工作排队挡住
- 一次损坏的依赖安装阻塞所有 agent
- 日志太吵，无法快速 debug
- review 队列健康，但 agent 在等待
如果人类 review 已经落后，不要增加容量。更多 agent 只会制造更多过期分支。
下一步
如果你正在比较 agent framework，先看我们的 OpenClaw vs Codex 对比。如果你已经知道工作是 repo-shaped，Office Claws for OpenClaw users 路径可以给你 persistent Codex runners，而不会把扩展变成终端考古。
我们的建议很简单：每次只给 Codex CLI 增加一个 runner，保持每个分支隔离，并在 review 变成瓶颈时立刻停止增加 agent。