你派了一個子代理（sub-agent）去做一件大事：把整個專案的舊版 API 呼叫，全部換成新的 SDK。聽起來很適合丟給它——你不想讓這堆瑣碎的搜尋跟改寫塞滿你自己的對話視窗。

然後它做到一半就卡住了。

不是它不會做，是這件事對「一個」子代理來說太大了。它得讀十幾個模組、追每一處呼叫、改完還要驗證，這些東西全擠進它那一個有限的 context 視窗，到後面它開始忘記前面查過什麼，輸出越來越飄。它面對的，正是你一開始想躲掉的那個問題——只是換它來承受。

問題的根，是它沒辦法像你一樣「再往下派人」。

先試過的那兩條路，為什麼都不夠順

第一個直覺，是回到你自己身上，把大任務切成十幾個小任務，一個一個派子代理。可行，但你又變回那個微觀管理的中間人——每個子任務的邊界、每個回報的串接，全得你親手喬。你只是把子代理沒法分層的痛，搬回自己頭上扛。

第二條路是開 Agent Teams，拉一組平級的代理同時上工。這個在「很多份量差不多、彼此獨立的活」上很強，我之前在 Agent Teams 那篇寫過。但它的形狀是「攤平」的——一排人並肩做事。而你現在這個任務的形狀是「有層次」的：一件大事底下分幾個中等的事，每個中等的事底下又有一堆小事。硬用攤平的隊形去套有層次的任務，總有一層對不上。

Claude Code 在 2.1.172 加進來的 Subagent Nesting（巢狀子代理），補的就是這一層：子代理可以自己再開子代理，最多五層深。

換個畫面：這就是一間公司怎麼把事情做完

別急著看設定，先把畫面換成你熟悉的東西——一間公司接了個大專案。

老闆（也就是你的主對話）不會自己去寫每一行程式。他把「做完這個專案」交給一個專案經理。這個經理底下事情還是太多，於是他把專案拆成幾塊，每塊交給一個組長。組長再把自己那塊拆成具體任務，分給工程師。工程師做完，把結果交回組長，組長彙整後交回經理，經理再給老闆一句「搞定了」。

巢狀子代理就是這個。每一層都能往下再委派一層，事情順著層級往下拆、結果順著層級往上收。在這之前，Claude Code 的子代理只能當「工程師」——能做事，但不能再請人；現在它也能當「組長」「經理」了。

這裡有個關鍵，是這整套機制真正值錢的地方：每一層都有自己獨立的工作桌。

工程師桌上堆滿草稿、查到一半的資料、試錯的痕跡——這些組長通通看不到，組長只收到工程師交上來那份乾淨的結論。同樣地，老闆也不會看到工程師桌上的一團亂，他只看到經理那句「搞定了」。對應到 Claude Code，就是每個子代理都在自己獨立的 context 視窗裡幹活，它中間爆搜了多少檔、走了多少冤枉路，都不會回灌到上一層的視窗。上一層只拿到最終那段摘要。

回頭看開頭那個卡住的子代理——它之所以撐不住，就是因為它被迫把「組長該管的層級」跟「工程師該做的細節」全塞進同一張桌子。給它開分身的能力，等於給它多幾張乾淨的桌子，把細節推到下一層去爆，自己只留著彙整。

為什麼是五層，不是無限層

你可能會問：既然能往下開，為什麼卡在五層？

寫過遞迴的人對這個會有直覺——任何會自己呼叫自己的東西，都必須有個停下來的底，不然就是無限展開，直到把資源燒乾。子代理開子代理，本質就是遞迴，五層就是那個明確畫下的底。

但除了「防失控」，還有個更實際的理由，跟傳話遊戲一模一樣。每往下一層，結果回來就要多經過一次「摘要」。工程師講給組長、組長講給經理、經理講給老闆——每轉一手，資訊就被壓縮、被取捨一次。轉一兩手還好，轉到第七、第八手，老闆聽到的版本跟現場實際發生的，可能已經對不太上了。五層是個折衷：深到足以容納大部分真有層次的任務，又淺到回報不至於被摘要到走樣。

參考來源：Claude Code Changelog（v2.1.172）。深層巢狀的實際協調行為，文件著墨不多，下面怎麼用的判斷是我自己照它的設計推的，你實測時可以自己抓手感。

什麼時候該用，什麼時候別硬巢狀

有了能往下開五層的能力，最容易犯的錯就是「能開就開」。

判準其實很單純：先看你的任務有沒有天然的層次。

像「把整套服務從一個雲遷到另一個雲」這種，天生就是樹狀的——大遷移底下分網路、資料庫、服務三塊，每塊底下又是一堆具體檔案。這種任務每一層都值得一張獨立的桌子，巢狀下去剛剛好，每個子代理只需要扛住自己那一層的 context。

反過來，如果你的任務其實是「平的」——就是一堆份量差不多、彼此不太相干的小活——那硬巢狀只是自找麻煩。多包一層，就多一次委派的延遲、多一次回報的損耗，換不到任何隔離的好處。這種情況，一層子代理直接做掉，或者開 Agent Teams 攤平處理，都比堆三層漂亮。

一個能戳破過度設計的反問：這一層，真的需要一張新桌子嗎？ 如果這層子代理要處理的東西，塞進上一層的視窗也綽綽有餘，那它就不值得獨立成一層——你只是在為了用新功能而用新功能。好的委派從來不是「我能指揮幾層」，是「每一層只交出剛好夠用的資訊，不多不少」。

學完這個，往哪走

巢狀子代理真正改變的，不是你能同時跑幾個 AI，是它逼你開始用「組織設計」的眼光去看一個任務——這件事該分幾層？哪一層需要被隔離保護？資訊在每一層之間，該交出多少、藏起多少？

這套思考方式一旦裝進腦袋，你會發現它跟你怎麼設計一個系統的模組邊界、怎麼決定一個函式該知道多少、怎麼切微服務的職責，根本是同一回事。委派的藝術和封裝的藝術，底層是同一門功課。

如果你是第一次接觸子代理，先回去把基礎那篇的「為什麼要隔離 context」吃透，巢狀只是把這個觀念多疊了幾層。如果你已經很熟、而且想要對「哪個子代理在什麼時候做什麼」有程式級的精確控制，那下一站是 Dynamic Workflows——用腳本把整套編排寫死，而不是靠 AI 臨場決定。

巢狀子代理是「讓 AI 自己決定怎麼分層」，Dynamic Workflows 是「你來決定每一層幹嘛」。先學會放手，再學會收回精確控制——這個順序，比反過來好走得多。