正在加载，请稍候
Cohere Labs 实测：多智能体团队比单智能体强，但贵 3–7 倍；异构 17 个只比同构 5 个高 1.4 分、成本低 70%。算力该投在哪一层，附验收门禁对照表。
Cohere Labs 的一项新实测给出反直觉结论：多智能体团队确实比单智能体强，但贵 3–7 倍；把预算押在「多派几个执行者」上，是最常见、也最容易亏的一种花法。
关键数字：3–7 倍成本、1.4 分差距、70% 成本下降、47.5% / 13.9%、4 个 worker 天花板、评审轮次 2.08→1.32。
在 ProgramBench 基准上，多智能体团队确实稳定优于单智能体，代价是 3 到 7 倍的成本——这是 Cohere Labs 团队 2026 年 10 月 12 日登上 arXiv 的实测结论（arXiv:2610.17471）。
这篇文章值得 B 端团队读的地方在于，它没有停留在「多智能体更好」的结论上，而是把团队设计直接建模成一个算力分配问题：从单个智能体出发，多出来的这部分推理算力究竟该投到哪个环节，才能推到收益—成本帕累托前沿上。
实验做法很克制：从零搭一个最小多智能体框架，然后每次只改一个变量——lead 在哪个阶段（规划、实现、验证）把任务下发给 worker、团队由哪些模型组成、worker 数量多少。
结果里最值得记住的一条是：一个异构的 17 个智能体团队，与一个全强模型的同构 5 个智能体团队只差 1.4 分，成本却低 70%。换句话说，团队的「人数」不是主变量，「谁在什么位置」才是。把 17 个和 5 个拿来比，差距远小于直觉预期，这正是成本陷阱的来源——多花的钱并没有买回同等比例的收益。同样务实的判断，在站内另一篇讨论「模型还是 Harness 决定 AI 编程成败」的工程真相拆解里也能看到：真正决定产出的是编排与护栏，而不是把模型堆得更多。
同一篇论文给出的答案是：多出来的算力优先投给规划层——只把规划委派出去、自己负责实现与验证的 lead，能以约一半的成本拿到与「全过程委派」持平的收益。
这条结论来自一个很干净的对照：在同构团队里，让 lead 自己决定要 spawn 多少 worker，然后把「只委派规划」和「规划、实现、验证全程委派」两种策略直接对打。结果是收益持平、成本减半。对做交付的技术负责人来说，这意味着一个可执行的动作顺序——先给规划阶段加预算，不要先给执行阶段加人手。
论文里还有两条同样有操作价值的发现：
把这三点合起来看，一份可参考的预算分配原则大致是：lead 用强模型、规划层的 worker 可以便宜且可以多、实现和验证层的 worker 控制在 4 个以内并且别降级模型。
因为代码写得越快，评审就承担越多返工——Anthropic 在 2026 年 6 月到 9 月合并的 PR 数量翻倍以上，revert 率下降超过 40%，但评审人力成了新的瓶颈，这部分成本会直接抵消多智能体在编码环节省下的算力。
Anthropic 在官方博客 solving-code-review-at-anthropic 里公开了这次重构的细节。这里只谈与成本相关的两点，机制层面的七道闸门设计我们此前已经单独拆过（见评审闸门拆解）。
第一，评审会陷入「翻旧账」的死循环。他们曾有一个由子智能体写的 CLI PR，一夜之间跑了 50 多轮评审，而 git blame 显示被反复标记的代码里约 59% 在第一轮评审之前就已经存在于代码库。每一次这样的轮次都在烧算力和人类等待时间，却不产生任何缺陷修复。
第二，把评审本身当作可评测系统，才能把成本曲线压下来。Anthropic 的解法是三条硬约束——三轮封顶（超过就退回来重新考虑方案）、后续轮次只看增量 diff、标记 bug 类别而非单行且禁止重复发现。结果是平均评审轮次从 2.08 降到 1.32，5 轮以上的 PR 占比从 8.9% 降到 1.5%，一轮通过率从 65% 提升到 78%。轮次下降 37% 意味着评审环节的算力与人力开销同步下降。
Anthropic 更有迁移价值的一点是：他们把过去引发事故、经专家确认的 PR 做成 eval 集，让评审器每天跑分，只有分数提升的改动才被保留——评审质量因此变成可度量、可优化的目标，而不是主观感受。
这本质上是把「评审」也当成一条要算投入产出的产线：噪声用两个指标度量（人对评论的反应、在已知干净的 PR 上跑评审器看误报），改动只有在评分提升时才保留。同期站内对移动端 AI 编码落地数据做过一次统计，结论与这里一致——工具铺开之后，卡住交付的往往不是生成能力，而是验证与验收环节。
下表数字全部来自 arXiv:2610.17471 在 ProgramBench 上的实验，口径是单一基准、单篇论文的实验设定，不能直接外推成「所有团队都如此」。
| 配置 | 相对成本 | 收益表现 | 适合的场景 |
|---|---|---|---|
| 单智能体（先想更久 / 多采样） | 基准 1× | 基准 | 任务小、上下文集中、验收信号明确 |
| 同构 5 个（全强模型） | 高于单智能体，但显著低于大团队 | 作为对照基准 | 任务可清晰拆解，预算充足 |
| 异构 17 个（强 lead + 便宜 planner） | 比同构 5 个低 70% | 与同构 5 个仅差 1.4 分 | 规划密集、实现相对标准化的任务 |
判断标准只有两条：任务能被拆成可并行的子问题，且存在可自动化的验收信号——两条都满足再谈多智能体，否则先把门禁建起来。
翻回第一节的实验设定，多智能体的收益建立在「委派—汇总」这套结构上；如果任务本身无法拆解，多出来的智能体只会制造重复劳动和协调失败——论文里也明确把 duplicate work 和 coordination failures 列为典型损耗。而验收信号缺失的团队，问题会更直接：你无法判断交回来的东西到底对不对，多智能体只是把这个判断难题放大到 17 倍。已有团队用多智能体去做存量维护类的脏活，比如一次清理 6 万多个开关的配置债回收，这类任务的特征恰好是「可拆解 + 可验收」。
实操上建议按这个顺序走：先有可执行的测试与构建（哪怕只覆盖核心路径），再把「人类审批人数」和「等待时间」变成看板指标，最后才是引入规划层 worker 扩容。蓝曜炬辉在广州给企业做软件定制交付时，评估是否把多智能体工作流接进交付流程，用的也是同一套顺序——先看验收能不能自动化，再谈并行度；需要把 AI 编码流程接进现有研发体系的团队，可以从我们的服务了解工程化做法。
不一定，多智能体团队在 ProgramBench 上确实优于单智能体，但成本是 3 到 7 倍，且收益高度依赖算力分配方式；任务无法拆解时，多出来的智能体主要产生重复劳动与协调失败。所以在引入前应先确认任务可并行、验收可自动化，再决定是否扩团队。
能，但只能放在规划层——实验显示强 lead 配便宜 planner 可获得全强模型团队收益增益的 47.5%，而额外成本仅 13.9%；把便宜模型放到实现环节反而会拉低收益。验证层的情况类似：不是越便宜越好，而是要匹配位置。
按论文的规模曲线，执行者与验证者超过 4 个后收益进入平台期，规划者则持续上升，因此可先把规划层扩到 4 个以上，而把实现与验证层控制在 4 个以内。这个 4 是 ProgramBench 实验设定下的拐点，不是普遍常数，实际取值要在自己的任务集上复测。
取决于有没有给评审加约束——Anthropic 的实践是：内部 PR 的实质性评审意见占比从 16% 提升到 54%，同时通过三轮封顶、只审增量 diff、禁止重复发现，把一轮通过率从 65% 拉到 78%。缺少这些约束时，评审器会在旧代码上打转，反而拖慢合并并推高成本。
先补最小可用的验收信号再上多智能体，因为多智能体的结构天然依赖「委派—汇总」的判定；建议先把核心路径的测试与构建跑通，并把人类审批人数和等待时间变成团队看板指标，再考虑扩大团队规模。这条顺序比选模型更影响最终成本。