多智能体系统协调专门组件来处理复杂工作流。不过，并非每个复杂任务都需要这种方式——配合合适（有时是动态的）工具和提示的单个智能体，往往也能取得类似效果。

​

为什么需要多智能体？

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

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

当单个智能体拥有过多 工具 而难以做出正确选择时，多智能体模式尤为有价值；当任务需要大量上下文的专业知识（长提示、领域专用工具），或需要施加顺序约束、只有满足特定条件后才能解锁能力时亦是如此。

​

模式

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

​

选择模式

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

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

​

可视化概览

​

性能对比

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

• 模型调用次数 ：LLM 调用次数。调用越多，延迟越高（尤其是串行时），单次请求的 API 成本也越高。
• 处理的 token 数 ：所有调用的 上下文窗口 使用总量。token 越多，处理成本越高，也更容易触及上下文限制。

​

一次性请求

用户： “买咖啡”

专门的咖啡智能体/技能可以调用 buy_coffee 工具。 关键结论： 对于单个任务，任务移交、技能和路由器最为高效（每次 3 次调用）。子智能体会多一次调用，因为结果需要回到主智能体——这部分开销换来的是集中式控制。

​

重复请求

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

用户在同一对话中重复相同请求。 关键结论： 有状态模式（任务移交、技能）在重复请求中可节省 40–50% 的调用次数。子智能体每次请求成本稳定——这种无状态设计带来强上下文隔离，但代价是重复的模型调用。

​

多领域

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

每个语言智能体/技能包含约 2000 个 token 的文档。所有模式都可以并行调用工具。 关键结论： 对于多领域任务，具备并行执行的模式（子智能体、路由器）最为高效。技能调用次数更少，但因上下文累积而消耗更多 token。任务移交在此场景下效率较低——它必须串行执行，无法利用并行工具调用来同时咨询多个领域。

​

总结

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

---