![[AI Context #5] 為什麼要使用子代理程式？AI 代理程式的上下文隔離原理與委派標準 封面圖](/assets/images/posts/6f12e091-1d37-4258-b659-1070e39916f1/1.jpg)
前幾篇介紹了節省上下文的方法：在工作邊界清除歷史紀錄（第3篇），並將固定成本設計得短小（第4篇）。但仍有些工作難以負荷，例如「請搞清楚這個程式碼庫中的付款邏輯如何流動」。認真的代理程式會讀取數十個檔案；如第1篇所見，讀到的內容全都會累積在上下文中。調查完成時，反而沒有足夠的上下文用來修改程式碼。
本篇主題的子代理程式（subagent）能從結構上解決這個問題。重點只有一個：上下文視窗不必只有一個。
在另一個上下文中工作，只帶回結論
子代理程式是由主要代理程式建立的獨立代理程式執行個體。關鍵在於，這個執行個體會獲得一個專屬且乾淨的新上下文視窗。
流程如下。主要代理程式把「調查付款邏輯流程並摘要」這一則指示交給子代理程式。子代理程式在自己的上下文中讀取數十個檔案、搜尋並追蹤呼叫關係。過程會累積數萬個 token，但全都屬於子代理程式的上下文。完成後，它回傳一份整理好的報告便消失。主要上下文只留下1則指示和1份報告，也就是幾百到幾千個 token。
這是組織中很熟悉的結構。主管不親自做市場調查，而是交給調查員，再收到一頁報告。重點是調查員瀏覽的100份資料不會堆在主管桌上。主管的桌面，也就是主要上下文，只保留做決策所需的資訊。
哪些工作該委派？
適合委派的工作都有共同點：過程沉重，結論輕量。
第一，探索與調查。「所有使用這個函式的地方」或「掌握與此錯誤相關的程式碼」等工作需要大量閱讀，但最終答案只是一份清單或摘要，是子代理程式的典型工作。Claude Code 設置專用探索代理程式也是基於同樣原因。
第二，可以平行拆分的工作。如果要分別分析5個模組，5個子代理程式可以在各自的上下文中同時進行。不僅能縮短時間，也不會讓彼此的中間產物混在同一個上下文中造成混亂。
第三，是需要新鮮觀點的工作，性質稍有不同。程式碼審查就是典型例子。剛寫完程式碼的主要代理程式，其上下文充滿實作時的假設與試錯。在這種狀態下審查自己的程式碼，容易受自身假設限制而過於寬容。只把程式碼交給沒有背景脈絡的子代理程式，它就能以陌生審查者的視角檢視。此時隔離不是節省 token，而是品質機制。
反過來，有些工作委派反而吃虧。讀取一兩個檔案這類輕量工作，委派的往返成本更高。高度依賴既有對話脈絡的工作也不適合，原因如下。
隔離的代價：子代理程式什麼都不知道
子代理程式的乾淨上下文並非免費。乾淨也代表它完全不知道到目前為止的對話。
主要工作階段累積一小時的前提，例如這個專案必須維持舊版 API、不可碰測試，以及使用者偏好的做法，子代理程式全都不知道。除非寫進指示，否則這些資訊對它不存在。因此，委派品質取決於指示品質。必須在單一指示中放入必要背景、限制條件與期望的產出格式，才能避免收到基於錯誤前提完成的報告。
回傳方向也是如此。主要代理程式收到的只有子代理程式的最終報告，報告未包含的發現會隨子代理程式消失。因此，養成指定報告格式的習慣很有用，例如「請包含影響判斷的依據與已確認的檔案清單」。第2篇提到的 context poisoning 也會在此再次出現。若報告不準確，錯誤會以壓縮形式移植到主要上下文；主要代理程式沒有原始資料可驗證，就會照單全收。越重要的結論，越應連同依據一起取得。
總結
- 子代理程式在獨立的乾淨上下文中工作，只回傳結論。重點是過程中的數萬個 token 不會進入主要上下文。
- 過程沉重、結論輕量的工作（探索、調查、平行分析）適合委派。像審查這類需要新鮮觀點的工作，隔離也能以品質為目的發揮作用。
- 隔離的代價是脈絡中斷。子代理程式不知道對話歷史，因此指示必須包含完整背景與限制，報告也必須要求依據。
系列最後一塊拼圖還沒完成。執行 /clear 會讓對話消失，子代理程式也會在工作階段結束時消失，但專案仍會繼續。即使工作階段結束也必須保留的知識，應該放在哪裡？下一篇將討論上下文之外的儲存空間，也就是記憶與外部化。