Multi-Agent 架构：什么时候该用，什么时候不该用？
TL;DR: 只有 11% 的企业真的在生产跑 agent。Google DeepMind：超过 4 个 agent 错误放大 17 倍。我们 6 人团队的经验：大多数时候单 agent 就够了。
Deloitte 2025年的调查：只有 11% 的企业真正在生产环境跑 agentic AI。Gartner 预测：40% 以上的 agentic AI 项目将在 2027 年前被取消。不是暂停——是取消。
u/MorroHsu，Manus 的后端负责人，做了 2 年 agent 系统。最后换回了一个 Unix CLI 工具。
我们自己也搭了一个 6 人 agent 团队——Researcher、Tech Lead、Product Owner、Verifier、Content Writer、King。然后发现，大多数时候根本不需要它。
核心原则：大多数团队不需要 Multi-Agent
Anthropic 的立场很明确：大多数团队不需要 Multi-Agent 系统。在单个 Agent 上反复打磨 prompt，效果可以匹配那些花了几个月搭建的复杂多 Agent 架构。
代价是真实的：
- 普通 Agent 的 token 消耗大约是聊天的 4 倍
- Multi-Agent 系统大约 15 倍
这些额外开销来自跨 Agent 的上下文复制、协调消息、结果汇总。
实际数字：4 个 agent 处理同一任务用了 35,000 token，单 agent 只需 10,000。3.5 倍的成本，还没算重试和协调消息。
Google DeepMind 的研究更直接：无结构的多 agent 系统会把错误放大 17.2 倍。收益在 4 个 agent 时就到顶了，之后加的只是噪音。
这是一个经济学问题，不是技术问题。
三种该用 Multi-Agent 的场景
上下文污染
当不同子任务积累的信息互相干扰，导致推理质量下降时，需要用独立的子 Agent 做上下文隔离。
Manus 的核心原则：通过通信来共享上下文，而不是通过共享上下文来通信。
具体操作：对于有明确输入输出的独立任务，启动全新的子 Agent，只传入具体指令。只有当子 Agent 必须理解完整轨迹时（比如需要看到之前所有错误尝试的调试 Agent），才共享完整上下文。
举个例子：让一个 Agent 同时做代码审查和写文档。代码审查过程中积累的大量 diff、错误信息会污染文档写作的上下文，导致文档里出现奇怪的技术细节泄漏。这时候就该拆成两个独立的子 Agent。
并行探索
当任务可以拆成多个独立方向同时推进时，Multi-Agent 的效果是碾压性的。
Anthropic 的研究系统用多 Agent 架构比单 Agent 高出 90% 的效果。原因是多 Agent 投入了足够多的 token 来解决问题——在他们的分析中，token 使用量本身就解释了 80% 的性能方差。
Claude 的研究功能：主 Agent 同时生成 3-5 个子 Agent，每个子 Agent 又并行执行多个工具调用，复杂查询的研究时间减少多达 90%。
关键洞察：并行不只是为了快，而是为了充分探索解空间。单个 Agent 容易陷入局部最优，多个 Agent 可以同时探索不同方向，最后汇总最佳结果。
工具过多
当 Agent 需要管理 20 个以上的工具时，选择准确率会明显下降。Manus 发现，给模型 100+ 个工具会导致幻觉参数或调用错误。
Manus 后端负责人做了 2 年 agent，最后换回单个 Unix CLI。原因：工具越多，选择准确率越低。一个统一的命令接口胜过 15 个独立的函数定义。
解决方案有两种：
按领域拆分：给每个专业化 Agent 聚焦的工具集。比如一个专门处理数据库操作的 Agent、一个专门处理文件系统的 Agent、一个专门处理 API 调用的 Agent。
工具搜索（Skill 渐进式加载）：Claude Code 提供了另一个思路——用一个工具去搜索工具，让模型按需动态发现工具，而不是一次性加载所有定义。可以减少多达 85% 的 token 使用量，也更符合"从简单开始"的原则。
三种不该用的情况
大多数编码任务
编码的子任务之间耦合度高，真正可并行化的部分比研究类任务少得多。涉及 1-3 个文件的修改，单 Agent 更快也更便宜。
代码修改往往是序列依赖的：先改接口定义，再改实现，最后改调用方。这种链式依赖决定了并行收益有限，协调开销却很大。
简单查询和低价值任务
Anthropic 在研究系统里直接写了缩放规则：
| 任务类型 | Agent 数量 | 工具调用次数 |
|---|---|---|
| 简单事实核查 | 1 个 | 3-10 次 |
| 直接对比 | 2-4 个子 Agent | - |
| 复杂研究问题 | 10+ 个子 Agent | - |
早期版本甚至出现过对简单查询生成 50 个子 Agent 的失控情况。规模要和价值匹配。
u/Material_Clerk1566 在 r/LangChain 写道：6 个月的生产故障，agent 在 demo 好使，上线就挂。追了几个月 prompt，最后发现问题根本不在 prompt——是架构错了，他让 LLM 控制路由。
拟人化的角色分工
这是最常见的反模式。不要按组织架构图给 Agent 排角色——什么经理、设计师、程序员互相聊天。
Manus 团队说得很直接：把子 Agent 当作工具来调用，不要当作同事来对话。
正确模式：主 Agent 调用一个函数，底层启动临时子 Agent 循环并返回结构化结果。
错误模式："经理 Agent"给"程序员 Agent"发消息，"程序员 Agent"思考后回复，"经理 Agent"再评估决定下一步——每一轮都在消耗 token，大部分用在了"沟通"而不是"解决问题"上。
两个实战细节
任务指令必须极其具体。 Anthropic 一开始允许主 Agent 给出简短指令，比如"研究半导体短缺"。结果多个子 Agent 在做完全相同的搜索，完全没有有效分工。好的指令要包含目标、输出格式、工具范围、任务边界四项。
并行不是万能的。 无状态的探索任务可以放心并行。有共享状态的操作任务必须序列化——两个 Agent 同时操作同一个文件，或者同时调用同一个有状态的 API，结果是不可预测的。OpenClaw 在同一会话内一次只处理一条消息，就是刻意的设计选择，不是限制。
该用多 Agent 吗？三个问题
1. 任务能拆成真正独立的子任务吗？ 不能 → 单 agent，多了只是协调开销
2. 单 agent 基准低于 45% 吗？ 不是 → 加 agent 不会有效果，DeepMind 数据支持
3. 你有能力调试分布式 agent 系统吗？ 没有 → 先别用。一个 agent 出错你能找到原因，四个 agent 出错你很可能找不到
本文基于 Anthropic、Manus、OpenClaw 等项目的公开文档，结合 Google DeepMind、Deloitte、Gartner 公开报告及 Reddit 社区真实案例整理。
Want to work together?
I'm always happy to connect — whether it's a project, a question, or just to say hi.
Get in Touch →