前言¶
單 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
