Multi-Agent 架构：什么时候该用，什么时候不该用？

面试官问你："Multi-Agent 的架构到底什么时候该用，什么时候不该用？"

如果你回答"任务复杂就用多 Agent"，面试官一定会追问：怎么定义复杂？代价是什么？有没有不该用的情况？

这个问题回答不好，就丢分了。

今天我们从 Anthropic、Claude Code、Manus、OpenCode、OpenClaw 这些前沿产品的实战经验里，提炼出一套清晰的判断框架。

核心原则：大多数团队不需要 Multi-Agent

先说最关键的一点：Anthropic 的立场非常明确——大多数团队不需要 Multi-Agent 系统。

他们发现，在单个 Agent 上反复改进 prompt，效果可以匹配那些花了几个月搭建的复杂多 Agent 架构。而且代价很大：

• 普通 Agent 的消耗大约是聊天的 4 倍 token
• Multi-Agent 系统消耗大约 15 倍 token

这些额外开销来自：

• 跨 Agent 的上下文复制
• 协调消息
• 结果汇总

所以，Multi-Agent 需要任务价值足够高，高到能为这些开销买单。

这是一个经济学问题，不是技术问题。

三种该用 Multi-Agent 的场景

1. 上下文污染

当不同子任务积累的信息互相干扰，导致推理质量下降时，就需要用独立的子 Agent 做上下文隔离。

Manus 的核心原则说得很好：

通过通信来共享上下文，而不是通过共享上下文来通信。

具体操作：

• 对于有明确输入输出的独立任务，启动全新的子 Agent，只传入具体指令
• 只有当子 Agent 必须理解完整轨迹时（比如需要看到之前所有错误尝试的调试 Agent），才共享完整上下文

举个例子：你让一个 Agent 同时做代码审查和写文档。代码审查过程中积累的大量 diff、错误信息会污染文档写作的上下文，导致文档里出现奇怪的技术细节泄漏。这时候就该拆成两个独立的子 Agent。

2. 并行探索

当任务可以拆成多个独立方向同时推进时，Multi-Agent 的效果是碾压性的。

Anthropic 的研究系统用多 Agent 架构比单 Agent 高出 90% 的效果。

为什么？因为多 Agent 帮助投入了足够多的 token 来解决问题。在他们的分析中，token 使用量本身就解释了 80% 的性能方差。

Claude 的研究功能就是这么做的：

• 主 Agent 同时生成 3-5 个子 Agent
• 每个子 Agent 又并行执行多个工具调用
• 对于复杂查询可以减少多达 90% 的研究时间

这里有个关键洞察：并行不只是为了快，而是为了充分探索解空间。

单个 Agent 容易陷入局部最优，而多个 Agent 可以同时探索不同方向，最后汇总最佳结果。

3. 工具过多

当 Agent 需要管理 20 个以上的工具时，选择准确率会明显下降。

Manus 发现，给模型 100+ 个工具会导致幻觉参数或调用错误。

解决方案有两种：

方案 A：按领域拆分

给拥有聚焦工具集的专业化 Agent。比如：

• 一个专门处理数据库操作的 Agent
• 一个专门处理文件系统的 Agent
• 一个专门处理 API 调用的 Agent

方案 B：工具搜索（Skill 渐进式加载）

Claude Code 提供了一个替代思路：用一个工具去搜索工具，让模型按需动态发现工具，而不是一次性加载所有定义。

这个思路目前比较火，可以减少多达 85% 的 token 使用量。

我个人更倾向于方案 B，因为它更符合"从简单开始"的原则——不需要一开始就设计复杂的 Agent 分工。

三种不该用 Multi-Agent 的情况

1. 大多数编码任务

编码的子任务之间耦合度高，真正可并行化的部分比研究类任务少得多。

涉及 1-3 个文件的修改，单 Agent 更快也更便宜。

为什么？因为代码修改往往是序列依赖的：

• 先改接口定义
• 再改实现
• 最后改调用方

这种链式依赖决定了并行的收益有限，而协调的开销却很大。

2. 简单查询和低价值任务

Anthropic 在研究系统的 prompt 里直接写了缩放规则：

任务类型	Agent 数量	工具调用次数
简单事实核查	1 个	3-10 次
直接对比	2-4 个子 Agent	-
复杂研究问题	10+ 个子 Agent	-

早期版本甚至出现过对简单查询生成 50 个子 Agent 的失控情况。

规模要和价值匹配。 "帮我查一下北京今天天气"不需要启动一个 Multi-Agent 研究系统。

3. 拟人化的角色分工

这是最常见的反模式。

不要按组织架构图给 Agent 排角色——什么经理、设计师、程序员互相聊天。

Manus 团队说得很直接：

把子 Agent 当作工具来调用，不要当作同事来对话。

正确的模式是：

• 主 Agent 调用一个函数
• 底层启动临时子 Agent 循环并返回结构化结果

不是：

• "经理 Agent" 给 "程序员 Agent" 发消息
• "程序员 Agent" 思考后回复
• "经理 Agent" 再评估决定下一步

Anthropic 也指出，按角色分工会产生持续的协调开销。每一轮对话都在消耗 token，而这些 token 大部分用在了"沟通"而不是"解决问题"上。

两个关键的实战经验

1. 任务指令必须极其具体

子 Agent 的任务指令要包含：

• 目标：具体要达成什么
• 输出格式：返回什么结构的数据
• 工具范围：允许使用哪些工具
• 任务边界：不要做什么

Anthropic 一开始允许主 Agent 给出简短指令，比如"研究半导体短缺"。结果发现多个子 Agent 在做完全相同的搜索，完全没有有效分工。

好的指令长这样：

目标：研究 2023-2024 年汽车芯片供应链的变化
输出格式：JSON，包含 key_events, major_players, timeline
工具范围：web_search, read_url
边界：不要分析 AI 芯片市场，专注汽车行业

2. 并行不是万能的

OpenClaw 在同一会话内一次只处理一条消息，按会话序列化执行。

原因很明确：当多个 Agent 共享状态时，并发会导致工具冲突和状态损坏。

这是刻意的设计选择，不是限制。

想象一下：两个 Agent 同时操作同一个文件，或者同时调用同一个有状态的 API。结果是不可预测的。

所以：

• 无状态的探索任务 → 放心并行
• 有共享状态的操作任务 → 必须序列化

面试答题框架

总结一下，面试时建议这样组织答案：

先说原则：

从最简单方案开始，只在有明确证据时才引入 Multi-Agent。

然后说三个该用的场景：

1. 上下文污染 → 用隔离
2. 并行探索 → 用分发
3. 工具过多 → 用专业化

再说三个不该用的情况：

1. 编码任务耦合度高
2. 低价值查询不划算
3. 拟人化角色分工是反模式

最后补两个加分点：

1. 任务委派指令要极其具体
2. 共享状态时序列化比并行更安全

把这些讲清楚，这个问题就稳了。

---

本文基于抖音视频内容转写，结合 Anthropic、Manus、OpenClaw 等项目的公开文档整理。