多代理并行修缺陷，如何减少代码冲突

4 个 Claude Code agent 同时处理同一个仓库里的 11 个 bug，最后只出现了 1 次合并冲突。作者靠的不是让 agent 更谨慎，而是先核实问题，再按文件划分任务，用独立工作目录隔离修改，最后集中验收和发布。

这套流程值得程序员参考，因为它处理的是 AI 并行编程里很实际的问题：重复修复、互相覆盖，以及代码各自通过检查，合在一起却出错。多数规则都来自作者踩过的坑。

并行之前，先确认问题还存在

作者原本准备分发 14 份 bug 报告，先让一个 agent 对照最新代码逐项核实。结果发现，3 个问题已经被前几周的其他会话修复，9 份报告只有部分描述成立，最终留下 11 个待处理问题。

这里不能把「部分成立」理解成可以跳过。它要求重新确认：哪些现象仍能复现，哪些判断已经过时，实际需要改什么。

随后，主会话按修改涉及的文件分组，分成金额与 token、文案、邮件、影片四组。目标是让不同组尽量不碰同一批文件。

但这次仍有两组修改落在同一个文件里：一个 agent 重构了函数，另一个修改了函数内部逻辑。主会话保留重构，再手工把另一处修改放进去。这就是唯一的冲突。

按文件分工能减少冲突，但仍需要有人理解修改的语义。

独立 worktree，解决的是工作目录互相干扰

每个 agent 都从 origin/main 创建新的 Git worktree。它可以理解为同一个仓库下的独立工作目录，各自关联分支，文件修改互不干扰。

下面两条命令用于获取远端状态，并为邮件修复创建工作目录：

git fetch origin
git worktree add -b fix-emails ../scratch/fix-emails origin/main

要看清第二行最后的 origin/main：新任务从远端主分支起步，而不是继承某个会话当前的工作状态。

作者禁止 agent 在主检出目录里干活，也禁止在那里切换分支。多个会话共用目录时，一次 git checkout 就会改变所有会话眼前的文件。

新 worktree 没有 node_modules。作者在 Windows 上用目录联接（junction）复用主目录的依赖，从主检出目录执行：

cmd /c mklink /J ..\scratch\fix-emails\node_modules C:\work\app\node_modules

要注意 cmd /c 和 /J，这是 Windows 的目录联接命令。移除 worktree 前，作者要求先执行 cmd /c rmdir ..\scratch\fix-emails\node_modules 删除联接，避免递归删除误伤真实依赖目录。PowerShell 中的 rmdir 是 Remove-Item 的别名，因此这里明确写出 cmd /c。

这隔离了源码工作目录，却仍共享依赖安装；原文没有说明任务需要不同依赖版本时如何处理。

为什么完整测试和发布要集中进行

执行修复的 agent 只写代码、运行类型检查，不跑完整测试，也不提交。主会话阅读每份 diff 后，在统一的 release worktree 中完成完整测试和提交。

作者列出了集中验收发现的三个问题：

• 一个测试把 matcher 对象存进了本该保存真实值的位置，后续比较的对象因此错了。
• 一个测试仍然断言刚被删除的旧行为。
• 新增的两条路由没有同步纳入权限测试。

这些问题都在提交前被发现。它们说明，类型检查通过，并不能证明行为和测试预期一致。

发布时，作者把提交通过 cherry-pick 放到基于 origin/main 的新 worktree。若主分支已经前进，就先 rebase，再做最终检查，检查之后不再 rebase。多个修复可以陆续提交，但集中 push 和部署，以节省构建分钟数；正在影响客户的问题则例外处理。

完整测试还暴露过一个影片测试：并行分片运行时失败，单独运行却通过。作者的经验是，这类问题追查后都有真实原因，例如共享临时文件、端口冲突，或者机器繁忙时触发超时。

单独通过，只能帮助缩小排查范围，不能抵消完整运行中的失败。

我的判断

我赞同把任务核实和最终验收放在并行执行的两端。前者减少无效修改，后者检查组合后的结果，都比单纯增加 agent 数量更有操作价值。

但「11 个 bug、4 个 agent、1 次冲突」只是一次工作记录。作者没有给出串行处理的耗时、返工量或缺陷遗漏率，不能据此认定四路并行一定更快。

集中跑完整测试也有前提：主会话能读懂所有 diff，完整测试能及时给出结果。与每个 agent 都跑完整测试相比，它可能减少重复执行，也可能让错误更晚暴露。原文没有对照数据，这是作者的流程经验。

按文件划分任务同样有边界。不同文件可能通过接口、权限规则或测试夹具互相影响；Git 没有冲突，并不代表功能可以正确组合。

能拿来做什么

• 分发积压 bug 前，先让 agent 对照最新代码核实复现条件，把「已修复」「部分成立」和「仍需处理」区分清楚。
• 在前端或 Node 仓库里并行修复时，先列出预计涉及的文件，再分配 worktree；公共函数和共享配置由主会话协调。
• 可以借鉴「agent 做类型检查，主会话审查 diff 并跑完整测试」的分工，同时重点检查测试断言、路由权限和旧行为是否同步更新。
• 遇到只在并行测试中失败的用例，保留失败信息，优先排查临时文件、端口和超时，不要用一次单跑成功关闭问题。