Cohere Labs 研究：编码 Agent 团队扩编的经验，以 30% 成本逼近前沿效果

Agent 团队正在构建软件

在过去一年里，编码 Agent 团队已从有趣的演示走向构建大规模软件项目。十六个 Claude Agent 编写了一个 10 万行的 C 编译器，能够构建 Linux 内核，该项目大约耗费了 2,000 个 Agent 会话和 20,000 美元的 API 成本 [1]。Cursor 运行了数百个 Agent，它们共同从零编写了一个 Web 浏览器，代码超过一百万行，耗时约一周 [2]。Bun 在 11 天内从 Zig 移植到 Rust，峰值时有 64 个 Claude Agent 并行运行 [3]。

这些团队都产出了可用的软件，但它们在许多方面同时存在差异，从模型和角色到项目本身的范围。C 编译器的 Agent 作为对等体工作，没有编排器，通过锁文件认领任务。Cursor 采用层级结构，规划器递归地将工作分解为子任务，委派给数百个工作 Agent。Bun 分配固定角色，将每项工作交给一个实现者、两个对抗性审查者和一个修复者。

然而，对它们进行比较，并不能说明哪些设计选择重要，或者与单个 Agent 相比成本如何。Factory 对自家多 Agent 系统的研究——该系统以固定循环轮转编排器、实现者和验证者——表明这种成本可能有多大 [4]。在一项重建地理空间库 GDAL 的任务中，他们的三角色团队获得的奖励是单个 Agent 的两倍多，几乎达到与参考程序的行为对等，但成本高出 14 倍，耗时多出 13 倍。

因此，Agent 团队能比单个 Agent 做更多事，但运行成本更高，通常耗时也更长。这引出一个重要问题：如果 Agent 团队是一种新的推理算力使用方式，应该如何组织它，才能既有效又高效？为了回答这个问题，我们构建了一个受控测试平台，并在其上运行编码 Agent 团队。

图 1. 编码 Agent 团队的一次示例运行。负责人将工作分发给其工作 Agent，后者探索原始程序、编写代码，并在共享工作区中检查代码。

一个受控测试平台

一个最小化测试框架

我们构建了一个刻意最小化的测试框架，灵感来自 mini-SWE-agent [5]，以便我们能够一次只改变一个设计选择。每个 Agent 都通过一个简单的 bash 工具工作，整个团队共享一个工作区。一个 Agent（负责人）接收任务，并用 delegate_agent 工具分发工作。工作 Agent 只能看到分配给它的子任务，并在完成后汇报。给定任务后，负责人动态决定生成多少工作 Agent、每个工作 Agent 做什么，以及如何整合它们返回的结果。¹

每次 delegate_agent 调用要么以全新的上下文窗口启动一个新的工作 Agent，要么恢复负责人之前使用过的工作 Agent。恢复的工作 Agent 保留其先前的上下文，因此负责人可以跟进一个已经了解部分程序的 Agent。例如，负责人可以要求工作 Agent 修复其编写的代码中的错误，而不是从头向新工作 Agent 介绍情况。

在此基础上，我们改变五个方面：

负责人（lead）在哪些环节使用 worker。我们用两个主要提示词来指示负责人，二者的区别在于给出的指导程度不同。minimal 提示词告诉负责人它负责一个团队，并要求它给 worker 分配彼此独立的不同任务，但其余一切——从使用多少个 worker 到如何拆解任务——都交给负责人自行决定。PIV 提示词则增加了一套结构化工作流：探索与规划（P）、实现（I）、验证（V），并要求负责人在全部三个阶段都使用 worker。
负责人如何等待。阻塞式负责人会等待 worker 回报，在此期间不做任何事。异步负责人则在 worker 运行期间继续工作，并多出两个工具：wait_for_updates 用于等待下一次回报，list_agents 用于查看 worker 的状态。
哪些模型扮演哪些角色。团队中的每个 agent 都需要最强、最贵的模型吗？我们用两类团队来测试这一点。在同质团队中，负责人和 worker 都运行同一个模型。在异质团队中，负责人保留强模型，但 worker 运行更便宜的模型。可以想象成一位资深工程师负责指挥工作并做出关键决策，而大部分跑腿工作由初级工程师完成。
有多少个 worker。团队越大就一定越好吗？为了探究这一点，我们比较了两种设置。第一种由负责人自行决定需要多少个 worker。第二种是我们把团队规模固定为两个、四个、八个或十六个 worker，观察奖励和成本随团队扩大如何变化。
agent 之间如何通信。默认情况下，所有通信都经由负责人，由它分发每个子任务并接收每个 worker 的报告。在一组运行中，我们为 agent 提供了一个 send_message 工具，让它们可以直接互相发消息。

图 2。两个负责人分派相同的子任务，且每个 worker 运行耗时相同。阻塞式负责人在 worker 回报前一直空闲。异步负责人则继续工作，并在第一批报告到达后立即开始第二轮。条形表示工作时段，向下箭头表示对 delegate_agent 的调用，向上箭头将报告送回负责人。时间仅为示意。

ProgramBench

我们在 ProgramBench [6] 上测试这些选择，该基准包含 200 个需要从零重建的程序。在每个任务中，agent 从空工作区开始，手中有原程序的可执行文件（可以运行但不能读取）以及该程序的文档。它必须探测程序以发现其接口、边界情况和行为，然后编写一个行为相同的新实现。我们按重建程序通过隐藏行为测试套件的比例给每个任务打分，并对各任务取平均，得到我们通篇报告的奖励。²

任务范围从 jq 和 ripgrep 这样的小型命令行工具，到 SQLite、FFmpeg 和 PHP 解释器这样的大型系统。最具挑战性的任务仍然遥不可及。在 FFmpeg 上，公开排行榜上的最佳成绩通过了约 10% 的测试。

每个任务都需要工作流的全部三个阶段：弄清程序做什么、编写程序，以及对照原程序进行检查。这使得 ProgramBench 成为观察哪些阶段能从额外 agent 中受益的良好试验台。

图 3. 一个 ProgramBench 任务，dsq，一个命令行工具，可在 JSON、CSV 和其他数据文件上运行 SQL 查询。上方面板是使用最小提示的单个 Sol 智能体，下方面板是使用 PIV 提示的异步 Sol 团队。单个智能体将其程序写为一个 Python 文件，而团队将其拆分为多个模块，其中一些由 worker 编写。团队面板跟随一次运行的文件，命令从智能体自身的命令简化而来，时间仅为示意。

我们主要关注三个 GPT-5.6 模型：Luna、Terra 和 Sol，能力和成本依次递增。除非另有说明，我们在所有 200 个 ProgramBench 任务上对每种配置运行三次，并报告三次运行中奖励、总成本和总挂钟时间的平均值。单个任务的得分每次运行都有变化，标准差约为 6 分，但基准范围内的平均值要稳定得多，典型配置的标准差为 0.5 分，噪声最大的为 1.4 分。每种配置都在相同的任务上运行，因此我们逐任务比较每个团队与其 solo 基线，并报告这些差异的 95% 置信区间。

我们还运行了 Commit0-Lite [7]，这是一组 16 个 Python 库，其实现已被移除。智能体会获得每个库的仓库骨架、文档和单元测试，并且必须填写代码以使测试通过。在 ProgramBench 中，智能体必须通过运行原始程序来弄清楚要构建什么。在 Commit0 中，这些提供的材料明确说明了这一点，因此该基准测试表明当规范已经给出时，相同的阶段是否仍然有效。由于只有 16 个任务，我们将其用作次要检查。

团队的表现优于 solo 智能体，但成本更高

我们从最简单的比较开始：单个 Sol 智能体与 Sol 智能体团队。在相同的最小提示下，阻塞式团队平均通过了 61.8% 的测试，而 solo 智能体为 52.1%。给 solo 智能体提供 PIV 提示缩小了部分差距（57.7%），但使用 PIV 提示的阻塞式团队仍然领先约 5 个百分点（63.1%）。

我们还使用异步负责人运行了两种提示，该负责人可以在其 worker 运行时继续工作。所有四个 Sol 团队的成本都是相应 solo 智能体的 4 到 7 倍。使用 PIV 提示时，异步团队完成时间比阻塞式团队少 19.5%，并达到大致相同的奖励。

使用最小提示时，异步团队完成时间减少了 60%，但其负责人自己完成了更多工作，每个任务仅委派 4.4 次，而阻塞式负责人为 6.1 次。其团队仅比使用最小提示的 solo 智能体高出 3.8 分，而阻塞式团队为 9.7 分，并且以 55.9% 甚至低于使用 PIV 提示的 solo 智能体（57.7%）。

**图 4.** 平均奖励与推理成本（左）和挂钟时间（右）的关系，每个都是所有 200 个任务在三次运行中的平均值总计。误差条是每个团队与相应 solo 智能体配对逐任务差异的 95% 区间。

Worker 在规划中收益最大

为了弄清工人在哪个环节回报最高，我们让负责人只在一个阶段把子任务委派给工人，另外两个阶段由自己完成。在探索与规划（P）阶段，工人运行程序以了解其行为并起草计划，负责人负责实现和验证。在实现（I）阶段，工人编写代码。在验证（V）阶段，工人测试负责人的实现。

规划阶段明显胜出。在异步团队中，只委派规划阶段的负责人，其奖励与委派所有阶段的负责人相当（63.6% 对 63.2%），但成本只有一半（249 美元对 510 美元）。以每增加 100 美元成本所获得的奖励来衡量，规划阶段的效率约为次优阶段的两倍。³

**图 5.** 只委派一个阶段或全部三个阶段的异步 Sol 团队。三次运行的平均值。线条从单人 PIV 智能体延伸到每个团队。虚线箭头从 PIV 团队指向规划团队，后者的成本只有一半。误差条是相对于单人 PIV 智能体的配对 95% 区间。

例如，在 dsq 上，使用 PIV 提示词的单人智能体平均通过了 60% 的测试。只委派规划阶段的团队在异步负责人下通过了 79%，在阻塞式负责人下通过了 76%，且它们的六次运行每次都优于所有单人运行。委派实现或验证阶段的团队只通过了 58% 到 71%。

原因在于基准测试的设计。目标程序是一个黑盒，因此必须通过运行它来发现其行为。规划工人并行地做这件事，每人探测程序接口的不同部分，并把发现交给负责人。随后负责人自己编写代码，对要构建什么有了更完整的认识。

其他工作也报告了相关发现。Factory 的验证器在编写任何代码之前，先探测参考程序，以构建一个可执行的“完成”标准 [4]。Carlini 的 C 编译器团队通过使用 GCC 作为对照标准，解决了 Linux 内核上的难题 [1]。在每个案例中，确切知道要构建什么才是瓶颈，把算力放在那里就得到了回报。

Commit0 则展示了另一面。在那里，仓库已经明确了要构建什么，而在我们的十种团队设置中，有八种显示实现而非规划是最有效的委派阶段。然而，像 GPT-5.6 Sol 这样的前沿模型已接近使 Commit0 饱和，一个能力强的单人智能体在 16 个任务中已有 12 个通过了所有测试，只剩下四个任务团队可能做得更好，因此我们将其视为提示性而非结论性的结果。

规划工人可以很便宜

如果规划工人主要是为负责人收集信息，它们需要是强模型吗？我们保留 Sol 作为负责人，把它的规划工人换成 Luna，一个便宜得多的模型。该团队相比全 Sol 团队损失了几分（60.5% 对 63.6%）。不过，与单人智能体相比，它只用了全 Sol 团队额外成本的 13.9%，就保留了其 47.5% 的收益，因此每一美元买到的奖励超过三倍。

现在将其与我们在未查看任务的情况下可能构建的方案进行比较。一个自然的对比对象也是 PIV 设置，即我们让一个强力的负责人（lead）在每个阶段都使用强力的工作者（worker）。该团队达到了 63.2%，但成本为 510 美元。通过认识到 ProgramBench 的瓶颈在于发现程序的功能，并且只在规划阶段使用廉价工作者，我们以五分之一的成本达到了与其相差 2.7 个百分点的水平。

**图 6。**图 5 中的团队，以及两个将 Sol 负责人与 Luna 工作者配对的团队（工作者圆点更小），一个委托规划，一个委托全部三个阶段。所有团队都是异步的。虚线箭头从全 Sol 规划团队指向 Luna 规划团队，标注为 Luna 团队占全 Sol 团队增益和额外成本的比例，两者均相对于单独 PIV 智能体测量。误差条是相对于单独 PIV 智能体的配对 95% 区间。

为了将负责人的贡献与工作者的贡献区分开，我们将工作者固定为 Luna，并将负责人从 Luna 升级到 Terra 再到 Sol。奖励随每次升级而上升，从 42.5% 到 51.6% 再到 60.5%（图 7），并且每个团队都击败了运行其负责人模型的单独智能体（37.4%、47.2% 和 57.7%）。然而，廉价工作者无法弥补较弱的负责人。Terra 负责人与 Luna 工作者搭配仍不及单独工作的 Sol 智能体（51.6% 对 57.7%）。

**图 7。**单独 PIV 智能体和异步规划团队的平均奖励与总推理成本（对数刻度）的关系。同质团队（每个智能体使用相同模型）的圆点大小相等，而异质团队（将更强的负责人与 Luna 工作者配对）的工作者圆点更小。阴影带连接了三个使用 Luna 工作者的团队。

这与 Meta 最近关于元推理的工作 [8] 相符。他们的系统将智能体分为控制器（决定下一步做什么以及基于哪些先前结果）和工作器（执行该工作）。在相同的工作器和相同的预算下，更好的控制器在 ProgramBench 上得分更高（71.5% 对使用 GPT-5.5 的 63.7%），并且其优势随着预算增加而扩大，而更简单的控制则趋于平缓。在他们的设置和我们的设置中，更强的决策者都提升了相同工作者的成果。

扩展工作者数量

到目前为止，负责人选择使用多少工作者。为了了解更多工作者能带来什么，我们固定了团队规模，给一个 Sol 负责人配备两个、四个、八个或十六个 Luna 工作者。规划团队随着规模增长而提升了整体表现，从两个时的 59.6% 到十六个时的 61.8%。即使在十六个时，Luna 规划者的成本为 155 美元，比全 Sol 规划团队（249 美元）低 38%，比委托全部三个阶段的全 Sol 团队（510 美元）低 70%，同时与两者相差不到两个百分点。

实现和验证工作者的表现不同。它们从两个到四个工作者有所改善，然后随着更多工作者的加入而略有下降。查看运行内部可以解释原因。无论团队规模如何，每个规划者运行参考程序约七次，因此更多规划者向负责人展示了更多程序行为。在整个团队中，参考程序的运行次数从两个规划者时的 15 次增长到十六个时的 109 次，规划者的报告从 17,000 个字符增长到 75,000 个字符。

增加实现者并没有带来这类信息。每个实现者分到的计划片段更薄，任务分配从两名实现者时每名工人约 1,400 个字符缩减到十六名时的 440 个字符。实现者承担的代码份额从两名时的 54% 增长到十六名时的 85%，但负责人将合并后的程序与参考实现对照检查的频率并未提高，无论是合并两个片段还是十六个片段，都是 5 到 6 次运行。

**图 8。**由 2 到 16 名 Luna 工人组成的异步 Sol 负责人的奖励，按团队规模（左）和总成本（右）展示。每个 Luna 工人标记对应每个工人的一个小圆点。圆点大小相同的标记是由负责人确定规模的纯 Sol 团队。每种固定规模配置运行一次。误差条是相对于单独 PIV 智能体的配对 95% 区间。

探索通信

到目前为止，智能体只在负责人分配工作时和工人汇报时交换信息。我们还尝试给每个智能体一个 send_message 工具，可以联系任何其他正在运行的智能体。

在我们的运行中，我们注意到该通道主要用于向上汇报。在使用 PIV 提示词的 Sol 团队中，84% 的消息从工人发给负责人，携带阶段性发现、提议的接口、测试失败和问题。⁴ 工人之间的消息平均每个任务不到一条，只有在告诉工人将彼此视为协作者时才升至每个任务约一条。

更强的模型更多地使用了该通道。Sol 智能体写的消息文本量是 Luna 智能体的 3.4 到 5 倍，Sol 负责人向工人发送了更多指导。然而，Sol 和 Terra 团队的奖励保持不变，Luna 团队则损失了 4 到 7 分。一种可能的解释是，阶段性更新的洪流压垮了较弱的负责人，而较强的负责人能够吸收。另一种解释是 Luna 工人使用该工具不当，约一半的 send_message 调用格式错误并被测试框架拒绝。

**图 9。**带有 send_message 工具的异步纯 Luna、纯 Terra 和纯 Sol 团队。斜线阴影部分是被拒绝的调用。左：每个任务的消息数。中：每个任务的消息文本量。右：与没有该工具的同一团队相比的奖励变化，附配对 95% 区间。

话虽如此，通信在合适的环境中仍可能有帮助。我们的测试框架围绕拆分工作和委派构建。最小提示词和 PIV 提示词都要求负责人给工人分配不同且独立的任务，因此每个工人几乎没有其他工人需要的东西。因此，工人给负责人发消息远多于彼此发消息是合理的。

与此形成对比的是，Park 等人发现，当智能体共享一个目标和共同工作空间、没有固定角色时，由五个通信智能体组成的团队在 ARC-AGI-3 上匹配了 33 个独立智能体中的最佳表现 [9]。他们称之为已验证进展共享的关键要素是，智能体可以检查队友的发现是否确实是改进。微软的自组织测试框架 Agensh 也报告称，在大型扁平团队中合作会自行涌现 [10]。

智能体之间交流多少取决于任务、工作如何拆分、智能体如何被提示以及其模型如何训练。我们预计，当智能体追求同一目标、能够检查彼此的进展并被提示将通信视为工作的一部分时，消息传递最为重要，我们正在后续工作中积极探索这一点。

其他模型如何使用团队

我们还在 ProgramBench 的 30 个任务子集（10 个简单、10 个中等和 10 个困难任务）上，用相同的工具和提示词测试了另外五个模型，并将它们与 GPT-5.6 在相同任务上的运行结果进行了比较。⁵ 对于每个模型，我们分别使用 minimal 和 PIV 两种提示词设置，对单智能体、阻塞式团队和异步团队各运行了一次试验。由于每个模型只运行一次，几个百分点的差异可能只是噪声。

各模型对团队的使用方式差异很大。GPT-5.6 团队经常进行委派，相比其最佳单智能体最多提升了 6.9 个百分点，而且其大多数团队配置都取得了更好的成绩。Claude Opus 4.8 的表现大致相同，在 PIV 提示词和异步负责人的配置下提升了 5.9 个百分点。Claude Opus 4.7 很少委派，每个任务最多委派 1.3 次，其团队相比最佳单智能体几乎没有提升。⁶ Claude Haiku 4.5 和 Gemini 3.7 Flash 的委派频率与 GPT-5.6 相当，但并未从中获得任何收益。Gemini 3.8 Flash 在 PIV 提示词和阻塞式负责人的配置下提升了 3.1 个百分点，但在异步负责人配置下下降了 4.6 个百分点。

**图 10。**在 ProgramBench 的 30 个任务子集上，每个任务的委派次数（左）以及团队相对最佳单智能体的提升（右）。对于每个模型，提升值是相对于使用 minimal 或 PIV 提示词时得分更高的那个单智能体来衡量的。每个标记代表四种团队配置之一。GPT-5.6 的结果是这 30 个任务上三次运行的平均值。其他模型均为单次运行，因此小于约 5 个百分点的差异可能只是噪声。

团队要发挥作用，必须做好两件事。负责人必须选择进行委派，并且必须善加利用返回的结果。Opus 4.7 在第一点上表现不足，而 Haiku 4.5 和 Gemini 3.7 Flash 则在第二点上表现不足。两个 Opus 模型表明，在同一个模型家族内，这一点可能变化很大。Opus 4.7 几乎不进行委派，而更新的 Opus 4.8 则像 GPT-5.6 一样将工作分散到团队中，并从中获益。更新的模型是否普遍更擅长领导团队，这个问题我们无法仅凭每个模型一次运行来定论。

这些模型构建程序的方式也有所不同。GPT-5.6 将大多数程序用 Python 重写（占提交的 70% 到 93%），无论原始程序是用什么语言编写的。Claude 模型在 72% 到 90% 的提交中用原始语言重新实现了程序，而 Gemini Flash 模型则介于两者之间（43% 到 70%）。Claude Opus 4.8 和两个 Gemini 模型还将程序分散到更多文件中，每个任务的中位数为 5 到 11 个源文件，而 GPT-5.6 为 1 到 3 个。

下一步

我们的结果指向了几个令我们兴奋的方向。

层级制与自组织。在 ProgramBench 上，单个负责人可以将整个程序保持在视野之内，因此层级制效果很好。但一个由数千个智能体组成、工作数周的团队，很可能会超出任何单个负责人所能跟踪的范围。这样的团队将必须决定由谁分配角色、信息如何流动以及何时重组。在这种规模下，智能体将需要直接分享它们学到的东西，或许通过它们自己发明的协议。预训练已经赋予了它们基本动作，例如报告、询问和委派。随着模型规模扩大，真正的协调是会从这些动作中涌现，还是必须通过训练获得，这是一个开放问题，我们认为它对扩展推理至关重要。
替代的沟通形式。在我们的运行中，消息大多只是重复了负责人本来就会在报告中收到的内容。共享目标、共享进度日志，或携带可核查证据的消息，可能会让智能体更有理由交流。
适应任务。规划在 ProgramBench 上奏效，是因为必须去发现规格说明，但在其他任务上瓶颈可能别处。在 Commit0 上，实现帮助最大。一个能判断自己任务卡在哪里的负责人，可以把工人调到那里，而无需被告知该委派哪个阶段。
训练模型去领导。各模型在使用团队方面的表现差异很大，这表明领导是一项可以训练的技能。一个善于委派、能权衡相互冲突的报告、并知道何时等待的负责人，可以从同样的工人身上获得更多产出。

我们团队奏效的很大一部分取决于负责人：它选择委派什么，以及它如何处理返回的报告。随着模型越来越擅长领导，组织团队的最佳方式也可能随之改变。

脚注

当团队规模是动态的时，一个负责人在每个任务中最多可以启动五个不同的工人，超过这个数量就必须恢复已有的工人。将上限提高到二十改变了负责人的委派方式，但没有改变团队的表现。负责人启动了更多新工人而不是恢复旧工人，每个任务的委派总数变化最多为 0.9，奖励变化在 −1.6 到 +1.6 分之间。
ProgramBench 的作者按完全解决的任务比例对模型进行排名，并以至少通过 95% 测试的任务（“几乎解决”）作为次要参考。如今很少有任务被完全解决，因此为了衡量团队设计如何改变性能，我们使用更细粒度的测试通过比例。
效率是指相对于单独 PIV 智能体每增加 100 美元成本所获得的奖励。对于异步负责人，规划每 100 美元获得 3.4 分，而次优阶段（实现）为 1.7 分。对于阻塞式负责人，差距较小（3.8 对 2.4，即 1.6 倍）。
问题很少见，占工人到负责人消息的 6%。略少于一半询问工人的部分应如何与其余部分连接，例如另一个模块期望哪些函数名或参数类型。略多于三分之一询问在工人的构建覆盖参考程序后，参考程序去了哪里，其余大多数询问参考程序的确切行为。Sol 负责人回答了其中 74% 的问题。
我们还在 30 个任务的子集上尝试了 Claude Opus 5，但在八个试验任务全部达到八小时超时后停止了。那些任务每个花费约 500 美元，约为 Opus 4.8 团队每个任务花费的 15 倍。
Opus 4.7 是唯一一个单独智能体在使用 PIV 提示时明显比使用最小提示时表现更差的模型（46.8% 对 50.9%）。与使用相同提示的单独智能体相比，其 PIV 团队本会获得 5.5 到 6.4 分。与其最佳单独智能体（图 10 使用的）相比，它们获得了 1.4 到 2.3 分。