多 Agent 并行写代码：收敛才是真问题

凌晨一点，你在五个终端里各起了一个 Agent，分别去修认证 bug、加限流、补测试、改文档、清技术债。它们互不打扰，因为你给每个人开了一个 git worktree。早上打开电脑，五条分支都在，四条能跑，还有一条把别人改过的接口签名覆盖回了旧版本。

git 不觉得这里有冲突。冲突检测发生在同一条分支上，而这五个 Agent 从头到尾没见过同一条分支。

一、今天的榜单在说同一件事

10 月 2 日的 GitHub 趋势里，多 Agent 相关项目几乎包场：NVIDIA/OpenShell 当天 2456 星，mvschwarz/openrig 642 星，还有 ruvnet/ruflo、msitarzewski/agency-agents、Donchitos/Claude-Code-Game-Studios（49 个 Agent 加 72 个技能），以及一个专门给 Agent 做独立审计的 ifixai-ai/iFixAi。Rust 榜上还躺着一个 max-sixty/worktrunk，全名叫「给并行 AI Agent 用的 git worktree 管理 CLI」。

这些项目卖的不是模型能力。它们卖的是同一件东西：怎么让 N 个 Agent 一起干活而不翻车。

竞争重心已经从「单个 Agent 能不能完成任务」，挪到了「任务跑完之后谁来收场」。收场这件事分成三层：隔离、协调、验证。三层各有各的账。

二、隔离解决的是「写坏了」，不是「写重了」

worktree 是目前的标准答案。它让每个 Agent 有一份独立的检出目录，共享同一个 .git 对象库，各自占一条分支。worktrunk 把这套降到了跟切分支一样的成本：

wt switch -x claude -c feature-a -- 'Add user authentication'
wt switch -x claude -c feature-b -- 'Fix the pagination bug'
wt switch -x claude -c feature-c -- 'Write tests for the API'

三条命令，三个隔离环境，三个并行任务。这确实是这一层最干净的抽象，比手写 git worktree add 加一堆终端管理脚本舒服得多。

但 worktree 买到的只是「不出事」。它把冲突解决整个推到了合并那一刻，而那时候每个 Agent 已经为自己的设计付出了代价。

STORM 那篇论文把这件事讲得非常直白：隔离防止了编辑期间的互相干扰，代价是冲突全在 merge 阶段结算；文本冲突还好找，语义冲突（两边单独编译都过、合起来就坏）更难，而现有工具没法自动解。更麻烦的是错会复利：Agent A 写了个 helper，假设了某个签名；Agent B 在自己的分支里把这个签名改了；依赖这两者的代码现在坏了，而且是两个分支单独看都不坏的那种坏。

STORM 的做法是不隔离：所有 Agent 待在同一个工作区，但每一次写都要过校验。每个文件有一个递增的版本号，Agent 读文件时记下版本快照，写之前系统校验「你读过的那些文件有没有被别人改过」。没有就原子写入，改过就拒绝，并把目标文件的当前内容、变更 diff、以及过期依赖清单一起返回，让它在正确的基线上重新规划。核心洞察是一句很轻的话：Agent 不需要整个仓库冻结，它只需要自己读过的那些文件在推理期间别动。这叫本地状态一致性。

在同一批 LLM 上跑，STORM 在 Commit0-Lite 比 worktree 基线高了 18.7 分。

我的判断是：worktree 是必要的第一层，但它买的是「不崩」，不是「能收敛」。真正决定一个多 Agent 流程能不能交付的，是第二层。

三、协调不是开会，是把冲突的代价提前

有个结论比技术细节更值得记住，来自 AgentRoom 那篇论文。

它给一组并发编码 Agent 做了一个 CRDT 支撑的共享工作区，再用 MCP 暴露四个工具：claim（声明文件所有权）、release（释放）、broadcast（广播进展）、state（读当前占用和最近消息）。然后它对比了几种方案，结果里最反直觉的一条是：无协调的 parallel-merge，得分比单个 Agent 还低。 因为 Agent 会互相覆盖对方的文件，或者做出互不兼容的接口假设。

也就是说，「多开几个 Agent 各干各的，最后合并」这个看起来最自然的做法，是把钱花了、质量还降了。论文的总结一句话：起承载作用的是协调，不是并行，也不是 CRDT 合并本身。

它还测到一个副作用我很有共鸣：单个 Agent 遇到硬任务时容易弃坑，写个空壳加几个 TODO 就退出。有同伴在场、有共享工作区的时候，这个弃坑率的下降在统计上显著。多 Agent 的价值有时候不在于并行提速，而在于「有人在看着」这件事本身。

人这边的经验几乎一样。Claude Code 的 Agent Teams（实验特性）给的是一套显式协调原语：共享任务列表（带依赖）、Agent 之间的 mailbox、基于文件锁的任务认领、plan-approval 门禁（先只读规划，批准了再动文件）、以及任务生命周期钩子。社区踩出来的经验值也很具体：每个 teammate 分 5 到 6 个任务，每个任务独占一组文件，3 到 5 个 teammate 是甜点区，再多协调成本就开始吃掉并行的收益。

最容易踩的坑是分解的轴选错。按 Jira ticket 切，冲突率很高，因为 ticket 根本不认模块边界：「修认证 bug」和「加限流」很可能都要动同一个 middleware。正确的切法是按文件或模块的所有权切，让每个任务在整个运行期间独占一组写权限。如果两个任务确实都需要改同一个文件，那它们不独立，应该串行排队，或者干脆并成一个任务。硬把「看起来独立、其实耦合」的活并行化，是绝大多数编排方案悄悄退化成合并冲突工厂的地方。

有个细节值得单独说：Forge 那类工具用文件级锁来防冲突，但锁是协作式的。Agent 绕过 MCP 接口直接写文件，锁就形同虚设。任何靠 Agent 自觉的约束，都不能算边界。

四、知识蒸发和架构漂移，比冲突更安静

冲突至少会报错。有两类失败不会。

Forge 的技术文档列了并发多 Agent 的三类系统性失败：大规模合并冲突、知识蒸发、架构漂移。中间那个例子特别典型：Agent A 发现数据库迁移必须先于 API 服务启动；Agent B 在另一个上下文窗口里完全不知道这件事，直接部署了 API，然后花了二十分钟 debug 一个它注定找不到原因的问题。人类团队靠站会和文档传递这种信息，Agent 没有对应机制，会话一结束，知识就跟着上下文一起没了。

架构漂移更隐蔽：Agent A 把认证模块重构成了新写法，Agent B 不知情，用旧写法实现了新功能，Agent C 又从训练数据里带来第三套。代码库表面还能跑，实际上在积累看不见的债。

对应到工程上，需要的是共享的记忆层。openrig 用一份 CULTURE.md 定协调规范，让研究型 rig 走探索文化、实现型 rig 走保守加交叉验证文化；另外一些方案用 hub 上下文或持久知识库。但共享记忆是个双刃剑：它同时是错误结论的放大器。一个 Agent 得出了错的前提，写进共享层之后会污染所有人。所以记忆层需要的是「记录了什么、谁记的、什么时候记得」，不是一份没有来源的公共黑板。

五、账单不是线性的

这一层的账最容易被算错。

Anthropic 自己的实测数字是：单 Agent 大约消耗 4 倍于聊天的 token，多 Agent 系统大约 15 倍。在 BrowseComp 上，token 用量单独就能解释约 80% 的性能方差。

超支的钱花在四个地方：上下文被复制到多个 Agent 而不是复用；编排层本身的开销（每个交接都带一份协调成本）；重试（第 15 轮重试会带着 15 轮历史重发，第二次永远比第一次贵）；以及验证。MCP 工具 schema 这一项就很吓人，在静态工具集里能占到 token 用量的 60% 到 80%，而且每次迭代都重新计费。所以「三个 Agent 应该是三倍成本」这个假设基本不成立，实际常见的是五到十五倍。

好消息是这一层还有很大优化空间。Harness Effect 那篇做了一次很干净的受控实验：同样的 22 个锁定任务、同样的 6 个模型（Claude Sonnet 4.6、Gemini 3.1、Gemini Flash 3.5、Qwen 3.6、GLM 5.1、Palmyra X6），只替换编排层，用常规生产 Agent 循环对比一个显式设计的 harness。结果是单任务混合成本降 41%（0.21 美元到 0.12 美元），token 降 38%，中位墙钟时间降 44%，而完成质量持平。

更有意思的是两个分开的结论：效率收益与模型无关（每个模型都便宜了 33% 到 61%），质量收益与模型能力高度相关（r 等于 0.99）。同一个 harness，强模型捞到的好处远大于弱模型。

同一篇里还有一个门槛值得记住：把子任务委派出去这个能力，只在最强的几个模型上稳定可用（Palmyra X6 是 0.86，Sonnet 4.6 是 0.85），在快模型上掉到 0.42 到 0.45。也就是说，编排功能不是免费开关。模型的底子低于某个门槛，你打开多 Agent 买到的不是生产力，是失败。

六、验证才是收工的开关

把上面几层剥掉，会剩下一个不太舒服的判断：很多多 Agent 架构，本质上是一个你一直没去构建的验证器。

常见的那套四件套（planner、critic、researcher、executor）里，critic 干的事情就是检查 executor 的输出。这不是协调，是把验证穿了件衣服在跑，代价是一份额外的 token 预算（常见 30% 到 50%）加翻倍的时延。

问题出在相关性上。critic 和 executor 共享训练分布，会瞎在同一个地方。一个随机模型审另一个随机模型，抓到的是表层错误，漏掉的是生成原始错误时的同一类盲区。它给你的不是保证，是相关性错误加一条更长的调试链。

MAST 的失败分类里，约 23.5% 的多 Agent 失败跟验证有关：过早终止、验证不完整、验证错误。很多是因为验证器和执行器待在同一个模态里。

出路是模态转换。代码转成测试执行结果、文本转成模拟器状态、输出转成确定性 schema。编译器、测试、断言，在它们覆盖的范围内，比第二个 LLM 更便宜，也更可靠。只有当某个失败模式确实没有便宜的确定性验证器时，才该去开第二个 Agent。

iFixAi 是目前少见的一个工程化样本，值得看一眼它的评分设计：

它有 50 项检查（32 项核心、18 项扩展），每条证据都必须声明自己的评估方式，是结构化调用、rubric 判分，还是原子断言拆解。缺钩子或缺判分器的地方，会显式标成「证据不足」或「不确定」，而不是静默判过。默认行为里有一条我认为是整份设计里最重要的：自动跨 provider 配对判分器，只有一个凭证时除非显式打开自评模式，否则直接拒绝运行，而且打分卡上会带自评偏差的警告。它的理由只有一句话，Agent 不该给自己打分。

它自己也承认局限：治理钩子往往是 fixture 里声明的，不是测出来的；对抗语料是公开的，及格不代表能挡住一个有针对性的攻击者。

我会从这里抄走三条纪律。验证尽量落在确定性检查上，测试、类型、编译、schema 都算。判分方和执行方不同源，同源就等于没有第二个人。没有证据的时候标「不知道」，不要静默通过。

七、什么时候不该开多 Agent

• 你能用一句话说清这个任务、句子里没有「and」，就别 swarm。这个判断很粗糙，但很少判错。
• 3 到 5 个 teammate 是上限。再加人，人均协调开销会吃掉并行收益，lead 的上下文也会先被任务状态填满。
• 协调者不写代码。Claude Code 的 delegate mode 就是干这个的：把 lead 限制成只有编排类工具。lead 一旦亲自下场，它手上那件事就变成串行的。
• 先修架构，再并行。模块边界一塌糊涂的代码库，Agent 之间的时间会大量花在互相通知冲突上，不如先把依赖理干净。
• Claude Code 里 teammate 的模式是 spawn 时固定的，plan 模式不能中途切换。要「先规划再执行」，得新开一个 teammate 把计划接过去。

结语

这一层的演进方向，跟操作系统和数据库走过的路是一样的。先从「能跑」到「能隔离」，再从「能隔离」到「能收敛」。而收敛这一步，最后靠的是确定性的、可审计的裁判，不是更多的聪明模型。

用一个测试就能判断你缺哪一层：把 Agent 的数量翻倍。如果代码质量没变、账单翻倍，你缺的不是 Agent，是验证器。

参考来源

• GitHub Trending 日报 2026-10-02：https://curvesoft.net/posts/github-trending/2026-10-02/
• Worktrunk 项目与文档：https://worktrunk.dev/
• OpenRig 多 Agent harness（mvschwarz/openrig）：https://github.com/mvschwarz/openrig
• STORM: Multi-agent Collaboration with State Management（arXiv:2605.20563）：https://arxiv.org/html/2605.20563v1
• AgentRoom: Concurrent Multi-Agent Coding in a CRDT-Backed Shared Workspace（arXiv:2608.23740）：https://alphaxiv.org/abs/2608.23740
• The Harness Effect: How Orchestration Design Sets the Token Economics of Enterprise Agentic AI（arXiv:2607.06906）：https://arxiv.org/html/2607.06906
• Multi-Agent Cost Compounding: Why 3 Agents Cost 10x：https://www.augmentcode.com/guides/multi-agent-cost-compounding
• The Forge Whitepaper: Multi-AI Orchestration for Software Development：https://nxtg.ai/insights/forge-whitepaper
• Claude Code 并行 Agent 官方文档：https://code.claude.com/docs/en/agents
• Claude Code Subagents 文档：https://code.claude.com/docs/en/agent-sdk/subagents
• Agent Teams 最佳实践：https://www.buildthisnow.com/blog/guide/agents/agent-teams-best-practices
• iFixAi 方法论文档：https://github.com/ifixai-ai/iFixAi/blob/main/docs/methodology.md