> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 多 Agent 团队到底值不值？50 个全栈应用实测：成本涨 1.8–5.1 倍，只有一种组合显著涨分 - URL: https://www.hubwiz.com/blog/do-agent-teams-pay-off/ - Published: 2026-10-15T12:59:43.000Z - Updated: 2026-10-15T13:00:38.000Z - Description: "多 Agent 更强"这句话，在这项 50 个全栈应用的基准上只对一种组合成立。Vals AI 把 8 种设置各跑 50 个应用：团队成本 1.8–5.1 倍，唯一统计显著的涨分是 Sol 中等强度团队的 +7.3 分；Opus 得分最高的组合 $122/应用，领先不显著。两个 lead 的编排风格也完全不同。 - Author: admin - Tags: AI Agent, 多智能体, 基准测试, Claude, Codex **一句话结论**：只记住一个数字就够——多 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 teams on Vibe Code Bench：一个 lead 分出四条并行路径，再汇合到第二个节点](https://www.hubwiz.com/blog/content/images/2026/10/img_4ef2b963214cc636a217988afca4227e.png) --- ## 一、要回答的问题：原生多 Agent 到底买到了什么 OpenAI 与 Anthropic 现在都提供**原生多 Agent 支持**：一个 lead agent 可以派生子 Agent，把任务的一部分交给每个子 Agent，再汇总它们返回的结果。Vals AI 想量化三件事：这**买到了什么**、**成本是多少**、**对哪类工作有帮助**——而且要在接近真实软件项目的任务上测。 测试床是他们的 **Vibe Code Bench**：从一份产品规格出发，构建**完整的 Web 应用**。每个应用用 Docker Compose 部署，由浏览器 Agent 点击工作流来打分。工作天然分成**数据库、API、界面、部署**四块，而这些部分**接缝处**的 bug 会直接反映在分数上。 实验设置： | 维度 | 设置 | | ---- | -------------------------------------------------------------------------------------------------------------------- | | 模型 | **GPT 6 Sol**（经 OpenAI Agents API，multi\_agent 关/开）**Claude Opus 5.5**（经 Claude Code CLI headless，移除/保留 subagent 工具） | | 形态 | 单 Agent vs 多 Agent 团队 | | 推理强度 | medium / max | | 应用数 | 50 个，每种设置各跑一遍（共 8 种设置） | | 团队规则 | lead 最多同时派 **5 个**子 Agent；子 Agent 不能再派生 | | 统一指令 | 两种 lead 收到同一句：把工作拆成独立部分、逐一分派、然后**集成并验证** | | 得分 | 每个应用 UI 测试通过率，50 个应用取平均 | 任务提示词、沙箱和评分器在对比中保持一致。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 应用的基准，结论不一定能推广到其他类型的工作。 --- ## 三、全表：得分、成本与运行时间 | 模型 | 设置 | 得分 | 单应用平均成本 | 中位运行时间 | | --------------- | ------------ | --------- | -------- | ------------ | | GPT 6 Sol | 中等强度，单 Agent | 77.6% | $1.22 | 12.4 分钟 | | GPT 6 Sol | 中等强度，团队 | **84.9%** | $3.07 | 11.9 分钟 | | GPT 6 Sol | 最大强度，单 Agent | 89.0% | $4.82 | 38.4 分钟 | | GPT 6 Sol | 最大强度，团队 | 90.4% | $8.54 | 27.6 分钟 | | Claude Opus 5.5 | 中等强度，单 Agent | 91.5% | $4.08 | 20.3 分钟 | | Claude Opus 5.5 | 中等强度，团队 | 91.2% | $9.10 | 26.6 分钟 | | Claude Opus 5.5 | 最大强度，单 Agent | 89.8% | $23.77 | 74.7 分钟 | | Claude Opus 5.5 | 最大强度，团队 | **93.2%** | **$122** | **174.1 分钟** | 几个补充数字： - **多出来的钱主要是缓存输入**：每个子 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 个。 | 模型与强度 | 设置 | 首次部署 | 完成 | | ------------------ | ------- | ------- | -------- | | GPT 6 Sol，中等 | 单 Agent | 5.1 分钟 | 12.4 分钟 | | GPT 6 Sol，中等 | 团队 | 5.7 分钟 | 11.9 分钟 | | GPT 6 Sol，最大 | 单 Agent | 19.9 分钟 | 38.4 分钟 | | GPT 6 Sol，最大 | 团队 | 15.3 分钟 | 27.6 分钟 | | Claude Opus 5.5，中等 | 单 Agent | 12.2 分钟 | 20.3 分钟 | | Claude Opus 5.5，中等 | 团队 | 12.5 分钟 | 26.6 分钟 | | Claude Opus 5.5，最大 | 单 Agent | 51 分钟 | 74.7 分钟 | | Claude Opus 5.5，最大 | 团队 | 56.8 分钟 | 174.1 分钟 | --- ## 七、涨分从哪来——以及没从哪来 为了看团队是否在**更难的**应用上更有用，作者用"对比之外"的一次运行给应用分组（例如评估中等强度对比时，用同模型**最大强度单 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 / 自动化完全指南](https://www.hubwiz.com/blog/agent-stack/)；也可以继续读 [为什么多智能体编程会失败](https://www.hubwiz.com/blog/why-multi-agent-coding-fails/) 与 [用 Pi 搭一条多智能体编程工作流](https://www.hubwiz.com/blog/a-multi-agent-coding-workflow-powered-by-pi/)。 > **这是「Agent / MCP」专题的一部分。**完整地图见：[Agent / MCP / 自动化完全指南](https://www.hubwiz.com/blog/agent-stack/)