在昨天的文章中，我們透過 LangGraph 實作了一個具備工具循環與持久化記憶的單一 ReAct Agent。

然而，當系統的業務邊界持續擴大——既要處理即時資料檢索、又要撰寫深度分析報告、同時還得執行資料庫寫入與郵件發送時，把所有的職責、提示詞與數十個工具全部塞進「同一個 Agent」會引發災難性的後果：

1. Prompt 嚴重膨脹：多種角色的行為規範互相干擾，模型極易混淆職責。
2. Context 污染：資料爬取的冗長日誌與分析節點的上下文混在一起，Token 消耗失控。
3. 工具調用失準：當可用工具超過 20 個，單一模型的路由決策錯誤率顯著上升。

解決這個瓶頸的標準架構，就是將單一龐大的 Agent 拆解為專業分工的 Multi-Agent 系統（多智能體協同架構）。今天我們就來拆解兩種最主流的協同模式：主管模式（Supervisor Pattern） 與 階層式工作流（Hierarchical Pattern）。

一、為什麼需要 Multi-Agent？從「全端工程師」到「專業團隊」

單一 Agent 就像一個必須包辦產品設計、後端架構、前端切版、測試與維運的「全端工程師」；而 Multi-Agent 架構則是建立一個「各司其職的敏捷團隊」：

[傳統 Single-Agent]
User ──> [ 超大 Agent: 負責 30+ 工具 + 5 種角色 Prompt ] ──> 容易混亂、難以除錯

[現代 Multi-Agent (Supervisor)]
                    ┌──> [ 檢索專家 Agent (專用 Context + 搜尋工具) ]
User ──> [ 主管 Agent ] ├──> [ 代碼執行 Agent (專用 Context + Python 環境) ]
                    └──> [ 報告撰寫 Agent (專用 Context + 格式規範) ]

多 Agent 協同的核心優勢：

• 職責單一化（Separation of Concerns）：每個 Agent 只專注於單一任務，Prompt 簡短明確，大幅提升推論準確度。
• 上下文沙盒化（Context Isolation）：各子 Agent 擁有獨立的 Context 視窗，繁雜的過程資料在子節點內消化，只向全域狀態回傳精簡結論。
• 高可維護性與可測試性：可獨立針對特定子 Agent 進行單元測試與提示詞迭代，不影響其他模組。

二、模式 1：主管模式（Supervisor Pattern）

主管模式是目前業界最常見、也最容易落地的 Multi-Agent 架構。

運作原理：

• 設立一個具備指揮權限的 主管節點（Supervisor Agent）。
• 主管節點不直接執行底層繁瑣任務，而是專門負責**「任務拆解（Task Decomposition）」與「調度派工（Routing）」**。
• 每當子 Agent 完成任務後，控制權會重新回到 Supervisor 手中，由主管評估「是否需要派工給下一個專家」，或者「任務已全部完成，直接向使用者回覆（FINISH）」。

                  ┌───────────────────┐
                  │    __start__      │
                  └─────────┬─────────┘
                            │
                            ▼
               ┌─────────────────────────┐
               │    Supervisor (主管)    │ ◄──────────┐
               └────────────┬────────────┘            │
                            │ (條件邊派工)              │
         ┌──────────────────┼──────────────────┐      │ (回報結果)
         ▼                  ▼                  ▼      │
┌─────────────────┐┌─────────────────┐┌─────────────────┐
│ WebResearcher   ││ DataAnalyst     ││ EmailNotifier   │
│ (網路檢索專家)   ││ (數據分析專家)   ││ (通知發送專家)   │
└────────┬────────┘└────────┬────────┘└────────┬────────┘
         │                  │                  │
         └──────────────────┴──────────────────┘

Supervisor 的決策輸出通常是一個結構化路由：

from typing import Literal
from pydantic import BaseModel, Field

class RouterOutput(BaseModel):
    next_node: Literal["WebResearcher", "DataAnalyst", "EmailNotifier", "FINISH"] = Field(
        description="根據目前任務進度，決定下一個負責執行的專家 Agent；若任務已完成則為 FINISH"
    )
    instruction: str = Field(
        description="派發給該專家的具體子任務指令與背景資訊"
    )

三、模式 2：階層式工作流（Hierarchical Pattern）

當業務複雜度進一步提升，單一層級的主管模式可能會使頂層 Supervisor 的決策負擔過重。這時會演化為階層式架構（樹狀 / 網狀組織）。

運作原理：

• 頂層管理層（Executive Agent）：負責接收最終商業目標（如「產出一份 2026 年生成式 AI 趨勢白皮書」），並拆分為「市場調研」與「報告撰寫」兩大方向。
• 中層組長（Team Leads）：
  • 「調研組長」主管底下管理 2 個專員：Google Search Agent 與 ArXiv Paper Agent。
  • 「寫作組長」主管底下管理 2 個專員：Markdown Formatter Agent 與 Fact Checker Agent。
• 基層專員（Workers）：直接掛載特定工具執行底層動作。

                       [ 總指揮 (Director Agent) ]
                                   │
              ┌────────────────────┴────────────────────┐
              ▼                                         ▼
   [ 調研主管 (Research Lead) ]              [ 寫作主管 (Editorial Lead) ]
         │                  │                      │                 │
         ▼                  ▼                      ▼                 ▼
   [ 搜尋專員 ]        [ 論文專員 ]           [ 起草專員 ]       [ 審校專員 ]

階層式架構讓大型複雜系統具備了無限向外擴展（Scale-out）的能力。

四、Multi-Agent 的通訊與協調機制

在設計 Multi-Agent 系統時，子 Agent 之間主要有兩種溝通機制：

1. 集中式黑板模型（Shared Blackboard / State Graph）

• 機制：所有 Agent 共享同一個全域 State。每個 Agent 讀取全域狀態中的特定鍵值，並將自己的執行結果寫回 State。
• 優點：架構清晰、狀態易於持久化與除錯，適合 LangGraph 的實作哲學。

2. 點對點訊息傳遞（Peer-to-Peer Message Passing）

• 機制：Agent 之間直接相互發送訊息（類似 Actor Model），無需經過單一主管集中轉發。
• 優點：去中心化、靈活性極高，但工作流追蹤與避免死循環的難度顯著上升。

五、Single-Agent vs. Supervisor vs. Hierarchical 架構選型指南

小結與下集預告

Multi-Agent 架構不是為了炫技，而是為了在複雜任務中維護「高凝聚、低耦合」的系統邊界。透過 Supervisor 與階層式設計，我們能讓每個 Agent 專注於自己的專業領域，打造真正穩定且具備彈性的 AI 團隊。

理解了 Supervisor 的協同理念後，在實戰中該如何用 LangGraph 將多個獨立的 Agent 節點串接起來？

明天 【Day 13】實作 LangGraph Supervisor Multi-Agent 系統，我們將進入實戰篇，透過 Python 程式碼完整構建一個由主管動態派工、串接 Research 與 Writer 兩大專家的 Multi-Agent 工作流！