当单个 Agent 处理复杂任务力不从心时，很多团队会想到“多智能体”：一个负责规划，一个负责检索，一个负责写作，一个负责审核，像一个小团队一样协作。这种架构在演示中往往效果惊艳，但在生产环境中，多 Agent 系统的复杂度、成本和不确定性都会显著上升。在决定采用之前，值得先认真问一句：真的需要多个 Agent 吗？

常见的多 Agent 架构模式

主管—执行者模式

一个主管 Agent 负责理解目标、拆解任务，并把子任务分派给专门的执行 Agent，最后汇总结果。这是最常见、也相对容易控制的模式。

流水线模式

多个 Agent 按固定顺序处理，前一个的输出是后一个的输入，例如“调研—撰写—审校—排版”。流程清晰，但灵活性有限。

辩论与评审模式

两个或多个 Agent 从不同角度分析同一问题，或者一个生成、一个挑错，通过多轮交互提升结果质量。

自由协作模式

多个 Agent 在共享环境中自主交流、按需协作。灵活性最高，但最难预测和调试，生产环境中较少采用。

什么时候真的需要多个 Agent

多 Agent 的合理使用场景通常具备以下特征：

  • 任务可以自然拆分为相对独立的子任务，且子任务可以并行，比如同时调研多个竞品；
  • 不同子任务需要不同的工具集或权限，拆开后每个 Agent 的工具更少、权限更小、更安全；
  • 单个上下文装不下，需要把信息分散到多个 Agent 各自处理后再汇总；
  • 需要独立的审核视角，让“检查者”不受“生成者”思路的影响。

反过来，如果任务步骤之间强依赖、需要频繁共享细节，拆成多个 Agent 只会增加沟通开销。很多时候，一个设计良好、工具清晰的单 Agent 加上合理的流程编排，就能达到同样效果。

多 Agent 系统的主要风险

  1. 成本成倍增长：每个 Agent 都要消耗 Token，Agent 之间的对话也要消耗 Token；
  2. 信息在传递中失真：主管给执行者的任务描述不完整，执行者的结果汇报遗漏关键细节，类似人类团队中的沟通损耗；
  3. 错误被放大：一个 Agent 的错误输出被其他 Agent 当作事实继续加工，最终结论看似有理有据却完全错误；
  4. 循环与僵局：Agent 之间互相推诿或反复修改，无法收敛；
  5. 难以调试：出问题时很难定位是哪个环节、哪次交互导致的。

这些问题在单 Agent 中也存在，只是在多 Agent 中更加突出，具体排查方法可参考 AI Agent 常见故障模式。

让多 Agent 系统可控的方法

明确的角色与边界

每个 Agent 的职责、可用工具、输入输出格式要写清楚，避免职责重叠。

结构化的通信

Agent 之间传递结构化数据而不是自由文本：任务目标、约束条件、已知信息、期望输出格式，逐项明确。

设置预算与终止条件

为整个任务设定最大轮数、最大 Token 消耗和超时时间，达到上限就停止并交由人工处理。

保留完整轨迹

记录每个 Agent 的输入、输出和工具调用，方便事后复盘和评测。

关键节点人工审核

在不可逆操作或重要结论输出前加入人工确认环节，参见人在回路的设计。

小结

多 Agent 是解决特定复杂问题的有力工具，但不是默认选项。先用单 Agent 把流程跑通并建立评测，确认存在明确的拆分收益后，再逐步引入多 Agent，并用清晰的角色、结构化通信和预算控制保持系统可控。