用 Claude Code subagents 拆解大型任務：一個能 ship 的工作流

你有沒有遇過這種狀況：一個任務明明只有一個目標，做起來卻像在管十個分頁。一邊翻程式碼找某個函式定義，一邊查第三方套件的最新用法，一邊還要記得剛剛那個測試為什麼會掛。每切換一次，腦袋就要重新載入一次上下文，到最後真正做決定的力氣反而被切換成本吃光。

Claude Code 的 subagent 機制，就是為了解決這件事而存在。它讓你的主 agent 不必親自跑完每一段苦工，而是把可以獨立完成的部分派給專責的 subagent，自己只接收結論。這篇文章拆解三件事：什麼時候該動用 subagent、怎麼把任務切給它、以及怎麼避免 context 在中途爆掉。

Claude Code subagent 是什麼？

先把心智模型講清楚，後面的判斷才有依據。

一個 subagent，本質上是一個全新的 Claude 實例：它有自己獨立的 context window，由主 agent 啟動，收到一份「自我完整」的任務說明，做完之後回傳一則總結訊息給主 agent。（完整的設定方式——自訂系統提示、限制可用工具——可參考 Anthropic 官方的 Claude Code subagents 文件。）

關鍵在最後一句。主 agent 看到的，只有那則總結，而不是 subagent 中間讀了哪 50 個檔案、跑了哪些搜尋、試錯了幾輪。那些過程全部留在 subagent 自己的 context 裡，做完就丟。

這個「過程留在裡面、只回傳結論」的設計，正是 subagent 全部價值的來源。它帶來三件事：

• 隔離：龐大的搜尋結果、整份檔案的內容、冗長的試錯，全部關在 subagent 的 context 裡，不會污染你主線的思路。
• 並行：彼此獨立的子任務可以同時開跑，而不是排隊一件一件做。
• 專業化：你可以用為特定任務調校過的 agent（搜尋、程式碼審查、探索），它們有各自的提示詞與工具權限。

理解了這三件事，「什麼時候該用」就不再是憑感覺，而是可以對照的判斷。

什麼時候該用 subagent？

判斷準則

當一個子任務同時滿足下面兩個條件，它就是 subagent 的好對象：

1. 它會產生大量你不需要逐字看的中間內容。 例如「在整個 repo 找出所有呼叫這個 API 的地方」，過程要翻幾十個檔案，但你真正要的只是一張清單。
2. 它可以被一句話講清楚目標、且不需要跟你來回確認。 你能寫下「找什麼、在哪找、回傳什麼格式」，subagent 就能獨立跑完。

最典型的三種場景：

• 開放式搜尋與探索：「這個功能是怎麼跨檔案串起來的」「X 在哪裡被定義」——這類問題的成本不在答案，而在抵達答案前要翻的量。
• 彼此獨立的並行工作：同時審查三個模組、同時研究四個套件的最新文件。它們之間沒有先後依賴，就讓它們同時跑。
• 保護主線 context：當某段工作會吐出大量輸出，但你只需要結論，把它推進 subagent，換回一份精簡摘要。

什麼時候不要用 subagent？

反過來，下面這幾種情況硬塞 subagent 反而更慢：

• 目標已經明確。 如果你已經知道是哪個檔案、哪一行，直接讀就好。為了「讀一個已知路徑」去啟動一個 subagent，是純粹的浪費。
• 需要緊密來回。 有些任務每一步都得看你的即時反應再決定下一步。這種對話節奏一旦切進 subagent，反而被它的「一次性回傳」打斷。
• 步驟之間有強依賴。 如果第二步必須拿到第一步的結果才能開始，那它們本來就無法並行，硬拆只是增加交接成本。

一句話總結判斷：當「交接成本」低於「省下的 context 與時間」，就用；反過來就別用。

怎麼把任務切給 subagent？

這是最多人做錯、也最關鍵的一段。subagent 之所以常常交出淺薄、籠統的成果，幾乎都不是因為它能力不足，而是因為任務交代得太隨便。

記住一個前提：subagent 完全沒有你這場對話的記憶。 它就像一個聰明、但剛走進房間的同事——不知道你試過什麼、排除了什麼、為什麼這件事重要。所以一份好的任務說明要做到「自我完整」：

• 說清楚目標與動機：你想達成什麼、為什麼。
• 交代已知與已排除的：把你已經查過、確定不是的方向講出來，省得它重走冤枉路。
• 指定回傳格式與長度：要清單就說要清單，要短就明講「200 字以內」。不限制，它就傾向給你一大坨。
• 查詢類給指令，調查類給問題：如果是明確的查找，直接給它要跑的指令；如果是開放調查，給它要回答的問題——因為當你的前提本身有問題時，被規定死的步驟反而會變成包袱。

還有一條最容易被忽略的原則：不要把「理解」外包出去。

不要寫「根據你查到的東西，把這個 bug 修掉」。這種句子等於把真正的思考——也就是綜合判斷——推給了 subagent，而它看不到全局。好的做法是你自己先消化結論，再把具體的指令交出去：改哪個檔案、改哪一行、改成什麼。subagent 負責執行苦工，你負責保留判斷。

舉個對比就清楚了：

太籠統：「研究一下我們的認證流程然後修好登入的 bug。」

夠具體：「讀 auth/session.ts，確認 token 過期後是否有正確清除 cookie。我懷疑問題在第 40 行附近的 early return 漏掉了清除步驟。回報：這個假設對不對，如果不對，實際斷在哪。」

第二種寫法，subagent 回來的東西你幾乎可以直接用；第一種，你大概要再來回三輪。

怎麼避免主線 context 爆掉？

就算用對了場景、切對了任務，如果不留意，主線的 context 還是會在不知不覺中被塞滿。下面三個做法，是讓一人工作流能長時間穩定跑下去的關鍵。

第一，把「讀的量」丟出去，把「想的部分」留下來。 凡是會產生大量中間內容的閱讀與搜尋——翻整個 repo、掃幾十個檔案、爬一長串日誌——都推進 subagent，讓那些原始內容在它的 context 裡燒掉，你只收一份消化過的摘要。你的主線永遠只裝結論，不裝原料。

第二，明確限制回傳長度。 預設情況下，subagent 傾向把它做的事鉅細靡遺講完。主動要求「回報一張清單」「300 字以內」「只講有沒有過、沒過的話斷在哪」，能讓回傳的 context 維持精簡。你要的是訊號，不是它的工作日誌。

第三，並行可以、重工不行。 把彼此獨立的工作同時派出去沒問題，但不要在派出去之後，自己又在主線跑一遍同樣的搜尋。如果你把某段研究交給了 subagent，就等它的結果，別並行地做重複的事——那只會兩邊都燒 context，還可能拿到互相打架的結論。

subagent 回傳的是它「打算做什麼」，不一定等於它「實際做了什麼」。當它寫了或改了程式碼，動手驗證真正的改動，而不是只信它的總結。

這條提醒值得單獨記住：信任，但要驗證。摘要描述的是意圖，不是證據。尤其當 subagent 動到程式碼，務必親自看一眼實際的 diff，再把工作報成完成。

一個人，跑出一支團隊的形狀

把上面拼起來，你會發現 subagent 真正改變的，不是「做得更快」這麼表層的事，而是一個人能掌控的任務複雜度上限。

過去你只能線性地做：查完這個、才查那個、再回來組起來，全程塞在同一顆腦袋、同一條 context 裡。有了 subagent，你變成那個「派工與整合」的角色——把能獨立的丟出去並行跑，自己專心在只有你能做的綜合判斷上。這正是路澄 LUCE 一直在談的「能 ship 的 agentic 工作流」：不是堆更多工具，而是重新切分工作，讓真正稀缺的注意力，只花在值得花的地方。如果你想把這套「一人團隊」的工作流真正落地到自己的專案或公司，這也正是路澄 LUCE 的「AI 一人公司」導入服務在做的事。

從你手邊那個「明明一個目標、卻像管十個分頁」的任務開始。把其中最不需要你親自盯的一段切出來，寫一份自我完整的說明，交給一個 subagent。跑通了，再擴展。

常見問題

subagent 和直接開一個新對話視窗有什麼不同？

開新對話視窗，你得手動把背景、相關檔案、目標再貼一次，跑完的結果也要你自己讀完、再搬回原本的工作裡。subagent 則是由主 agent 自動帶著一份「自我完整」的任務說明啟動，做完只回傳一則總結，過程的中間內容不會回流到你的主線。差別不在「能不能分工」，而在你省下了搬運與切換的成本。

一次可以同時跑幾個 subagent？

彼此沒有依賴的子任務可以同時派出去並行跑，例如同時審查多個模組、或同時研究多份套件文件。重點不是數量上限，而是這些任務之間不能有先後依賴——只要第二件事得等第一件的結果，它們本來就無法並行，硬拆只會增加交接成本。

subagent 看得到我和主 agent 之前的對話嗎？

看不到。每個 subagent 都是全新的 Claude 實例，沒有這場對話的任何記憶。這正是任務說明必須「自我完整」的原因：把目標、動機、已知、已排除的方向、以及要的回傳格式都寫進去，subagent 才不會因為缺背景而重走冤枉路或給出籠統結果。

哪些任務不適合丟給 subagent？

三種情況硬塞 subagent 反而更慢：目標已經很明確（你已知道是哪個檔案、哪一行）、需要每一步即時來回確認、或步驟之間有強依賴。判斷準則只有一句：當交接成本低於省下的 context 與時間，就用；反過來就別用。

• #claude-code
• #subagents
• #agentic-workflow