---

name: multi-agent-patterns description: 当用户要求"设计多智能体系统"、"实现监督者模式"、"创建群体架构"、"协调多个智能体"，或提到多智能体模式、上下文隔离、智能体交接、子智能体或并行智能体执行时，应使用此技能。 risk: unknown source: community

多智能体架构模式

多智能体架构将工作分配到多个语言模型实例中，每个实例拥有独立的上下文窗口。设计得当时，这种分布式方式能实现超越单智能体限制的能力。设计不当时，则会引入协调开销，抵消其优势。关键洞察是：子智能体的存在主要是为了隔离上下文，而非拟人化地模拟角色分工。

适用场景

在以下情况下激活此技能：

• 单智能体上下文限制制约了任务复杂度
• 任务自然分解为可并行的子任务
• 不同子任务需要不同的工具集或系统提示词
• 构建必须同时处理多个领域的系统
• 扩展智能体能力超越单上下文限制
• 设计具有多个专业化组件的生产级智能体系统

核心概念

多智能体系统通过分布式方式解决单智能体上下文限制。存在三种主要模式：监督者/编排者用于集中控制，对等/群体用于灵活交接，层级式用于分层抽象。关键设计原则是上下文隔离——子智能体的存在主要是为了分割上下文，而非模拟组织角色。

有效的多智能体系统需要明确的协调协议、避免附和的共识机制，以及对故障模式（包括瓶颈、发散和错误传播）的细致关注。

详细主题

为什么需要多智能体架构

上下文瓶颈 单智能体在推理能力、上下文管理和工具协调方面面临固有上限。随着任务复杂度增加，上下文窗口被累积的历史记录、检索的文档和工具输出填满。性能按可预测的模式下降：中间丢失效应、注意力稀缺和上下文污染。

多智能体架构通过将工作分配到多个上下文窗口来解决这些限制。每个智能体在专注于其子任务的干净上下文中运行。结果在协调层聚合，无需任何单一上下文承担全部负担。

Token 经济学现实 多智能体系统比单智能体方法消耗显著更多的 token。生产数据显示：

| 架构 | Token 倍数 | 使用场景 | |------|-----------|---------| | 单智能体对话 | 1× 基线 | 简单查询 | | 带工具的单智能体 | ~4× 基线 | 工具使用任务 | | 多智能体系统 | ~15× 基线 | 复杂研究/协调 |

BrowseComp 评估的研究发现，三个因素解释了 95% 的性能方差：token 使用量（80% 的方差）、工具调用次数和模型选择。这验证了多智能体方法——通过将工作分配到具有独立上下文窗口的智能体来增加并行推理容量。

关键的是，升级到更好的模型通常比加倍 token 预算带来更大的性能提升。Claude Sonnet 4.5 比在早期 Sonnet 版本上加倍 token 显示出更大的提升。GPT-5.2 的思考模式同样优于原始 token 增加。这表明模型选择和多智能体架构是互补策略。

并行化论点 许多任务包含可并行化的子任务，而单智能体必须顺序执行。研究任务可能需要搜索多个独立来源、分析不同文档或比较竞争方案。单智能体顺序处理这些，每一步都累积上下文。

多智能体架构为每个子任务分配专用智能体，配备全新上下文。所有智能体同时工作，然后将结果返回给协调者。总实际时间接近最长子任务的持续时间，而非所有子任务的总和。

专业化论点 不同任务受益于不同的智能体配置：不同的系统提示词、不同的工具集、不同的上下文结构。通用智能体必须在上下文中携带所有可能的配置。专业化智能体只携带所需内容。

多智能体架构实现了无组合爆炸的专业化。协调者路由到专业化智能体；每个智能体以针对其领域优化的精简上下文运行。

架构模式

模式 1：监督者/编排者 监督者模式将中央智能体置于控制位置，委派给专家并综合结果。监督者维护全局状态和轨迹，将用户目标分解为子任务，并路由到适当的专业化智能体。