五度妙笔
企业透视镜
API商城
数据库Multi-Agent 的收益边界：任务分解、协同增益与协调成本
Multi-Agent 正在成为 Agent 系统中最常见的架构选择之一。当单个 Agent 无法完成复杂任务时，一个直觉性的解决方案是增加 Agent：让一个 Agent 负责规划，几个 Agent 分头执行，再由另一个 Agent 汇总；或者让多个 Agent 分别推理、讨论、投票，希望通过“集体智能”得到比单 Agent 更好的结果。
但越来越多的公开实验正在显示一个反直觉的事实：Agent 数量增加，并不等于系统能力增加。
在一项对不同 Agent 架构进行受控比较的研究中，同样采用 Multi-Agent，在可分解的金融推理任务上，最佳架构相对 Single-Agent 提升了 80.8%；但在强顺序依赖的规划任务 PlanCraft 上，所有 Multi-Agent 架构都出现性能下降，最差达到 -70.0%。将六个 Benchmark 汇总后，Multi-Agent 相对 Single-Agent 的平均提升甚至只有 -0.3%。
这意味着，Multi-Agent 并不是一个简单的 Scaling 问题。真正值得回答的问题不是“应该使用几个 Agent”，而是：
本文尝试从这一问题出发，结合近期 Multi-Agent Benchmark 与 Anthropic 的实际系统案例，重新讨论 Multi-Agent 的收益边界。
Multi-Agent 最容易被看到的是收益。一个复杂任务被拆成多个子任务后，不同 Agent 可以同时工作；每个 Agent 可以拥有独立的 Context，从不同方向探索问题；不同 Agent 也可以配置不同模型、工具和 Prompt，引入能力互补。因此，Multi-Agent 理论上的收益至少包括三部分：
任务分解收益 + 并行收益 + 多样性收益。
但问题在于，每增加一个 Agent，系统同样会引入新的成本。为了分析这种成本，可以把 Multi-Agent 的整体净收益简化为：
Multi-Agent 净收益 = 分解收益 + 并行收益 + 多样性收益 - 协调成本
这里的“协调成本”并不仅仅是多调用几次模型产生的 Token Cost，而可以进一步拆为五类：
通信成本：Agent 间交换消息需要额外 Token 和 Context 整合成本：Manager 或其他 Agent 需要理解、筛选和合并多个结果 冗余成本：多个 Agent 可能重复搜索、推理甚至得出高度相似的答案 延迟成本：Agent 间存在依赖、等待、同步和重新规划 错误传播成本：一个 Agent 的错误可能被其他 Agent 当作事实继续传播
因此，本文关注的并不是“Multi-Agent 和 Single-Agent 谁更强”这样笼统的问题，而是比较四个维度：
任务效果：最终成功率是否真正提高； 计算效率：获得增益需要增加多少 Token、Tool Call 和延迟； 任务结构：任务是否能够被并行拆解，子任务间依赖有多强； 协作质量：多个 Agent 是否真正提供了互补信息，以及这些信息能否被正确整合。
从这几个维度来看，Multi-Agent 的适用边界正在变得越来越清楚。
讨论 Multi-Agent 的第一个问题，是如何定义一个公平的 Single-Agent baseline。假设 Single-Agent 完成一个任务消耗 1 万 Token，而一个由 5 个 Agent 构成的系统累计消耗 5 万甚至 10 万 Token。如果后者准确率更高，很难判断这种提升究竟来自“多个 Agent 的协作”，还是因为系统获得了更多 test-time compute。
2026 年的一项研究专门控制了这一变量。研究者在 Qwen3、DeepSeek-R1-Distill-Llama 和 Gemini 2.5 等不同模型上，将 Single-Agent 和不同 Multi-Agent 架构的 reasoning token budget 对齐。结果显示，在 multi-hop reasoning 任务上，当推理 Token 被控制在相同水平时，Single-Agent 持续达到或超过 Multi-Agent。作者进一步指出，一些已有 Multi-Agent Benchmark 中观察到的提升，可能混合了额外计算量和 Context 使用方式带来的收益，而不完全属于架构本身。这一结果并不能证明 Multi-Agent 没有价值，但它提示了一个非常重要的评测原则：
也就是说，实际观察到的性能变化可以理解为：
最终性能增益 = 额外计算带来的增益 + 协作架构带来的增益 - 协调成本
很多 Multi-Agent 系统表现更好，部分原因可能只是它允许系统更方便地消耗更多 Token、打开更多独立 Context Window、调用更多工具。
一个关键判断是：Multi-Agent 不应首先被理解为“能力增强技术”，而更应被理解为“计算组织技术”。
它真正组织的是模型的 test-time compute：哪些任务并行执行、哪些 Context 相互隔离、多少 Token 被分配给不同搜索路径、哪些结果最终进入主 Agent。因此，评价 Multi-Agent 时，单纯比较准确率是不够的。更有意义的指标应该是 Performance / Cost Frontier：在相同 Token 与延迟预算下，Multi-Agent 是否能获得 Single-Agent 无法达到的结果。
如果控制计算量之后 Multi-Agent 并不会天然胜出，那么什么因素真正决定它是否有效？目前最强的解释之一是：任务可分解性与子任务间依赖关系。
《Towards a Science of Scaling Agent Systems》比较了 Single、Independent、Centralized、Decentralized 和 Hybrid 五种架构，并在多个不同类型的 Benchmark 上进行受控实验。结果呈现出非常明显的两极分化。
在 Finance Agent 中，收入、成本、市场因素等问题可以相对独立地分析，再由上层进行汇总。Centralized Multi-Agent 相比 Single-Agent 获得了 +80.8% 的相对性能提升。
而在 PlanCraft 中，后续规划高度依赖之前形成的状态和约束。Multi-Agent 不仅没有带来增益，所有架构均出现下降，其中 Independent 架构下降 70.0%，即使表现最好的 Hybrid 架构也下降了 39.1%。
更值得注意的是，Finance Agent 与 PlanCraft 在论文定义的任务复杂度指标上其实非常接近，前者为 0.407，后者为 0.419。真正拉开二者 Multi-Agent 表现的并不是“任务难不难”，而是顺序依赖程度与可并行分解程度。研究最终同样认为，相比单纯的任务复杂度，sequential interdependence 更能解释协调是否值得。
因此，一个复杂任务并不会因为“复杂”就天然适合 Multi-Agent。例如，一个任务虽然包含 100 个步骤，但如果第 50 步必须严格依赖第 49 步形成的环境状态，那么把它拆给 10 个 Agent 并不能真正产生并行收益。相反，每次任务交接都可能造成状态丢失和重复理解。而一个只有 10 个步骤的研究任务，如果其中 8 个方向彼此独立，则可能非常适合让多个 Agent 同时搜索。因此，比“任务复杂度”更值得在系统设计阶段判断的是两个变量：
可分解性（Decomposability）和依赖强度（Dependency）。
可以把任务粗略划分成四类：
这也解释了为什么不同 Benchmark 对 Multi-Agent 会给出完全不同的答案：它们实际上测试的是完全不同的任务结构。
即使任务可以并行拆分，还存在第二个问题：增加更多 Agent 是否能够持续产生收益？
2026 年的一项研究从信息论角度研究了 Multi-Agent Scaling，结果发现，在使用相同模型、Prompt 和工具的 homogeneous MAS 中，Agent 数量增加后性能会很快出现明显的边际递减。原因并不复杂：多个高度相似的 Agent 很可能沿着相似的路径推理，提供的只是重复证据。相比之下，当 Agent 使用不同模型、Prompt 或工具时，系统获得的信息更加互补。在实验中，2 个 diverse agents 已经能够达到或超过 16 个 homogeneous agents 的表现。
研究进一步提出了“effective channel”的概念：如果两个 Agent 最终产生的推理路径高度相关，那么从信息增量来看，它们可能只相当于一个有效通道；只有真正提供非冗余信息的 Agent 才增加系统能力。这一结果对工程实践非常重要。目前很多 Multi-Agent 系统中的“角色分工”类似于：
Agent A：你是一名产品经理； Agent B：你是一名技术专家； Agent C：你是一名行业分析师。
但如果三个 Agent 背后使用的是完全相同的模型、Context、知识和工具，仅通过 System Prompt 创建不同 Persona，那么这种差异是否足以形成真正的能力互补，需要谨慎评估。相比之下，更有价值的异质性可能来自：
不同模型； 不同工具权限； 不同数据源； 不同 Context； 不同搜索空间； 不同验证机制。
换句话说，Multi-Agent 的核心资源不是 Agent Headcount，而是 Non-redundant Information。这也意味着，在增加 Agent 之前，更应该先判断新 Agent 能否获得其他 Agent 无法获得的信息。如果答案是否定的，那么增加 Agent 很可能只是在重复消耗 Token。
Multi-Agent 的另一个常见假设是：只要 Agent 之间能够正常交换信息，协作就能够发生。
Silo-Bench 对这一假设进行了更细粒度的验证。研究构建了 30 种算法任务、54 种配置，共进行了 1620 次实验，专门考察多个 Agent 在分布式信息环境中的协调能力。实验发现了一个非常有意思的现象：Agent 通常能够形成合理的通信拓扑，也会主动交换信息；很多失败案例中，负责最终决策的 Agent 实际上已经获得了解题所需要的信息。问题发生在下一步：
它无法把来自不同 Agent 的局部信息正确整合成全局状态。
研究将这一现象称为 Communication-Reasoning Gap。随着 Agent 数量增加，协调开销会继续累积，最终甚至可能完全抵消并行执行带来的收益。因此：
Communication ≠ Information Integration ≠ Coordination
“消息成功发送”只是 Multi-Agent 协作的最低层能力。真正困难的是，Agent B 收到 Agent A 的结果以后，能否准确理解：
这条信息对应哪个子任务； 它是在什么环境状态下产生的； 是否已经过期； 与其他 Agent 的结果是否冲突； 应该如何影响下一步决策。
随着 Agent 增多，这种问题会快速放大。另一项受控实验也观察到了类似的错误传播效应：Independent Multi-Agent 的 trace-level error amplification 达到 Single-Agent 的 17.2 倍，而加入 centralized verification 后可以降低到 4.4 倍。
因此，Multi-Agent 中真正昂贵的并不是“发消息”，而是维持一个一致、可验证的共享任务状态。这意味着工程设计不能简单依赖 Agent 之间用自然语言“开会”。Dependency、状态、任务完成条件以及验证结果，只要能够结构化，就应该尽可能交给程序和 Runtime 管理，而不是全部交给 LLM 自己理解。
如果前面的证据都在讨论 Multi-Agent 的成本，那么 Anthropic 的 Research 系统提供了一个很好的正向案例。
Anthropic 使用的是典型的 Orchestrator-Worker 架构：Lead Agent 先分析问题，并生成多个 Specialized Subagents；不同 Subagent 在独立 Context Window 中并行搜索不同方向，最后将压缩后的结果交还 Lead Agent 汇总。在 Anthropic 的内部 Research Eval 中，Claude Opus 4 作为 Lead Agent、Claude Sonnet 4 作为 Subagent 的 Multi-Agent 系统，相比单独使用 Claude Opus 4 性能提高了 90.2%。
但这个结果如果只理解为“Multi-Agent 比 Single-Agent 强 90%”，反而会错过其中最重要的信息。Anthropic 自己进一步分析 BrowseComp 结果后发现，Token usage 单独就可以解释约 80% 的性能方差；再加入 Tool Calls 和 Model Choice，三个变量共同解释约 95%。与此同时，Multi-Agent 系统平均消耗的 Token 大约是普通 Chat 的 15 倍。Anthropic 因此明确指出，Multi-Agent 更适合高价值、可以大量并行、需要处理超过单 Context 容量的信息，以及需要调用大量复杂工具的任务；而需要所有 Agent 持续共享同一 Context、子任务高度依赖的场景并不是当前 Multi-Agent 的理想应用。
Research 恰好满足这些条件。如果需要研究 20 家公司的公开信息，可以让不同 Agent 分别负责不同公司；一个 Agent 搜索失败，并不会直接破坏其他 19 个 Agent 的状态。各个结果还可以相对独立地检查和重试。因此，Anthropic Research 的成功并不是对前面结论的反例，反而很好地说明了 Multi-Agent 的收益边界：
它通过多个独立 Context Window 换取更广的搜索空间，以更高成本购买更高覆盖率。
综合这些研究，可以看到 Multi-Agent 并不存在一个简单的“规模越大越好”的规律。决定系统收益的至少有四个变量：
第一，任务是否可以独立分解。 如果子任务之间基本不存在状态依赖，并行执行能够真正缩短路径，Multi-Agent 更容易产生收益。
第二，Agent 是否具有真正的异质性。 新增 Agent 如果只是重复已有推理路径，边际收益会快速下降；不同模型、工具、数据源和搜索空间更有可能产生互补信息。
第三，中间结果能否独立验证。 如果每个 Agent 的结果都可以单独检查，一个局部错误就可以被隔离和重试；如果错误必须经过多个 Agent 才能暴露，错误传播成本会快速增加。
第四，任务价值能否覆盖额外成本。 即使 Multi-Agent 最终能够提高准确率，也仍然需要比较 Token、延迟和系统复杂度。对于低价值、高频任务，5% 的质量增益未必值得数倍的推理成本。
因此，在 Agent 系统设计中，更建议采用下面的决策顺序：
Step 1：先画 Task Dependency Graph。
不要先定义 Agent，而是先把任务拆成工作单元，并标注它们之间的依赖关系。
Step 2：判断哪些工作单元可以并行。
如果大多数节点形成长链式依赖，优先考虑 Single-Agent + Workflow；如果存在大量相互独立的分支，再考虑 Multi-Agent。
Step 3：判断新增 Agent 是否提供新的有效信息通道。
模型、工具、数据、Context 和搜索方向至少应该有一种形成实质差异。
Step 4：为关键汇合点增加 Verification。
尤其是在多个分支结果重新汇入主流程时，不应该默认所有 Agent 输出都可信，需要通过规则、环境状态、代码执行或独立 Reviewer 进行验证。
Step 5：同时评测效果和成本。
除了 Task Success Rate，还应该记录 Token、Tool Call、Latency、错误恢复次数以及 Cost per Successful Task。只有这样，才能判断 Multi-Agent 是否真的处于更好的性能—成本前沿。
一个关键结论是：未来 Multi-Agent 系统真正应该 Scale 的，不是 Agent 数量，而是“独立可验证的工作单元”。
Agent 数量只是任务拆分之后自然产生的结果，不应该成为架构设计的起点。
如果一个任务能够拆成 10 个彼此独立、可以并行执行、结果能够单独验证的工作单元，那么使用多个 Agent 可能非常合理。
但如果一个任务本质上只有一条高度耦合的执行路径，那么同时启动 10 个 Agent，很多时候只是让 10 个模型围绕同一个问题消耗更多 Token。
Multi-Agent 的价值已经越来越清楚：它本质上不是“多加几个 Agent 就更强”，而是一种对任务结构进行重组的系统设计方法。是否值得使用，关键不在规模，而在任务能否被合理拆分，以及拆分后的协调成本是否可控。
从现有研究来看，Multi-Agent 只有在任务具备较高可分解性、并行性、信息互补性，并且中间结果可验证时才更可能带来收益；否则往往只是把单模型问题变成更复杂的协调问题。因此工程上更合理的路径是：先建立强 Single-Agent baseline，再基于任务依赖关系决定是否引入 Agent 拆分，而不是一开始就“角色化设计系统”。在系统设计上，重点也不应是增加 Agent 之间的对话，而是尽可能结构化任务边界、状态与验证机制，让自然语言协作只发生在真正需要不确定性判断的部分。评估 Multi-Agent 时，也不能只看成功率，而要同时考虑成本、延迟与单位任务收益，判断其是否真正改善了 performance/cost trade-off。
从长期来看，Multi-Agent 的核心价值不在“更多 Agent”，而在于更清晰的任务分工与更高质量的并行结构。同质 Agent 的简单扩展会逐渐失效，真正有意义的是互补能力之间的组合。因此，一个更本质的问题是：
不是“需要多少个 Agent”，而是“这个任务是否真的需要被拆开”。
参考文献
Kim, Y., Gu, K., Park, C., et al. Towards a Science of Scaling Agent Systems. arXiv:2512.08296, 2025. Tran, D., & Kiela, D. Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets. arXiv:2604.02460, 2026. Yang, Y., et al. Understanding Agent Scaling in LLM-Based Multi-Agent Systems via Diversity. arXiv:2602.03794, 2026. Zhang, Y., et al. Silo-Bench: A Scalable Environment for Evaluating Distributed Coordination in Multi-Agent LLM Systems. arXiv:2603.01045, 2026. Hadfield, J., et al. How We Built Our Multi-Agent Research System. Anthropic Engineering, 2025.
