Anthropic建議收回Subagents？單Agent＋Skills的適用範圍、兩倍速度與Eval遷移

原帖、圖卡與留言

startupwithprestonhk的Threads貼文與附圖將建議摘要為「多數subagent可以收回主agent」，列出品質、成本、延遲與約2倍速度，也保留平行及context塞滿兩種情境。圖卡是三個subagents對比一個loop配三個skills的示意，沒有提供實驗條件或可重現數據。本次已查看圖卡與可見留言，coverage為partial。[1]

留言有讀者追問原文，也有人指出交棒的context重建才是痛點，主張減少角色並硬化權限；另有Meta AI回覆補充fresh-eyes review。這些分別是讀者經驗與另一AI的解說，不是Anthropic第一方證據；本篇改以原文確認，不將相關推薦串混入原帖。[1]

第一方來源確認：不是「越少越好」

原文為Diane Sarkis於2026-10-22發表的《Building agents: When to fold subagents into your main agent loop》，主要討論Claude Platform企業部署。它比較的是若干企業案例：單agent配skills經常優於巨型單prompt與分散subagents的設計。這是應用團隊經驗，非公開隨機試驗或普遍排名；也不能從「有客戶約2倍快」推導成本減半、所有品質指標提升或本系統也會提升兩倍。[2]

文章開頭仍肯定subagents在verification、parallel work與modular permissioning的用途，明列保留條件包括：context膨脹已造成可量測退化、可用獨立窗口平行完成的工作，以及主agent選工具困難或system prompt指令互相衝突。因此原帖僅列兩類情境是簡化，不是完整排除清單。[2]

核心差異：按context邊界拆，不照公司組織圖拆

原文批評每個團隊各做一個專家、上面再疊router的模式，會形成重複角色、有損摘要、相互矛盾規則與局部eval。若兩個專家總是依序處理相同資料，反覆重建context可能比隔離收益還大。相反地，獨立研究路徑、介面清楚的元件與黑箱驗證，仍是適合委派的邊界。[2]

「單loop」也不是把所有規則、文件與工具一次塞進prompt。它保留一個主模型掌握計畫與對話，skills按需載入流程與領域知識，tool search延遲載入不常用工具；同一回合仍能並行執行一批工具。單一決策loop不等於所有I/O必須串行，也不等於不能呼叫subagent工具。[2]

三種改法，不能全部叫作刪掉subagent

• Merge：先合併常一起被呼叫、共用資料或前後依賴很重的專家，再重新量測。[2][3]
• Fold：把領域程序變skill、API操作變直接tools，移除舊路由；不是把整段專家prompt原封不動搬到system prompt。[4]
• As-tool：子agent仍有自己的context，主agent接收結構化結論、證據、實際動作與限制，持續掌握對話。這是保留委派但減少完整對話handoff，不是變成同一個context。[5]

權限不能因收回主loop而變成口頭規定

kit的fold步驟把硬限制、approval與政策檢查放到tool內強制執行；一般流程進skill，參考資料進查詢或reference。文件要求以直接違規呼叫測試tool確實拒絕，而不是只看模型在eval裡剛好沒有嘗試被禁止動作。這是重要分野：模型表現好不能代替伺服器權限檢查。[4]

保留的subagent也要驗證輸入必要欄位與輸出schema；空回覆是錯誤，格式不符的非空回覆要帶低信心與未驗限制，不得當正常完成。主agent仍需對便宜可查的實際資料覆核。格式、結論、外部寫入與已驗收是不同證據層級。[5]

如何避免「變快但少做一步」

原文記錄一個support agent合併後延遲下降，卻漏向shipping專家確認送達日期；此問題重複跑兩次才有一次出現。建議的eval要涵蓋每條production交接鏈及不可破壞規則，逐任務查看前後翻轉，不只平均分數。沒有相同任務、相同驗收條件的基線，不宜宣告架構更好。[2]

kit進一步要求閱讀鄰近領域trace、檢查寫入動作與工具結果是否真正傳到下一步，對新skill做有／無skill比較；若去掉skill也一樣好，可能不需要這份skill。此處是工具包建議，不是本篇已跑出的成效。[3][4]

工具包的成熟度與本次查核範圍

官方anthropics/single-agent-loop-kit固定SHA為c43796287b83bec847db923f07131d1cc8de750d，README明示是reference implementation、不維護且不接受contributions；不能當作有維運承諾的產品。它附support-desk範例及比較腳本，offline fake model只驗證流程接線、不給品質分數，不能把smoke完成當實際模型驗收。[3]