多 Agent 體系：分工和調度

為什麼需要多個 Agent

主迴圈（query.ts）能處理大部分任務，但有兩類情況它單獨應付起來很吃力：需要長時間並行探索的任務，以及需要獨立驗證的任務。

並行探索的問題在於上下文污染。讓同一個 Agent 同時探索三個不同的程式碼路徑，它的上下文視窗很快就會被混在一起的資訊塞滿，判斷品質下降。拆成三個獨立的子 Agent，每個只看自己那條路徑，最後把結果彙整給主 Agent，效果好得多。

獨立驗證的問題更微妙。讓同一個模型既寫程式碼又驗證自己寫的程式碼，驗證形同虛設——它會傾向於認為自己的輸出是對的。Verification Agent 用對抗性 prompt 強迫它以批評者的角色重新審視，這個角色切換需要物理隔離，不能在同一個上下文裡完成。

6 種內建 Agent

限制最嚴格的是 Explore Agent：純唯讀，工具清單只剩 Read/Glob/Grep/LS。設計意圖是讓它無限制地探索程式碼庫，完全不用擔心副作用——即使 prompt injection 攻擊成功，它也寫不了任何東西。

另一個極端是 Verification Agent，system prompt 有 130 行，充滿對抗性措辭。核心思路是強迫它主動找理由說「這個實作是錯的」，而不是確認「這個實作是對的」。同一個問題用這兩種方式提，心理學研究早就發現答案會不一樣，Anthropic 直接把這個結論編進了 prompt。

General Agent 能力最全，工具集完整，是通用子任務的預設選擇。其餘三種各有側重：Architect Agent 偏向設計討論，不直接動程式碼；Summarizer Agent 做上下文壓縮；Planner Agent 把模糊需求拆解成有序子任務清單。

AgentTool.tsx：調度中心

子 Agent 通過 AgentTool（一個普通工具）被主 Agent 呼叫。主 Agent 在工具呼叫裡指定 Agent 類型、任務描述、輸入上下文，AgentTool.tsx 負責把這個請求轉化成一個完整的子 Agent 執行環境。

調度時有兩條執行路徑。Fork path 是預設路徑：子 Agent 繼承父 Agent 的上下文前綴（prompt cache 命中），只追加子任務的特定上下文。成本大約是 spawn 的 1/10。Spawn path 是乾淨啟動：全新上下文，不繼承父 Agent 狀態，用於需要完全隔離的場景（如 Verification Agent）。

runAgent.ts：生命週期管理

每個子 Agent 的生命週期由 runAgent.ts 管理，大致分四個階段：

初始化階段組裝 Agent 特定的 system prompt，載入對應的工具集，建立獨立的對話歷史。執行階段是一個縮小版的主迴圈——同樣的 10 步，但上下文邊界是隔離的。結果收集階段把 Agent 的輸出序列化為結構化摘要（強制要求 ≤1500 token），不允許直接回傳原始工具輸出。清理階段釋放工具資源，記錄執行統計。

結果摘要的 token 上限不是建議，是硬約束。目的是防止子 Agent 的冗長輸出反過來塞滿父 Agent 的上下文視窗，抵消並行化帶來的收益。

5 種任務類型路由

AgentTool.tsx 內部有一個任務類型路由，根據主 Agent 的請求特徵自動選擇 Agent 類型：

探索類任務（搜尋程式碼庫、理解結構）走 Explore Agent，驗證類走 Verification Agent，架構討論走 Architect Agent。需要壓縮長歷史或大量工具結果時，Summarizer Agent 上場；任務描述模糊、需要先拆解再執行時，先過 Planner Agent。對應不上任何專門類型的，全都歸 General Agent。

路由邏輯是基於 prompt 特徵的分類，不是嚴格的規則引擎，主 Agent 也可以在呼叫 AgentTool 時明確指定類型覆蓋自動路由。

---

參考來源： 本文內容參考 Xiao Tan（@tvytlx）的《Claude Code 源碼架構深度解析 V2.0》，基於原報告的分析框架和研究成果整理。