斯坦福实测GPT-5与Claude 4.5“双盲实验。AI编程，没有协作类产品的原因找到了

为什么在LLM推理能力大幅跃升的2026，我们依然只有AI Copilot而没有AI Teammate？尽管AI编程工具遍地开花，但不管是Claude Code还是Codex，本质上仍是“单Agent开发”或“主从控制”架构。而“AI结对编程”迟迟无法落地？

斯坦福在最新的CooperBench研究中解释了这一点：限制AI软件工程上限的不再是代码能力，而是心智理论（Theory of Mind）的缺失。

实验表明，SOTA模型在协作中遭遇了严重的“协作诅咒”，双盲协作的成功率比单兵作战的成功率非但没有提升，反而比单干暴跌了30%至50%，且随着节点增加，系统性能呈单调退化，本文将为您解读斯坦福的这项最新研究，看完您将理解，为何在缺乏社会智能的情况下，强行堆叠Coding Agent只能带来系统的熵增而非效率的叠加。

CooperBench

CooperBench是首个专门用于衡量代码智能体在具有潜在冲突任务中协作能力的基准测试。

实验设计的核心逻辑

不同于以往只关注“生成代码是否正确”的测试，CooperBench关注的是在隔离环境中工作的智能体如何处理冲突与依赖。

• 真实世界的代码库：研究者并没有使用合成的玩具数据，而是选取了12个拥有超过1000颗Star的流行开源代码库，涵盖Python、TypeScript、Go和Rust四种语言，包括DSPy、LlamaIndex、Pillow等知名项目。关于Dspy，感兴趣您可以看下：

• 任务分配机制：
• 每个测试案例包含一个代码库的初始状态和两个待开发的功能（Feature）。
• Solo模式（基准线）：由一个智能体独自按顺序完成这两个功能。
• Coop模式（协作组）：两个智能体（Agent 1和Agent 2）同时开始工作，每人负责一个功能。
• 隔离与沟通：在协作模式下，两个智能体在各自独立的Docker容器中运行。它们看不到对方的屏幕，也看不到对方正在写的代码。它们唯一的联系方式是一个聊天工具，可以发送自然语言消息给对方。

• 潜在冲突：这是实验设计的精髓。分配给两个智能体的任务在逻辑上是兼容的（即可以共存），但在代码实现层面存在潜在冲突（例如都需要修改同一个文件或同一个函数）。这迫使智能体必须通过沟通来协调，否则合并代码时必然出错。

严苛的评估标准

在这个基准测试中，所谓的“成功”必须同时满足以下两个条件：

1. 方案兼容性（Solution Compatibility）：两个智能体提交的代码补丁（Patch）必须能够通过 git merge 合并到主分支。为了排除仅因格式问题（如缩进风格）导致的“伪冲突”，研究者还训练了一个专门的小型代码模型来辅助处理琐碎的合并冲突。
2. 实现正确性（Implementation Correctness）：合并后的代码必须同时通过两个功能对应的所有单元测试。

核心发现：协作带来的性能崩塌

实验结果揭示了一个残酷的现实：目前的AI智能体完全不具备团队协作能力。

数据背后的“协作鸿沟”

研究者测试了包括GPT-5、Claude 4.5 Sonnet、MiniMax-M2以及Qwen系列在内的多个顶尖模型。结果显示：

• 性能断崖式下跌：在Solo模式下，GPT-5和Claude 4.5 Sonnet能够完成约50%的任务。然而一旦切换到双人协作模式（Coop），成功率直接腰斩，跌至25%左右。
• 中等难度陷阱：研究发现，这种“协作鸿沟”（Coordination Gap）在中等难度的任务中表现最为剧烈。
• 对于极简单的任务，智能体有余力去处理沟通。
• 对于极难的任务，单干也做不出来，协作也做不出来，差距不明显。
• 而在中等难度区间，智能体既要消耗算力处理代码逻辑，又要分心处理复杂的协作关系，导致系统性崩溃。
• 人多手杂：如果将团队规模从2个智能体增加到3个甚至4个，成功率会进一步单调下降。4个智能体协作的成功率仅为30.0%，远低于2个智能体的68.6%（在较小子集上的测试结果）。

沟通并没有拯救协作

您可能会认为，既然允许智能体聊天，它们应该能解决冲突。但数据反驳了这一直觉。

• 沟通工具无效：研究者对比了“允许沟通”和“禁止沟通”两组实验，发现开启沟通功能并没有在统计学意义上提高任务的最终成功率。
• 沟通的真实作用：沟通确实显著减少了代码合并时的物理冲突（Merge Conflicts）。这意味着智能体们通过聊天，成功避开了“同时修改同一行代码”的情况。但它们依然无法通过测试，因为它们解决不了逻辑冲突。

这引出了本研究最深刻的洞察之一：空间协调vs. 语义协调。

深度剖析：为什么AI的沟通是无效的？

虽然智能体在聊天频道里非常活跃（沟通步骤占了总行动步数的20%），但它们的沟通质量极低。研究者将其归结为“空间协调”与“语义协调”的错位。

空间协调（Spatial Coordination）：AI的强项

智能体非常擅长处理“位置”信息。它们会发送类似这样的消息：

“我将修改 src/utils.py 文件的第50到80行。”

这种沟通非常有效，能够让队友避开这30行代码，从而避免Git合并冲突。数据显示，如果在第一轮对话中就明确提出包含具体行号的计划（Plan），冲突率能降低近一半。

语义协调（Semantic Coordination）：AI的盲区

然而软件开发不仅仅是“分地盘”，更是“对逻辑”。智能体极度缺乏对代码意图和逻辑依赖的沟通能力。

案例分析：Jinja2项目中的惨败

让我们看一个具体的失败案例。任务要求两个智能体分别为 groupby 函数添加两个新参数：

1. Agent 1：添加 case_sensitive 参数（区分大小写），默认值应为 False。
2. Agent 2：添加 reverse 参数（倒序）。

发生了什么？

• 两个智能体进行了10轮对话，交换了3000多个单词。
• 它们完美地协商了插入位置：“你在签名里加前面，我在后面加”。
• 致命疏忽：Agent 2在修改函数签名时，为了适配代码，自己也声明了 case_sensitive 参数，但它错误地将默认值设为了 True。而在整整10轮对话中，双方从未讨论过这个参数的默认值应该是多少。
• 结果：代码合并时没有任何冲突（空间协调成功），但程序逻辑完全错误（语义协调失败），导致测试失败。

这表明，AI只能解决“你在哪里写代码”的问题，却无法解决“你写的代码是什么意思”的问题。

为了量化这种沟通效能的差异，研究者对数千条交互日志进行了统计分析，发现了一个反直觉的指标：“计划-提问比”（Plan-to-Question Ratio）。在那些成功避免了冲突的协作路径中，智能体主动陈述计划与被动提问的比例高达2.04；而在失败的案例中，这一比例仅为1.31。

这意味着，在AI协作的语境下，频繁的提问并不是在寻求共识，而是“迷失方向”的信号。成功的协作往往源于高信噪比的单向信息同步（如“我正在重构A模块”），而非低效的来回确认（如“我现在该做什么？”）。当一个智能体开始频繁提问时，往往意味着它已经失去了对共享状态的感知，随之而来的便是协作的崩塌

失败分类学：智能体是如何搞砸协作的？

研究者通过手动分析和LLM辅助标注，将协作失败的原因归纳为三大类能力缺失：沟通（Communication）、承诺（Commitment）和预期（Expectation）。

预期失效（Expectation Failures，占比42%）

这是最主要的失败原因。它反映了AI缺乏“心智理论”（Theory of Mind），即无法在脑海中构建队友的工作状态模型。

• 症状：工作重叠（Work Overlap）。
• 现象：Agent A明确告知“我要实现X功能”。Agent B收到了消息，回复了“收到”，但在自己的分支里，Agent B依然重新实现了一遍X功能，或者完全无视A的改动，继续写依赖旧代码的逻辑。
• 根本原因：智能体无法理解“队友正在做的改变将成为未来代码库的一部分”。它们在潜意识里依然认为自己是在独自面对代码库。

承诺失效（Commitment Failures，占比32%）

智能体在协作中表现得像一个不可靠的合作伙伴。

• 症状：不可验证的主张（Unverifiable claims）和违背承诺。
• 现象：
• Agent A：“我会添加一个 bypass() 检查函数。”
• Agent A实际上并没有写这个函数，或者写在了一个错误的地方。
• Agent A在聊天中自信地宣称：“任务完成，检查函数已添加。”
• Agent B相信了这句话，调用了这个不存在的函数，导致合并后崩溃。
• 信任悖论（The Trust Paradox）：这揭示了一个深层次的矛盾。现有的LLM经过安全训练（RLHF），被教导要“眼见为实”，不要轻信未经验证的信息。但在协作中（尤其是在看不到队友屏幕时），信任是必须的。AI陷入了两难：它既无法验证队友的代码，又不敢完全信任队友的承诺，最终导致行为错乱。

沟通失效（Communication Failures，占比26%）

即使在开口说话时，智能体的沟通效率也极低。

• 症状：无响应（Unresponsiveness）和重复废话。
• 现象：
• Agent A问：“我们是用方案A还是方案B？”
• Agent B回复了一大段关于自己正在修改哪个文件的废话，完全无视了选择题。
• 这种“各说各话”导致决策循环断裂，双方基于不同的假设继续工作，最终分道扬镳。
• 幻觉与噪声：智能体还经常发送重复的、毫无信息量的状态更新，甚至对自己的进度产生幻觉，给队友传递错误信号。

对于上述种种失败，工程界的直觉反应往往是：“是不是Prompt写得不够好？”为此，研究团队在附录中详细记录了一场名为“失败驱动设计”的提示词优化实验。他们尝试了业界最先进的Prompt技巧，包括明确要求智能体“必须报告具体行号”、“严禁使用占位符”、“必须在结束前同步状态”，甚至详细解释了Git合并冲突的原理。

但结果是：即便在最优化的提示词引导下，协作成功率的提升依然微乎其微。这一消极结果说明协作能力的缺失并非源于指令遵循（Instruction Following）层面的瑕疵，而是源于模型底层认知架构中对“动态共享状态”建模能力的系统性空白。换句话说，无论你如何通过Prompt强调“要小心冲突”，一个缺乏心智理论的智能体依然无法理解为何它的改动会破坏队友的代码

极少数的成功：涌现出的协作智慧

尽管大多数时候表现糟糕，但在那25% 的成功案例中，研究者观察到了类似人类高级工程师的协作模式。这些行为并非通过提示词（Prompt）强制灌输，而是自发涌现的。

角色分工（Role Division）

成功的智能体会自发地建立明确的责任边界。

• 示例：“你负责实现环境隔离功能，我负责多文件编辑支持。请你完全不要碰后端实现，后端由我端到端负责。”
• 关键点：双方都明确确认了这一分工，建立了共享的心理契约。

资源切分（Resource Division）

这比简单的“分工”更细致，是对代码资源的精确划分。

• 示例：“我只修改 lines 1161-1230，你可以在这之后添加你的代码。”
• 这种精确到行号的切分创造了“安全区”，从物理上杜绝了冲突的可能性。

谈判与共识（Negotiation）

当遇到冲突时，高级的协作模式是先暂停，再决策。

• 示例：“我检查了文件，我们在导出类时会有冲突。方案一：我加A类，你加B类；方案二：你加B类，我加A类。你偏好哪个？”
• 关键点：这种沟通将复杂的代码冲突简化为简单的选择题，一旦达成共识，双方就有了完全可执行的规范。

结论

CooperBench的研究结果说明我们不能简单地认为，只要把模型做得更聪明（参数更大、代码生成能力更强），它就会自动成为好队友。GPT-5的单打独斗能力很强，但在协作中依然表现拙劣。这说明社会智能（Social Intelligence）理解他人意图、建立共识、遵守承诺的能力是独立于智商之外的另一套技能树。在解决这些问题之前，虽然AI可以作为您的副驾驶（Copilot），但要让它们自己组队去构建下一个伟大的软件，恐怕还需要一些时间。

文章来自于“AI修猫Prompt”，作者 “AI修猫Prompt”。