TeamBench：在强制角色分离下评估智能体协同

# TeamBench：评估强制角色分离下的智能体协同

来源：https://arxiv.org/html/2605.07073
Yubin Kim${}^{1,2}$, Chanwoo Park${}^{1}$, Taehan Kim${}^{4}$, Eugene Park${}^{1}$, Samuel Schmidgall${}^{3}$, Salman Rahman${}^{2}$, Chunjong Park${}^{3}$, Cynthia Breazeal${}^{1}$, Xin Liu${}^{2}$, Hamid Palangi${}^{2}$, Hae Won Park${}^{1}$, Daniel McDuff${}^{2}$

${}^{1}$MIT ${}^{2}$Google Research ${}^{3}$Google DeepMind ${}^{4}$独立研究员

![[无标题图像]](https://arxiv.org/html/2605.07073v1/imgs/github-logo.png) GitHub (https://github.com/ybkim95/TeamBench)
![[无标题图像]](https://arxiv.org/html/2605.07073v1/imgs/hf-logo.png) 数据集 (https://huggingface.co/datasets/ybkim95/teambench)
![[无标题图像]](https://arxiv.org/html/2605.07073v1/imgs/globe-icon.jpg) 网站 (https://teambench.github.io/)

###### 摘要

智能体系统通常将任务分解到多个角色中，但这些角色通常由提示（prompt）指定，而非通过访问控制强制执行。在没有强制执行的情况下，团队的通过率可能会掩盖智能体是否真正进行了协同，或者是否有一个角色实际上代劳了其他角色的工作。我们提出了 **TeamBench**，这是一个包含 851 个任务模板和 931 个种子实例的基准测试，用于评估在操作系统强制执行的角色分离下的智能体协同能力。TeamBench 将规范访问、工作区编辑和最终认证分离到规划者（Planner）、执行者（Executor）和验证者（Verifier）角色中，使得没有任何一个角色可以同时读取完整需求、修改工作区并认证最终答案。仅凭提示和沙箱强制执行的团队达到了统计上不可区分的通过率，但仅凭提示的运行产生的案例中，验证者尝试编辑执行者代码的情况是后者的 3.6 倍。验证者批准了 49% 未能通过确定性评分器的提交，而在消融实验中移除验证者提高了平均部分分数。团队价值也是条件性的。当单个智能体表现不佳时，团队有助于提升表现，但当单个智能体已经表现良好时，团队反而会带来负面影响。在相同角色分离下进行的 40 会话人类研究表明，我们的基准测试揭示了通过率所忽略的交互模式。单独参与者直接完成任务，与智能体配对的人类参与者往往迅速批准，而人类团队则花费更多精力在不同角色间协调缺失的信息。我们的数据集、代码和实现细节可在 https://teambench.github.io/ 找到。

## 1 引言

参见图注
**图 1：TeamBench 在强制角色分离下评估智能体。** 规划者读取完整需求，执行者编辑工作区，验证者发出最终判决。沙箱限制了每个角色可以读取或写入的文件。示例显示了一种角色失败情况，即验证者接受了一个违反规划者约束的实现。

基于大语言模型（LLM）构建的智能体系统通常将任务拆分到不同角色中，并衡量相对于单个智能体的增益 [8, 26, 20, 14, 30, 11]。然而，通常不清楚这些增益是来自角色间的协同，还是来自同一个模型在单次运行中有效地承担了多个角色。一个增加验证步骤的团队需要知道，验证者是独立的质量关卡，还是仅仅另一次编辑过程。在许多基准测试中，不同的角色通过提示分配给同一个基础模型，且测试框架并不阻止该模型规划、编辑和认证同一个解决方案。最近的研究提出了关于角色崩溃（role collapse）、基准有效性和多智能体失败模式的相关问题 [1, 2, 29, 15]。SWE-Bench [10] 和 Terminal-Bench [17] 询问智能体是否能解决现实任务。**TeamBench** 询问的是，当规划者、执行者和验证者的分解产生有用协同时是怎样的，以及何时它仅增加了开销而没有真正的协同。

我们通过操作系统权限强制执行角色分离来研究这个问题。每个角色在单独的容器中运行，仅访问该角色所需的文件和工具。规划者读取完整需求但不能修改工作区。执行者可以编辑和测试工作区，但仅接收摘要简报而非完整规范。验证者在批准最终提交前审查需求和执行者的证据。没有任何角色可以同时读取完整需求、修改工作区并认证最终答案。这种设计使得协同成为必要，因为信息必须在角色间流动，团队才能完成任务。

TeamBench 包含 851 个任务模板，扩展为 931 个种子评估实例。这些任务涵盖 19 个基础类别，以及用于排行榜的 21 个细化类别。每个任务都有一个生成器，可以从种子生成确定性工作区，允许实例刷新而无需废弃基准测试。我们在分层抽样 90 个任务的子集上评估模型，并报告 TeamBench-Verified 结果。除了排行榜外，评估套件还包括规划者和验证者消融实验、27 种配置的跨提供商角色混合消融实验、仅提示与强制角色比较，以及在相同角色边界和确定性评分器下的人类研究。

实验中的几个发现包括：(i) 在角色混合消融实验中，验证者批准了 49% 未能通过确定性评分器的提交，且在参考消融实验中移除验证者提高了部分分数。(ii) 团队在 Solo 得分最低的五分位数中帮助最大，但在 Solo 已经表现良好的简单任务中带来负面影响。(iii) 仅提示和沙箱强制角色达到了统计上不可区分的通过率，而仅提示运行产生的验证者重写执行者代码的案例是后者的 3.6 倍。(iv) 在人类研究中，单独参与者直接完成任务，混合会话（参与者与智能体配对）往往迅速批准，而人类团队则花费更多精力在不同角色间协调缺失信息。

这些结果表明，相同的通过率可能掩盖不同的角色和验证行为，以及协同成本。我们的主要贡献是：

1.  **角色分离协同基准测试。** 我们引入了 TeamBench，利用操作系统权限分离规范访问、工作区编辑和最终认证。
2.  **针对角色价值的匹配消融实验。** 我们在 Solo、Restricted、Full Team、No-Plan 和 No-Evaluate 条件下运行匹配消融实验，隔离出规划、验证和缺失规范访问何时能改善性能。
3.  **验证者失败作为瓶颈。** 验证者批准了 49% 评分器判定失败的提交，且在参考消融实验中移除验证者提高了平均部分分数。
4.  **超越通过率的协同行为。** 团队价值取决于 Solo 能力，仅提示角色隐藏了更多的验证者代码编辑尝试，且我们的人类研究表明在相同角色边界下存在独特的 Solo、混合和团队交互模式。

## 2 TeamBench

TeamBench 隔离了仅提示评估中混合的三个角色。它衡量每个角色的边际贡献，将不同提供商分配给不同角色的效果，以及团队价值如何随任务难度变化。为了衡量这些效果，我们通过框架（harness）而非提示来强制执行角色边界。表 15 将 TeamBench 与现有的智能体基准测试进行了比较。

### 2.1 角色分离

每个角色在单独的容器中运行，仅拥有其所需的文件和工具。规划者接收完整需求但不能编辑或执行代码。执行者修改解决方案工作区并运行命令，但从未看到完整需求，仅看到简报。验证者读取完整需求和来自执行者的只读证据，然后发出最终的通过或失败判决。由于没有任何角色拥有全部三种权限，成功的运行需要信息在角色间流动。这三个角色分离了任务理解、实现和验证。移除验证者或规划者会给出消融条件（表 1）。实现细节，包括容器边界、文件路径和证明格式见附录 A.1。

### 2.2 任务构建

协同基准测试需要这样的任务：规范中包含仅凭工作区无法揭示的信息。如果仅凭工作区包含足够的信息让仅执行者的智能体解决任务，则该任务不需要协同。我们精心挑选了 851 个具有此属性的模板。每个模板包括一个确定性脚本评分器，并扩展为一个或多个种子评估实例，总共 931 个实例。我们精选了 161 个任务，其关键约束仅存在于完整需求中。我们改编了来自活跃开源仓库（包括 Flask、Django、NumPy、SciPy 和 Keras）的 650 个 GitHub bug 报告。我们还包含了基于经典公共数据集 [5] 构建的 30 个数据科学任务和 10 个从公开事后分析中改编的事故响应任务。该池涵盖 19 个基础类别，包括安全修补、数据管道修复、分布式系统调试、密码学正确性、对抗性规范陷阱等。基准测试包含许多挑战性任务，因为 §3.4 测试团队是否在单个智能体挣扎时帮助最大。图 2 显示了组成情况。

参见图注
**图 2：TeamBench 组成。** (a) 按来源类分布的源分布。(b) 跨越 851 个任务模板的领域分布。(c) 跨越 804 个具有评分器检查计数的模板的难度分布。其余 47 个模板因未提供评分器检查计数而被列为未评级。

任务跨越五种协同失败模式。**中继任务** 要求规划者传递执行者无法从工作区推断的规范细节。**对抗陷阱任务** 在工作区中放置看似合理但不正确内容。**开放式任务** 允许多种有效实现，但确定性检查定义哪些输出通过。**发现任务** 隐藏数据质量或 API 问题，执行者必须通过主动探索来发现。**综合任务** 需要跨多个文档关联证据。在 161 个作者编写的模板中，关键约束仅出现在完整规范中。它们不存在于简报和工作区中，因此执行者需要来自规划者的信息。按来源计数和文件布局见附录 A.2。

每个任务部署时都带有一个生成器，可以从不同的随机种子生成确定性但独特的工作区文件。生成器改变任务相关参数（配置值、API 字段名、bug 位置），同时保持结构复杂性，从而防止价值记忆。

### 2.3 消融条件

我们在五种条件下运行相同任务（表 1），以隔离每个角色的边际贡献。Solo 是具有完整规范、工作区和四种工具的单个智能体。Restricted 是相同的单个智能体，但没有访问完整规范的权限。三个团队条件（Full Team、Team No-Plan 和 Team No-Evaluate）随后添加或移除规划者和验证者。

**表 1：消融条件，以及哪个智能体拥有每种能力。** Spec = 读取完整规范，Edit = 修改工作区并执行命令，Attest = 写入最终证明。† 在 Team-No-Plan 中，执行者仅看到简报，验证者持有完整规范以进行合规性检查。

| 条件 | 智能体 | Spec | Edit | Attest |
| :--- | :--- | :--- | :--- | :--- |
| Solo | 单个智能体（完全访问） | ✓ | ✓ | ✓ |
| Restricted | 单个智能体（仅执行者工具） | – | ✓ | – |
| Full Team | 规划者 + 执行者 + 验证者 | 规划者 | 执行者 | 验证者 |
| Team, No Plan | 执行者 + 验证者 | 验证者† | 执行者 | 验证者 |
| Team, No Evaluate | 规划者 + 执行者 | 规划者 | 执行者 | – |

我们将 **团队工作必要性指数（Teamwork Necessity Index, TNI）** 定义为团队恢复的 Solo 与 Restricted 差距的比例。直观地说，TNI 询问当缺失的需求必须通过团队传递时，恢复了多少性能：

$$
\text{TNI} = \frac{S_{\text{team}} - S_{\text{restricted}}}{\max(\epsilon, S_{\text{solo}} - S_{\text{restricted}})},
$$

其中 $\epsilon = 0.05$ 以避免在 Solo–Restricted 差距接近零时的不稳定性。$\text{TNI}=1$ 表示团队完全恢复了单智能体优势，而 $\text{TNI}>1$ 则超过该优势。我们仅在对 $S_{\text{solo}} - S_{\text{restricted}} > \epsilon$ 的任务中汇总 TNI，因为较小的 Solo–Restricted 差距不能提供对团队工作必要性的有意义测试。我们额外报告规划价值 $= S_{\text{full}} - S_{\text{no\_plan}}$ 和验证价值 $= S_{\text{full}} - S_{\text{no\_verify}}$，并使用 $\pm 0.05$ 带宽将任务分类为 HIGH-TNI、TEAM-HELPS、NEUTRAL 或 TEAM-HURTS。

### 2.4 角色混合

如果规划者、执行者和验证者角色需要不同的能力，那么最适合一个角色的模型未必最适合另一个角色。因此，我们将模型分配视为实验变量，而不是像许多先前的智能体研究那样在所有角色中固定一个模型。该协议枚举了将三个模型分配给三个角色的每一种组合，给出 27 种配置，限于三个 LLM 家族（Anthropic、Google、OpenAI），每个家族一个模型以保持网格可控。每种配置在分层子集的所有 25 个任务上运行。我们使用紧凑代码表示配置，每个角色分配的提供商用一个字母表示。例如，PGEAVO 运行 Google 规划者、Anthropic 执行者和 OpenAI 验证者。

## 3 实验与结果

实验解决三个问题。1) 在结构强制执行下，每个角色的边际贡献是什么？2) 通过率是否取决于哪个提供商填充哪个角色？3) 团队在哪些任务体制中提供正向提升，在哪些地方带来负面影响？附录 C.1 列出了研究及其背后的数量。

### 3.1 设置

排行榜评估了四个家族（Anthropic、Google、OpenAI 和 Alibaba）中的 13 个模型。跨提供商网格使用每个商业家族中的一个紧凑前沿模型。每个角色都是在其拥有工具的沙箱中的工具调用循环。每个任务包括一个确定性脚本评分器。二元通过要求每个检查都通过，遵循 SWE-Bench [10] 和 Terminal-Bench [17]。保留的种子用于排行榜刷新。比较使用配对 Bootstrap（10,000 次迭代）和 Wilson 95% CI。强制执行研究使用带有 Holm-Bonferroni 的 McNemar 检验。可复现性细节列在附录 D.2 中。

### 3.2 主要结果

参见图注
**图 3：TeamBench 排行榜。** 行按 $\max(\text{Solo}, \text{Team})$ 降序排列，因此行顺序跟踪每个模型的最佳演示能力。条形图显示 Solo...