子代理越多越強？Anthropic 官方出來拆台了：很多企業的 Agent，第一步就搭錯了 這是 Anthropic 應用 AI 團隊 2026 年 10 … · @swordBluesy · TwKit

@swordBluesy

子代理越多越強？Anthropic 官方出來拆台了：很多企業的 Agent，第一步就搭錯了 這是 Anthropic 應用 AI 團隊 2026 年 10 月 22 日發的官方文章，標題直譯是《構建 Agent：什麼時候該把子代理收編回主 Agent 循環》。先把結論放在前面，因為它反常識： 他們在多個企業部署裡對比發現：一個帶著技能（Skills）的單一 Agent，在質量上經常同時打贏「一個提示詞打天下」和「一堆子代理分工」兩種設計，而且每個任務的成本和延遲往往還更低。 先說清詞。子代理（subagent），是擁有自己獨立的上下文窗口（context window，模型一次能看見的內容總量）、工具和指令、由一個協調者（coordinator）調度的小 Agent。它們是 Agent 設計的核心組件，擅長驗證、並行幹活和模塊化權限管理——Anthropic 自家的多代理研究系統就用它們。但最近，應用 AI 團隊在企業部署裡反复看到另一種情況：把路由器（router，負責分發任務的組件）、規劃器（planner）和各領域子代理收編回主循環，效果反而更好。 一個真實例子：有家公司給面向客戶的 Agent 配了十幾個專家子代理，結果品牌口徑很難保持一致，延遲還拖累了用戶體驗。 他們還點名了一種「眼熟的設計進化路線」：先來一個意圖分類器，再來一條固定的多步推理流水線，再按用戶分群分桶，各配一條推薦分支，最上面再壓一個多代理協調器。客戶反饋常常是：這套結構裡的大部分活，模型已經不需要有人替它幹了。一個清晰的系統提示詞、4 到 5 個薄數據工具、再加上牢靠的輸出護欄，就能覆蓋大多數使用場景。 先把話說全：子代理仍然有它的位置，包括在研究前沿。滿足下面三條，才該用它： 單一 Agent 循環因為上下文膨脹，出現了可測量的性能下降；或 多個任務需要並行推進，且各自需要一個用完即可丟棄的全新上下文窗口；或 單一 Agent 選不好工具，或者系統提示詞裡的指令互相衝突。 但太常見的情況是：企業給每個團隊、每類問題都配一個子代理，最後 Agent 架構變成了公司組織架構圖的複製品——官方直接點名，這是康威定律（Conway's law，系統的結構會長成組織溝通結構的樣子）在作怪。 一、大組織搭 Agent 的五種翻車方式 大公司通常想做一個把多個產品和能力縫在一起的統一客戶入口。每個能力歸不同團隊，於是自然的做法是：每個團隊先造自己的 Agent，再由中央平台團隊在上面造一個協調器。這看著最簡單，卻立刻帶來五個麻煩： 上下文管理：你得決定代理之間交換什麼上下文，來回傳遞中細節不斷丟失。 子代理蔓延：每個團隊都發自己的子代理，最後是幾百個互相重疊的子代理，沒有統一標準，也沒有明確負責人。 縫合怪提示詞（Frankenprompt）：每個團隊往系統提示詞裡加一句，規則互相衝突，口徑沒法統一。 未經審查、過度局部的評測：人人加自己的評測集（eval，用來給 Agent 打分的測試題集），全為自己的子任務優化；沒人擁有和維護全套，管理層拿著被稀釋的局部分數做決策。 延遲：多代理架構的複雜度本身就是延遲。有家客戶把自家多代理框架和單一 Agent 循環對比，後者運行速度大約快一倍。 二、替代方案：用「漸進式披露」餵上下文 協調器加子代理的設計，用來協調跨團隊造的專家，本身合理；但往往更有效的做法是：用技能漸進式披露上下文，用工具搜索（tool search）漸進式披露工具。意思是：Agent 平時只看到技能和工具的簡短描述，真正用到時才完整加載。這個做法成立，有三個理由： 共享上下文產出更好的答案：跑得久的 Agent，我們希望它把前面幾步的結果都留在主上下文窗口裡。親眼見過每一步結果的 Agent，能把線索串起來，產出比子代理遞回來的幾份摘要豐富得多，也少了幾次有損的交接。 漸進式披露防止上下文膨脹：團隊當初拆子代理，主要就是怕上下文塞爆；漸進式披露把這個拆分的理由直接拿掉了。他們用這一招，把 Claude Code 面向更先進模型的系統提示詞削減了 80% 以上，其中就包括技能和工具的漸進式披露帶來的裁剪。 模型本身更能幹了：從 Opus 4.5 開始，模型在單一循環裡能管的事比大多數團隊預期的多得多。像 Opus 5.5 這樣的新模型，思考（thinking）已經關不掉；新模型越來越會自述進度、邊幹邊自查，有些外殼（harness，圍著模型的那層調度程序）組件因此變得多餘。每出一代新模型，你就能把更多決策權從外殼挪回模型本身。而且循環越簡單，遷移到下一代模型越容易——他們幫客戶遷移時發現，僵硬的多代理結構常常正是擋住新模型發揮的那堵牆。 單一循環不是沒有代價，它要求紀律：系統提示詞要精心管理，技能和工具的描述要在正確的時機觸發，上下文窗口、記憶和筆記要刻意經營。治理上，官方建議由一個小的中央團隊握住端到端的質量和系統提示詞，每個新工具和新評測上線前都要過它的審。 如果你還是走多代理路線：從能跑通的最簡單模式開始（生成器-驗證器、協調器-子代理都行）。劃分邊界的原則是按上下文拆分，不要按問題類型拆分：給每個子代理一塊「不太需要系統其他部分信息」的活，讓它交回一個緊湊的結果——獨立的研究路徑、接口乾淨的獨立組件、黑盒驗證，都是好候選。一旦按問題類型拆，代理之間就會玩起「傳話遊戲」，每交接一次，保真度掉一次。 三、目標形態：單一 Agent 循環長什麼樣 官方建議朝這個設計收斂： 一個模型、一個上下文窗口，跑一個開放式工具循環；回合數和成本預算、寫入閘門這些硬限制，由外殼來設。 每一回合，模型批量發出一組工具調用，外殼並行執行，把原始結果交回同一個模型，由它決定下一步：再來一批、向用戶提問、還是給出答案。 模型給出答案或撞到預算，循環停止；答案之後可以選擇性地加一道目標或驗證檢查。 模型在第一回合就把計劃寫進上下文，結果回來就隨時修訂。這是和「協調器＋專家」模式最核心的區別：寫計劃的那個模型，就是執行計劃的那個模型，所以它能在幹到一半時改計劃。 上下文照樣要加載，但由 Agent 自己管理：把代碼步驟改寫成「按規則目錄生成計劃」這種事不再需要了，模型自己決定每一步；順序和領域流程，挪進技能；硬限制（校驗、審批閘門）和對話中途才需要的東西（比如查記憶），挪進工具；代碼仍可用來加載那些便宜且幾乎總相關的內容（比如實體消歧），以及在工具內部處理機械部分（拼請求、解析數據流、恢復澄清流程）。 這個設計還有一個好處：它正好通向很多團隊的終局目標——一個理解用戶高層目標、能代用戶行動的 Agent——因為它學到的所有東西都留在同一個上下文裡。 四、遷移三步走：從多代理收編回單循環 第一步：先建「任務完成度」評測 動手收編之前，先建一個能判斷「該不該收編」的評測集。有效的結構是：一個由中央團隊擁有的共享端到端評測集，加上各團隊隨自家技能附帶的小評測集。哪怕只有 10 個黃金示例，也夠起步。 打分上，拿一套評分標準（rubric）給 Agent 的最終答覆打分，是追踪答案質量的好起點。協調器還在的時候，同時追踪路由準確率（它選對子代理了嗎）；某個子代理被收編之後，改查另一件事：Agent 有沒有加載對的技能、調對的工具。在內部系統難以重放、用戶行為難以模擬的環境裡，一個內部驗證過的辦法是：在重要事件上記錄時間戳，日後重放出來當定向評測用。 第二步：按共享上下文，合併領域代理 第一次合併之前，先建一個小的端到端評測。然後從使用量最大的子代理開始，按共享上下文收編：那些互相接力產出、碰同一批數據、或者經常被一起調用的專家，優先合併。舉例：如果生產流量裡有相當大比例是「專家 A 緊接著專家 B」，這就是一對緊耦合的組合，正是合併候選。 第三步：先把子代理當工具調用，再決定去留 滿足前面「該留子代理」三條件之一、決定先保留的，可以讓主 Agent 把子代理當工具來調用，主 Agent 始終握著和用戶的對話。只有當子代理需要直接和用戶對話時，才建議完全交接（handoff）；其他情況，一個技能加一組工具，放進主循環就夠了。 這樣做的好處是：可以給子代理定義統一的回覆格式，主 Agent 能拿真實數據核對結論，還能修剪餵給最終合成步驟的輸入。而且這一步不用重寫子代理，還能先在任務完成度評測上拿到一條基線，再決定收編誰。但有些老毛病會留下來：每個專家仍有自己的提示詞、上下文、負責團隊和評測；每次調用仍交回一份有損摘要；每次調用都是一個嵌套的模型循環，照樣加延遲。 最後一步：逐個把子代理變成技能和工具 把每個子代理的提示詞改寫成技能、它的接口調用改寫成 MCP 工具（MCP 是給 Agent 接外部工具和數據的統一協議），一次收編一個；每收編一個，就對比有它和沒它時的評測表現，再決定去留。 對比時別只看最終分數，要看哪些任務翻轉了。他們在一個示例客服 Agent 上實測：把一個子代理收編進另一個，延遲降了，卻弄壞了一個原本通過的流程——主 Agent 握著訂單查詢工具自己就把答案給了，沒去問物流專家要發貨日期。所以每次改動之前，確保你的評測覆蓋了生產裡每一條會一起跑的代理鏈、每一條 Agent 絕不能破的規則；而且每個任務至少跑兩遍——上面那個故障，兩遍裡只出現了一遍。 五、多個團隊怎麼共建同一個 Agent 領域知識可以從知識庫、技能和 MCP 工具裡取。各團隊的「所有權」從代理轉移到技能和工具，一個小的中央團隊握住系統提示詞和端到端質量，新技能、新工具、新評測上線前都要過審。 MCP 工具適合：Agent 需要執行一個動作、從系統裡讀實時數據、或者以固定格式返回結果。也可以拿它當遷移期的過渡：繼續以工具形式調用子代理。官方建議工具按用戶意圖分組，不要一個接口配一個工具——因為系統提示詞裡的工具定義一旦超過 30 到 50 個，模型的選工具能力就會明顯退化。用工具搜索做延遲加載，減少硬性前置條件，必要的檢查放進工具內部：比如工具 Y 需要工具 X 的產出，Y 自己檢查、並返回一條模型能照著做的指示。按用戶的權限控制也是同理：每個工具自己檢查調用者能看什麼、能幹什麼，不行就返回一句模型能讀懂的明確拒絕——這樣一個循環就能服務不同權限等級的用戶，不用給每個權限等級配一個代理。 技能適合裝「一個團隊是怎麼做事的」：步驟、規則和判斷，過去都寫在專家子代理的提示詞裡。技能庫的維護，官方主張交回寫技能的人手裡——Claude 本身能幹重活，有專門的技能用來構建、測試和修剪其他技能。為了防技能蔓延，每個團隊設一名負責人（DRI），保證自家技能做得精、彼此不重疊、且自帶評測。兩個官方工具：/skill-creator 用來寫出格式良好的新技能，並審計現有技能做裁剪、去重和重組；/skill-doctor 用來看每個技能的成本和真實使用頻率，刪掉死重量。 知識庫適合裝「只是偶爾才需要」的參考材料：政策、指標定義、產品規格這類事實，放在搜索或查詢工具後面讓模型按需調用，或者作為參考文件裝進技能裡。要避免的做法是：讓代碼去檢索這些上下文、再粘貼進提示詞。 六、官方遷移工具包 Anthropic 最近發布了一組 Claude API 技能，上面大部分工作都能用它們加速；他們的遷移工具包（migration kit）把這些技能串成一條引導式工作流，用來評估多代理系統並遷移到單一循環，還附了一個演示，可以先在模擬系統上試，再動真格： /claude-api build-eval：幫你建第一套端到端評測（中央團隊擁有），或各團隊隨技能附帶的小評測。 /claude-api prompt-audit：標出你的提示詞、技能和工具描述裡那些「為舊模型寫的」指令，並以 diff（改動對比）形式給出修法。可以跑在系統提示詞上，找出那些當年為更早的模型加的、如今讓 Agent 變慢變僵的規則；各團隊負責人也可以跑在自家技能和工具描述上。 /claude-api hillclimb：拿著現有評測反復迭代改進應用。可用在「收編版 vs 保留版」的對比上——把一個子代理收編成技能加工具之後，讓它對著評測迭代技能和工具描述，看收編版能否追平或打贏子代理版；也可以用在系統提示詞上。 /claude-api cost-optimize：剖析你的調用都花在哪，給出省錢選項：提示緩存、裁掉不需要的輸入輸出 token、調整努力程度（effort）和模型選型——一次只改一樣。 結尾：原則比架構重要 官方在文末把話收得很克制：模型在變，他們對「怎麼用好模型」的理解和最佳實踐也在變。任何一種架構，都沒有背後的原則重要——測量，一次只改一樣東西，留下經得起檢驗的那個。 隨著模型越來越能幹、Agent 跑得越來越久，你手裡會有越來越多的子代理可以收編成技能和工具。但這一步不用一步到位：建一個小的端到端評測，收編一個子代理，只有當收編版的分數更差時，才把它留作子代理——然後重複這個過程。 原文連結：https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop 原文：@claudeai（由 S1哥 編譯） S1哥觀點 這篇文章最狠的地方，是它由 Anthropic 自己寫出來打自己的臉：多代理研究系統是他們家的招牌，子代理是他們賣了一年多的設計範式，現在官方親自下場說——大多數企業場景，單個 Agent 加技能，就夠了，而且更好、更便宜、更快。 我認為真正的信號不在架構，在那句「為舊模型寫的指令」。過去兩年，大家搭的分類器、流水線、協調器，本質上都是在替當時的模型補智商：它記不住，就給它分工；它選不對，就給它路由；它不自查，就給它驗證員。模型每升一代，這些補丁就有一批過期——還賴在架構裡的補丁，不再是助力，是枷鎖。這和寫代碼是一個道理：給弱者設計的流程，強者穿上就是緊身衣。 所以站隊問題來了：你現在的 Agent 架構，到底是在發揮模型的本事，還是在替兩年前的模型還債？敢不敢拿官方那套評測流程，收編掉你一半的子代理試試——評論區報一下你的子代理數量，和你敢砍掉幾個。

曝光 19 · 评论 0 · 点赞 0 · 书签 0