面向正在考虑多 Agent 架构的工程师：这篇文章不推荐任何框架，也不讲具体实现，而是帮你回答一个核心问题——什么时候应该用多 Agent 工作流，什么时候不该用。
一、先泼一盆冷水
过去一年，很多人对多 Agent 工作流非常兴奋：
- 把任务拆成多个 Agent
- 每个 Agent 负责一部分
- 最后组合起来完成复杂任务
听起来很美好，但实际做下来，很多团队发现：
- 复杂度飙升
- 调试困难
- 效果不一定比单 Agent 好
这篇文章的核心目的，是帮你避免这个坑。
二、什么时候该用多 Agent
1）任务天然可以拆分，且拆分后能独立执行
这是最理想的情况。
如果你的任务：
- 可以清晰地分成几个独立子任务
- 每个子任务的输入输出都明确
- 子任务之间不需要太强的依赖
那用多 Agent 是合理的。
2）不同子任务需要不同的能力
比如：
- 一个 Agent 负责理解用户意图
- 一个 Agent 负责调用工具执行
- 一个 Agent 负责检查结果
每个 Agent 的专长不同，组合起来各发挥优势。
3）需要不同上下文
有些信息只在特定环节需要。
如果混在一个 Agent 里，会污染上下文，用多 Agent 可以让每个 Agent 只看到它需要的信息。
4）需要不同工具集合
如果每个子任务需要的工具完全不同，强行放在一起会导致：
- 工具描述冗长
- 模型选择困难
- 错误率上升
三、什么时候不该用多 Agent
1）一个 Agent 就能搞定
这是最常见的过度设计。
如果单 Agent 加上合适的 prompt 和工具就能完成，就不要拆。
多 Agent 的协调成本比想象中高得多。
2）任务之间的依赖很强
如果子任务之间：
- 需要大量信息传递
- 前一个的输出直接影响下一个的输入
- 需要很强的上下文一致性
那强行拆成多个 Agent 会让简单问题变复杂。
3）协调成本不可控
多 Agent 最大的问题不是“能不能做”，而是：
- Agent 之间的通信怎么设计
- 错误怎么传导和处理
- 结果怎么汇总和验证
- 出了问题怎么定位
这些协调成本经常被低估。
4）你还在验证阶段
如果你还在做 Demo、MVP、或者探索可行性，先用单 Agent 跑通。
过早引入多 Agent 架构会让你：
- 难以迭代
- 难以定位问题
- 难以判断是架构问题还是单点问题
四、一个简单的判断标准
直接回答三个问题：
问题 1：一个 Agent 真的搞不定吗？
- 能搞定 → 单 Agent
- 搞不定 → 继续看
问题 2：拆分后的子任务真的需要不同能力吗？
- 不需要 → 单 Agent
- 需要 → 继续看
问题 3：你准备好处理协调成本了吗？
- 没准备好 → 单 Agent
- 准备好了 → 可以考虑多 Agent
五、如果真的要做，需要注意什么
1）从两三个 Agent 开始
不要一开始就想搞十个八个人的 Agent 团队。
从最简单的两三个开始，先验证协调链路是否跑得通。
2）明确每个 Agent 的职责
每个 Agent 应该有：
- 清晰的输入定义
- 清晰的输出定义
- 明确的边界
别让 Agent 之间职责重叠。
3）设计好通信协议
Agent 之间怎么传递信息：
- 直接传输出
- 通过第三方存储
- 通过主控 Agent 中转
这个设计要一开始就定清楚。
4）处理异常传导
当一个 Agent 出错了，下一步怎么办：
- 整个链路停止？
- 尝试重试？
- 跳过继续执行？
- 回退到之前的状态？
这些要有明确的处理策略。
5）做好可观测性
多 Agent 链路一旦出问题，定位起来比单 Agent 复杂很多。
从一开始就做好日志和追踪。
结尾
多 Agent 工作流是一个被过度炒作的概念。
它不是银弹，也不是必须。
能用单 Agent 解决问题的场景，永远不要为了“酷”而用多 Agent。
只有在确实需要、且你愿意付出协调成本的情况下，才考虑多 Agent 架构。
关键词建议
- 多 Agent 工作流
- Agent 架构
- Agent 设计模式
摘要建议
多 Agent 工作流是当前的热门概念，但这篇文章帮你冷静分析什么时候该用、什么时候不该用，以及如果真的要做需要注意什么。
