从单 Agent 到多 Agent（Multi-Agent）：什么时候该拆，怎么拆
很多人一上来就想搭"多 Agent 系统"：一个 Agent 负责规划、一个负责写代码、一个负责审查，听起来很高级。但真做下去往往发现：比单个 Agent 还难调、还慢、还贵，效果反而更差。
多 Agent 不是越多越好。这篇文章讲清楚：单 Agent 的瓶颈在哪、什么信号说明该拆成多 Agent、有哪些拆分模式、以及怎么避免把简单问题搞复杂。
一、先搞清楚：单 Agent 到底卡在哪
一个 Agent = 一个模型 + 一套提示词 + 一组工具，循环"思考→调工具→观察→再思考"。它在很多任务上已经够用。它会卡住，通常是因为：
- 职责太杂：又要规划又要写代码又要查资料，提示词越写越长，模型顾此失彼。
- 上下文爆炸：一条长任务做下来，历史记录堆满上下文窗口，开始"中间迷失"、丢早期信息。
- 工具太多：几十个工具塞进去，模型选不准该调哪个。
- 缺乏专精：什么都让同一个通用提示词来干，每件事都做得平庸。
当你发现"再怎么调提示词都按不住"时，往往就是单 Agent 的能力边界到了。
二、什么信号说明该拆成多 Agent
别为了拆而拆。出现下面这些信号，才考虑多 Agent：
- 任务能清晰切成几个职责不同的阶段（如：调研 → 写作 → 审校），每段需要的能力/提示词/工具明显不同。
- 单个 Agent 的上下文装不下整个任务，需要把子任务隔离开各自处理。
- 需要并行：多个子任务互相独立，可以同时跑，省时间。
- 需要相互制衡：比如一个生成、一个批判（critic），用对抗来提升质量。
如果你的任务一个 Agent 配好提示词和工具就能稳定完成，那就别拆------多 Agent 带来的协调成本不是白来的。
三、常见的多 Agent 拆分模式
1. 编排者---工作者（Orchestrator-Worker）
一个主 Agent 负责拆解任务、分派给若干专精的工作 Agent，再汇总结果。最常用、最通用的模式。适合复杂任务的分解执行。
2. 流水线（Pipeline / Sequential）
Agent 按固定顺序串联，上一个的输出是下一个的输入。比如"检索 Agent → 写作 Agent → 审校 Agent"。职责清晰、可控性强，适合阶段分明的任务。
3. 生成者---批判者（Generator-Critic）
一个 Agent 产出，另一个专门挑错并给修改意见，循环迭代。适合对输出质量要求高的场景（写代码、写方案）。
4. 并行 + 汇总（Parallel / Map-Reduce）
把任务拆成多个独立子任务并行跑，最后由一个 Agent 汇总。适合"分头调研多个主题再综合"这类任务，主要省时间。
| 模式 | 适合场景 | 关键收益 |
|---|---|---|
| 编排者---工作者 | 复杂任务需要动态分解 | 灵活、可扩展 |
| 流水线 | 阶段分明、顺序固定 | 可控、好调试 |
| 生成者---批判者 | 对质量要求高 | 输出更可靠 |
| 并行+汇总 | 子任务互相独立 | 省时间 |
四、怎么拆：四步走
- 先把任务画成流程图：哪些是阶段、哪些能并行、哪些需要来回迭代。结构清楚了，模式自然就出来了。
- 按职责划分 Agent，每个 Agent 单一职责：一个 Agent 只干一件事，提示词和工具都围绕这件事，别又让它兼职。
- 定义清楚 Agent 之间传什么：明确接口------上游给下游的是什么格式、包含哪些字段。接口含糊是多 Agent 系统最大的乱源。
- 加一个兜底的协调层：谁来决定流程走到哪、出错了怎么重试、什么时候终止。没有协调层，多个 Agent 很容易陷入死循环或互相等待。
五、几个常见的坑
| 坑 | 后果 | 怎么避 |
|---|---|---|
| 简单任务硬拆多 Agent | 更慢、更贵、更难调 | 单 Agent 够用就别拆 |
| Agent 之间接口含糊 | 互相传脏数据，整体崩 | 定义清晰的输入输出格式 |
| 没有终止条件 | 无限循环、烧光 token | 设最大轮次/明确的完成判据 |
| 上下文重复传递 | token 爆炸、成本失控 | 只传必要信息，别全量转发 |
| 没有协调层 | Agent 各跑各的、互相等待 | 加编排/调度逻辑统一管控 |
| 不做整体评估 | 不知道是哪个 Agent 拖后腿 | 既评端到端，也评单个 Agent |
六、总结
- 多 Agent 不是更高级，而是"单 Agent 装不下/管不住"时的拆分手段。
- 该拆的信号：阶段职责分明、上下文装不下、需要并行、需要相互制衡。
- 常见模式：编排者---工作者、流水线、生成者---批判者、并行+汇总。
- 拆的关键：单一职责、清晰接口、明确终止条件、一个兜底协调层。
- 最大的坑是"为拆而拆"------单 Agent 能稳定搞定的，就别上多 Agent。
先把单 Agent 用到极限，再在真正的瓶颈处拆分。这样搭出来的多 Agent 系统才不会是给自己挖的坑。
相关阅读：搭 Agent 的同学可以配合看看 MCP 实战、AI Agent 评估、Prompt Engineering、RAG 与长上下文、上下文工程（Context Engineering）这几篇。