CooperBench：为什么编程智能体还不能成为你的队友 CooperBench: Why Coding Agents Cannot be Your Teammates Yet
首个协作编程基准揭示AI智能体存在'协调诅咒'，协作比单干成功率低30%
前置知识
多智能体协作 (Multi-Agent Cooperation)
多智能体协作是指两个或多个AI智能体在共享目标下协同工作的场景。在软件开发中，多个开发者需要在同一个代码库上并行开发不同功能，这要求他们理解彼此的目标、计划和预期，以避免代码冲突。与单智能体任务不同，协作场景需要智能体具备'社交智能'——即理解他人意图、有效沟通和协调行动的能力。本文研究的核心问题是：当前的AI编程智能体是否具备这种协作能力。
理解多智能体协作的概念是理解本文研究问题的基础。本文发现，与人类团队中'加入队友通常提高生产力'不同，AI智能体的协作反而导致成功率下降约30%，这一现象被称为'协调诅咒'。
代码冲突与合并 (Code Conflict and Merge)
当多个开发者同时修改同一代码库的不同部分时，他们的修改可能在合并（git merge）时产生冲突。代码冲突分为两类：结构冲突（同一行代码被不同方式修改）和语义冲突（代码合并后逻辑不兼容）。本文的评估管道使用 git merge-file 工具检查补丁兼容性，并用单元测试验证合并后代码的正确性。为处理格式差异（如缩进风格）导致的虚假冲突，作者训练了一个小模型（Qwen 3 Coder 1.5B）来解决琐碎的合并冲突。
代码冲突是本文评估协作效果的核心机制。理解冲突的类型和解决方式有助于理解为什么'空间协调'（谁编辑哪几行）和'语义协调'（实现是否兼容）是两个不同层面的问题。
部分可观测性 (Partial Observability)
在本文的实验设置中，两个智能体在独立的虚拟机环境中工作，无法直接查看对方的代码编辑。每个智能体只能通过自然语言通信工具了解对方的计划和进展。这种'部分可观测性'意味着智能体必须基于不完整信息做出决策，需要建模对方的状态、计划和意图。这与完全可观测环境（如共享屏幕）形成对比，是协作失败的根本原因之一。
部分可观测性是理解'信任悖论'的关键：智能体被训练为谨慎、需要证据验证，但协作环境要求它们信任无法直接验证的对方声明。这种矛盾导致智能体即使收到明确信息也无法更新对伙伴状态的建模。
心智理论 (Theory of Mind)
心智理论是指理解他人信念、意图和知识状态的能力。在协作编程中，这意味着智能体需要推断'对方知道什么'、'对方计划做什么'以及'对方期望我做什么'。本文发现，当前智能体在这方面存在严重缺陷：42%的协作失败源于'预期失败'（一个智能体明确沟通了自己的计划，但另一个智能体仍然假设对方没有在做那项工作），32%源于'承诺失败'（智能体承诺做某事但实际没有做到）。
心智理论是实现有效协作的核心能力。本文的发现表明，即使智能体能够'说话'（发送消息），它们也缺乏理解消息含义并据此更新自己行为的能力，这是当前AI系统与人类协作能力的根本差距。
Solo-Coop 差距 (Solo-Coop Gap)
本文定义的核心指标，衡量同一工作量下'单干'（一个智能体完成两个任务）与'协作'（两个智能体各完成一个任务）的成功率差异。如果两个智能体的协作是有效的，协作成功率应不低于单干。但本文发现，所有测试模型的协作成功率都显著低于单干，GPT-5和Claude Sonnet 4.5的差距高达约50%，这被称为'协调诅咒'。
Solo-Coop差距是本文最重要的实验发现，直接证明了当前AI智能体缺乏有效的协作能力。这个指标为未来的多智能体系统研究提供了一个清晰的评估基准。
研究动机
现代AI智能体在单智能体任务上表现出色，如SWE-bench等基准测试所示，但在多智能体协作场景中的表现尚未得到系统评估。现有研究通过提供额外脚手架、强制严格工作流或主动监督来管理协调，这些方法限制了灵活的协作并增加了人类负担。更关键的是，这些方法掩盖了而非解决了底层的协调问题。在人类社会中，团队协作通常提高生产力——'三个臭皮匠赛过诸葛亮'。但本文假设AI智能体存在相反的问题：两个智能体协作反而比一个智能体单干表现更差。目前缺乏一个专门为评估自由形式协作编程能力设计的基准测试，现有基准要么强制轮流发言，要么假设完全可观测性，无法测试真实软件开发中的部分可观测协作场景。
本文的目标是本文的具体目标是：(1) 设计并构建CooperBench，一个包含652个协作编程任务的基准测试，覆盖12个开源库、4种编程语言（Python、TypeScript、Go、Rust）；(2) 系统评估当前最先进的编程智能体在协作场景中的表现，量化'协调诅咒'的程度；(3) 深入分析协作失败的原因，识别关键的协调能力缺陷；(4) 发现成功协作中的涌现行为模式，为未来的多智能体训练提供方向。通过这些目标，作者希望推动研究从追求单智能体能力转向开发'社交智能'——理解他人、有效沟通和协调行动的能力。
与已有工作不同的是，本文的独特切入角度在于三个关键创新：第一，将协作编程问题从'如何让AI写好代码'转变为'如何让AI学会与他人合作写代码'，这是一个根本性的视角转换。第二，通过工作空间隔离和部分可观测性设计，模拟真实软件开发中的并行开发场景，而非依赖结构化交互或完全可观测环境。第三，不仅评估协作结果（成功/失败），还深入分析协作过程中的通信模式、承诺履行和预期建模，识别出三个关键能力缺陷：预期失败（42%）、承诺失败（32%）和通信失败（26%）。这种从'结果'到'过程'再到'原因'的三层分析框架，为理解AI协作失败提供了前所未有的洞察。
核心方法
CooperBench的核心设计思想是：通过让两个智能体在独立环境中实现潜在冲突的功能，测试它们的协作能力。整体技术路线分为三个部分：基准构建、实验设置和评估管道。在基准构建方面，作者从12个真实开源仓库中提取PR（Pull Request），创建'特征池'——每个池包含多个可兼容实现但可能冲突的功能。在实验设置方面，基于OpenHands框架构建双智能体系统，使用SQL数据库实现通信工具，支持实时自然语言消息传递。在评估管道方面，先检查两个智能体生成的补丁是否可合并（结构兼容性），再运行两组单元测试验证功能正确性。这种设计确保了评估的确定性和可解释性，同时保留了自由形式协作的灵活性。
本文的核心创新点在于将'协作'从一个模糊概念转化为可验证的评估。与已有方法的本质区别体现在三个方面：第一，已有基准测试（如SWE-bench）评估单智能体能力，而CooperBench评估双智能体协作，这是第一个专门为协作编程设计的基准。第二，已有方法通过结构化交互（轮流发言、预定义角色）管理协调，而CooperBench允许自由形式通信，更接近真实协作场景。第三，已有方法假设完全可观测性或提供额外脚手架，而CooperBench通过工作空间隔离模拟部分可观测性，迫使智能体依赖通信而非直接观察来理解伙伴状态。此外，本文的'特征池'设计是一个重要创新：基于真实PR创建功能，确保任务真实可解；通过专家编写单元测试和真值解，确保评估准确性；通过控制功能间的冲突程度，系统研究协作难度的影响。
方法步骤详情
CooperBench的方法包含三个主要步骤：基准构建、实验执行和评估。基准构建分为三个阶段：阶段I（仓库与PR选择）从12个活跃维护的开源仓库中选取PR，要求仓库超过1000星且不在SWE-Bench或Multi-SWE-Bench中，每个仓库分配给熟悉其架构的作者；阶段II（特征提取与扩展）将每个PR转换为包含一个锚特征和多个合成相邻特征的特征池，由人类标注者（8位有实际软件工程背景的共同作者）编写自包含的功能描述、单元测试和真值解；阶段III（环境与可复现性）提供自动化设置脚本和容器化环境，确保确定性执行。实验执行方面，两个智能体在独立的Docker容器中工作，通过SQL数据库通信工具发送自然语言消息，每个智能体最多执行100个动作。评估方面，首先使用 git merge-file 合并两个补丁，如果合并失败则用训练的小模型（Qwen 3 Coder 1.5B）尝试解决琐碎冲突，最后在合并后的代码上运行两组单元测试，两个功能的测试都通过才算成功。
技术新颖性
CooperBench的技术新颖性体现在多个层面。首先，它是第一个专门为评估AI智能体协作编程能力设计的基准测试，填补了该领域的空白。其次，'特征池'设计方法新颖：基于真实PR创建功能池，确保功能可兼容实现（通过构建联合真值解验证）但存在潜在冲突（77.3%的任务有冲突的真值解），这种设计既保证了任务的真实性，又实现了冲突的可控性。第三，评估管道的创新在于将'结构兼容性'（代码能否合并）和'语义兼容性'（功能是否正确）分开评估，这种分层评估能够区分'避免重叠编辑'和'实现兼容功能'两个不同层面的协调挑战。第四，通信工具的设计支持异步执行和实时通信的结合，每个智能体可以随时发送消息，消息会立即进入对方的下一步提示，这种设置既提高了灵活性又增加了协调挑战。第五，对失败模式的系统分类（表1的10种症状和表2的3种根本原因）为理解AI协作失败提供了理论框架。
实验结果
本文的核心发现是'协调诅咒'：所有测试的5个模型在协作设置下的成功率都显著低于单干设置。GPT-5和Claude Sonnet 4.5在双智能体协作中仅达到25%的成功率，比单干设置低约50%。MiniMax-M2表现类似。Qwen模型的差距较小，但其单干成绩本身就很低。这一发现表明，增加队友不仅没有提高AI智能体的生产力，反而大幅降低了表现，与人类团队的经验完全相反。在通信分析方面，通信工具的使用并未提高协作成功率（有通信和无通信的差异在统计上不显著），但确实显著减少了合并冲突（Claude 4.5 Sonnet、GPT-5、MiniMax-M2和Qwen Instruct均受益）。这表明通信解决了'空间协调'问题（谁编辑哪几行），但未能解决'语义协调'问题（实现是否兼容）。成功轨迹的通信模式有三个特征：(1) 更多计划、更少提问（Plan:Question比例为2.04 vs 1.31）；(2) 第一轮计划最强预测因子（将冲突率从51.5%降至29.4%）；(3) 具体性很重要（成功轨迹有32.6次行号提及 vs 22.5次）。在失败分析中，通过手动审查50条失败轨迹，识别出三个根本原因：预期失败（42%，一个智能体明确沟通了计划，但另一个仍假设对方没有在做那项工作）、承诺失败（32%，智能体承诺做某事但实际没有做到）和通信失败（26%，无法建立共享上下文）。在涌现行为方面，尽管罕见，但在成功轨迹中观察到三种协调模式：角色分工（智能体同意谁负责哪部分任务）、资源划分（通过行级边界划分编辑范围）和谈判（提出互斥选项让对方选择）。在扩展性方面，增加协作智能体数量导致成功率单调下降：2个智能体68.6% → 3个智能体46.5% → 4个智能体30.0%。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 双智能体协作编程（CooperBench全数据集） | 成功率（Success Rate） | GPT-5: 25%, Claude Sonnet 4.5: 25%, MiniMax-M2: ~26%, Qwen3-Coder: ~14%, Qwen3-30B: ~5% | 单干设置（Solo）：GPT-5: ~48%, Claude Sonnet 4.5: ~47%, MiniMax-M2: ~36%, Qwen3-Coder: ~28%, Qwen3-30B: ~6% | 所有模型的协作成功率均低于单干，差距高达50%（GPT-5和Claude 4.5 Sonnet） |
| 通信对协作成功率的影响 | 协作成功率（有通信 vs 无通信） | 有通信设置下的成功率 | 无通信设置下的成功率 | 差异在统计上不显著，表明通信未能提高协作成功率 |
| 通信对合并冲突率的影响 | 合并冲突率（Conflict Rate） | 有通信：显著降低冲突率 | 无通信：较高冲突率 | Claude 4.5 Sonnet、GPT-5、MiniMax-M2和Qwen Instruct的冲突率均显著降低 |
| 扩展协作智能体数量 | 成功率 | 2个智能体: 68.6%, 3个智能体: 46.5%, 4个智能体: 30.0% | 2个智能体基线 | 增加智能体数量导致成功率单调下降，验证了'协调诅咒'的扩展性 |
局限与改进
本文存在几个重要局限性。首先，评估范围有限：仅测试了5个模型（GPT-5、Claude 4.5 Sonnet、MiniMax-M2、Qwen3-Coder-30B-A3B-Instruct、Qwen3-30B-A3B-Instruct-2507），且实验在46个任务的小规模扩展实验中仅使用了3个任务集。其次，通信工具设计单一：仅支持文本消息，未探索GUI共享、屏幕共享或其他模态的通信方式，这可能限制了智能体的协调能力。第三，动作数量限制为100个，虽然作者提到提高此数字未观察到性能提升，但这可能对复杂任务的评估造成影响。第四，真值解的构建依赖人类专家，虽然确保了质量，但可能引入主观性；且特征池的扩展（从锚特征到相邻特征）使用LLM辅助，可能存在质量不一致。第五，失败分析主要依赖GPT-5作为LLM-as-Judge进行分类，虽然有精度优先的分类法，但仍可能引入评判偏差。第六，未探索不同的智能体框架或通信增强方法，作者明确表示这是未来研究方向，但这也意味着当前结果可能低估了协作的潜力。最后，4种编程语言和12个仓库的覆盖范围可能无法完全代表真实软件开发的多样性。
独立分析的弱点
本文的弱点主要体现在以下几个方面：第一，通信效率问题：智能体花费高达20%的动作在通信上，但通信并未提高成功率，这表明当前的通信机制设计可能存在根本问题。改进方向包括：开发更高效的通信协议，减少冗余消息（如重复的状态更新），引入结构化的通信格式（如明确的'计划'、'状态'、'问题'模板），以及基于上下文的智能通信调度（避免在关键编辑阶段发送消息）。第二，信任机制缺失：'信任悖论'表明智能体被训练为谨慎验证，但协作需要信任无法直接验证的声明。改进方向包括：引入可验证的承诺机制（如代码签名、明确的插入点合同、集成检查），开发专门的信任建模模块，以及通过强化学习让智能体学会在适当情况下信任伙伴。第三，语义协调不足：通信解决了空间协调（避免重叠编辑），但未能解决语义协调（实现是否兼容）。改进方向包括：引入共享的'接口规格'，在编辑前协商参数值和返回类型，以及开发跨分支集成推理能力。第四，评估维度单一：仅评估最终结果（成功/失败），未量化协作过程的质量（如通信效率、协调准确性）。改进方向包括：引入过程质量指标，如'通信信噪比'、'承诺履行率'、'预期准确性'等。第五，可扩展性问题：增加智能体数量导致成功率单调下降，表明当前框架无法扩展到更大规模的团队协作。改进方向包括：开发层次化协调架构（如引入协调者角色）、实现角色分工协议、以及支持动态团队规模调整。
未来方向
作者提出了三个主要的未来研究方向：第一，训练目标：开发奖励部分可观测性下协调能力的训练目标。这包括使用多智能体训练方法（如Sotopia-π）强化成功的协作行为，通过强化学习让智能体从CooperBench的成功轨迹中学习角色分工、资源划分和谈判等涌现行为。第二，轻量级协议：开发可验证承诺的协议，如共享签名、插入点合同和集成检查。这些协议应将对话转化为可验证的共享状态，减少对信任的依赖。第三，丰富通信通道：扩展通信模态，如屏幕共享、代码审查界面、共享编辑器视图等，以增加通信带宽、减少通信噪声。基于本文成果可延伸的研究方向包括：(1) 将CooperBench应用于人机协作场景，研究AI智能体如何与人类开发者协作；(2) 开发专门的协调能力训练数据集，通过大规模模拟生成多样化的协作场景；(3) 研究不同编程范式（如函数式编程、面向对象编程）对协作难度的影响；(4) 探索动态冲突检测和解决机制，在编辑过程中实时识别潜在冲突；(5) 开发跨语言、跨框架的通用协调协议，使不同背景的智能体能够有效协作。此外，作者特别鼓励研究人员开发新型框架或训练方法，以在CooperBench上实现更高的Coop分数或缩小Solo-Coop差距。
复现评估
本文在可复现性方面做得较好。作者开源了完整的框架代码，包括通信工具、评估管道和任务数据。每个任务集都包含自动化设置脚本，能够克隆仓库到精确的基础提交、安装依赖并运行完整测试套件。此外，提供了容器化环境（Docker）封装完整的仓库状态和所有运行时依赖，确保在不同硬件和操作系统上的一致行为。数据方面，652个任务覆盖12个仓库、4种编程语言、34个特征池，每个特征池有2-12个功能。算力需求方面，评估使用云虚拟机确保隔离工作空间和充足资源，每个智能体最多执行100个动作。复现的主要挑战包括：(1) 需要访问GPT-5、Claude 4.5 Sonnet、MiniMax-M2等闭源模型的API；(2) 两个Qwen模型通过vLLM服务，需要相应的GPU资源；(3) 完整的评估需要运行652个任务，每个任务需要两个智能体并行执行，计算成本较高。作者提供了95%Wilson置信区间用于统计评估，并在附录中报告了详细的实验设置和消融研究。总体而言，本文的可复现性较高，为后续研究提供了坚实的基础。
论文图表
