少一點子 agent，多一點 skills
Anthropic Applied AI 寫道：在 Claude Platform 上建 agent 時，把路由、規劃與領域子 agent 折進主 agent 迴路，搭配漸進揭露的 context／tools，常能在品質上升的同時降低成本與延遲。跨多個企業部署的比較裡，單一 agent 加 skills 經常勝過「一題一長 prompt」與「多子 agent」兩種設計。
一例：某公司客服型 agent 裡十幾個專家子 agent，讓品牌語氣難統一，也拖慢體感；對照單一迴路後，運行時間大約 快 2 倍。團隊也常看到意圖分類器、固定多步管線、用戶分群與推薦分支堆成「組織圖複製品」（Conway's law）。
什麼時候還該留子 agent
官方仍建議在這些情況保留子 agent：
- 單迴路因上下文膨脹出現可量測的效能下降
- 多任務需要平行、用完可丟的新上下文
- 單 agent 選錯工具，或系統提示裡指令互相衝突
其餘時候，優先考慮 skills＋工具搜尋：短描述先露出，完整內容按需載入。官方說 Claude Code 在較新模型上把系統提示砍掉逾 80%，其中包含漸進揭露。共享上下文也讓長程 agent 能把前幾步結果留在同一視窗，減少「電話傳話」式損耗。
怎麼折：評測、合併、再變 skills
目標形態大致是：一個模型、一個上下文、開放式工具迴路；每輪可平行跑一批工具，同一模型決定下一步；計畫寫在上下文並隨結果改寫。遷移步驟建議：
| 步驟 | 做什麼 |
|---|---|
| 任務完成評測 | 中央團隊管端到端集；各 skill 附小集；先有約 10 個 golden 也好 |
| 合併領域 agent | 常串在一起、碰同一資料的專家先合 |
| 子 agent 當工具 | 過渡期由主 agent 呼叫，少做整段對話移交 |
| 折成 skills／MCP | 一次折一個，對照評測；看哪些題翻盤 |
失敗模式包括：子 agent 蔓延、Frankenprompt、過度局部的 eval，以及多層編排帶來的延遲。中央小組應擁有系統提示與端到端品質；領域團隊改擁 skills／工具。
遷移套件：Apache-2.0
配套倉庫 anthropics/single-agent-loop-kit 提供引導式工作流（找模式、比對、驗證），含可先在 mock 上試的 demo。授權經驗證為 Apache-2.0：GitHub API、release 分支 LICENSE 全文，以及 README 的 SPDX-License-Identifier: Apache-2.0 一致。README 註明為參考實作、不維護、不收 PR。
套件串起 /claude-api 的 build-eval、prompt-audit、hillclimb、cost-optimize 等 skills。原則是：量測、一次改一樣、數字站得住才留。
本文建議：先建一小份端到端評測，折進一個最常串接的子 agent，比較延遲與翻盤題；若折完變差，就把它當工具留下。工具定義超過約 30 至 50 個時，官方提醒工具選擇常會變差，記得開 deferred loading。
