單一 Agent 在同一個 Context 裡規劃、呼叫工具並整理結果。任務變複雜後，會遇到三個問題：

• Context 被原始資料占滿：排查故障時讀進上萬行日誌，後續判斷指標與發布紀錄的注意力，會被重複的錯誤堆疊稀釋。
• 工具太多會選錯：指標、日誌、部署等工具的定義全放在同一個 Agent 上，模型容易挑錯工具或混淆參數。
• 高權限工具與不可信任的輸入擠在一起：同一個 Agent 既讀使用者輸入，又能執行退款或部署，Prompt Injection 就可能直接觸發寫入。

這三個問題都出在所有事情共用同一個 Context、同一組工具與同一份權限。Multi-Agent 把工作拆給多個 Agent，各自擁有獨立的 Context、工具集與行為指令：讀大量資料的子任務交給獨立 Context 的 Agent，只回傳摘要；每個 Agent 只配備自己領域的工具；處理不可信任輸入的 Agent 與握有高權限工具的 Agent 分開，兩者以約定好的格式交接結果。

Multi-Agent 的適用場景

接著來看 Multi-Agent 如何解決前面的問題。任務遇到下列情況時，切分出獨立的 Sub-Agent 能帶來實質效益：

1. 上下文保護（Context Protection / Isolation）

大型語言模型的 Context Window 有限，且隨著輸入長度膨脹，模型的注意力與推理品質會逐步下降。當某個子任務需要翻閱大量資料，而這些原始資料對主任務並不重要時，就會造成「上下文污染（Context Pollution）」。

• 單一 Agent 的痛點：以系統故障排查為例，若排查日誌時把 10,000 行錯誤日誌全部倒進主 Context，模型後續在判斷指標或發布紀錄時，注意力會被大量重複的錯誤堆疊嚴重稀釋。
• Multi-Agent 的解法：建立專門的 Log_Agent。它在獨立的 Context 內翻閱上萬行日誌，提煉出 100 Tokens 的結構化摘要（如 { "error_signature": "NullPointerException in Gateway", "count": 820 }）回傳給主 Agent，保持主 Context 的精簡與專注。

2. 專業化分工（Specialization）

不同任務往往需要完全不同的工具集、行為模式或安全權限：

1. 工具集過載（Tool Set Specialization）：當單一 Agent 擁有的工具過多時，模型容易出現選錯工具或參數混淆的情況。拆分成專屬 Agent（如指標查詢 Agent、K8s 部署 Agent），每個 Agent 僅配備該領域的核心工具，能大幅降低錯誤率。
2. 行為模式衝突（Persona Specialization）：不同任務對模型行為的要求可能互相衝突。例如：一線客服需要同理心與耐心的回覆風格，而內部風控審查則需要嚴格、懷疑與批判性的審計思維。讓同一個 Agent 在這兩種模式間切換容易產生混亂，分離為不同 Agent 效果更佳。
3. 資安與權限邊界（Security Boundary）：一線接觸不可信任的使用者自然語言時，可能遭遇 Prompt Injection 攻擊。將「一線接待」與「高權限寫入（如退款、刪除、部署）」分離到不同 Agent，低權限 Agent 僅負責萃取結構化事實，高權限 Agent 在獨立 Context 中讀取驗證後的契約並執行操作，能有效縮小資安風險。

Multi-Agent 架構選擇

Multi-Agent 的協作架構常見有三種形態：固定順序交接的管線模式（Pipeline）、自由對話的去中心化模式（Peer-to-Peer / Swarms），以及由中心調度的協調者—子代理模式（Orchestrator-Subagent）。

管線模式（Sequential / Pipeline）

管線模式將任務拆解為固定順序的多個步驟，每個步驟由專屬 Agent 負責，上游 Agent 的輸出直接作為下游 Agent 的輸入（例如：資料檢索 Agent → 數據分析 Agent → 摘要報告 Agent）。

• 適用情境：執行步驟高度確定、各階段職責邊界清楚，且執行順序在執行前已完全確定的線性工作流。
• 架構限制：
  • 缺乏動態調度能力：無法根據中間的執行結果動態增減子任務、切換分支或反覆回退。
  • 誤差逐級放大（Cascading Errors）：長管線中，上游 Agent 產生的微小偏差或幻覺會被下游 Agent 當作既定事實處理，導致後段產出嚴重失真。

協調者—子代理（Orchestrator-Subagent）

在需要高確定性、可觀測與狀態可控的正式環境中，協調者—子代理模式是最推薦的架構。由單一協調者動態規劃任務，子代理各自獨立執行並回報結構化結果：

• Orchestrator（協調者）：負責接收原始目標、拆解子任務、分派 Worker，並在收集所有結果後進行邏輯推論與彙整。
• Sub-Agent（子代理）：在受限的獨立 Context 中執行專屬任務，完成後回傳乾淨的結構化資料，不將內部的中間嘗試與 Trace 暴露給外層。

去中心化模式（Peer-to-Peer / Agent Swarms）

在去中心化模式中，系統沒有單一的主導協調者，多個 Agent 處於平級地位。Agent 之間透過自然語言或共享訊息匯流排自由對話，並自主決定何時將任務交接（Handoff）給下一個 Agent。

• 適用情境：開放式創意發想、探索性調研，或是需要多角色自由辯論以激盪想法的研究場景。
• 生產環境的架構風險：
  • 容易陷入訊息死循環：Agent 之間可能互相重複委派或爭論不休，迅速耗盡 Token 預算或觸發呼叫上限。
  • 狀態難以收斂與稽核：缺乏單一決策中心，排查時難以重現或追蹤最終結論是由哪一次狀態轉換推導而來。
  • Token 浪費：多個 Agent 之間使用非結構化自然語言對話，會產生大量對業務結果無直接貢獻的無效 Token。

因此，在講求可維護性、確定性與成本控制的正式環境中，多數系統會優先選擇以 Orchestrator 作為核心調度中心，集中管控 Sub-Agent 的生命週期與資料交接。

跨 Agent 協作契約

Multi-Agent 系統的穩定性取決於 Agent 之間的交接契約（Contract）。Agent 之間不應傳遞隨意的自然語言長文，而應使用具備型別約束的結構化資料。協作契約通常包含「下發任務」與「回報結果」雙向規範：

1. 下發任務契約（Orchestrator → Sub-Agent）

Orchestrator 派工時不能只傳遞模糊的自然語言提示（例如「幫我排查系統異常」），否則 Sub-Agent 容易漫無目的地呼叫工具或偏離主題。Orchestrator 應傳遞邊界明確的任務規格：

from pydantic import BaseModel, Field


class SubTaskAssignment(BaseModel):
    """Orchestrator 派發給 Sub-Agent 的任務契約。"""
    task_id: str = Field(description="子任務識別碼，用於關聯追蹤")
    target_agent: str = Field(description="負責執行的專責 Agent 名稱，如 log_agent 或 metric_agent")
    goal: str = Field(description="單一且具體的執行目標，不包含模糊的多重指令")
    parameters: dict[str, str] = Field(
        default_factory=dict,
        description="執行所需的精確約束（如 service='checkout', time_range='10:00-10:15'）"
    )
    context_artifact_ids: list[str] = Field(
        default_factory=list,
        description="前置步驟產出的大型資料 ID 參照，避免直接倒入長文字"
    )

• 明確限定範圍：透過 parameters 鎖定排查的服務、時間區間或日誌等級，避免 Sub-Agent 撈取非必要的全量資料。
• 輸入產物參照：若子任務需要前置步驟的產出，只傳遞 context_artifact_ids，由 Sub-Agent 視需要主動調閱，防止主 Prompt 膨脹。

2. 回報結果契約（Sub-Agent → Orchestrator）

Sub-Agent 完成任務後，只將推論所需的最小事實集合回傳給 Orchestrator：

class SubTaskResult(BaseModel):
    """Sub-Agent 交回給 Orchestrator 的結果契約。"""
    task_id: str = Field(description="對應的子任務識別碼")
    status: str = Field(description="執行狀態：success 或 failed")
    key_findings: list[str] = Field(description="萃取出的核心事實（控制在 3-5 條以內）")
    artifact_id: str | None = Field(default=None, description="若有大型原始資料，以 ID 參照存放於外部儲存")

• 高密度摘要：key_findings 只保留主任務推論所需的關鍵結論（50~100 Tokens）。
• 產物以 ID 參照（Artifact Reference）：若 Sub-Agent 抓取了大型資料（如報表檔案或完整 Log），應將其存入外部儲存區，僅在契約中傳遞 artifact_id，嚴禁將數萬字原始資料直接貼進回傳訊息。

從單一 Agent 開始，需要時再換成 Multi-Agent

Multi-Agent 用獨立的 Context、工具集與權限，解決單一 Agent 的 Context 污染、工具過載、行為衝突與權限混用。拆分後，Orchestrator 集中調度 Sub-Agent，型別化的任務與結果契約約束 Agent 之間的交接，每個 Agent 只處理自己範圍內的資料與工具。

任務確實遇到上述問題時，才需要改用 Multi-Agent。單純步驟多或工具多時，單一 Agent 可以依序呼叫多個工具，在同一個 Context 內規劃、觀察結果並自主修正。每多一個 Agent，就要付出下列成本：

• Token 消耗增加：Agent 之間重複傳遞背景資訊、協調指令與交接摘要，會顯著增加整體的 Token 消耗。
• 交接脈絡遺失（Handoff Degradation）：將前一個 Agent 的推論過程壓縮為摘要交給下一個 Agent 時，容易遺失隱性細節，導致後續 Agent 做出的決策品質下降。
• 故障點增加與除錯困難：每個新增的 Agent 都是一個潛在的幻覺與失敗來源，跨 Agent 的非預期互動會讓排錯軌跡變得極長。

因此先優化 System Prompt、精簡 Tool 定義並提供明確的範例，確認單一 Agent 是否能完成任務；單一 Agent 確實遇到上述問題，再切分出 Sub-Agent。

下一篇將以 SRE 事故診斷系統為例，在 LangGraph 中完整實作 Orchestrator-Subagent 架構。