多智能体

多智能体系统协调专门的组件来处理复杂的工作流程。然而，并非每个复杂任务都需要这种方法——一个配备了合适（有时是动态的）工具和提示的单一智能体通常也能达到类似的效果。

​

为什么需要多智能体？

当开发者说他们需要“多智能体”时，他们通常是在寻找以下一种或多种能力：

• 上下文管理：提供专门的知识，而不会使模型的上下文窗口不堪重负。如果上下文是无限的且延迟为零，你可以将所有知识倾倒到一个提示中——但既然不是，你就需要模式来有选择地呈现相关信息。
• 分布式开发：允许不同的团队独立开发和维护功能，并将它们组合成一个具有清晰边界的大系统。
• 并行化：为子任务生成专门的工作者并并发执行它们，以获得更快的结果。

当单一智能体拥有太多工具并且在使用哪些工具上做出糟糕的决策时，当任务需要具有广泛上下文（长提示和特定领域的工具）的专门知识时，或者当你需要强制执行顺序约束，只有在满足某些条件后才能解锁功能时，多智能体模式尤其有价值。

​

模式

以下是构建多智能体系统的主要模式，每种模式都适用于不同的用例：

​

选择模式

使用此表将你的需求与合适的模式匹配：

• 分布式开发：不同的团队能否独立维护组件？
• 并行化：多个智能体能否并发执行？
• 多跳：该模式是否支持串联调用多个子智能体？
• 直接用户交互：子智能体能否直接与用户对话？

​

可视化概览

​

性能比较

不同的模式具有不同的性能特征。理解这些权衡有助于你为延迟和成本要求选择合适的模式。 关键指标：

• 模型调用次数：LLM 调用的次数。调用次数越多 = 延迟越高（尤其是顺序执行时）以及每次请求的 API 成本越高。
• 处理的令牌数：所有调用中使用的总上下文窗口。令牌越多 = 处理成本越高，并且可能达到上下文限制。

​

单次请求

用户： “买咖啡”

一个专门的咖啡智能体/技能可以调用 buy_coffee 工具。 关键洞察： 对于单次任务，交接、技能和路由器最有效（各 3 次调用）。子智能体增加了一次额外调用，因为结果需要流回主智能体——这种开销提供了集中控制。

​

重复请求

第 1 轮： “买咖啡” 第 2 轮： “再买一次咖啡”

用户在同一对话中重复相同的请求。 关键洞察： 有状态模式（交接、技能）在重复请求上节省了 40-50% 的调用。子智能体保持每次请求的成本一致——这种无状态设计提供了强大的上下文隔离，但代价是重复的模型调用。

​

多领域

用户： “比较 Python、JavaScript 和 Rust 在 Web 开发中的应用”

每个语言智能体/技能包含约 2000 个令牌的文档。所有模式都可以进行并行工具调用。 关键洞察： 对于多领域任务，具有并行执行能力的模式（子智能体、路由器）最有效。技能调用次数较少，但由于上下文累积，令牌使用量很高。交接在这里效率低下——它必须顺序执行，无法利用并行工具调用来同时咨询多个领域。

​

总结

以下是所有三种场景下模式的比较： 选择模式：

---