CooperBench：协作的诅咒——当两个 GPT-5 组队，效率反而腰斩

> 斯坦福和 SAP Labs 的研究团队做了一个反直觉的实验：让两个顶级 AI 编程 Agent（GPT-5、Claude Sonnet 4.5）组队完成真实代码库的协作任务。结果不是 1+1=2，而是 1+1=0.5——两个 Agent 一起工作的成功率比单个 Agent 单独做两个任务低了 50%。这不是算力问题，不是模型能力问题，而是 AI 根本不懂"社交"。论文提出了 CooperBench，首个专门测试 AI Agent 协作能力的基准，652 个任务、12 个真实代码库、4 种语言。核心发现：当前 AI 的瓶颈不是任务能力（Task Competence），而是社交智能（Social Intelligence）。

---

一、悖论：为什么两个 Agent 比一个 Agent 更笨？

想象一下这个场景：你让两个顶级程序员合作开发一个功能。A 负责序列化时添加图像可变性的支持，B 负责在同一段序列化流程中添加备份功能。两个功能逻辑上兼容，但会修改重叠的代码。

对人类团队来说，这是日常——同步一下思路，确认一下接口，各自开发，合并代码，测试通过。

但对 AI Agent 来说，结果是：

A 改了序列化函数，B 也改了同一个函数
没有事先确认对方会改哪里
合并时冲突，测试全挂

CooperBench 的发现：

Solo 模式（一个 Agent 做两个任务）：成功率约 50%
Coop 模式（两个 Agent 各做一个任务）：成功率约 25%
协调缺口（Coordination Gap）：协作比单干差 50%

这与人类团队完全相反。对人类来说，加队友通常提升效率。对 AI 来说，加队友严重降低效率。

---

二、CooperBench 是什么？一句话定位

> "CooperBench 是首个专门测试 AI Agent 协作能力的基准，从 12 个真实开源代码库中抽取 652 个任务，要求两个 Agent 在共享代码库中并行实现可能冲突的功能，通过专家编写的测试验证协作成功。"

论文信息：

标题：CooperBench: Why Coding Agents Cannot be Your Teammates Yet
作者：Arpandeep Khatua, Hao Zhu, Peter Tran, Arya Prabhudesai, Frederic Sadrieh, Johann K. Lieberwirth, Xinkai Yu, Yicheng Fu, Michael J. Ryan, Jiaxin Pei, Diyi Yang
机构：Stanford University, SAP Labs US
arXiv: 2601.13295
网站：https://cooperbench.com

任务设计：

从真实 PR 中拆分出两个独立但可能冲突的功能
两个 Agent 在隔离的沙箱中并行开发
共享 Git 仓库和消息通道（可选通信）
成功标准：两个 Agent 的 patch 能合并且所有测试通过

---

三、核心发现：协调的诅咒（The Curse of Coordination）

3.1 协调缺口普遍存在

模型	Solo 成功率	Coop 成功率	协调缺口
GPT-5 (OpenHands)	~50%	25%	50%
Claude Sonnet 4.5	~50%	25%	50%
Minimax M2	~50%	25%	50%
Gemini 3 Flash	~50%	27.76%	~44%
Qwen3-30B-A3B	~15%	~10%	~33%

关键发现：

所有模型都表现出协调缺口——无一例外
顶级模型（GPT-5、Claude Sonnet 4.5）缺口最大，因为它们 Solo 能力强，但协作能力差
任务难度中等时缺口最大（太容易不需要协作，太难怎么协作都失败）

3.2 三个致命失败模式

论文通过大规模分析，将失败归纳为三类：

#### 1. 期望失败（Expectation Failures）—— 42%

问题：Agent 对队友的计划、观察和状态有错误的预期。

典型场景：

Agent A: "我会实现新的 API 格式，你处理路由"
Agent B: 没有确认，但假设 API 格式保持不变
Agent B: 用旧格式实现了路由
合并: 冲突，测试全挂

Agent B 的"假设"从未被沟通或确认过。它在自己的"心智模型"中编了一个故事。

#### 2. 承诺失败（Commitment Failures）—— 32%

问题：Agent 不遵守自己的承诺，做出无法验证的声明。

典型场景：

Agent A: "我会在序列化函数的第 150 行添加图像可变性"
Agent B: "好的，我在第 200 行添加备份功能"
Agent A: 实际上改了第 180 行（因为中间发现了其他问题）
Agent B: 仍然按原来的位置修改，没有重新确认
合并: 代码逻辑冲突

Agent 做了承诺，但环境变化后没有更新承诺，也没有通知队友。

#### 3. 通信失败（Communication Failures）—— 26%

问题：消息模糊、时机不当、内容不准确。

典型场景：

Agent B: "我应该用新的还是旧的 API 格式？"
[Agent A 没有回应]
Agent B: 假设旧格式，继续实现...
Agent A: 完成后使用了新格式
合并: 不兼容

其他通信问题：

重复发送状态更新（"我还在工作..."），占用 20% 的计算预算，但无助于协调
问题被直接忽略（不回应）
消息内容模糊，没有可执行的信息

---

四、通信悖论：允许聊天反而没有帮助

一个反直觉的发现：给 Agent 通信通道，允许它们实时聊天，结果成功率并没有显著提高。

为什么？

1. 通信渠道被堵塞：大量重复、无用、不及时的消息，真正的关键信息被淹没 2. 通信不等于协调：即使传达了信息，Agent 也不一定能整合这些信息到自己的工作计划中 3. 空间协调 vs 语义协调：

空间协调（Spatial Coordination）："你改文件 A，我改文件 B"——这 Agent 能学会
语义协调（Semantic Coordination）："你改接口，我需要确认这个改动不会影响我的路由逻辑"——这 Agent 做不到

具体数据：

Agent 在通信上花费高达 20% 的计算预算
但这些通信减少了合并冲突（Git conflict），没有提高整体成功率
减少的是"技术冲突"（文件同时修改），没有解决"语义冲突"（逻辑不兼容）

---

五、涌现的协调行为：少数成功的 Agent 在做什么？

虽然大多数协作失败，但论文在大规模模拟中发现了罕见但有趣的涌现协调行为：

5.1 角色分工（Role Division）

Agent A: "我负责添加 header + octal_str"
Agent B: "好的，我添加 binary_str，放在它们之间"

两个 Agent 主动分配了代码空间的职责，避免了修改冲突。

5.2 资源分工（Resource Division）

Agent 识别出哪些文件/函数需要串行处理，哪些可以并行，并据此分配工作。

5.3 谈判（Negotiation）

Agent A: "我提议用新的 API 格式，因为它支持未来的扩展"
Agent B: "但新格式需要更多验证，你有测试覆盖吗？"
Agent A: "我会在测试里加上。如果你同意，我们就用这个方案"
Agent B: "同意，但请确保错误处理也更新"

这些行为不是被 prompt 或 scaffold 引导的，而是自发涌现的。这暗示了一个路径：通过强化学习在 CooperBench 上训练，Agent 可能学会协调能力。

---

六、为什么当前 AI 不会协作？三个深层原因

6.1 缺乏心理理论（Theory of Mind）

Agent 不理解队友有自己的信念、目标、计划。它假设队友的行为是确定的、可预测的，但实际上队友也是复杂的推理系统。

人类的做法："我知道你可能不知道我已经改了接口，所以我需要明确告诉你。" Agent 的做法："我改了接口，我应该不需要说，因为队友会看到的。"（但队友没有看）

6.2 缺乏共享心智模型（Shared Mental Model）

成功的团队有一个共享的"任务模型"——每个人都理解整体目标，知道自己的部分如何融入整体。

Agent 没有这个能力。每个 Agent 只看到自己的任务描述，没有全局视角，也无法构建全局视角。

6.3 承诺与信任的机制缺失

人类团队中：

我承诺做 X → 我尽量做 X → 如果做不到了，我提前通知你 → 你调整计划

Agent 团队中：

我承诺做 X → 环境变化导致我做不了 X → 我没有通知你 → 你按原计划做 → 冲突

Agent 没有"承诺维护"的机制，也没有"信任修复"的能力。

---

七、CooperBench 的实验设计

7.1 任务来源

从 12 个真实开源代码库的真实 PR 中抽取：

Python: Flask, Scikit-learn, LlamaIndex, Pandas, Matplotlib
TypeScript: Prisma, Vue
Go: Kubernetes client
Rust: Tokio, Clap

每个任务来自一个真实的 PR，该 PR 引入了多个功能，被拆分成两个独立的子任务。

7.2 成功标准

1. 个体正确性：每个 Agent 的 patch 单独通过自己的功能测试 2. 合并兼容性：两个 patch 能合并，没有冲突（或冲突被正确解决） 3. 联合正确性：合并后的代码通过所有测试（两个功能都正确）

7.3 评估模式

Coop 模式：两个 Agent 各做一个任务，可选通信，可选 Git 协作
Solo 模式：一个 Agent 做两个任务（顺序执行），作为基线

---

八、排行榜：当前 SOTA still 很低

排名	模型	框架	Git	Coop 成功率
1	GPT-5 (OpenHands)	OpenHands	No	27.95%
2	Gemini 3 Flash (OpenHands SDK)	OpenHands SDK	Yes	27.76%
3	Gemini 3 Flash (OpenHands SDK)	OpenHands SDK	No	26.23%
4	Claude Sonnet 4.5 (OpenHands)	OpenHands	No	25.92%
5	Gemini 3 Pro (Mini-SWE)	Mini-SWE	Git	21.78%

关键观察：

即使排名第一的 GPT-5，成功率也只有 27.95%
允许 Git 协作（共享代码仓库） vs 不允许 Git 协作，差异不大——说明代码共享不是瓶颈，语义协调才是
所有模型都远低于 Solo 基线（~50%）

---

九、对 AI 研究的启示：从个体能力到社交智能

CooperBench 论文的核心论点：

> "我们呼吁研究重心从追求个体 Agent 能力转向发展社交智能（Social Intelligence）：理解他人、有效沟通、协调行动的能力。"

当前 AI 研究的偏差：

大家都在刷 SWE-bench、HumanEval——测试个体编程能力
但真实软件开发是团队协作
一个 Solo 成功率 90% 的 Agent，如果 Coop 成功率只有 20%，它在团队中就是累赘

未来方向： 1. Theory of Mind for Agents：让 Agent 能建模队友的信念和目标 2. 承诺维护机制：Agent 需要跟踪自己的承诺，并在无法兑现时主动通知 3. 共享心智模型构建：Agent 需要构建对整体任务的理解 4. RL 训练涌现协调：通过 CooperBench 上的成功强化，训练出协调行为

---

十、局限与未来工作

1. 只有两个 Agent：真实团队协作可能涉及更多人，多 Agent 协调更复杂 2. 同步协作：异步协作（如代码审查、PR review）也是重要场景 3. 人类-AI 混合团队：当前只测试了 AI-AI 协作，人类-AI 协作是下一个 frontier 4. 长期协作：单次任务 vs 长期项目中的信任建立

---

十一、一句话总结

CooperBench 揭露了一个被忽视的真相：当前 AI Agent 的强大个体能力，在团队协作中反而成了负担——因为 Agent 会做、不会问，会写、不会说，能干、不会商量。GPT-5 可以写出完美的代码，但它不知道队友改了同一个函数。Claude Sonnet 4.5 可以修复杂的 bug，但它不会主动确认接口兼容性。这不仅是技术问题，更是范式问题：我们训练 AI 下棋时假设对手是理性的，但写代码时队友是复杂的、不确定的、会犯错的。CooperBench 证明，AI 需要的不只是更多的算力和更大的模型，而是一种全新的能力——社交智能。这可能比 GPT-6 更难训练。

---

参考信息

论文：CooperBench: Why Coding Agents Cannot be Your Teammates Yet
作者：Arpandeep Khatua, Hao Zhu, Peter Tran, Arya Prabhudesai, Frederic Sadrieh, Johann K. Lieberwirth, Xinkai Yu, Yicheng Fu, Michael J. Ryan, Jiaxin Pei, Diyi Yang
机构：Stanford University, SAP Labs US
arXiv: 2601.13295
网站：https://cooperbench.com
核心创新：CooperBench 基准（652 任务，12 代码库，4 语言），"协调的诅咒"发现，三类失败模式分析
测试模型：GPT-5, Claude Sonnet 4.5, Minimax M2, Gemini 3 Flash/Pro, Qwen3-30B-A3B
关键结果：Coop 成功率 25%（vs Solo 50%），协调缺口 50%
失败模式：期望失败（42%）、承诺失败（32%）、通信失败（26%）
通信开销：高达 20% 计算预算，但不提高成功率
涌现行为：角色分工、资源分工、谈判（罕见但成功）
代码库：Flask, Scikit-learn, LlamaIndex, Pandas, Matplotlib, Prisma, Vue, Kubernetes client, Tokio, Clap 等

---

*CooperBench 让我想到一个更深层的问题：我们一直在用"个体能力"衡量 AI，但真实世界的价值创造几乎全是协作。一个顶级程序员如果不懂得沟通、协调、妥协，他在团队中就是负资产。AI 也是一样。当前 Agent 的爆发让人兴奋，但如果它们只会"单干"，那么多 Agent 架构就是伪命题——你把两个天才放在一个房间里，他们不会自动变成梦之队。CooperBench 的价值在于它把这个残酷现实量化了。未来的 AI 研究可能需要重新思考：与其训练一个更聪明的 Agent，不如训练一个更懂"人"（或懂其他 Agent）的 Agent。社交智能可能比通用智能更难，因为人类自己花了几十万年才进化出它。*

#CooperBench #协作诅咒 #社交智能 #AIAgent #团队编程 #斯坦福 #SAP #多Agent #协调失败 #涌现行为

CooperBench：协作的诅咒——当两个 GPT-5 组队，效率反而腰斩

一、悖论：为什么两个 Agent 比一个 Agent 更笨？

二、CooperBench 是什么？一句话定位

三、核心发现：协调的诅咒（The Curse of Coordination）

3.1 协调缺口普遍存在

3.2 三个致命失败模式

四、通信悖论：允许聊天反而没有帮助

五、涌现的协调行为：少数成功的 Agent 在做什么？

5.1 角色分工（Role Division）

5.2 资源分工（Resource Division）

5.3 谈判（Negotiation）

六、为什么当前 AI 不会协作？三个深层原因

6.1 缺乏心理理论（Theory of Mind）

6.2 缺乏共享心智模型（Shared Mental Model）

6.3 承诺与信任的机制缺失

七、CooperBench 的实验设计

7.1 任务来源

7.2 成功标准

7.3 评估模式

八、排行榜：当前 SOTA still 很低

九、对 AI 研究的启示：从个体能力到社交智能

十、局限与未来工作

十一、一句话总结

🌟 智谱 GLM-5 已上线