GitHub Radar

這是 Anthropic 在 Claude 部落格發表的實務文章（作者 Diane Sarkis，閱讀約 18 分鐘），談什麼時候該把 subagent，也就是擁有各自 context、工具與指令的 agent，合併回單一的主 agent loop。Subagent 在驗證、平行工作和模組化權限上仍然有用，Anthropic 自己的多 agent 研究系統也在用。但 Applied AI 團隊觀察到，許多企業部署在把 router、planner 和 domain subagent 合併成單一 loop 之後反而變好。在多個部署的比較中，「單一 agent 加 skills」的品質常常同時勝過單一 prompt 設計和 subagent 設計，成本和延遲通常也更低。有一家公司養了十幾個專家 subagent，結果品牌語氣始終不一致，延遲也增加。常見的提案設計是意圖分類器、固定推理 pipeline、使用者分群、推薦分支，最上面再疊一個 orchestrator；Anthropic 的回饋通常是：一份清楚的 system prompt、4 到 5 個精簡的資料工具，加上嚴格的輸出 guardrail，就能涵蓋大部分需求。

什麼時候 subagent 仍然合理

當單一 loop 因 context 膨脹出現可量測的退化；當任務能平行執行，而且適合用完即丟的新 context window；或當單一 agent 選不好工具、system prompt 內有互相衝突的指令時，就保留 subagent。文章也提醒，企業常讓每個團隊各養一個 subagent，最後架構會長成組織圖的樣子（Conway's law）。

大型組織的失敗模式

公司常希望多個產品共用一個客戶介面，於是各團隊各做一個 agent，平台團隊再加一層 orchestrator，可能是 orchestrator-subagent，也可能把專家 agent 包成 MCP 工具。這看似簡單，卻會帶來幾個問題：agent 之間交接時細節流失；出現數百個重疊、沒有標準也沒人負責的 subagent；每個團隊都往 prompt 加規則，拼出互相衝突、沒有一致語氣的「Frankenprompt」；各團隊只優化自己的子任務，高層看到的是被稀釋的分數；延遲方面，有客戶發現單一 agent loop 比他們的 multi-agent harness 快大約 2 倍。

用漸進揭露的 agent loop 取代 orchestrator

文章主張用 skills 漸進揭露 context、用 tool search 漸進揭露工具：agent 平時只看到簡短描述，需要時才載入完整內容。理由有三個。第一，共享 context 會產生更好的答案，因為 agent 直接看到每一步的原始結果，而不是 subagent 回傳的摘要，context window 和有損交接都比較少。第二，漸進揭露可以防止膨脹，Anthropic 針對較先進的模型把 Claude Code 的 system prompt 砍了超過 80%，其中一部分正是靠 skills 和工具的揭露機制。第三，模型能力更強了，自 Opus 4.5 起，模型在單一 loop 內能處理的事情多了很多，新模型會主動報告進度、自我檢查，讓部分 harness 元件變得多餘，簡單的 loop 也比較容易遷移到新模型。單一 loop 仍然需要紀律：system prompt 要謹慎管理，skills 和工具的描述要在對的時機觸發，context、記憶和筆記也要刻意處理，並由一個小型中央團隊負責端到端品質與 system prompt，審核每個新工具和 eval。如果還是要用多 agent，就從最簡單的模式（generator-verifier 或 orchestrator-subagent）開始，並按 context 切分工作：讓每個 subagent 處理一塊不太需要其他部分資訊的工作，回傳精簡結果。按問題類型切分則會變成傳話遊戲，每經過一手就失真一點。

目標設計與遷移步驟

目標是一個模型、一個 context window 跑開放式工具迴圈，harness 設好回合數、成本預算和寫入閘門。每一回合模型發出一批工具呼叫，harness 平行執行後回傳原始結果，直到模型給出答案或碰到預算上限，之後可以選擇再跑一次目標或 verifier 檢查。模型在第一回合寫下計畫，隨結果修正；規劃者與執行者是同一個模型，所以可以中途轉向。順序和領域流程移到 skills，驗證與核准閘門等硬限制以及記憶查詢移到工具，程式碼只保留便宜且幾乎每次都需要的載入（例如實體解析）。遷移要分階段進行：先建立由中央團隊維護的端到端 eval，再加上每個 skill 自帶的小 eval，10 個 golden example 就足以起步；用 rubric 評最終訊息，合併前追蹤路由準確率，合併後追蹤是否載入了正確的 skill 或呼叫了正確的工具。先合併使用量最高、互相串接或常被一起呼叫的 subagent。必須保留的 subagent，就讓主 agent 把它當工具呼叫，只有需要直接對使用者說話時才完整交接。接著把 subagent 的 prompt 逐一轉成 skill、API 呼叫轉成 MCP 工具，比較有無合併的 eval 結果，並檢查是哪些任務翻盤，而不只看總分。在一個範例客服 agent 的測試中，合併後延遲下降，但主 agent 在回答訂單問題時沒有去問出貨專家交期，壞了一個原本通過的流程，而且這個失敗只在兩次執行中出現一次，所以每個任務都要跑不只一次。

多團隊如何共同維護一個 agent

團隊從擁有 agent 轉為擁有 skills 和工具。MCP 工具適合動作、即時資料讀取和固定格式的結果，應該依使用者意圖分組，而不是一個 API 配一個工具，因為 prompt 裡超過 30 到 50 個工具定義後，選工具的品質就會下降；搭配 tool search 和延遲載入，前置條件和權限也放進工具裡，以明確的拒絕訊息回應。Skills 適合承載一個團隊的工作方法，由團隊負責人維護並附上 eval，可以用 /skill-creator 撰寫和稽核，用 /skill-doctor 查看每個 skill 的成本、使用率並揪出無用的部分。知識庫則放偶爾才需要的參考資料，用搜尋工具或 skill 參考檔提供，不要用程式碼硬塞進 prompt。

工具與結論

Anthropic 提供 Claude API skills 和遷移 kit（github.com/anthropics/single-agent-loop-kit），包含 build-eval、prompt-audit（標出為舊模型寫的指令）、hillclimb（對 eval 反覆改進）和 cost-optimize。結論是原則比架構重要：量測、一次只改一件事、留下有效的改動。先建一個小型端到端 eval，合併一個 subagent，只有在合併版分數變差時才保留 subagent，然後重複這個流程。