很多團隊在搭建企業級 Agent，甚至在使用 Claude Code時，都習慣按業務或部門拆出一大堆“專家子 Agent”。
動輒十幾個甚至上百個子 Agent 層層巢狀，覺得這樣才算架構清晰。
但就在最近，Anthropic 官方卻給這股熱潮潑了一盆冷水，甚至開始下場“勸退”了。
Anthropic Applied AI 團隊在對比了多個企業級 Agent 部署後發現：配備了 Skills 的「單 Agent」，在輸出質量上往往優於複雜的「子 Agent」架構，且單任務的成本和延遲也更低。
這篇文章給出了非常具體的架構判斷與遷移方法：你可以按“上下文獨立性”決定子 Agent 的去留，將提示詞和 API 轉化為 Skills 與工具，把合適的子 Agent 逐步並回主循環，最後用端到端評測確保遷移的穩定性。
子 Agent、Skills 和提示詞各自該承擔多少工作？這套方法能幫你徹底想清楚。接下來，我們就從多 Agent 架構為什麼會變複雜說起。
一、多 Agent 架構為什麼變複雜，何時可以簡化
最近，一些企業將 Agent 架構中的路由器、規劃器和各領域子 Agent 並回「主 Agent 循環」後，取得了顯著收益。相比於「一個超長提示詞包攬一切」或「複雜的多 Agent 架構」，單 Agent + Skills 的模式表現出了極大的優勢。
在此之前，我們經常看到企業的 Agent 設計沿著熟悉的路徑層層疊加：先放意圖分類器，再接固定的多步推理流程，然後按使用者分群設定不同路徑，分出獨立的推薦分支，最後在最頂層加一個多 Agent 編排器。例如，某家公司的客服 Agent 內部竟然塞了 12 個專家子 Agent，這不僅導致品牌調性難以統一，還大幅增加了延遲，嚴重損害了使用者體驗。
這類設計得到的反饋往往是：絕大部分架構都在替模型做“不再必要”的工作。 如今，一個清晰的系統提示詞、4 至 5 個輕量資料工具和嚴格的輸出限制，就能覆蓋大部分用例。
很多企業之所以按團隊或問題類型分別設定子 Agent，其實是讓技術架構照搬了公司的組織架構圖——這正是“康威定律”的體現。
當然，子 Agent 並非毫無價值。但只有滿足以下任一條件時，才建議保留子 Agent：
- 上下文膨脹導致性能下降：單個 Agent 循環因上下文過長，出現了可測量的性能衰退。
- 高並行且上下文獨立：多個任務需要平行處理，且每個任務只需要一個用完即棄的全新上下文窗口。
- 工具過載或指令衝突：單個 Agent 難以在海量工具中做出正確選擇，或者係統提示詞中的指令開始相互打架。
如果不滿足以上三點，盲目在大型組織中推行多 Agent，往往會陷入以下五大常見失敗模式：
- 上下文丟失：你需要決定 Agent 之間交換那些資訊，細節往往在來回傳遞中丟失。
- 子 Agent 氾濫：每個團隊都交付自己的子 Agent，最後衍生出上百個彼此重疊的子 Agent，既無統一標準，也無明確負責人。
- 拼接提示詞衝突：每個團隊都在系統提示詞裡添上一句，最終規則相互衝突，整體口吻極其割裂。
- 評測局部化：各團隊只圍繞各自的子任務過度最佳化。完整評測集無人維護，管理層看到的分數被局部任務稀釋，無法反映真實的端到端表現。
- 高昂的延遲：多 Agent 的跳轉極其耗時。有客戶實測對比發現，單 Agent 循環的運行速度約為多 Agent 架構的 2 倍。
二、解法：在單 Agent 循環中用漸進式披露按需載入
對於跨團隊協作，與其用“編排器 + 子 Agent”來硬性拼湊，往往更有效的做法是回歸單 Agent，並採用漸進式披露機制——即通過 Skills 和 Tool Search（工具搜尋）按需載入上下文與工具。Agent 一開始只看到簡短描述，需要時才載入完整內容。
這種做法之所以在今天行得通，基於三個核心原因：
- 共享上下文能帶來更好的回答。對長時間運行的 Agent，他們希望來自不同任務的上下文都留在主上下文窗口中。Agent 看過此前每一步的結果，就能把它們聯絡起來。相比子 Agent 交回的一組摘要，這樣可以產出更豐富的內容和更深入的見解。這也意味著上下文窗口更少，有損交接也更少。
- 漸進式披露可以防止上下文膨脹。團隊因此能讓一個 Agent 處理多種任務，無須把所有上下文一次性裝進冗長的系統提示詞。這消除了過去把工作拆給多個子 Agent 的主要原因。Claude Code 團隊將 Claude Code 面向更先進模型的系統提示詞縮減了 80% 以上（https://claude.dev/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models/），其中包括對 Skills 和工具採用漸進式披露後刪掉的內容。
- 模型能力更強了。從 Opus 4.5 開始，模型在單個循環中能處理的工作已經遠超大多數團隊的預期。Opus 5.5 和 Fable 5.1 無法關閉思考。近期模型也越來越會在工作過程中說明進展並自我檢查，讓 harness 中的部分機制變得多餘。每一代新模型都讓你能把更多決策從 harness 轉移給模型本身。更簡單的循環也更容易遷移到下一代模型。在他們協助客戶完成的遷移中，僵化的多 Agent 結構常常阻礙新模型承擔更多工作。
單 Agent 循環需要細緻的設計和維護。系統提示詞需要精心管理，Skills 和工具的描述要在合適的時機觸發，上下文窗口、記憶和筆記也要妥善處理。後續章節會進一步討論遷移和設計上需要考慮的問題。
一個中央團隊應負責端到端質量和系統提示詞，並稽核每個新工具和每套新評測，通過後再上線。中央團隊保持精簡，有助於快速迭代，降低大型組織內的協調成本。
如果你選擇多 Agent 路線，先從可行的最簡模式開始，例如生成器加驗證器、編排器加子 Agent，或其他簡單結構。
劃分邊界時，應按上下文拆分。交給每個子 Agent 的工作應幾乎不依賴系統其餘部分，並讓它返回精簡的結果。相互獨立的研究路徑、介面清晰的獨立元件和黑盒驗證都是合適的候選。
如果按問題類型拆分 Agent，它們就會像玩傳話遊戲一樣來回傳遞資訊。每交接一次，資訊保真度都會下降。
三、理想的單循環設計長什麼樣？
許多團隊已經在生產環境中運行編排器和一組專家子 Agent。下面是 Applied AI 團隊建議逐步演進到的單循環設計。
- 一個模型和一個上下文窗口運行開放式工具循環，harness 負責設定輪次與成本預算、寫操作限制等約束。
- 每輪，模型發出一批工具呼叫。harness 平行執行這些呼叫，並把原始結果返回給同一個模型。模型再決定下一步是繼續呼叫一批工具、向使用者提問，還是給出答案。
- 模型給出答案或觸及預算（https://platform.claude.com/docs/en/build-with-claude/task-budgets）時，循環停止。答案生成後，還可以選擇運行目標檢查或驗證器檢查。
- 模型在第一輪把計畫寫入上下文，並隨著結果返回不斷修訂。這是單循環設計與編排器加專家 Agent 方案的主要區別。寫計畫和執行計畫的是同一個模型，因此它可以在執行中途修改計畫。
- 不再需要由程式碼根據規則清單改寫計畫，因為每一步都由模型決定。
- 執行順序和領域流程移入 Skills。
- 硬性限制，包括驗證和審批關卡，以及對話中途出現的需求，例如記憶查詢，移入工具。
- 程式碼仍可用於載入成本低且幾乎始終相關的內容，例如實體解析步驟，也可以在循環呼叫的工具內部處理機械性工作，例如構造請求體、解析資料流，以及在澄清問題後恢復執行。
- 上下文仍需載入，但改由 Agent 自己管理。
這種單循環設計也有助於實現許多團隊期待的最終形態，讓 Agent 理解使用者的高層目標並代為行動，因為它積累的所有資訊都保留在同一個上下文中。
四、實戰指南：如何分步將子 Agent 並回主循環？
如果你已經在生產環境中運行著“編排器 + 專家子 Agent”，可以分四個階段平穩遷移到單 Agent 循環：
第一步：用任務完成評測判斷子 Agent 去留
第一步是建立一套評測集，幫助你判斷某個子 Agent 是否適合併回主 Agent 循環。
Applied AI 團隊見過一種有效的評測結構。中央團隊負責一套共享的端到端評測集，各團隊則隨自己負責的 Skills 提供較小的評測集。即使只有 10 個黃金樣例，也足夠起步。
用評分標準給 Agent 的最終回覆打分，是追蹤回答質量的良好起點。
保留編排器時，還應追蹤路由精準率，確認它是否選對了子 Agent。子 Agent 並回後，則改查 Agent 是否載入了正確的 Skills 或呼叫了正確的工具。
逐步轉向任務完成評測也很有幫助，因為比較不同架構時，任務是否完成最為重要。
在內部系統難以重放、使用者互動難以模擬的環境中，這項工作會比較複雜。Anthropic 內部有一種行之有效的做法，給重要事件記錄時間戳，之後重放這些事件，運行有針對性的評測。
第二步：先合併緊密耦合的領域 Agent
向單 Agent 循環演進，要把子 Agent 並回主循環，改用工具和 Skills 承擔相應工作。具體可以合併領域子 Agent、把子 Agent 作為工具呼叫，或用 Skills 和工具替換它們。
第一次合併前，先建立一套小型端到端評測集。隨後按共享上下文確定並回對象，先處理使用最頻繁的子 Agent。
應當合併那些輸出彼此串聯、訪問同一份資料或經常被一起呼叫的專家 Agent。
例如，如果生產流量中有相當一部分都是先呼叫一個專家 Agent，緊接著呼叫第二個，那麼這兩個 Agent 就緊密耦合，可以考慮合併為一個領域 Agent。
第三步：過渡期，將保留的子 Agent 降級為“工具”
如果符合上述三個條件之一，因而保留了子 Agent，可以讓主 Agent 把它作為工具呼叫。這樣，主 Agent 仍能持續與使用者對話。
只有當子 Agent 需要直接與使用者交談時，他們才建議完整交接，讓它接管對話。其他場景都可以由主循環中的 Skills 加工具處理。
這樣，你可以為子 Agent 定義統一的響應結構，讓主 Agent 對照真實資料核驗結論，並精簡最終彙總步驟的輸入。
這是不錯的第一步，因為你無須重寫子 Agent。在決定把那些子 Agent 並回主 Agent 之前，你還能先得到任務完成評測的基線。
不過，以下問題仍然存在。
- 每個專家 Agent 仍各有提示詞、上下文、負責團隊和評測集。
- 每次呼叫返回的仍是有損摘要。
- 每次呼叫仍是一個巢狀的模型循環，會增加延遲。
第四步：徹底拆解，將子 Agent 轉化為 Skills 和工具
每次只處理一個子 Agent，把它的提示詞轉成 Skills，把 API 呼叫轉成 MCP 工具，徹底併入主 Agent。分別評測保留子 Agent 和並回後的表現，再決定保留那一種方案。
比較時，別只看最終分數，還要看那些任務的結果發生了翻轉。
他們在一個示例客服 Agent 上測試時發現，把一個子 Agent 並回另一個子 Agent 後，延遲降低了，但一個原本能通過的流程卻失敗了。主 Agent 持有訂單查詢工具，沒有向配送專家詢問送達日期，便自行給出了回答。
每次改動前，確保評測集覆蓋生產環境中會共同運行的每一個 Agent 呼叫鏈，也覆蓋 Agent 絕不能違反的每一條規則。
每個任務都要至少運行兩次，因為上述問題在兩次運行中只出現了一次。
四、 組織協同：多個團隊如何共建一個單 Agent？
當子 Agent 被拆解後，各業務團隊的交付物就從“獨立的 Agent”變成了“知識庫、Skills 和 MCP 工具”，並統一交由小型中央團隊稽核上線。這三類資產的維護規範如下：
MCP 工具（負責執行操作、讀取即時資料、返回固定結構）
當 Agent 需要執行操作、從系統讀取即時資料，或按固定結構返回結果時，工具是合適的選擇。遷移期間，你也可以繼續通過工具呼叫子 Agent。
他們建議按使用者意圖給工具分組，不要每個 API 都配一個工具，因為系統提示詞中的工具定義超過 30 至 50 個後，模型往往會更難選對工具。
使用 tool search 並延遲載入工具。儘量減少硬性前置條件，必須保留的條件放進工具內部。
例如，Y 依賴 X 的輸出時，Y 的工具會檢查該輸出是否存在，並返回一條模型可據此處理的指令。
使用者級權限也可以這樣處理。每個工具檢查呼叫者有權查看什麼、執行什麼，並在無權操作時返回一句模型能讀懂的明確拒絕說明。這樣，同一個循環就能服務權限不同的使用者，無須為每個權限等級單獨設定 Agent。
Skills（負責承載業務步驟、規則和判斷方法，即原專家 Agent 的提示詞）
當 Agent 需要瞭解團隊如何開展工作，例如專家子 Agent 的提示詞過去承載的步驟、規則和判斷方法時，Skills 是合適的選擇。
Anthropic 擴充 Skills 庫的做法，是把維護工作交還給編寫 Skills 的人。Claude 可以用 Skills 來建構、測試和精簡其他 Skills，承擔其中的繁重工作。
為了避免 Skills 無序擴張，可以讓每個團隊的直接負責人（DRI）管理各自的 Skills，確保它們設計得當、彼此有明確區分，並附帶合適的評測。
- /skill-creator 可幫助你編寫結構規範的新 Skills，也能審查現有 Skills，進行精簡、去重和重組。
- /skill-doctor 可查看 Skills 庫中每個條目的成本和實際使用頻率，並刪除無用條目。
知識庫（負責存放偶爾需要的靜態參考資料）
知識庫適合存放 Agent 只偶爾需要的參考資料。政策、指標定義、產品規格等事實性內容和參考資料，可以放在搜尋或查詢工具後面，由模型按需呼叫，也可以作為參考檔案放進 Skills。儘量避免用程式碼檢索這些內容，再貼上到提示詞中。
寫在最後
隨著模型不斷演進，我們對最佳實踐的認知也會持續刷新。因此，比起執著於某一種具體架構，背後的工程原則更重要：建立測量基線，每次只改一個變數，只保留經得起評測驗證的方案。
面對多 Agent 架構的簡化，完全不必一步到位。
現在就可以先建一套包含 10 個樣例的小型端到端評測集，挑一個最常用的子 Agent 嘗試並回主循環。
只有當並回版本的得分確實更低時，才保留它；否則，就果斷用 Skills 和工具取代它。然後，不斷重複這一過程。 (Datawhale)