Subagent 架構實作課：何時該把任務拆給子 Agent

今日主題：Subagent 架構：何時拆、怎麼拆、拆完怎麼收

2026-10-19 | 資料來源：Anthropic 工程部落格（多智能體研究系統）、Anthropic《Building multi-agent systems》、Generative Programmer（Subagent vs Advisor）、Rerun（Subagent 實務歸納）、Glasp（Agents as Teammates）、Neomeric（編排模式）

前言

當一個 AI Agent 要處理複雜任務時，最常見的死法不是「做不出來」，而是上下文視窗被塞爆：搜尋結果、日誌檔、工具回傳一股腦灌進同一個對話，主 Agent 還沒開始整合，就先被雜訊淹沒了。

Anthropic 在 2025 年 4 月公開的工程報告《How we built our multi-agent research system》中，給了一個有數據支撐的答案：把任務拆給子 Agent（subagent）做——一個 Lead Agent 負責規劃，3 到 5 個子 Agent 平行探索——在內部研究評測上，比單一 Agent 高出 90.2%。

但同一份報告也給了警告：這套做法用了約 15 倍的 token，只適合高價值任務。Subagent 不是「Agent 越多越聰明」，而是一個需要精算的架構決策。今天這篇，就把「何時拆、怎麼拆、拆完怎麼收」一次講清楚。

一、Subagent 到底是什麼

Subagent 指的是：主 Agent（parent／lead／orchestrator）把一段邊界明確的子任務，委派給另一個獨立運作的 Agent 執行。子 Agent 擁有自己的上下文視窗、自己的 system prompt、自己的工具權限；做完之後，只把精簡過的結果交還給主 Agent。

它的價值來自兩個機制：

1. 平行化（parallelization）：多個子 Agent 同時跑，能探索的資訊空間比單一 Agent 大得多。Anthropic 的 Research 功能就是典型：Lead Agent（Claude Opus 4）拆解問題，子 Agent（Claude Sonnet 4）各自跑自己的搜尋迴路，最後由 Lead 整合。

2. 上下文隔離（context isolation）：子任務產生的大量中間資訊（搜尋結果、日誌、檔案內容）留在子 Agent 自己的視窗裡，主 Agent 只收到結論。Claude Code 的官方建議很直白：當某個側任務「會用你之後用不到的搜尋結果、日誌或檔案內容淹沒主對話」時，就該丟給 subagent——例如跑測試、查文件、處理日誌檔。

如圖一所示，主 Agent 只做三件事：拆解、委派、整合；髒活全部隔離在子 Agent 的視窗裡。

二、為什麼它有效：Anthropic 的實證數字

Anthropic 的 Research 系統是目前公開資訊最完整的一次實證，幾個關鍵數字值得記下來：

- 效果：Lead 用 Claude Opus 4、子 Agent 用 Claude Sonnet 4 的配置，在內部研究評測上比單一 Opus 4 Agent 高出 90.2%。研究類任務是典型的「廣度優先」問題：同時追好幾條獨立線索，遠勝過一條一條慢慢查。

- 代價：多 Agent 系統的 token 用量約為一般對話的 15 倍。Anthropic 進一步指出，在瀏覽密集的評測（如 BrowseComp）上，token 用量本身就解釋了約八成的效能變異——白話說，錢花下去，效果幾乎線性成長。

- 時間：子 Agent 與工具呼叫平行執行，讓複雜查詢的研究時間最高縮短約九成。

- 邊界：同一份報告明確指出，Subagent 對「緊密耦合」的任務效果不佳，例如大多數寫程式任務——子任務之間依賴太深、需要共享完整上下文，平行度是假的。

這些數字給了我們第一條設計準則：Subagent 是在用 token 買推理容量，買之前先確認任務值得這個價。

三、五種常見的 Subagent 模式

實務上的 Subagent 組合，歸納起來不脫以下五種（整理自 Rerun 的實務歸納）：

1. Orchestrator–worker（主從式）：一個主 Agent 拆解任務、多個 worker 平行執行、主 Agent 整合結果。適合「多條界線清楚的工作流」。主要風險：主 Agent 自己變成瓶頸。

2. Router–specialist（路由專家式）：請求進來先判斷該交給哪一位專家。適合「一個請求只需要一種專長」的場景。主要風險：路由判斷錯誤，整單做錯方向。

3. Parallel fan-out（平行發散式）：同一個問題，多個 Agent 從不同角度同時做，最後投票或調和。適合廣度優先的探索，也能降低單一 Agent 犯錯的衝擊。主要風險：重複工作、結論互相矛盾要人收拾。

4. Sequential pipeline（序列管線式）：子 Agent 一棒接一棒，例如研究→起草→潤飾→排版。適合有依賴鏈的轉換流程。主要風險：錯誤層層放大。

5. Reviewer agent（審查者式）：專門負責挑錯的第二雙眼睛，不參與生產，只負責檢查。主要風險：AI 審 AI 帶來的虛假安全感。

選錯模式是常見的錯誤：把有先後順序的任務硬做平行，只是多花錢；把彼此獨立的任務排成序列，只是在浪費時間。先看任務的依賴結構，再選模式。

四、決策框架：該拆，還是不該拆？

先給「該拆」的檢查清單，符合越多條，越值得拆：

- 任務可以切成邊界清楚、彼此獨立的工作流；

- 需要橫跨大量來源做廣度研究；

- 資訊量超過單一上下文視窗的實用容量；

- 不同的子任務需要不同的工具、權限或專長；

- 任務價值夠高，值得多花模型用量；

- 子 Agent 的輸出可以被客觀檢查、可以合併。

再給「不該拆」的清單：

- 所有子任務必須共享同一份完整上下文才能做好——大多數寫程式任務屬於此類；

- 子任務之間依賴緊密、需要即時協調；

- 步驟可以事先列舉——那就該寫成固定的 workflow，而不是用 Agent 動態委派；

- 任務小到連委派的 overhead 都比執行本身貴。

如圖二的決策流程：四個問題——「能切成獨立工作流嗎？」「能平行嗎？」「單一上下文是瓶頸嗎？」「價值值得多花 token 嗎？」——全是「是」，才值得拆；任一題答否，先用單 Agent 或固定 workflow 解決。

這裡順帶釐清一個常被搞混的對比：Subagent vs Advisor。Subagent 是「往下委派」——把界線清楚但瑣碎的工作交給 worker，省下主 Agent 的上下文與注意力，擴展的是吞吐量；Advisor 是「往上請益」——執行者遇到自己判斷不了的難題時，向更強的模型要建議，擴展的是判斷力。兩者可以並存於同一個系統：主 Agent 把資料抽取丟給 worker，遇到架構取捨問 advisor，最後再叫另一個 worker 重排格式。

五、實作要點：拆完之後的工程細節

1. 寫一份好的委派 brief

子 Agent 的表現上限，取決於你給的任務說明。一份可用的 brief 至少包含四項：目標（要產出什麼）、輸出格式（JSON schema、字數、章節結構）、可用工具與邊界（能碰什麼、不能碰什麼）、完成標準（什麼算做完）。缺了完成標準，子 Agent 會一直「再查一下」停不下來。

2. 上下文隔離要徹底

只給子 Agent 它需要的資訊。如果任務是「摘要這份 changelog」，就給 changelog 和輸出格式，不要給整個專案的對話歷史。隔離越乾淨，token 花得越少，錯誤擴散的範圍也越小，驗證也越容易。

3. 大輸出走「工件模式」，不要走對話

子 Agent 的產出如果很大（長報告、整理好的資料表），讓它寫到檔案或外部儲存，只把輕量參考（路徑、摘要）交還給主 Agent。Anthropic 的 Research 系統就是這麼做的：避免每一次轉述都是一場「電話遊戲」，資訊在多次轉手後失真，同時也省下把大輸出複製進對話歷史的 token。

4. 模型分級：強的規劃，輕的執行

規劃與整合需要最強的推理，執行子任務往往不需要。Anthropic 用 Opus 4 做 Lead、Sonnet 4 做子 Agent；Claude Code 內建的 Explore 子 Agent（唯讀搜尋程式碼庫）直接用 Haiku。把貴的推理留給真正需要判斷的步驟，是 Subagent 架構最重要的省錢手段。

5. 驗證與升級路徑

子 Agent 的輸出要有人檢查：格式對不對、品質夠不夠。實務上的標準配備是四件套——Orchestrator（懂全貌、決定拆什麼）、Worker（在有限上下文裡完成一件有邊界的事）、Validator（檢查輸出是否達標）、Escalation rule（失敗或高風險的案例升級給更強的模型或人類）。委派出去的任務，一定要有「做壞了怎麼辦」的答案。

6. 同步等待的代價

Anthropic 的 Research 系統採用同步分派：主 Agent 等同一批子 Agent 全部完成才繼續。協調簡單，但一個慢的子 Agent 會拖住全體。實作時要決定：用超時加部分結果繼續，還是硬等全部？這是延遲與完整性的取捨，沒有標準答案，但一定要在設計時想清楚。

最小可跑骨架

import asyncio
from anthropic import AsyncAnthropic

client = AsyncAnthropic()

async def research_subagent(facet: str) -> dict:
    """每個子 Agent 擁有自己的上下文視窗"""
    resp = await client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=4096,
        messages=[{"role": "user", "content": f"研究主題：{facet}"}],
        tools=[web_search, read_document],
    )
    return extract_findings(resp)

async def research_topic(query: str) -> dict:
    facets = await lead_agent.decompose_query(query)  # 主 Agent 拆解
    results = await asyncio.gather(                   # 子 Agent 平行執行
        *[research_subagent(f) for f in facets]
    )
    return await lead_agent.synthesize(results)       # 主 Agent 整合

結論

Subagent 架構的本質，是把「一個大腦記所有事」換成「一個大腦管很多個小腦」。它買到的是平行推理容量與乾淨的上下文，付出的代價是 token、延遲與協調複雜度。

實作的順序應該是：先問單 Agent 或固定 workflow 能不能解決；真的遇到上下文瓶頸、任務可平行、價值夠高，再拆。拆的時候記住三件事：brief 寫清楚、輸出走工件、強弱模型分級。這三件事做對，Subagent 才會是加速器，而不是帳單製造機。

參考來源

- Anthropic，《Building multi-agent systems: when and how to use them》：https://claude.com/resources/articles/building-multi-agent-systems-when-and-how-to-use-them

- Generative Programmer，《Distribution vs Escalation: When to Use Subagents or Advisors》：https://generativeprogrammer.com/p/subagents-vs-advisor-distribution

- Rerun，《Subagents Explained: How AI Agents Delegate Work to Other Agents》：https://rerun.build/blog/subagents

- Glasp，《Agents as Teammates: Hierarchy, Roles, and What 2025 Taught Us》：https://glasp.co/articles/agents-as-teammates-hierarchy-roles

- Neomeric，《Multi-Agent AI Orchestration Patterns (2026)》：https://neomeric.com/blog/multi-agent-ai-orchestration-patterns/