多代理

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

​

为什么使用多代理？

当开发人员说他们需要“多代理”时，他们通常是在寻找以下一种或多种能力：

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

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

​

模式

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

​

选择模式

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

• 分布式开发：不同的团队可以独立维护组件吗？
• 并行化：多个代理可以并发执行吗？
• 多跳：该模式支持串行调用多个子代理吗？
• 直接用户交互：子代理可以直接与用户交谈吗？

​

视觉概览

​

性能比较

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

• 模型调用：LLM 调用次数。更多调用 = 更高延迟（如果是顺序的）和更高的每个请求 API 成本。
• 处理的 Token：跨所有调用的总上下文窗口使用量。更多 Token = 更高的处理成本和潜在的上下文限制。

​

一次性请求

用户： “买咖啡”

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

​

重复请求

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

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

​

多领域

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

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

​

总结

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

---