多代理

多代理系统通过协调专业化组件来处理复杂工作流。然而，并非每个复杂任务都需要这种方式——配备了合适（有时是动态的）工具和提示词的单个代理通常也能实现类似的效果。

​

为什么需要多代理？

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

• 上下文管理：在不超出模型上下文窗口限制的情况下提供专业知识。如果上下文无限且延迟为零，你可以将所有知识塞入单个提示词——但现实中做不到，因此需要一些模式来选择性地呈现相关信息。
• 分布式开发：允许不同团队独立开发和维护各自的能力，并通过清晰的边界将它们组合成更大的系统。
• 并行化：为子任务生成专业工作进程并并发执行，从而加快结果获取速度。

当单个代理拥有过多工具而难以正确选择时、当任务需要具备大量上下文的专业知识（长提示词和领域专用工具）时，或者当你需要强制执行顺序约束——只有满足特定条件后才能解锁某些能力时，多代理模式尤为有价值。

​

模式

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

​

选择模式

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

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

​

可视化概览

​

性能对比

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

• 模型调用次数：LLM 调用的次数。调用越多 = 延迟越高（尤其是串行时）且每次请求的 API 成本越高。
• 处理的 Token 数：所有调用中上下文窗口的总使用量。Token 越多 = 处理成本越高，且可能触及上下文限制。

​

单次请求

用户： “买咖啡”

专业的咖啡代理/技能可以调用 buy_coffee 工具。 关键洞察： 移交、技能和路由器对单个任务最为高效（各需 3 次调用）。子代理多一次额外调用，因为结果需要回流到主代理——这一开销换来的是集中化控制。

​

重复请求

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

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

​

多领域

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

每个语言代理/技能包含约 2000 个 Token 的文档。所有模式均可发起并行工具调用。 关键洞察： 对于多领域任务，具备并行执行能力的模式（子代理、路由器）最为高效。技能的调用次数更少，但因上下文累积而导致 Token 使用量较高。移交在此场景下效率低下——它必须串行执行，无法利用并行工具调用同时查询多个领域。

​

总结

以下是三种场景下各模式的对比： 选择模式：

---