Subagents 與多代理:讓 AI 分身協作

上一課你親手讓 Claude Code 當你的代理,替你開瀏覽器查資料、寫檔案、跑指令。體驗完之後,很多人的第一個問題是:「既然 AI 可以自己動手,那能不能同時跑好幾件事?」

這個問題問對了。一個 agent 的天花板,正是它一次只有一個注意力,一條線從頭走到尾。你叫它研究競品、寫報告、整理資料,它只能一件一件串著做,就像辦公室只有一個人,再能幹也有做不完的時候。多代理(multi-agent)架構就是給這個問題的答案——讓多個 AI 分身同時工作、互相審查、最後匯報給一個統籌的指揮官。

這堂學什麼

• 為什麼一個 agent 不夠用:分工、並行、互相審查三個理由
• orchestrator 概念白話解釋:誰下令、誰執行
• Claude Code Agent Teams 的結構與怎麼開啟
• 手把手實戰:用多 agent 跑一個研究任務
• 多代理系統的三大翻車模式與解法

觀念一:為什麼一個 agent 不夠用

先把問題說清楚。單一 agent 有三個內建限制:

第一:序列執行,慢。 你叫一個 agent 做四件不相干的事,它只能一件接一件串。每一步都等上一步。四件事要四倍的時間。

第二:context 視窗有限。 每個 AI 同一時間能「看到」的文字量是有上限的(以 Claude 為例,目前 200K tokens)。一個複雜專案的所有程式碼、文件、歷史加起來可能遠超這個上限——塞不進去就看不到,看不到就可能做錯。

第三:一個角色難以自我審查。 叫同一個 agent 「幫我寫,然後幫我找自己的錯」,它往往找不出來。人也一樣,自己的文章自己改,很難抓到邏輯漏洞——需要另一雙眼睛。

多代理架構解決這三個問題:把任務切塊、平行執行、不同 agent 互相審查。

觀念二:orchestrator 白話解釋

多代理系統有兩個角色,你只要記住這兩個詞就夠了:

Orchestrator(統籌者):負責看清楚全局、拆解任務、派工,不自己做細活。像工程師裡的 tech lead,或者一個工程總監:他知道整個專案要做什麼,把前端交給 A、後端交給 B、測試交給 C,然後統整結果。

Subagent(執行者):接到任務、埋頭做,完成後回報。它的視野很窄——它只知道自己被派的那一塊,不需要了解全局。

在 Claude Code 裡,這個機制叫做 Task tool。當你叫 Claude Code 去做某件事,它在背後可以用 Task tool 開一個新的 Claude 實例、給它一段說明、讓它去執行、然後把結果帶回來。你在主視窗看到的只是「它完成了」,但底下可能同時有好幾個 subagent 在跑。

2026 年 2 月,Anthropic 隨 Opus 4.6 推出一個實驗功能把這個機制包起來:Agent Teams——一個 session 當 team lead,它統籌、分配、驗收;多個 teammate 各自在自己的 context 視窗裡工作,完成後報告給 team lead。跟單純的 subagent 不同的是,teammate 之間共享一份任務清單、可以自己認領工作,還能直接彼此溝通,不一定所有事都要繞過 team lead。

觀念三:分工的三種理由

多代理不只是「跑快一點」這麼簡單。整理成三個理由,每個都有它的適用場景:

理由一:並行加速

四份競品報告、同時調查四家公司,每家派一個 subagent,一起出發。原本要四小時的工作,變成一小時——因為四個 agent 平行跑,時間取最慢那個,不是相加。

適用:任務之間沒有依賴關係,做 A 不需要等 B 的結果。

理由二:專業分工

一個 orchestrator 管全局,一個 subagent 只負責搜尋資料,一個只負責寫稿,一個只負責審查語法。每個角色的 system prompt 可以針對它的職責高度最佳化。

適用:任務有明確的「階段」或「職能差異」,讓各角色成為專家。

理由三:互相審查

寫作 agent 寫完,審查 agent 讀並且批評它。因為兩個 agent 的 context 不同、沒有互相的「情感包袱」,審查者更容易找到問題。這比叫同一個 agent 自我校對效果好很多。

適用:品質要求高、需要批判性思考的場景(報告、法律文件、技術設計)。

手把手實戰:研究任務多 agent 分工

我們用一個真實場景:「幫我研究台灣三個主流 AI 寫作工具(Notion AI、Gamma、Claude.ai),比較功能、定價、適合誰。」

這個任務拆一下:調查三家工具可以平行跑,最後再合併比較。完美的多 agent 場景。

# 在 Claude Code 設定或專案的 .env 裡加上
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

你是任務統籌者。請用三個獨立的 subagent 分別調查以下三個 AI 工具:
1. Notion AI(功能、定價、適合對象)
2. Gamma(功能、定價、適合對象)
3. Claude.ai 付費版(功能、定價、適合對象)

每個 subagent 完成後回傳結構化報告(Markdown 格式,包含:功能亮點、方案與定價、適合誰、限制)。三份報告都收到後,你再整合成一份比較表格。

先告訴我你打算怎麼拆分任務,確認後再執行。

[Orchestrator] 啟動 Subagent A:調查 Notion AI...
[Orchestrator] 啟動 Subagent B:調查 Gamma...
[Orchestrator] 啟動 Subagent C:調查 Claude.ai...
[Subagent A] 搜尋 Notion AI 定價頁面...
[Subagent B] 搜尋 Gamma.app 功能列表...
[Subagent C] 取得 Claude.ai 付費方案資訊...

謝謝。現在請你扮演一個挑剔的使用者——讀完這份比較表,找出三個地方你覺得資訊不夠清楚、或可能有誤,提出來讓我決定要不要補查。

好,針對第一點,派一個 subagent 去 Gamma 官網定價頁確認年繳方案細節,回來後更新比較表。

多代理翻車三大模式

現在來講讓人搥牆的部分。多代理很強,但失控起來也比單一 agent 更難救。

翻車模式一:傳話遊戲失真

**症狀:**Orchestrator 派給 subagent 的任務說明只有幾行,但原始需求其實有很多細節。Subagent 沒收到完整脈絡,照著不完整的指令跑,產出方向跑偏了。等你看到最終結果才發現——這時候所有 subagent 都跑完了。

**具體情境:**你叫 orchestrator「調查競品的定價」,但你原本的意思是「台灣地區、以中小企業為目標客群的定價方案」。Orchestrator 傳給 subagent 的指令只有「調查定價」,subagent 就調查了全球方案、企業大客戶的數字——不是你要的。

**解法:**在最一開始給 orchestrator 的指令裡,把所有限定條件和格式要求都寫清楚,要求它在派工時把條件完整傳下去。可以這樣寫:

重要:你在派工給 subagent 時,必須把以下限制條件完整帶入每個 subagent 的說明:
- 地區限定:台灣
- 目標客群:中小企業(50 人以下)
- 定價格式:列出月繳與年繳,折扣百分比
- 資訊來源:必須是官方網站或 2025 年之後的文章

翻車模式二:上下文撞牆、agent 失憶

**症狀:**一個複雜任務拆成十個步驟,跑到第八步時 orchestrator 的 context 視窗快滿了——它「忘記」了前幾步的結論,或者開始重複做已經做過的事。你在主視窗看到:

[Orchestrator] 我注意到之前尚未調查 Notion AI 的定價...

但 Subagent A 三步前就調查完了,結果已在報告裡。Orchestrator 失憶,準備要重跑。

**解法:**把中間結果存成檔案(不要只留在記憶裡)。要求 orchestrator 每完成一個階段就輸出一份 progress.md,內容是到目前為止所有已知結論的摘要。之後的步驟開頭都要先讀這份檔案——這樣就算 context 翻轉,事實依然在磁碟上。

每個階段完成後,把所有已確認的結論存進 progress.md(追加模式,不要覆蓋)。之後每個新 subagent 開始前,先讀取 progress.md 確認現狀。

翻車模式三:代理鬼打牆,無窮迴圈

**症狀:**Orchestrator 發現 subagent 的結果有問題,叫它重跑;subagent 重跑後結果一樣有問題;orchestrator 再叫它重跑——三個人來回踢皮球,token 燒完也沒有產出。你看到對話視窗裡一直在轉,帳單一直在跑。

具體錯誤訊息(常見樣式):

[Orchestrator] Subagent B 的輸出不符合格式要求,請重試...
[Subagent B] 已依指示重新格式化...
[Orchestrator] 仍不符合要求,請重試...
[Subagent B] 再次調整...
(重複 8 次)

**解法:**在 orchestrator 的指令裡加上「最多重試幾次」的條件,超過就直接跳過或升交給你:

如果某個 subagent 在兩次嘗試後仍無法產出符合要求的結果,停止重試,在最終報告裡標記「此項目需人工補查」,繼續處理其他任務。不要陷入無窮重試。

費用要注意:多代理燒得更快

多代理等於同時跑多個 Claude 實例,token 消耗是倍數計算。三個 subagent 同時跑,費用大約是三個 session 加總。以 Claude Code 的 Pro 方案($20/月)日常使用 OK,但大量多代理任務容易撞到限制;想穩定跑多代理,建議至少 Max 5x 方案($100/月)。

剛開始體驗時,先派 2-3 個 subagent 做短任務,確認流程跑通再放大。不要上來就開十個 agent 跑幾小時——先驗證方向對,再決定規模。

常見坑

坑 1:開了 Agent Teams 但看不到 Teammate 狀態欄

症狀:設定了 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1,重啟後側欄還是沒有出現 Team 選項。

解法:確認環境變數是寫在 Claude Code 本身的設定裡,不是專案的 .env。Claude Code 的全局設定路徑在 ~/.claude/settings.json,把 "experimentalAgentTeams": true 加進去,或者在 Claude Code 設定 UI 裡找 Experimental 區塊手動切換。確認後完全關閉、重新開啟 Claude Code(不是只重整對話)。

坑 2:Subagent 回傳的格式完全不對

症狀:你要求 Markdown 格式的結構化報告,subagent 回了一大段自由文字,沒有標題沒有表格。Orchestrator 的整合因此爆掉——拿到的材料沒有辦法解析。

解法:在給 subagent 的指令裡用具體範例說明格式。不要只說「Markdown 格式」,而是這樣:

回傳格式必須嚴格遵照以下結構:

## 工具名稱

**功能亮點**
- (條列)

**方案與定價**
| 方案 | 月繳 | 年繳 | 適合對象 |
|------|------|------|---------|

**限制**
- (條列)

給範例永遠比描述規則有效。

坑 3:Orchestrator 自己去做了,沒有派給 Subagent

症狀:你叫 orchestrator 派三個 subagent,但它直接自己回答了三家工具的比較,根本沒有開任何 subagent。對話視窗裡看不到任何 [Subagent X] 的標記。

原因:如果任務對 orchestrator 來說「感覺不難」,它會選擇直接回答,因為這樣更快。它不知道你「學習多代理」這件事本身是目的。

解法:明確在 prompt 裡說「這個任務必須透過 subagent 分工執行,不可以自己直接回答」。或者加一個理由讓它相信分工有意義:「因為三家工具的資訊需要即時搜尋,請分別派 subagent 去各自的官網取得最新資訊。」

作業

1. **體驗平行執行:**用本課的研究任務 prompt(三工具比較),實際跑一遍。觀察主視窗裡 subagent 的啟動順序,記下整個任務花了多少時間。
2. **設計你的分工:**想一個你生活或工作裡常做的重複性研究任務(例如:比較幾個訂閱服務、調查幾個地點的資訊),寫出一個 orchestrator 指令,把任務拆成 2-3 個可平行執行的 subagent。不需要真的跑,光是「想清楚怎麼拆」就是很重要的練習。
3. **測試翻車保護:**在你的 orchestrator 指令裡加入「最多重試兩次,超過就標記為待補查」的條件。測試當 subagent 故意給錯格式時,orchestrator 能不能按計畫停下來。

下一課預告

你已經知道怎麼讓多個 AI 分身分工合作了。但用完這一課的體驗之後,很多人會發現一件事:每次開一個新的 agent 對話,它好像什麼都不記得——你上次告訴它你的偏好、你的專案背景、你的風格,下次開它又全忘了,要重新說一遍。這不是 bug,是 AI 記憶機制的本質設計。

第 5 課《記憶與脈絡:為什麼 Agent 會忘記》,我們會把這個問題從根說清楚:context 視窗是什麼、記憶有哪幾種(有些真的是永久的)、怎麼讓 agent 記住你的工作規矩——這樣你就不用每次開對話都重新自我介紹。