用途
multi-agent-patterns 用于在构建多智能体系统时提供架构设计参考。当用户提出「设计多智能体系统」「实现监督者模式」「创建群体架构」「协调多个智能体」等需求时可激活该技能。其核心场景是：单智能体上下文限制约束了任务复杂度、任务可自然分解为并行子任务、不同子任务需要不同工具集或系统提示、需要同时处理多个领域、或需要将智能体能力扩展到单上下文之外。
文档强调一个关键认识：子智能体存在的主要目的是隔离上下文，而不是拟人化地划分角色。
主要能力与核心概念
文档将多智能体系统定位为解决单智能体上下文限制的手段，指出三种主导模式：
- 监督者/编排者（Supervisor/Orchestrator）：由中心智能体控制，委派给专家智能体并汇总结果。适用于分解清晰、跨领域协调、需要人工监督的复杂任务。优点是严格控制工作流、便于人在环路、确保遵循既定计划；缺点是监督者上下文成为瓶颈、监督者失败会级联、存在「传话游戏」问题。文档提到 LangGraph 基准发现监督者架构初期因传话游戏问题表现比优化版本差 50%，解决方案是实现 forward_message 工具让子智能体直接向用户传递响应。
- 对等/群体（Peer-to-Peer/Swarm）：移除中心控制，智能体根据预定义协议直接通信，任何智能体可通过显式交接机制将控制权转给另一个。适用于灵活探索、僵化规划适得其反、需求涌现且无法预先分解的任务。优点是无单点故障、利于广度优先探索、支持涌现式问题解决；缺点是协调复杂度随智能体数量增加、缺乏中心状态保持者有发散风险、需要健壮的收敛约束。
- 分层（Hierarchical）：将智能体组织为战略层、规划层、执行层的抽象层级。适用于层级结构清晰的大型项目、带管理层的企业工作流、既需高层规划又需详细执行的任务。优点是映射组织结构、关注点清晰分离、不同层级可用不同上下文结构；缺点是层间协调开销、战略与执行可能错位、错误传播复杂。
使用方式与设计机制
上下文隔离被视为设计的首要原则，文档给出三种隔离机制：完整上下文委派（适用于子智能体需要完整理解的复杂任务）、指令传递（适用于简单明确子任务）、文件系统记忆（适用于需要共享状态的复杂任务）。文档说明三者各有取舍：完整委派能力最强但违背子智能体初衷；指令传递保持隔离但限制灵活性；文件系统记忆可在不传递上下文的情况下共享状态，但引入延迟与一致性问题。
共识与协调方面，文档指出简单多数投票会把弱模型的幻觉与强模型的推理等同看待，若不干预，多智能体讨论会因偏向一致的固有偏差而沦为对错误前提的共识。提供的机制包括：加权投票（按置信度或专业度赋权）、辩论协议（多轮互相批判，对抗性批判在复杂推理上常比协作共识更准确）、触发式干预（监测停滞、谄媚等行为标记）。
失败模式与缓解包括：监督者瓶颈（用输出模式约束让 worker 只返回精炼摘要，用检查点持久化监督者状态）、协调开销（明确交接协议、批量结果、异步通信）、发散（定义清晰目标边界、收敛检查、设置存活时间限制）、错误传播（传递前验证输出、重试与熔断、幂等操作）。
适用场景与限制
适用场景包括研究团队架构（监督者下有研究者、分析者、事实核查者、写作者）、客户请求路由等交接协议示例。文档还提到不同框架的实现哲学：LangGraph 使用基于图的带显式节点与边的状态机，AutoGen 使用对话/事件驱动的 GroupChat，CrewAI 使用基于角色的分层 crew 流程。
限制方面：文档明确指出应仅在任务清晰匹配上述范围时使用该技能；不应将输出视为环境特定验证、测试或专家审查的替代；若缺少必需输入、权限、安全边界或成功标准，应停止并请求澄清。此外，文档提到多智能体系统令牌消耗显著更高（约 15× 基线），且升级到更好的模型往往比翻倍令牌预算带来更大性能提升。价格、收费等商业信息暂未提供。