多编程智能体并行的三个协作关口

让 Claude Code 和 Codex 同时写一个仓库，难点往往不在模型，而在协作方式：它们可能读到彼此改了一半的文件，抢跑尚未完成的任务，再各自宣布测试通过。代理越多，这些问题越难靠人盯住。

作者给出的解法有三层：用 Git worktree 隔离现场，用任务依赖图控制开工顺序，再让独立检查决定任务是否完成。这套方法值得看，因为它把「多开几个终端」拆成了程序员能落实的工程规则；但文中的效率判断仍以团队经验为主。

先隔离工作现场，再谈并行提速

两个代理共用同一个工作目录，危险不只是同时修改同一行。一个正在修改配置，另一个恰好运行测试；测试通过了，却没人能还原当时到底用了哪组文件。提交暂存区也可能混进其他代理的改动，最后连 diff 属于谁都说不清。

作者因此把隔离放在第一位。依赖排错了、验证漏了，至少还能检查产物；工作目录混在一起，产物的归属就先丢了。

Git 已经提供了基础工具：git worktree add。它可以基于同一仓库创建另一个工作目录，并让这个目录使用自己的分支。多个 worktree 共享仓库对象库，不需要为每个代理重新克隆整份历史，也不需要为创建目录访问远端。

每个代理有自己的目录和分支，测试就能针对它自己的代码运行，交付物也变成可按现有习惯审查的分支。

并行工作的第一条规则，是让每次修改和每次验证都有明确归属。

不过，目录隔离只是起点。作者专门提醒，端口和状态也要隔离。两个开发服务都使用 3000，可能让后启动的代理访问到先启动的服务，拿别人的页面证明自己的修改正确。原文没有展开状态隔离的具体方案，因此不能把 worktree 当成完整的运行环境隔离工具。

任务依赖必须决定谁能开工

即使文件互不干扰，两个代理仍可能基于错误的前提各自写出能合并的代码。

原文举的例子是数据库迁移和接口：迁移尚未完成，接口代理已经按照想象中的 schema 开发。放到完整链路里，就是「迁移 → 接口 → 调用接口的 UI」。这些先后关系，人通常知道，单独接到任务的代理未必知道。

作者建议把工作写成任务图。每个任务都明确依赖哪些任务，只有前置任务完成，后续任务才进入可领取状态。

这里有三个实用细节：

• 一个任务对应一个代理能够独立完成的工作单元，并提供足够上下文，让它从空白会话也能开始。
• 如果一项工作需要两个代理，就拆成两个任务，把协作关系写出来。
• 未满足依赖的任务应当无法领取，不能只在提示词里写一句「请等待接口完成」。

第三点最关键。提示词表达意愿，调度规则限制行为。代理只拿到已经具备开工条件的任务，空闲后再领取下一个，协调成本才能降下来。

还要留意作者没有讲透的一步：前置任务完成后，它的代码如何进入后续任务的 worktree？任务状态变成「完成」，并不会自动让其他分支拥有最新接口。采用这套方法时，仍需确定依赖代码如何同步，否则任务图上的顺序正确，代理看到的代码却可能过时。

「已经完成」必须经过独立检查

作者的另一条规则是：写代码的代理不能独自决定任务是否完成。

代理说「所有测试通过」，首先只是一个声明。只有重新运行并检查结果，才能把声明变成证据。单代理时，人还能逐条核对；同时跑到约 3 到 4 个代理后，作者认为审查能力就容易成为瓶颈。

他们建议增加一次独立验证：使用全新上下文和只读工具，最好再换一个模型，检查结果能否复现。独立上下文有助于减少检查者沿用实现者错误假设的机会，但原文并没有给出不同模型之间的对照结果。

失败之后也要有流程。检查结果应带着证据返回原代理，并设置尝试上限，避免它围绕同一个错误反复修改。

作者团队开发的 Ninebrains，就是把这些规则自动化的桌面应用。按原文描述，它让 Claude Code 和 OpenAI Codex 并排运行，每个代理拥有独立的 git worktree、终端和浏览器；中央 Brain 保存任务图，把就绪任务交给空闲工作通道。

任务结束前，验证关卡会运行测试、截图，并启动独立审查者。失败反馈最多回传三次，之后阻塞任务并通知人处理。原文还提到，公开源码包含这些验证关卡，以及供测试驱动关卡的 fake-agent harness，即模拟代理行为的测试装置。

Ninebrains 调用用户已经登录的 claude 和 codex CLI，作者称应用不接管凭据。原文所述版本为 v0.2.9，免费开源，采用 Apache-2.0 许可证，提供 macOS、Windows 和 Linux 构建；当时构建尚未代码签名，作者也将其定位为适合阅读和试用的早期产品。这些是原文提供的版本状态，不代表当前状态。

我的判断

我认同它的优先级：先保证工作现场可信，再提高任务吞吐。对前端和全栈团队来说，读错开发服务、依赖尚未就绪、验证结果无法复现，都比「模型不够聪明」更具体，也更容易治理。

但文章没有提供耗时、返工率或吞吐量对照。「约 3 到 4 个代理后审查成为瓶颈」是作者的经验判断，不能直接当作团队容量公式。任务规模、测试质量和审查者熟悉程度都会影响这个数字。

独立代理也不自动等于可靠裁判。如果验收标准含糊，或者测试没有覆盖需求，第二个代理仍可能认可错误实现。截图能留下界面证据，却不能单独证明交互和数据链路正确。

验证关卡的价值，取决于它检查什么，以及失败后能否提供可操作的证据。

相比一个代理串行完成全部工作，这套方式更适合依赖清晰、能够拆出独立分支的任务。迁移、接口、UI 严格前后相接时，多开代理也无法消除依赖等待；它们真正能利用的是任务图中同时就绪的工作。

至于 Ninebrains，文章既是方法分享，也是作者团队的产品介绍。可以吸收其中的工程规则，工具效果则需要另行验证。原文自己也承认，worktree、手写依赖图和第二代理复核，已经能实现大部分流程。

能拿来做什么

• 同时使用 Claude Code 和 Codex 时，为每个代理建立独立 worktree，并记录各自的开发服务端口，确保浏览器访问的是对应分支的代码。
• 把涉及 Node 接口和前端页面的需求拆成明确任务，写清「谁依赖谁」，并约定前置代码如何进入后续任务的工作目录。
• 在开工前写好验收条件，再让独立会话复跑测试、检查页面或审查 diff；把失败日志和截图一起交回实现代理。
• 先用少量代理试运行这套流程，观察人工审查是否跟得上，再增加并发；同时设置失败重试上限，让卡住的任务及时转交人处理。