前言¶
单 Agent 在长任务里往往会把检索结果、工具输出和历史对话堆进同一个上下文窗口，出现注意力稀释、中间信息丢失或无关内容「污染」有效信号等问题。不少团队于是拆成多个模型实例并行或分工，但若缺少明确的协调协议，协调成本会抵消拆分带来的收益。
下面介绍仓库 Agent-Skills-for-Context-Engineering 中的 Skill multi-agent-patterns：它在设计阶段帮你选型编排者、点对点、层级式等架构，并把「上下文隔离」当作拆分子 Agent 的首要理由，而不是单纯模拟组织角色。
这是什么¶
multi-agent-patterns 是一份面向「多 Agent 系统设计」的结构化指南（SKILL.md 格式），维护者为该 Context Engineering 技能合集项目。官方描述指出：在需要上下文隔离、监督者或蜂群式协调、显式交接（handoff）、并行执行，或需要判断「是否真的值得上多 Agent」时，应启用本 Skill。
其核心命题是：子 Agent 主要服务于隔离上下文——每个实例在相对干净的窗口里处理子任务，避免信息在多次摘要传递中劣化（俗称「传话游戏」）。
与本 Skill 边界相邻、官方明确划归其他 Skill 的工作包括：任务与模型匹配、管线形态（project-development）、托管沙箱与远程运行时（hosted-agents）、编排者 KV 压缩共享（latent-briefing）、各 Agent 暴露的工具设计（tool-design）等；做拓扑选型时应避免混用职责。
核心功能¶
何时启用¶
在以下情况官方建议激活本 Skill：
- 单 Agent 上下文上限制约任务复杂度
- 任务可自然拆成可并行的子任务
- 不同子任务需要不同的工具集或 system prompt
- 系统需同时处理多个领域
- 需要在单上下文之外扩展 Agent 能力
- 设计带多个专用组件的生产级 Agent 系统
三种主导架构模式¶
选型应基于协调需求，而非组织隐喻：
| 模式 | 适用情形 |
|---|---|
| Supervisor / Orchestrator（监督者 / 编排者） | 任务可清晰分解、需要跨域协调或人工 oversight |
| Peer-to-Peer / Swarm（点对点 / 蜂群） | 需要灵活探索、刚性规划反而有害、需求动态涌现 |
| Hierarchical（层级式） | 大规模项目，策略、规划、执行分层抽象，各层上下文结构不同 |
设计时应围绕：显式协调协议、能抑制谄媚（sycophancy）的共识机制、以及防止错误级联传播的失败处理。
为何需要多 Agent（资料中的论证线）¶
上下文瓶颈：当单窗口被历史、检索文档和工具输出填满时，可关注三类退化信号——lost-in-middle（中间段注意力变弱）、注意力稀缺（过多竞争项）、上下文污染（无关内容挤占有用信息）。多窗口分工后，在协调层聚合结果，避免任一上下文承担全部负担。
Token 经济学：资料强调多 Agent 往往显著高于单 Agent 对话的 token 消耗，并给出相对量级示意（非精确计费公式）：
| Architecture | Token Multiplier | Use Case |
|---|---|---|
| Single agent chat | Baseline | Simple queries |
| Single agent with tools | Higher than baseline | Tool-using tasks |
| Multi-agent system | Much higher than baseline | Complex research/coordination |
资料同时指出：评测研究中 token 用量、工具调用与模型选择常主导表现方差；应相对单 Agent 基线测量，而非默认「多加 Agent 就好」。模型升级有时比单纯加倍 token 预算更有效，架构与模型选择应互补。
并行与专用化：可并行的子任务交给带新上下文的专用 Agent，墙钟时间更接近最长子任务而非各步相加；协调者可将请求路由到只携带本子任务所需 prompt、工具与上下文的专用实例，避免通用 Agent 在上下文中堆砌全部配置。
模式一：Supervisor / Orchestrator¶
中央 Agent 维护全局状态与轨迹，分解用户目标并路由到工作者，再聚合输出：
User Query -> Supervisor -> [Specialist, Specialist, Specialist] -> Aggregation -> Final Output
权衡：流程可控、便于 human-in-the-loop；但监督者上下文易成瓶颈，监督者失败会波及工作者，且存在「传话游戏」——监督者转述子 Agent 回答时丢失细节。资料提到 LangGraph 类基准中，监督者架构在未优化时可能明显弱于优化版本（约 50% 量级，以官方引用的 benchmark 表述为准）。
缓解传话游戏：实现 forward_message，让子 Agent 在合适时直接把完整回答交给用户，跳过监督者二次合成。官方示例：
def forward_message(message: str, to_user: bool = True):
"""
Forward sub-agent response directly to user without supervisor synthesis.
Use when:
- Sub-agent response is final and complete
- Supervisor synthesis would lose important details
- Response format must be preserved exactly
"""
if to_user:
return {"type": "direct_response", "content": message}
return {"type": "supervisor_input", "content": message}
若子 Agent 可直接对用户响应，资料倾向于在可行时考虑 swarm，以消除翻译误差。
模式二：Peer-to-Peer / Swarm¶
去掉中心控制，Agent 按预定协议直接通信；通过显式 handoff 将控制权交给另一 Agent。示意（资料片段）：
def transfer_to_agent_b():
return agent_b # Handoff via function return
agent_a = Agent(
name="Agent A",
functions=[transfer_to_agent_b]
)
权衡：无单点故障、利于广度扩展；但 Agent 数量上升会带来协调复杂度、发散风险，且缺少中心状态时需要更强的收敛约束（资料在截断处继续展开该主题）。
模式三：Hierarchical¶
用于多层抽象的大规模分解：高层负责策略与规划，低层负责执行，各层维护与粒度匹配的上下文结构（细节见仓库内完整 SKILL.md）。
安装与启用¶
本 Skill 以通用 Agent Skills（SKILL.md）形式发布，官方路径为：
https://github.com/muratcankoylan/Agent-Skills-for-Context-Engineering/tree/main/skills/multi-agent-patterns
合集根目录说明其适用于从零构建 Agent、优化性能、调试上下文问题、设计多 Agent 架构等场景。各宿主（Cursor、Codex CLI、Claude Code 等）如何把该目录注册为可加载 Skill，以你所用产品的 Skills 文档为准；已抓取资料中未给出统一的安装命令或版本号，此处不臆造配置字段。
启用逻辑以 Skill 元数据为准：当任务涉及多 Agent 拓扑、隔离、协调与并行决策时，在对话或 Agent 配置中加载 multi-agent-patterns 对应说明即可。
典型用法（设计流程）¶
结合官方「When to Activate」与架构章节，可复现的设计顺序如下：
- 判断是否真的需要多 Agent：若复杂度仍可由单上下文承载，或问题属于
project-development阶段的任务-模型匹配，先不要套用本 Skill 的拓扑建议。 - 识别并行与工具差异：子任务是否独立可并行、是否需要不同工具或 system prompt；若是，再在三种模式中选型。
- 为监督者架构加防劣化措施：若采用 Supervisor，评估是否必须为最终答案保留
forward_message直通路径，避免监督者 paraphrase 损失细节。 - 为 swarm 定义 handoff 协议：用显式
transfer_to_*或等价机制约定控制权转移，避免隐式「谁接着说话」含糊不清。 - 对照基线评估成本：用单 Agent 基线对比 token、工具调用与任务完成质量；资料强调不应默认多 Agent 更优。
适用场景与注意¶
适合谁：正在设计或重构生产级多组件 Agent 系统的开发者；需要在大检索量、多域并行、长轨迹任务里做上下文分区的团队。
限制与坑：
- Token 与调用次数通常显著高于单 Agent，需有预算与基线评测。
- 监督者架构要专门处理传话游戏与监督者单点故障。
- Swarm 需要协议与收敛约束，否则易发散。
- 工具清单、沙箱运行时、KV latent 共享等应交给对应 Skill，避免在一个对话里混谈全部基础设施细节。
与 Cursor、Codex 等工具演进方向一致的是：多 Agent 正在成为常见能力，但架构模式可复用；本 Skill 提供的是选型与隔离策略层面的共识语言，而不是替代具体框架实现。
结尾¶
multi-agent-patterns 把多 Agent 设计收敛为「上下文隔离 + 三种协调模式 + 显式协议与失败处理」，并提醒用单 Agent 基线和 token 现实校验架构选择。完整条文、层级模式细节及截断后的进阶主题，请以官方仓库为准：
https://github.com/muratcankoylan/Agent-Skills-for-Context-Engineering/tree/main/skills/multi-agent-patterns
