如何同时跑多个 Codex 智能体而不让自己绊倒自己

2026年4月21日2 分钟阅读

Share with

一个 Codex 很简单，四个就是运维问题了

跑一个 Codex 智能体不过是一条 codex 命令。它登录、拿到你的仓库、开始干活。大多数人第一次尝试「多智能体」，就是打开四个终端、把同一条命令敲四遍。这种做法大致能工作十分钟——直到两个智能体抢同一批文件，或者其中一个把 ChatGPT Plus 的消息额度吃光，顺带把另外三个也拖下水。

真正的问题不是「能不能同时跑几个 Codex 智能体」，而是「怎么让它们不互相妨碍」。我们大多数日子都会并行跑四到六个 Codex 智能体，失败模式总是那几种。下面这套方案能挺过这些模式。

四个 Codex 智能体分别跑在彼此隔离的 VPS 上，通过 Tailscale 互联

并行跑时到底会撞到什么

在挑方案之前，先把「什么会坏」说清楚。我们见过三类碰撞：

认证碰撞。 Codex CLI 会把订阅凭证缓存在 ~/.codex/ 里。共享这个目录的两个进程会争抢 token 刷新、把对方踢下线，或者触发一个重认证死循环，把账号锁上好几分钟
文件系统碰撞。 两个智能体编辑同一棵工作树会互相覆盖。就算一个智能体跑 go test 而另一个正在改文件，也会产生幻影失败，光是为了排查这些失败就能啃掉一大块上下文
速率限制碰撞。 ChatGPT Plus 按滑动窗口内的消息数封顶——按账号，不是按设备。四个饿着的智能体挂在一个 Plus 账号上，大约单独跑的四分之一时间就会撞顶；一个吵闹的智能体会把其他几个饿死

三者的解法其实是同一个：给每个智能体自己的机器、自己的家目录——如果你要压榨它们的话，再加上自己的账号。

能扛住真实使用的方案

在 Office Claws 里，你创建的每个智能体都会落到一个专属的 DigitalOcean droplet 上，大约两分半钟就能配好。这个 droplet 有自己的 ~/.codex/ 目录、自己的仓库 checkout、自己的 Tailscale 身份。你不用去想上面那些碰撞——隔离是默认值。

关注点	笔记本上多终端	Office Claws 多智能体
认证缓存	共享 `~/.codex/`——会竞态	每个 droplet 分开
工作树	共享——互相覆盖	每个智能体一份仓库
速率限制	一个账号服务所有智能体	每个智能体一个账号（可选）
恢复	杀掉所有终端	重启某一台 droplet
可见性	4 个 tmux 面板	像素办公室里 4 张桌子

典型的四智能体一天是这样：

researcher-agent  → reads issues, writes tickets
builder-agent     → takes a ticket, implements it
reviewer-agent    → reviews the builder's PRs
scribe-agent      → writes release notes, updates docs

每个都活在自己的 VPS 上。每个都有自己的 Codex 会话。每个在像素办公室里都是一个独立角色，你一眼就能看到谁在干什么。

订阅这一侧的两条路

第二个问题是：你到底需要几个 ChatGPT 账号。这比基础设施那一侧更不直观，答案取决于智能体工作强度。

一个订阅，多个智能体。 对于轻到中等的使用——两三个智能体，每个每天几小时——一个 ChatGPT Plus 订阅（20 美元/月）就能搞定一切。Plus 是按滑动窗口内的消息数封顶，不是按账号乘设备，两个轮流干活的智能体离上限还远得很。从这里开始。

每个智能体一个订阅。 一旦你有四个或更多智能体、每个都跑好几个小时，就会开始看到速率限制警告。到这一步，再加一个 Plus 比升到 Pro 便宜，尤其是当其中两个智能体主要做被动工作（观察、总结）、另外两个在狠写代码的时候。Plus 以 20 美元/月 × N 个并行账号，可以线性扩展到大约六个智能体；再往上，200 美元的 Pro 才开始有意义。

订阅策略：轻度使用一个 Plus 账号，重度使用一个智能体一个账号，超过六个智能体上 Pro

我们每天用的三种模式

方案只是一半，智能体还需要角色，而且角色得够窄，才不会互相踩：

流水线。 researcher 把一张 ticket 交给 builder，builder 把一条 PR 交给 reviewer，reviewer 把合并交给 scribe。每个智能体都要等前一个。慢但安静——没有碰撞，因为同一时刻只有一个智能体在动同一批文件
扇出。 一个规划智能体产出 N 张互不相关的 ticket，N 个 builder 在不同仓库里并行各取一张。快，但对「边界」要求很严——绝不能两个 builder 同时动同一个模块
watcher + worker。 一个智能体跟日志 / PR / issue，在需要时叫你；另外几个等你点头后接具体任务。零冲突风险，非常适合值班风格的流程

这些模式并不互斥。大多数日子我们会跑一对流水线加一个独立的 watcher——五个智能体、零碰撞，因为流水线把共享文件的访问串行化了，而 watcher 从不写入。

有些事别做

下面这些听起来挺合理，但会让你浪费一整天：

在多个智能体之间共享一个 git clone。 就算每个智能体分别开一条分支，stash / commit hook / 构建缓存也会打架。每个智能体一份 clone，每个 droplet 一份
一台 droplet 上跑多于一个 Codex 进程。 1GB 内存的基础 droplet 刚好能舒服地撑起一个 CLI；第二个会在重构中途把第一个 OOM 掉
在已经频繁撞限制的情况下，在一个 Plus 账号上做轮询。 如果你每天都能在某个智能体身上看到「你已用完消息」的那张屏，20 美元再买一个 Plus 的代价，比那些被切断的智能体丢掉上下文的代价要低

从零开始

如果你想先试一下、不想一上来就上完整方案：

开两个 Office Claws 智能体。Self-Hosted 方案下，应用每月 4.99 美元加 droplet 每月 4 美元，头两个合计大约 13 美元
给其中一个分配一个狭窄的 watcher 角色（每天早上总结所有打开的 PR），另一个分配一个 builder 角色（盯一个具体仓库）
让它们跑上一周。你会真正看到碰撞模式长什么样，也会看到单个 Plus 订阅的天花板长什么形状
只有在这一周里看到速率限制咬到不止两次，你才需要用一个独立的 ChatGPT 账号开第三个智能体

我们一直回到的那条原则：哪里能靠隔离省时间就为它付钱，哪里不能就共用。Droplet 便宜，订阅没那么便宜，大多数有用的多智能体方案就活在它们中间的那条带上。