subagent 是什麼？子代理讓 AI 學會分工

2026 年 2 月，Anthropic 工程團隊發了一篇文章：16 個 Claude 同時開工，兩週跑了近 2,000 個 Claude Code session，寫出一個 10 萬行的 C 編譯器——能編譯 Linux 核心，主流編譯器測試套件通過率 99%，總帳單不到 2 萬美元。

過程中沒有人類在中間派工。這 16 個 agent 自己認領任務、自己合併程式碼、自己解衝突。

這種「一群 AI 合力做一件大事」的畫面，拆到最底層，是一個 2025 年就定型的概念：子代理（subagent）。

子代理（subagent）是由主 agent 派生出來、在自己獨立的 context window 裡執行子任務的 agent。它把搜尋、讀檔、試錯這些高耗量工作隔離在自己的脈絡裡，做完只把結論回傳給主 agent。主 agent 的 context 保持乾淨，能持續專注在整體任務上。context 隔離是 subagent 存在的理由，平行加速是附帶的好處。

打個比方：你在趕一份報告，桌面就這麼大。你請同事幫忙查一個數字，他去翻了三十份文件，回來只跟你講兩句結論——那三十份文件攤在他桌上，一張都不會堆到你桌上。subagent 就是那位同事，context window 就是那張桌子。

Context 隔離，是 subagent 存在的理由

AI agent 工作時，每一步的工具輸出都會進 context window：搜尋結果、檔案內容、指令 log。麻煩在於，很多輸出是「過程廢料」——agent 在一個大型程式庫裡找一個函式定義，可能要讀進幾萬 token 的檔案內容，最後有用的只有一行。

context window 有上限，塞太多雜訊還會讓模型「讀了後面忘了前面」。單一 agent 做大任務，最先崩的通常就是這裡。

subagent 的解法很直接：髒活外包，只收結論。主 agent 把「去找出這個 bug 在哪個檔案」這種子任務派出去，subagent 在自己的 context 裡翻完幾十個檔案，回傳一句「在 auth.ts 第 142 行，原因是 token 過期沒處理」。幾萬 token 的搜尋過程，主線 context 一個字都不用背。

對主 agent 來說，呼叫 subagent 的動作長得就像一次工具呼叫——Claude Code 內部這個工具早期就叫 Task tool。差別在這個「工具」的另一頭是一個完整的 agent，有自己的模型、系統提示詞和工具權限。

第二個好處是平行：主 agent 可以同時派三、五個 subagent 各查一條線，等結果一起回來，時間不用疊加。

起源：Anthropic 2025 年把它變成正式機制

subagent 機制在 Claude Code 早期版本就內建（就是上面說的 Task tool），但 2025 年有兩個節點讓它從內部實作變成行業通用詞。

第一個節點是開放自訂。2025 年 Claude Code 在 v1.0.60 加入 /agents 指令，你可以自己定義 subagent：在 .claude/agents/ 目錄放一個 markdown 檔，用 YAML frontmatter 設定名稱、可用工具、觸發時機，內文就是它的系統提示詞。一個專門審 code 的 reviewer、一個只負責跑測試的 tester，各自帶著獨立 context 和受限的工具權限開工。

第二個節點是 2025 年 6 月 Anthropic 的工程文〈How we built our multi-agent research system〉，把 Claude 研究功能背後的 orchestrator-worker 架構攤開來講：一個主 agent 分析問題、擬定策略，再派出多個 subagent 平行探索不同方向，最後收攏結果。Anthropic 工程團隊在文中給了一個常被引用的數字：

以 Claude Opus 4 當主 agent、Claude Sonnet 4 當 subagent 的多代理系統，在內部研究評測上比單一 Opus 4 agent 的表現高出 90.2%。 ——Anthropic 工程部落格，2025 年 6 月

這篇文章讓「lead agent + subagents」變成一種有官方背書的架構模式。到 2026 年，OpenAI 的 Codex、Cursor、GitHub Copilot 都支援 subagent 機制，Cursor 甚至直接讀取 .claude/agents/ 目錄的設定檔。subagent 已經是跨工具的標準詞，跟「context window」「tool calling」同一層級。

Agent teams：先被挖出來，才被發表

subagent 有個天生限制：它只跟主 agent 講話。派出去的幾個 subagent 彼此不知道對方存在，所有協調都得繞回主 agent 這個瓶頸。下一步很自然——讓 agent 之間直接對話。

這一步的公開過程有點戲劇性。2026 年 1 月下旬，開發者 kieranklaassen 對 Claude Code v2.1.29 的執行檔跑了一行 strings 指令，挖出一套完整實作、但被 feature flag 鎖住的多代理系統：TeammateTool，內含 13 種操作，涵蓋隊伍生成、成員互傳訊息、廣播、計畫核准、優雅關閉。1 月 26 日技術部落格 paddo.dev 把細節整理成文，社群給這套隱藏功能起了個綽號——swarm mode（蜂群模式），還做出強制開啟旗標的工具。

Anthropic 沒讓它藏太久。2026 年 2 月 5 日（美國時間），agent teams 隨 Claude Opus 4.6 正式推出，定位是研究預覽：你可以在 Claude Code 裡開一組 agent 平行作業、自主協調，官方說法是「最適合能拆成獨立、以讀取為主的工作，例如程式碼庫審查」。你隨時可以用 Shift+Up/Down 接管任何一個成員。

它跟 subagent 的差異，並排看最清楚：

維度	subagent	agent teams 成員
context	獨立 context window	獨立 context window
對話對象	只回報主 agent	成員之間直接互傳訊息、廣播
任務來源	主 agent 指派	共用任務清單，可自己認領
生命週期	做完子任務即收	獨立 session，持續存在
適合場景	單點外包（查資料、跑測試）	大任務長時間分工

開頭那個 C 編譯器就是 agent teams 路線的展示作：16 個 agent 靠 git 加上共享目錄裡的鎖定檔協調任務，各自寫完、拉取上游、解衝突、推送、釋放鎖，循環兩週。

代價：token 倍增與協調成本

多 agent 不是免費升級，Anthropic 自己就把醜話講在前面。

token 燒得快。 同一篇 2025 年 6 月的工程文估算：agent 任務的 token 用量約是一般對話的 4 倍，多代理系統約是 15 倍。每個 subagent 都是完整的模型呼叫，context 隔離的另一面就是——每個隔離的 context 都要各自重讀一次它需要的背景。

協調本身有成本。 成員可能重工、可能互相衝突。C 編譯器專案得自己搭一套 git 鎖定機制才壓住 16 個 agent 的衝突，而那還是精心挑過、高度可平行的任務。

很多任務根本切不開。 Anthropic 的準則寫得直白：多代理適合可大量平行、資訊量超過單一 context window、以讀取為主的工作；步驟彼此高度相依、需要共享完整脈絡的任務——文中點名「多數 coding 工作」——單 agent 表現反而更好。

所以判斷順序是：先問任務切不切得開，再問正確率的提升值不值那 15 倍 token。單 agent 夠用的地方，多 agent 只是比較貴的煙火。

你可以直接試的一件事

有用 Claude Code 的話，下次遇到「幫我查這個 codebase 裡所有用到 X 的地方」這種問題，明講一句「開 subagent 去查，只回報結論」。然後對比一下主線 context 用量——你會直觀感受到 context 隔離在省什麼。

進一步，用 /agents 建一個自訂 subagent：例如一個只有讀取權限的 code reviewer，讓它做完審查回報清單，主線再動手改。工具權限受限這件事，同時也是安全邊界。

評估要不要上 agent teams（或其他工具的同類功能）時，用這條準則：把任務寫成清單，如果每一項都能獨立驗收、不需要看到別項的中間過程，才值得開一組 team；只要有兩項互相卡脖子，先回到單 agent 加 subagent 的組合。

一句話帶走：subagent 解的是 context 的分工，agent teams 解的是 agent 的協作——往上走一階，能力上限變高，token 帳單也至少翻一倍。先學會用好一個 subagent，再考慮養一支隊伍。

資料來源：Anthropic 工程部落格、Anthropic Claude Opus 4.6 發布公告、Claude Code 官方文件、paddo.dev、TechCrunch

矽基前沿 · 大百科線（編輯：廖玄同），《subagent 是什麼？子代理讓 AI 學會分工》，矽基前沿 [Si]gnals，2026-07-05。https://signals.tw/articles/what-is-subagent/