Dylan House: 多智能體

顯示具有 多智能體 標籤的文章。顯示所有文章

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/

多智能體編排：五種模式與「該不該拆」的決策框架

2025 年中，Anthropic 公開了自家 Research 功能的幕後架構：一隻「總管」agent 帶領 3 到 5 隻子 agent 併行做研究，複雜查詢的研究時間最多縮短 90%，內部評測比單一最強模型高出 90.2%。「多智能體」一夕成了所有 agent 產品的標配詞彙。

隔年（2026 年 4 月），Stanford 的研究卻潑了一盆冷水：在算力對等的條件下，單一 agent 常常一樣好、甚至更好——agent 之間交接時流失的資訊，往往把併行的紅利吃光。

於是問題變得很有意思：多智能體編排到底在解決什麼問題？本文整理五種常見模式，並給出一個「該不該拆」的決策框架。

一、Anthropic 怎麼做：Orchestrator–Worker

Anthropic 的多智能體研究系統是目前最有說服力的生產級案例（Anthropic Engineering Blog, 2025/6）。架構很直白：

一隻 Lead agent（Claude Opus 4）負責分析查詢、制定研究策略、把任務切成可併行的線程；
派給 3–5 隻 子 agent（Claude Sonnet 4），各自擁有獨立的 context window，平行探索不同角度；
Lead 等子 agent 全部回來後彙整成最終答案，必要時再派第二輪。

兩個層次的平行化。不只 agent 層併行（3–5 隻子 agent），工具層也併行——每隻子 agent 同時打 3 個以上的搜尋工具。這是時間縮短 90% 的主因。

代價是 token。多智能體系統的 token 用量約為純聊天的 15 倍，只划算在高價值任務上。這也是為什麼他們把「工作量級縮放規則」直接寫進總管的 prompt：簡單事實查詢只用 1 agent＋3–10 次 tool call，複雜研究才上 10+ 子 agent。

委派必須明確。實戰教訓：模糊的委派會造成重工。總管給子 agent 的指令要包含明確目標、輸出格式、以及與其他子 agent 的邊界。

一個反直覺的洞見。他們發現，升級到更好的模型（Sonnet 4）帶來的效率提升，大於把 token 預算直接翻倍——模型品質 > 算力堆疊。

同樣誠實的是他們的 caveat：需要緊密共享 context 的任務（例如寫程式）效益有限——這點後面 Stanford 的研究會用數字再證實一次。

二、五種編排模式速覽（如圖一）

把業界框架（LangGraph、AutoGen、CrewAI、OpenAI Agents SDK）與學術文獻攤開看，生產級的多智能體系統其實只收斂成五種形狀：

1. Orchestrator–Worker（總管—工人型）
總管拆解任務、派發、彙整。適合可分解、讀取密集、廣度優先的工作。LangGraph 稱之為 Supervisor Pattern（「supervisor 的工具就是其他 agent」），CrewAI 叫 Hierarchical Process，Anthropic 內部就叫 Orchestrator–Workers。

2. Sequential Pipeline（接力管線型）
agent 按固定順序接力：研究 → 撰寫 → 審查。上一棒的輸出是下一棒的輸入。沒有併行所以慢，但最容易理解與除錯，適合流程固定、每一步都要產出中間成品的任務（文件處理、合規審查）。

3. Fan-out / Fan-in（併行發散—收斂型）
多隻 agent 用不同策略／不同模型／不同工具集，同時解同一道題，最後投票或加權收斂。研究顯示，彼此看不到對方、只做單一面向的獨立驗證者能帶來 8–20% 的穩定增益，而「生成端」的多智能體（辯論、混合模型）在算力對等下常常贏不了強單一 agent。重點：併行的價值在「獨立驗證」，不在「一起發想」。

4. Hierarchical（階層團隊型）
總管下面還有 team lead，team lead 再帶工人。LangGraph 用子圖（subgraph）表達：一個團隊本身就是上層圖的一個節點。協調開銷最大，只有單一總管的協調負載成為瓶頸時（企業級規模）才需要。

5. Debate／Critic-Actor（辯論—批判型）
一隻 agent 提案，另一隻的唯一工作就是挑毛病，多輪攻防後定稿。目的不是快，而是抓出「自己審自己」會漏掉的錯誤。

如圖一，五種模式沒有絕對優劣，只有「適不適合手上的任務」。

三、Stanford 2026 的潑冷水：何時不該拆

2026 年 Stanford 連發了幾篇直指要害的研究，值得每個要做多智能體的人讀：

辯論在什麼時候真的有用？（2026/4）Stanford 團隊把辯論架構、序列鏈、集成方法、單一 agent 放在一起比較。辯論在團隊配置中勝出，但只在三種情境下優勢明顯：底層模型較弱、輸入資料有噪聲、需要從大量資訊中篩選。一旦把算力拉平——給單一 agent 同樣的總算力——單一 agent 常常打平甚至反超。元兇就是交接時的資訊流失。

會自己組織的團隊才算數。Stanford 的 SAT（self-organizing AI teams）框架讓模型自己學會組織策略，而不是硬套辯論協議。結果：平均準確率 66.7%，超過等算力單一 agent 的 58.7%，在 AIME 2026 上達到 71.2%。最有意思的發現是「可辨識性」（demonstrability）：當正確的推理一出現在對話中、團隊能認出來並跟進時，增益最大（Spearman 相關 0.90）。換句話說，多智能體的紅利不在「人多」，而在「懂得合作」——數學、物理這類推理鏈可驗證的領域最吃香。

辯論讓解釋變漂亮，但決策沒有變好。另一篇 Stanford 論文（arXiv:2609.29701）在模擬市場中跑了 210 次受控實驗：多輪辯論把推理品質評分從 0.72 拉到 0.84（+17.7%），但推理品質與投資組合的 Sharpe ratio 相關係數只有 r = 0.07——agent 們寫出了漂亮得多的辯護詞，配置決策本身卻沒有變好。評估時只看對話紀錄會被騙，這正是「評測要看終點、不要只看軌跡」的原因。

把三篇研究和 Anthropic 的實戰放在一起，結論很一致：多智能體的勝場集中在「可分解、讀取密集、廣度優先」的任務；凡是需要緊密共享 context、交接成本高的任務，單一 agent 往往是更好的答案。

四、決策框架：該不該拆？（如圖二）

動手前先依序回答三個問題：

問題一：任務能拆成獨立子任務嗎？
不能 → 直接用單一 agent。硬拆只會製造協調成本。

問題二：子任務之間依賴緊密、需要共享完整 context 嗎？
是 → 用單一 agent。Stanford 已經證明，handoff 的資訊流失會吃掉併行紅利；Anthropic 也承認寫程式這類任務效益有限。

問題三：任務是什麼型態？

廣度優先／讀取密集（研究、資訊蒐集）→ Orchestrator–Worker。Anthropic 的 90.2% 就是在這裡拿到的。
需要多視角糾錯 → Debate＋「新鮮 context 的驗證者」。Anthropic 的實戰結論：用全新 context 的子 agent 做驗證，效果優於讓原 agent 自我批判。
嚴格順序相依（draft→review→revise）→ Sequential Pipeline。慢，但每一步都可審計。

最後檢查：成本。多智能體約 15 倍 token，任務的價值夠高嗎？不夠 → 回到單一 agent。這條檢查線應該寫成團隊的硬性門檻，而不是憑感覺。

五、實作要點

選定模式之後，還有四個工程細節決定成敗：

委派要寫規格：每個子 agent 的目標、輸出格式、與他人的邊界，全部寫死在 prompt 裡。模糊是重工的源頭。
狀態外部化：把研究計畫與已完成階段存在 agent 外部，才能撐過 context window 截斷、支援失敗續跑（durable execution）。
可觀測性＋人審核點：長跑流程需要漸進式部署（rainbow deployment）與中途介入機制，例如 LangGraph 的 interrupt()／Claude Code 的 plan-approval gating。
評測看終點：Anthropic 用單一 LLM judge 按固定維度（事實正確性、引用品質、完整性、來源權威性、工具效率）打分——judge 終態，不驗證每一步。

附上一段 LangGraph Supervisor 模式的骨架（Python，概念示意）：

def supervisor(state):
    # 總管：看目前狀態，決定下一個工人，或結束
    decision = supervisor_llm.invoke(state["messages"])
    return decision.next_agent  # "researcher" / "coder" / END

builder.add_node("supervisor", supervisor_node)
builder.add_node("researcher", researcher_node)
builder.add_node("coder", coder_node)
builder.add_conditional_edges(
    "supervisor", supervisor, ["researcher", "coder", END])
builder.add_edge("researcher", "supervisor")  # 做完回報總管
builder.add_edge("coder", "supervisor")

動態併行（「把 N 個子題各派一隻 agent」）則用 LangGraph 的 Send 原語：一個 plan 節點在執行期才決定派幾個分支。