多 Agent 团队到底值不值？50 个全栈应用实测：成本涨 1.8–5.1 倍，只有一种组合显著涨分

一句话结论：只记住一个数字就够——多 Agent 团队的账单是单 Agent 的 1.8–5.1 倍，而 8 种组合里只有 一种换来了统计显著的涨分：GPT 6 Sol 中等推理强度的团队，比同模型单 Agent 高 7.3 分（p=0.005，95% 区间 +2.3 到 +12.4）。Claude Opus 5.5 的"最大强度 + 团队"拿到了全场最高分 93.2%，但单应用成本 122 美元、中位运行近 3 小时，是它自己中等强度单 Agent 的 约 30 倍成本，而 1.6 分的领先在统计上并不显著（p=0.36）。

本文完整编译自 Vals AI 博客《Do Agent Teams Pay Off? A Case Study on Vibe Code Bench》（2026-10-09），并做中文整理。

一、要回答的问题：原生多 Agent 到底买到了什么

OpenAI 与 Anthropic 现在都提供原生多 Agent 支持：一个 lead agent 可以派生子 Agent，把任务的一部分交给每个子 Agent，再汇总它们返回的结果。Vals AI 想量化三件事：这买到了什么、成本是多少、对哪类工作有帮助——而且要在接近真实软件项目的任务上测。

测试床是他们的 Vibe Code Bench：从一份产品规格出发，构建完整的 Web 应用。每个应用用 Docker Compose 部署，由浏览器 Agent 点击工作流来打分。工作天然分成数据库、API、界面、部署四块，而这些部分接缝处的 bug 会直接反映在分数上。

实验设置：

任务提示词、沙箱和评分器在对比中保持一致。Opus 的团队运行还关掉了 Claude Code 对后台子 Agent 的 10 分钟限制；推理强度分别通过 OpenAI 的 reasoning.effort 与 Claude Code 的 CLAUDE_CODE_EFFORT_LEVEL 设置。

二、核心发现：贵 1.8–5.1 倍，只有一处显著

• 成本：团队是单 Agent 的 1.8 到 5.1 倍，但只有一处得分差异在统计上显著。
• 唯一显著的涨分：Sol 中等强度团队比它的单 Agent 高 7.3 分（p=0.005）。其余三处差异——+1.4 分（Sol 最大强度）、−0.3 分（Opus 中等）、+3.4 分（Opus 最大）——都不显著（p=0.16 到 0.81）。
• 对 Sol 来说，加推理强度比加团队更有效：最大强度让单 Agent 涨了 11.4 分（p<0.001），高于团队在中等强度带来的 7.3 分。不过最大强度单 Agent 也比中等强度团队贵 1.6 倍（$4.82 vs $3.07）、慢约 3 倍。
• 对 Opus 来说，最大强度单干反而没涨分：89.8%（$23.77）对中等强度的 91.5%（$4.08），p=0.48。全场最高分来自"最大强度 + 团队"的 93.2%，代价是中等强度单 Agent 的约 30 倍成本，1.6 分的领先仍不显著（p=0.36）。
• 跨模型看：Sol 的最大强度团队（90.4%，$8.54）离 Opus 中等强度单 Agent（91.5%，$4.08）只差约 1 分，但贵一倍。

这是一个全栈 Web 应用的基准，结论不一定能推广到其他类型的工作。

三、全表：得分、成本与运行时间

几个补充数字：

• 多出来的钱主要是缓存输入：每个子 Agent 都有自己的上下文（装着规格和它自己的工作状态），每次模型调用都要重发。最大强度下，Opus 的子 Agent 中位读取每个应用 2.24 亿缓存 token，而 lead 是 1,700 万、单 Agent 是 5,500 万。
• 有一个 Opus 最大强度团队在验证阶段就超时了，其约 $189 的成本按 token 用量估算，并计入平均值。
• 并行确实省时间的是 Sol：中等强度 11.9 分钟 vs 12.4 分钟，最大强度 28 分钟 vs 38 分钟。Opus 的团队更慢，最大强度下最长到单 Agent 的 2.3 倍——它按"波次"串行推进，每一波都要等最慢的成员。
• 多出来的时间是子 Agent 的实数工作，不是空等；但跑得久并没有换来更高分——Opus 最大强度团队的运行时长与相对单 Agent 的增益之间没有相关性。它有 4 次运行超过 4 小时，其中 1 次撞上 5.25 小时上限。

四、两条路：加推理强度，还是加团队

团队和更高推理强度都会抬升成本，但对分数的影响不同：

• Sol：最大强度把单 Agent 拉高 11.4 分，大于团队在中等强度带来的 7.3 分。最大强度单 Agent 也比中等强度团队高 4.1 分（89.0% vs 84.9%），但差异不显著（p=0.08），代价是 1.6 倍成本、3 倍时间。
• Opus：单加最大强度没有涨分。最大强度 + 团队拿到最高分，但那条曲线非常贵。

所以没有一个默认正确的选项：对 Sol，加推理强度是更划算的杠杆；对 Opus，最便宜的设置在这批任务上跑出了和它最贵设置差不多的分数。

五、两种 lead 风格：Sol 拆分后自己测，Opus 先写合同再分波

两个 lead 收到的是同一句指令，但拆活的方式完全不同。

Sol 的 lead：一分钟内派出全部子 Agent，自己负责测试

• 中等强度下，它按架构线拆分（数据库与种子数据、API、界面、部署），大约 1 分钟内创建完所有子 Agent。
• 最大强度下，它更常把界面拆成独立功能块（50 次开局计划中有 13 次，中等强度是 7 次），并且边跑边追加子 Agent。
• 相比自己的中等强度，最大强度下它会派生略多的子 Agent（5.1 vs 4.2 个），发出接近两倍的后续请求（每应用 31 vs 18 条）。
• 它自己驱动无头浏览器验证：两种强度下都在 50 次运行中的 46 次里跑了浏览器测试，约为单 Agent 的两倍，而且大多打在应用的公网 URL 上，不是沙箱内的 localhost。中等强度下，单 Agent 只在 localhost 测过 18/50 次，团队 lead 只有 4 次。
• 它的记录显示，它抓到的是只有拼装后才暴露的接缝 bug：界面发送的字段和数据库 schema 对不上、同一个合计在界面和数据库里各算一套。每个修复都被打回给拥有该文件的子 Agent。

Opus 的 lead：先写共享合同，再按波浪推进

• 在派生任何 Agent 之前，Opus 的 lead 会先写一份共享文档（通常是 CONTRACT.md），描述 schema、API 路由和文件所有权——中等强度 50 次里有 42 次这么做，最大强度 40 次；单 Agent 几乎从不这么做。
• 它以波次派生：中等强度通常是"建造者 → 端到端测试子 Agent"；最大强度会再加一波——先建地基的子 Agent，再在其上建功能的子 Agent，最后测试与审查的子 Agent。
• 大多数运行里 README 由它自己写；它编辑应用代码的比例是中等强度 10/50、最大强度 26/50。
• 最大强度下团队更大：每应用 6.8 个子 Agent（中等 4.2 个），50 次运行全部带一个测试子 Agent，子 Agent 工具调用约 1,140 次（最大强度单 Agent 约 270 次），浏览器测试 36 次/应用，是单 Agent 的 6 倍。

六、时间都花在哪：首次部署之后才是分水岭

团队和单 Agent 到达首次部署（第一次 docker compose up）的时间差不多：中等强度下两个模型的团队和单 Agent 都在 1 分钟内；最大强度下 Sol 的团队早约 5 分钟，Opus 的团队晚约 6 分钟。

但 Opus 的最大强度团队把 三分之二的时间花在首次部署之后（单 Agent 不到三分之一）：在那段时间里，lead 与子 Agent 合计投入中位 68 个 agent-分钟用于测试，单 Agent 只有 10 个。

七、涨分从哪来——以及没从哪来

为了看团队是否在更难的应用上更有用，作者用"对比之外"的一次运行给应用分组（例如评估中等强度对比时，用同模型最大强度单 Agent 在该应用上是否低于 90% 来定义"更难"），避免用被比较的那次运行决定分组。

• Sol 中等强度团队在约一半应用上有增益：24 个更高、11 个更低、15 个持平。在更难的应用上平均约 +15 分，在更容易的应用上约 +1 分。最大强度下增益变小，且均匀分布在难易两类上。
• 在 Sol 中等强度团队涨 20 分以上的 9 个应用里，可以看到涨分来自"把单 Agent 跳过的东西补上"：那些单 Agent 报告"测试已通过"，但有些功能根本没实现、整条工作流从未跑过。团队覆盖了更多规格、检查得更认真，并且 lead 把分开构建的部分互相对照，抓出了表单和 schema 不匹配、权限规则挡住某一步这类问题。
• Opus 的得失更平衡，且不偏向更难的应用：中等强度 14 涨 15 跌，最大强度 13 涨 8 跌。中等强度下它在难的应用上约 −4 分、在容易的应用上约 +2 分；最大强度下两类都约 +3 到 +4 分。
• 其他属性没有一致影响：规格长度、UI 测试数量、单用户/多用户应用都没有稳定效应。唯一的例外是"用户角色更多"的应用让 Sol 中等强度团队涨了 15 分，但其他配置没有复现这一点。

八、作者判断的下一步

在这个基准上，团队的效果取决于模型、推理强度和应用本身。真正开放的问题是：哪些任务里团队能可靠地优于单 Agent？

作者给出的方向是：团队最能发挥的场景，是工作能拆成可并行的部分，而且 lead 组合这些部分所花的时间少于省下的时间。他们下一步想看的任务包括：大型代码库、宽泛的研究问题、跨大量文档的分析——这类任务有大量独立的片段和长长的可分离工作段。

九、方法与局限（读数字前必看）

• 每个设置只跑了一次：文中的区间和 p 值反映的是跨应用的差异，不是同一设置的重复运行差异。
• 团队运行额外收到了"委派"指令，所以每次对比实际上是"子 Agent + 委派提示词" vs "两者都没有"。
• 两个模型跑在不同的 harness 上，因此跨模型比较混合了模型与 harness 两个变量。
• Sol 走的 OpenAI Agents API 事件流只记录 lead 的回合：能看到它何时创建、发消息、等待子 Agent，但看不到它说了什么、子 Agent 做了什么（且一个子 Agent 会发两条 subagent.created 事件，作者按唯一 ID 去重）。Claude Code 则记录每个子 Agent 的工具调用。
• Sol 的成本假设上报的 token 用量包含子 Agent，并采用基础档列表价（输入 $2/百万、缓存 $0.20/百万、输出 $10/百万）；超过 272K 的长上下文档位无法按请求评估，未计入。Opus 的成本是 Claude Code 上报的列表价合计。

来源

• Vals AI, Do Agent Teams Pay Off? A Case Study on Vibe Code Bench（2026-10-09）：https://www.vals.ai/blogs/multi-agent-vibe-code-bench
• 基准：Vibe Code Bench：https://www.vals.ai/benchmarks/vibe-code

本文由 汇智网 · Software 2.0 完整编译整理，转载请注明出处。 想系统了解 Agent 的循环、上下文与工具层，见 Agent / MCP / 自动化完全指南；也可以继续读 为什么多智能体编程会失败 与 用 Pi 搭一条多智能体编程工作流。

这是「Agent / MCP」专题的一部分。完整地图见：Agent / MCP / 自动化完全指南