3个AI同时写代码，人类成了最忙的bug

一个人用AI写代码很爽。三个人同时用，代码库当场爆炸。

作者同时跑了Claude Code、Codex和Aider三个月，发现从单代理切换到多代理的瞬间，三个问题直接击穿工作流：文件冲突、质量失控、人类沦为调度员。这不是AI不够聪明，是监督方式没跟上。

文件冲突：各自关进独立房间

两个代理同时改同一个文件，后保存的直接覆盖前者。双方都不知道发生了啥，等你发现时项目已经编译失败。

Git worktree（工作树）是现成的解决方案。给每个代理单独建目录、单独分支、单独工作区：

git worktree add .worktrees/agent-1 -b agent-1/task-1

物理隔离消除了覆盖风险。代理完工后合并回主分支，冲突只解决一次，而不是持续不断地救火。

实际瓶颈在3-5个并行代理。再多，代码库本身的合并压力会超过人类处理能力。

质量门：测试不过就是没做完

代理宣布"完成"的标准是代码生成完毕，不是代码能跑。不加拦截，你会得到一堆看起来对、实测全挂的代码。

作者的做法简单粗暴：合并前先跑测试套件。

cargo test # 或 npm test、pytest 等

echo $? # 返回0才合并，非零打回重写

测试失败就把报错丢回给代理，让它自己修。这个反馈循环把"代理搞崩东西"的概率压低了约80%。剩下的20%是测试覆盖不到的场景——那是测试的问题，不是代理的问题。

关键洞察：不需要复杂的评估框架。你维护的现有测试套件就是质量门。exit 0等于完工，其他等于重试。

调度困局：从写代码变成切窗口

多代理并行时，人类的工作变成：切终端、查谁在干啥、解冲突、手动跑测试。代理在干活，你在当项目经理。

作者试过让代理自组织，结果任务重复、资源争抢、优先级混乱。人类必须保留调度权，但要把操作成本压到最低。

他的解法是用一个主控脚本轮询状态：哪个代理空闲、哪个在跑、哪个需要干预。把"切六个窗口"变成"扫一眼状态板"。

这个模式的核心是分离关注点。代理负责生成代码，脚本负责状态同步，人类只做决策。三方各干各的，不互相阻塞。

三个月跑下来的体感

作者的原话是：单代理是"帮我写代码"，多代理是"帮我管理团队"。后者省下的不是打字时间，是上下文切换的脑力消耗。

Git worktree解决冲突，测试套件卡住质量，主控脚本接管调度。三个补丁都不需要新AI能力，全是现有工具的排列组合。

最反直觉的发现：并行代理的上限不是算力，是合并带宽。代码库能吸收多少并发修改，取决于你的测试覆盖率和架构解耦程度。

作者最后提了一个没说完的问题：当代理能从"写函数"进化到"拆任务"，人类调度员这个角色还有必要存在吗？