Agent Systems

Multi-Agent 一定比单 Agent 更好吗？

Mason2026.07.2912 MIN

过去两年，Multi-Agent System 几乎成了 Agent 领域的默认架构选项。Planner、Researcher、Coder、Reviewer 排成一列，看着就像一支分工明确的团队，很难不让人觉得“多个 Agent 天然优于单个 Agent”。但翻开论文和实际项目，它并不是自动放大智能的魔法。真正该问的是：这件事，值不值得拆给多个 Agent 来做。

先说结论

Multi-Agent 并不一定比单 Agent 更好。它真正擅长的，不是让模型凭空变得更聪明，而是扩大测试时计算、并行处理子任务、隔离不同上下文，并组织具有不同工具与职责的执行模块。

对于简单或中等复杂度任务，一个强单 Agent 配合良好的任务分解、上下文管理、工具调用和验证机制，通常更便宜、更快，也更稳定。对于高度并行、信息密集、工具复杂且结果可验证的高价值任务，Multi-Agent 才可能带来显著收益。

如果只保留一条原则，我会写成：使用完成任务所需的最少 Agent，并且只在协作能够产生明确信息增量时增加 Agent。

Multi-Agent 为什么看起来更强

Multi-Agent 最直接的优势，是把复杂任务拆成相对独立的子任务。例如一份行业研究报告，可以拆成市场规模搜索、竞争对手分析、技术趋势梳理、风险分析和最终撰写；多个 Agent 分别处理，再由主 Agent 汇总。

AgentVerse将流程划分为专家招募、协同决策、行动执行和结果评估，并在部分推理、编码与环境任务中取得优于单 Agent 的结果。ChatDev则把软件开发拆成设计、编码和测试等角色，通过自然语言与代码交流提升完整性、可执行性与需求一致性。

另一类方法甚至不强调复杂角色分工，只是让同一模型生成多个独立答案再投票。More Agents Is All You Need发现，在一些推理和生成任务中，并行采样实例增加后性能可以提升。Mixture-of-Agents则让多个模型先独立生成候选，再由后续模型整合，在 AlpacaEval 与 MT-Bench 等评估中表现较好。

这些结果说明：增加 Agent 数量确实可能管用。但容易忽略的一点是——这种提升未必来自我们想象中的“社会化协作智能”。很多时候只是推理预算变大了。

提升效果的可能不是协作，而是更多计算

假设模型只生成一次答案，它可能因采样随机性、局部推理错误或遗漏信息而失败。若生成十次再投票，正确答案被选中的概率自然可能提高。把这十次调用包装成十个 Agent，从本质上看更接近集成学习或测试时计算扩展，而不是十个真正具备不同知识与能力的智能主体。

Anthropic 在构建多智能体 Research 系统时发现，在 BrowseComp 搜索评估中，token 使用量、工具调用次数和模型选择可以解释约 95% 的性能差异，其中仅 token 使用量就解释了约 80%。换句话说，多 Agent 系统表现更好，很大程度上是因为它调用了更多模型、执行了更多搜索，并投入了更多推理资源。详见其工程文章How We Built Our Multi-Agent Research System。

这不是说 Multi-Agent 没有价值，而是说比较得公平。如果 Multi-Agent 调用模型二十次，而单 Agent 只调用一次，我们其实同时改变了两个变量：架构和计算预算。效果的提升，不能全部归因于 Agent 之间的协作。

RULE

更公平的比较是：在相同或相近的 token、工具调用次数、延迟和费用下，Multi-Agent 是否仍然优于经过良好设计的单 Agent？在这个前提下，优势往往会明显缩小。

强单 Agent 可能已经足够

一项针对多智能体讨论的系统性研究发现：当单 Agent 使用较强模型和较完善的 Prompt 时，其表现可以接近最好的多 Agent 讨论框架。多 Agent 的优势主要出现在单 Agent 缺少示例、提示不足或初始推理能力较弱的场景中。研究还观察到两种典型错误：负责裁决的 Agent 作出错误判断，以及原本回答正确的 Agent 被错误共识说服，从而改成错误答案。见Rethinking the Bounds of LLM Reasoning。

换句话说：多个 Agent 坐在一起讨论，不等于多个独立观点就能被正确整合。如果这些 Agent 使用同一个模型、相似的 Prompt 和相同的信息来源，犯的错也会高度相关——同一种幻觉同时出现，再经过讨论互相强化。

这种情况下，多 Agent 并没有带来真正的多样性，只是把同一种偏差复读了好几遍。倒不如把精力花在一个强单 Agent 上——清晰的任务分解、合理的工具调用、结构化中间状态和结果验证，往往就够完成许多中等复杂度任务。与其直接堆 Agent 数量，不如先改善主 Agent 的上下文管理、规划能力和验证流程。

Multi-Agent 会引入新的失败模式

单 Agent 的主要风险通常是理解错误、推理错误、工具调用失败和上下文丢失。Multi-Agent 不仅继承这些问题，还额外增加了 Agent 之间的协调问题。

2025 年的研究Why Do Multi-Agent LLM Systems Fail?分析了多种多智能体框架与大量任务，总结出 14 类失败模式，并归纳为三组：任务规格与系统设计失败、Agent 之间的信息或目标不一致，以及验证和终止机制失败。

一个典型问题是信息没有被正确传递：执行 Agent 已经发现关键要求，却没有告诉管理 Agent；管理 Agent 也没有主动询问，最后导致整条流程反复失败。另一个问题是无效交流：多个 Agent 多轮讨论、消耗大量 token，却没有真正更新方案。系统看起来执行了复杂协作，但对话并未产生有效的信息增量——该研究观察到，一些软件开发 Agent 在经过多个角色和多轮交流后，仍然没有修复最初代码中的核心问题。

此外，多 Agent 还容易出现错误级联。假如 Planner 一开始就错误理解用户需求，后续 Researcher、Coder 和 Reviewer 都可能在错误规划上继续工作。随着流程向后执行，错误会被包装得越来越完整，也越来越难被发现。

BOUNDARY

多 Agent 不仅需要执行能力，还需要能够验证任务方向、中间结果和最终输出的可靠控制机制。没有验证，协作只会放大噪声。

通信本身具有成本

Agent 之间每交流一次，就是一次新的模型调用。一个 Agent 的输出成为另一个的输入；为了让各方理解当前状态，系统还可能重复提供用户需求、任务规划、中间文件和历史对话。

这会带来三种成本。

首先是直接的 token 费用。Anthropic 披露：普通 Agent 工作流通常消耗约普通聊天四倍的 token，而多 Agent 系统可能消耗约普通聊天十五倍的 token。也就是说，多 Agent 只有在任务价值能撑住这笔额外开销时，才算经济上划算。

其次是延迟。若多个 Agent 必须依次执行，增加数量只会拉长调用链；即便部分任务可并行，最终汇总与验证仍要等待最慢的 Agent。

最后是上下文成本。把所有 Agent 的完整对话都传给下一个节点，会导致上下文快速膨胀；真正重要的任务约束反而可能被淹没。

因此，成熟的 Multi-Agent 系统通常不会简单广播全部历史，而是让子 Agent 只返回结构化结果、摘要、文件引用或验证结论。

什么情况下 Multi-Agent 更值得使用

我会先看三类信号。

01 / 可并行
子任务依赖较少，例如同时检索多篇论文、调查多家公司，或检查多个代码模块。
02 / 需隔离
不同步骤需要不同工具、权限或上下文，例如数据库只读、网页搜索与安全审查分开。
03 / 可验证
中间结果存在客观标准：单元测试、符号计算、查询回读，而不是纯主观共识。

Anthropic 的多智能体研究系统采用 Orchestrator-Worker 架构：主 Agent 负责规划，再把不同搜索方向分配给并行子 Agent。他们同时指出，多 Agent 更适合高度并行、信息量超过单一上下文窗口，或需要操作大量复杂工具的高价值任务。

但如果任务本身缺少客观标准——开放式战略判断、价值观讨论或高度主观的文案评价——增加多个 Critic 和 Judge 并不一定得到更正确的答案，可能只是得到一个更加冗长的共识。

什么情况下单 Agent 更合适

当任务规模较小、执行步骤高度串行、所有步骤都依赖同一份完整上下文时，单 Agent 通常更加稳定。修改一封邮件、分析一段代码、整理一次会议记录或回答一个明确问题，都没有必要固定调用 Planner、Writer、Reviewer 和 Judge。一个强模型通过一次或少量几次调用通常就能完成。

当延迟和成本非常重要时，单 Agent 也更加合适。客服、实时交互、输入分类和简单工具调用通常要求快速响应，复杂的多 Agent 协商流程可能得不偿失。

再有，如果没有靠谱的验证器兜底，多 Agent 也未必能提高可信度。让同一个模型扮演 Critic，不保证它能抓住另一个实例的错。尤其当多个 Agent 共享同样的知识缺口时，它们很可能一起点头，达成一个自信但错误的共识。

更合理的方案：单主 Agent，加按需子 Agent

固定的 Multi-Agent 流水线和永远只用单 Agent 之间，其实还有一种更务实的做法：

默认使用一个主 Agent；只有当任务出现明确的并行、专业化或上下文隔离需求时，才临时调用子 Agent。

例如，主 Agent 收到任务后先评估复杂度。简单回答直接完成；需要调查三个相互独立的市场时，并行创建三个研究子 Agent；实现完成后若需检查代码安全，再调用安全审查 Agent。子 Agent 完成后只返回必要结果或结构化摘要，由主 Agent 保持对最终答案的控制。

OpenAI 的Agent 编排文档同样建议尽可能从一个 Agent 开始，只有当专业 Agent 能明显改善能力隔离、策略隔离、Prompt 清晰度或执行轨迹时才拆分；并区分让专业 Agent 接管对话的 Handoff，以及由主 Agent 把专业 Agent 当作工具调用的 Manager 模式。

LangChain 的多 Agent 文档也指出：并不是每一个复杂任务都需要多 Agent；一个具有合适工具和动态 Prompt 的单 Agent，经常能够取得相似效果。

这种按需组合避开了固定流水线的包袱：简单任务不多花一分钱，复杂任务照样能拿到并行搜索和专业分工的好处。

如何判断是否应该使用 Multi-Agent

在设计系统之前，可以先回答下面几个问题。

01 / 可拆分吗
任务能否拆成相对独立的子任务，且这些子任务真的能够并行？
02 / 有差异吗
不同 Agent 是否拥有不同的工具、信息、模型或权限，而不只是同一 Prompt 的复读？
03 / 能验证吗
中间结果是否可以被客观验证，而不是依赖另一个同质模型扮演 Critic？
04 / 划算吗
性能提升是否足以覆盖额外的 token、延迟、维护成本与协调风险？

如果这些问题大多答不上来，那加 Agent 多半只是在增加架构复杂度。一个实用的判断公式是：

Multi-Agent 净价值
= 并行收益 + 专业化收益 + 验证收益
− 通信成本 − 推理成本 − 协调风险 − 错误传播风险

只有当左侧收益明显大于右侧成本时，多 Agent 才是合理选择。