多智能体

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

​

为什么需要多智能体？

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

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

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

​

模式

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

​

选择模式

使用此表将你的需求与正确的模式匹配：

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

​

可视化概览

​

性能比较

不同的模式具有不同的性能特征。了解这些权衡有助于你根据延迟和成本要求选择正确的模式。 关键指标：

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

​

单次请求

用户： “买咖啡”

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

​

重复请求

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

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

​

多领域

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

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

​

总结

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

---