过去一年，AI 编程工具的叙事从「副驾驶」升级成了「团队」：主流编程 agent 纷纷支持子 agent 并行干活（Claude Code 的官方文档就专门有「并行运行 agent」一节，列了四种并行方式），编排框架把「多 agent 协作」当卖点，不少团队已经在讨论怎么让十个 agent 同时改一个代码库。潜台词很直白：一个 agent 能干活，一队 agent 就能干更大的活。

斯坦福 Diyi Yang 团队最近把这个假设放到台面上测了一次（Stanford HAI 报道、论文 arXiv:2601.13295）。结果是：让两个顶级编程 agent 结对完成真实软件任务，综合成功率比一个 agent 单干平均低 41%。先交代口径：41% 是按下文的 AUC 指标算出的相对降幅（0.338 掉到 0.200），论文摘要自己用的是另一种口径，说法是「平均低 30%」，两个数字统计方式不同、不矛盾。论文给这个现象起了个名字：协作的诅咒（curse of coordination）。

实验是怎么设计的

这套基准叫 CooperBench，设计上刻意贴近真实团队开发：652 对任务，来自 12 个真实开源仓库，覆盖 Python、TypeScript、Go、Rust 四种语言。每对任务是两个可以独立实现、但实现起来可能互相冲突的功能，冲突不是小概率事件：77.3% 的任务对，连标准答案的两份实现之间都存在真实冲突。单个功能的体量平均改 52 行代码、动 4.4 个函数，是正经的开发任务，不是玩具题。

流程模拟远程结对：两个 agent（论文用 OpenHands 框架，测了 GPT-5、Claude Sonnet 4.5、MiniMax-M2 和两个 Qwen3-30B 变体）各自在隔离的容器里改同一个仓库的副本，期间可以随时给对方发消息。两边完工后用 git 合并补丁，评测甚至安排了一个专门微调的 0.5B 小模型（Qwen2.5-Coder 微调版，论文正文一处写作 1.5B，以附录发布的模型规格为准）帮忙解决琐碎的合并冲突，然后在合并后的代码上跑单元测试。对照组（solo）是同一个 agent 独自把两个功能都做完。

指标用的是「成功率对任务难度」曲线下的面积，可以粗略理解为跨所有难度档的综合成功率。结果：五个模型合并计算，solo 是 0.338，结对掉到 0.200，只保住 59%。最强的 GPT-5 也只保住 64%（0.506 掉到 0.325），Claude Sonnet 4.5 保住 60%，MiniMax-M2 只剩 46%。更扎心的是，把实时消息通道整个关掉，成功率没有统计显著的变化。能说话，和说了有用，是两回事。

失败长什么样

论文用 LLM 标注了全部失败轨迹的症状分布：最大的两类是工作重叠（33.2%，两边各自独立实现了同一块功能，力气白费或互相覆盖）和架构分歧（29.7%，各自的实现在设计上互不兼容）。再往后是重复刷屏（14.7%，不停发没有新信息的状态更新）、不回消息（8.7%，队友的直接提问石沉大海）。

作者又人工细读了 50 条失败记录，把根因归成三类：期望失败（42%，对队友在干什么、会怎么干的预判是错的）、承诺失败（32%，说好的事没做，或做了说好不做的事）、沟通失败（26%）。对话记录里的具体场面，做过项目的人都会觉得眼熟：一个 agent 明确警告「这个文件我在改」，对方口头表示收到，然后照样把它的代码覆盖掉；通信多的模型（如 Claude、GPT-5）最多有约 20% 的操作步骤花在发消息上，但消息没有换来协调。

这份分类里有个值得单独点破的模式：占比最大的两类症状，都出自「并行动手、互相看不见」的工作方式。工作重叠是两边各自把同一件事做了一遍；架构分歧是两边的设计互不兼容，论文的定义到此为止，「双方在看不到对方成品的情况下各自拍板」是我对成因的推断。顺着这个推断，我怀疑真正致命的变量是并发写入，不是人数本身。但得说明白：论文没有设「两个 agent 串行」的对照组，从现有数据里分不清罪魁是「多了一个人」还是「两个人同时动手」，这只能算待检验的假说。solo 设定能提供一点旁证但不算实锤：论文只说同一个 agent 领了两个功能，没规定先后次序，不过单个 agent 每写一行都看得见自己之前的全部改动，冲突随写随消解，积累不起来。

顺着这个思路自然会问：让两个 agent 串行接力（A 做完，B 在 A 的结果上继续）是不是就能把成功率拉回来？论文没有测这个设定，我只能按机制推演：串行能直接消掉工作重叠，也能大幅缓解架构分歧，因为 B 动手前能看到 A 的全部成品代码；剩下的损耗在交接处，B 拿到的只是代码，不是 A 的设计意图和没写进代码的假设。代价也明显：串行放弃了并行提速，而「更快」正是多 agent 编排的核心卖点。如果并发确实是主因，这个诅咒更准确的名字是并发写共享状态的诅咒。

机制：空间协调救得了，语义协调救不了

论文把协作拆成两层，这个拆法是全文最有解释力的部分。

空间协调解决「谁改哪儿」：只要说清楚文件和行号，两边就不会撞车。这一层消息通道确实有用，开了通信后 Claude 和 GPT-5 的合并冲突明显减少，成功避开冲突的轨迹里 agent 提及具体行号的次数也更多（平均 32.6 次，出了冲突的轨迹只有 22.5 次）。

语义协调解决「改出来的东西合不合得上」：两边实现要共享同一套设计决策，比如接口签名、参数含义、数据结构。冲突合并干净了，测试照样挂，因为 A 实现假设的数据格式和 B 实现产出的对不上。这层错位理论上也能靠聊天解决：只要两边在动手前把接口和数据格式的定义对齐就行。难点在于这些决策大多是隐式做出的。「我在改哪个文件哪几行」是显式信息，一句话说清；而 agent 写代码时顺手选定一种数据格式，它自己都不把这当成需要通报的「决策」，也预判不到对方会在哪个假设上和自己岔开，等合并后测试挂掉才暴露，这时两边实现都已成型。这解释了「开了通信、合并冲突减少、成功率却没动」的组合：显式的位置信息传到了，隐式的设计假设没传到。

数据还指出了时机问题：成功的 agent 规划型消息对提问型消息的比例更高（2.04 比 1.31），而在第一轮消息里就把完整计划摊开的组合，冲突率从 51.5% 降到 29.4%。有效的协调发生在动工之前；agent 的习惯却是先动手、边干边聊，等发现不兼容时双方都已经写了几十行。

为什么会这样？我的推测（论文没有从训练角度做实验，这一段没有数据支撑）：编程 agent 的强化学习训练通常以单人回报为信号，优化的是任务完成、测试通过，「承诺要兑现」「队友的预期要维护」这些量很难进入训练信号。HAI 报道里作者的说法和这个方向一致：这些模型没有被训练成「社会性地」使用语言，团队建议在训练中加入协调相关的奖励。人类工程师其实也天然协调不好，《人月神话》讲的就是加人带来的沟通成本（沟通通道数随人数平方增长）；按我自己做工程的经验，人类是靠制度把它压住的：接口先行、code review、持续集成。agent 两头都缺，既没有内化的协作习惯，也没人给它们套上制度。

单 agent 榜单的盲区

先把这项研究里的「单」和「多」说清楚，因为它和眼下常见的产品形态不是一回事。现在不少编程 agent harness 的做法是一个主 agent 把任务拆给若干 sub-agent 并行执行，最后由主 agent 收拢集成，切分和集成都有中心节点拍板，属于中心化编排（OpenAI Agents SDK 的 manager 模式、Claude Code 的 subagent 都是这一类）。CooperBench 测的多 agent 没有这个中心节点：两个 agent 完全对等，谁也不指挥谁，任务怎么切由题目预先给定，集成靠事后 git 合并，协调全凭双方互发消息。它说的 solo（也就是本文的「单 agent」）是同一个 agent 不带任何队友、独自把两个功能都做完。主 agent 编排 sub-agent 的模式介于两者之间，接近下文第二条建议说的「协调靠架构做掉」；但只要多个 sub-agent 并行写同一个代码库，语义冲突照样会出现，只是化解它的责任落到了主 agent 头上。

这项研究真正动摇的是评测的选型逻辑。SWE-bench 这类主流基准全是单 agent 独立解题（官方的任务定义就是：给定一个代码库和一个 issue，让单个模型产出修复补丁），一个模型在上面分数再高，对「部署一队 agent 共享代码库」这件事没有预测力：CooperBench 里 solo 分数的排序和结对后能力保留率的排序并不一致，MiniMax-M2 的 solo 成绩不差，结对后却掉得最狠。

而且这个坑随规模变深。论文在 46 个任务的子集上把 agent 数量从 2 个加到 4 个，成功率从 68.6% 一路掉到 46.5%、再到 30.0%。在协作能力补上之前，agent 数量不是加速器，是除数。

现在该怎么用多 agent

对正在搭 agent 工作流的人，我认为可以直接落地的判断有三条。

第一，眼下多 agent 编排真正成立的场景，是没有共享写入状态的并行：只读的代码检索、各自独立的 review、fan-out 式的分析汇总。这些不触发协作的诅咒，因为根本不需要协作。

第二，如果一定要并行写代码，协调要靠架构做掉，别指望 agent 自己聊出来。由人（或编排层）把任务按模块切分、先把接口定死、保证文件不重叠，等于把最难的语义协调在分工时就消解掉。如果连模块都切不开，退一步用串行接力（A 完工 B 再上）也比并行硬闯稳当，前提是接受它不再省时间。这和论文的建议方向一致：给承诺加验证机制、定期强制集成，本质都是给 agent 套上人类工程制度。

第三，如果 agent 之间必须沟通，逼它们在第一轮就交换完整计划。这是论文里和低冲突率关联最强的通信行为（51.5% 对 29.4%）；多提具体行号、多发规划型消息也和更少冲突相关。要留个注脚：这些都是观察性关联，不是受控实验证出的因果。

CooperBench 揭示的缺口会不会随模型能力增强自动消失？论文回答不了这个纵向问题，它能给的证据是横截面的：五个模型的 solo 能力排序和协作保留率排序对不上，说明协调不是编码能力的免费附赠。我的判断是不乐观：协作是要单独训练、单独评测的能力，而现在两者都刚起步。在那之前，最好的多 agent 架构，是让 agent 尽量不需要彼此协作的架构。

参考来源