多代理

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

​

为什么需要多代理？

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

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

当单个代理拥有太多工具而对其使用决策做出错误判断时，当任务需要具有广泛上下文的专业知识（长提示和特定领域工具）时，或者当您需要强制执行顺序约束以在满足某些条件后解锁能力时，多代理模式特别有价值。

​

模式

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

​

选择模式

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

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

​

可视化概览

​

性能比较

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

• 模型调用：LLM 调用次数。更多调用 = 更高的延迟（尤其是如果顺序执行）和更高的按请求 API 成本。
• 处理的令牌数：所有调用中上下文窗口的总使用量。更多令牌 = 更高的处理成本和潜在的上下文限制。

​

单次请求

用户： “买咖啡”

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

​

重复请求

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

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

​

多领域

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

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

​

总结

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

---