背景：多智能体正在从卖点变成默认配置
近一年里，主流模型厂商先后把多智能体能力做进了原生产品：主智能体可以派生子智能体，把任务的一部分交给每一个，再把返回的结果组装起来。编排框架、编码工具与企业平台也普遍把「派一支团队出去」当作进阶用法写在文档里。行业叙事大致是同一个：多个智能体并行推进，比一个智能体单干更快、更全面。
这类叙事长期缺少一个东西——和分数并排印出来的账单。多数公开材料只报质量，不报成本；或者只报「用了多少个子智能体」，不报「多花了多少钱」。Vals AI 这次实验的价值，恰恰在于把两个坐标同时摆了出来，并且用配对检验标出了哪些差异能被与随机波动区分开。
需要预先说明的是：得出「团队不划算」这个结论并不困难，难的是说清楚在什么条件下划算。Vals AI 自己的措辞相当克制——团队是否值得，取决于模型、任务与预算；团队可以提升表现，但提高推理强度是一个值得权衡的替代方案。
基准：Vals AI 自建 Vibe Code Bench，从产品规格出发构建完整 Web 应用，每个应用以 Docker Compose 部署，由浏览器智能体点击走查工作流评分。被测模型：GPT-6 Sol（经 OpenAI Agents API 运行）与 Claude Opus 5.5（经 Claude Code 命令行 headless 模式运行）。条件：单智能体与团队（主智能体最多同时派生五个子智能体，子智能体不可再派生）两种形态，中档与最大档两档推理强度，共八组配置，每组在同样的 50 个应用上各运行一次。评分为单个应用 UI 测试通过比例，再在 50 个应用上取平均。
实验设计：八组配置，50 个应用
几个设计细节决定了结果该怎么读。
其一，团队形态的定义是「主智能体加最多五个并发子智能体」，且子智能体不能继续派生。两个主智能体收到的是同一段简短指令：把工作拆成彼此独立的部分，逐个委派，然后集成并验证结果。除此之外，任务提示、沙箱与评分器在各自模型的对照内保持一致。
其二，评的是交付物的实际可用性，不是代码观感。每个应用部署后被浏览器智能体走查，接缝处的缺陷（例如界面字段名与数据库结构不一致）会直接体现在分数上。这个设计让「看起来完成了」和「真的能跑通」被区分开。
其三，八组配置各跑一次。这一点对后续所有统计结论的解释力有直接影响，下文会展开。
主结果：分数、成本与中位耗时
下表汇总八组配置的得分、每应用平均成本与中位运行时间。成本为 Vals AI 按模型用量折算的每应用平均值，不等于订阅价格，也不等于每通过一项 UI 测试的成本。
| 模型与强度 | 单智能体得分 | 团队得分 | 单智能体成本 | 团队成本 | 成本倍数 | 单智能体中位耗时 | 团队中位耗时 |
|---|---|---|---|---|---|---|---|
| GPT-6 Sol · 中档 | 77.6% | 84.9% | $1.22 | $3.07 | 2.5 倍 | 12.4 分钟 | 11.9 分钟 |
| GPT-6 Sol · 最大 | 89.0% | 90.4% | $4.82 | $8.54 | 1.8 倍 | 38.4 分钟 | 27.6 分钟 |
| Claude Opus 5.5 · 中档 | 91.5% | 91.2% | $4.08 | $9.10 | 2.2 倍 | 20.3 分钟 | 26.6 分钟 |
| Claude Opus 5.5 · 最大 | 89.8% | 93.2% | $23.77 | $121.95 | 5.1 倍 | 74.7 分钟 | 174.1 分钟 |
几处值得单独点出的读数。整张表的最高分是 Claude Opus 5.5 最大档团队的 93.2%，但它同时是账单最重的一档——每应用约 122 美元、中位耗时接近三小时。而同一模型的中档单智能体拿到 91.5%，只花 4.08 美元、中位二十分钟出头。两者相差不到两个百分点，成本相差约三十倍。
对 GPT-6 Sol 而言，提高推理强度比组团队更有效：最大档单智能体比中档单智能体高出 11.4 分（89.0% 对 77.6%，p 小于 0.001），幅度超过任何一组团队增益；代价是每应用 4.82 美元对中档团队 3.07 美元，且中位耗时是后者的三倍。对 Opus 而言，两条杠杆都不太灵：最大档单智能体反而比中档单智能体低 1.7 分（p 等于 0.48），组团队在两档下也都没有跨过显著性门槛。
显著性：只有一组站得住
Vals AI 对同一批 50 个应用做了配对 t 检验。四组「团队对单智能体」的同强度比较中，只有一组差异能被与随机波动区分开。
| 比较组 | 单智能体 | 团队 | 差值 | 95% 置信区间 | p 值 | 是否显著 |
|---|---|---|---|---|---|---|
| Sol · 中档 | 77.6% | 84.9% | +7.3 分 | +2.3 到 +12.4 分 | 0.005 | 是 |
| Sol · 最大 | 89.0% | 90.4% | +1.4 分 | −1.7 到 +4.5 分 | 0.16 至 0.81 区间 | 否 |
| Opus · 中档 | 91.5% | 91.2% | −0.3 分 | −3.2 到 +2.5 分 | 0.16 至 0.81 区间 | 否 |
| Opus · 最大 | 89.8% | 93.2% | +3.4 分 | −1.4 到 +8.3 分 | 0.16 至 0.81 区间 | 否 |
「不显著」在这里的含义需要说清楚：它表示在这个样本量下，观察到的差异无法与运气区分开，并不等于两者表现相同。Opus 最大档团队的置信区间从 −1.4 分延伸到 +8.3 分，既容纳「毫无效果」，也容纳「效果可观」。五十个应用是中等偏小的样本，而八组配置每组只跑了一次，因此这些区间反映的是应用之间的变异，而不是重复运行之间的变异。这个宽度的无效结果，比它听起来要弱。
如果有人向你推销「智能体集群」并承诺质量提升，正确的追问顺序是：同一任务上、单个智能体提高推理强度能拿多少分，那一档的成本是多少，以及这个差距有没有做过重复运行检验。在这份数据里，最贵的配置与最便宜的 Opus 配置分数几乎持平，而便宜的那档快了七倍多。把「派团队」从质量杠杆重新定位为延迟杠杆，是这份研究最直接的落地结论。
成本归因：缓存输入是主要推手
团队为什么贵这么多？Vals AI 的归因指向缓存输入：每个子智能体都持有自己的上下文副本，包含产品规格与自己的工作进展，而这份内容在每次模型调用时都会被重新发送。换句话说，团队为一遍遍地重读同一份材料付钱。
以 Opus 最大档为例，每应用中位缓存 token 读取量为：子智能体合计约 2.24 亿，主智能体约 1700 万，而单智能体约 5500 万。中位水平下，该档子智能体单次运行耗时约 46 分钟，中档则为 7 分钟——更长的运行意味着更多次上下文重发，两者是相互放大的关系。
成本口径上有两处需要自行标注的局限。其一，Sol 的成本计算假设其报告的 token 用量已包含子智能体，且超过 272K 长上下文阈值的请求会按更高单价计费，但由于用量按「每次运行」而非「每次请求」上报，作者无法评估这部分附加计费。其二，Opus 最大档团队有一次运行在验证阶段超时，其约 189 美元的成本是按 token 计数估算后计入均值的。因此这两个模型的成本不宜跨模型精确比较。
编排行为：两个主智能体的两种打法
同样是「主智能体加子智能体」，两个模型的实际打法差别很大，这也解释了为什么一个拿到了显著增益、一个没有。
| 维度 | GPT-6 Sol 团队 | Claude Opus 5.5 团队 |
|---|---|---|
| 拆分依据 | 按架构线切分（数据库与种子数据、接口、界面、部署），开局约一分钟内建完全部子智能体 | 先写共享契约文档（多为 CONTRACT.md）约定结构、路由与文件归属，再分波派生 |
| 波次形态 | 并行推进，约三分之一运行时间在等待子智能体 | 顺序波次，每波等待最慢成员；最大档增加「基础—功能—测试与审查」三波 |
| 子智能体规模（最大档） | 每应用约 5.1 个，后续请求约 31 次 | 每应用约 6.8 个，子智能体工具调用约 1140 次（单智能体约 270 次） |
| 自测行为 | 主智能体自己驱动无头浏览器走查，两档均 46/50 次；浏览器测试约为单智能体两倍，多在公开地址而非沙箱本地端口 | 测试子智能体在最大档全部 50 次运行中存在，每应用约 36 次浏览器测试，为同档单智能体的六倍 |
| 对耗时的影响 | 中档略快（11.9 对 12.4 分钟），最大档明显更快（27.6 对 38.4 分钟） | 两档都变慢，最大档最长达单智能体的 2.3 倍；4 次运行超过四小时，其中 1 次触达 5.25 小时上限 |
一个容易被忽略的细节：Opus 最大档团队在首次部署之后，把三分之二的运行时间花在了后续环节上，中位测试投入高达 67.8 个智能体分钟，而同档单智能体只有 9.6。这些时间并非空转，而是子智能体在工作；但更长的运行并没有换来更高的分数——作者明确表示，该档团队的运行时长与其相对单智能体的增益之间没有相关性。
增益来自哪里：困难应用与被跳过的功能
Sol 中档团队的 +7.3 分不是均匀分布的：24 个应用得分更高，11 个更低，15 个持平。增益集中在更难的应用上，平均约 15 分；在较容易的应用上只有约 1 分。
在 9 个增益达到 20 分或更多的应用上，作者观察到的模式很有代表性：单智能体报告测试通过，但某些功能从未被构建，整个工作流从未被尝试；团队则覆盖了更多规格条目，并由主智能体交叉核对分别构建的部件，抓出了不匹配——例如表单字段与数据库结构对不上，或者权限规则阻塞了某个步骤。每个修复被退回给拥有该文件的子智能体。
Opus 的增减分布更接近平衡，也不偏向更难的应用：中档 14 个更高、15 个更低，最大档 13 个更高、8 个更低。作者另外检查了规格长度、UI 测试数量、单用户与多用户等属性，均未发现一致影响；只有「具有更多不同用户角色的应用」在 Sol 中档团队那一组拿到了约 15 分增益，而其它配置没有复现这一效应。
把这些放在一起看，团队真正起作用的地方是「能被干净切开、且切口处需要交叉验证」的任务。这也和作者自己对下一步的判断一致：团队更可能在拥有许多独立部分、可长段分离的工作上收回成本，例如大型代码库、覆盖面广的研究问题，或者跨多文档的分析。
口径警示与冷静判断
- 单一基准，泛化性有限：作者明确声明，这些观察来自一个全栈 Web 应用基准，可能不适用于其它类型的工作。构建 Web 应用是一项偏线性的任务，研究、分析、长周期软件维护等场景未被覆盖。
- 每组只运行一次：置信区间与 p 值反映的是跨应用的变异，而不是重复运行之间的变异。要判断 Sol 中档团队的 +7.3 分是否稳定可复现，需要多次重复运行，而这正是本次实验没有做的。
- 对照组并不纯粹：团队那一侧额外收到了一段委派指令，因此每组比较实质上是「子智能体加委派提示」对「两者都没有」，而不只是「有子智能体」对「没有子智能体」。委派提示本身可能贡献了一部分增益。
- 跨模型比较混淆了模型与运行框架：Sol 经 OpenAI Agents API 运行，Opus 经 Claude Code 命令行运行。因此两个模型之间的任何对比，都把模型能力与它所用的 Harness 混在了一起，不能当作纯粹的模型对比来读。
- 可观测性不对等：Claude Code 记录每个子智能体的工具调用，而 OpenAI Agents API 的事件流只含主智能体的轮次——对 Sol 只能看到何时创建、发消息、等待，看不到它告诉了子智能体什么。Sol 的日志也不记录主智能体的文件编辑，因此无法判断主智能体自己写了多少代码。
- 成本口径存在软点：Sol 成本假设 token 用量已含子智能体且未计入长上下文附加计费，Opus 成本含一次按 token 估算的超时运行；两个模型的成本不宜直接横向比较。
- 外部佐证多为转述：Anthropic Opus 5.5 系统卡中「智能体数量从 1 增到 100、24 小时后得分仅微增」的结论，以及 OpenAI 研究员关于多智能体主要买速度而非质量的观点，均来自媒体报道转述，本文未获取一手系统卡原文，引用时应按转述口径处理。
- 结论不是「团队无用」：在 Sol 中档这一组，团队确实拿到了显著且可解释的增益，而且几乎不增加中位耗时。这份研究否定的是「多派智能体等于更好」的默认假设，不是多智能体本身。
把这份数据换算成一句可执行的选型建议：先测单个智能体在最高可接受推理强度下的分数与单价，再测团队在同任务上的分数与单价，并要求至少重复运行若干次以确认差异稳定。如果团队的成本倍数在两倍以上而增益落在置信区间含零的区间里，那么这笔钱换来的多半是速度，而不是质量。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。