這是 Anthropic 應用人工智慧（Applied AI）團隊工程師 Will 在「Code w/ Claude London」實作工作坊的分享。他用一個名為 Stock Pilot 的庫存管理代理當範例，示範一個常見的困境：代理隨著業務需求不斷加功能，系統提示（system prompt）膨脹到數百行、工具與子代理越堆越多，最後評估分數不升反降。講者示範如何用「評估爬山（eval hill climbing）」的流程，重新在工具（tool）、技能（skill）、子代理（subagent）三種原語之間做出正確取捨，並把代理遷移到 Claude 管理的代理（Claude-managed agents, CMA）。

---

原影片連結：https://www.youtube.com/watch?v=mWvtOHlZM-I

影片重點

• 代理常見的退化模式：不斷加功能 → 系統提示膨脹到約 400 行、12 種工具、多個子代理 → 評估分數回退。
• 範例代理 Stock Pilot：中型零售商的庫存管理代理，能提醒低庫存、預測需求、挑選供應商、送出採購訂單、產生每週報告。
• 評估體系：12 項評估任務、5 種評分器；R 系列代表回歸（regression，單輪），F 系列代表故障模式（failure mode，多輪）。
• 確定性 vs 非確定性評分器：前者看回合數、延遲、token 數；後者用 LLM-as-judge 評個性、語氣、風格與輸出品質。
• 三個典型失敗：F1（路徑繞遠、效率不足）、F2（子代理與協調器溝通斷裂）、R8（系統提示中兩段策略互相矛盾，導致預測倍數幻覺）。
• R8 根因是「情境問題」而非「模型問題」：過長且互相衝突的系統提示讓模型混亂。
• 解法一：用技能（skill）取代冗長系統提示，靠漸進式揭露（progressive disclosure），把約 400 行提示縮到約 50 行。
• 解法二：優先使用類人、原始的內建工具（程式執行、檔案系統、網路搜尋、待辦清單），少堆疊自訂工具與雜亂的 MCP 伺服器。
• 解法三：需要時才用子代理，並善用 CMA 原生的子代理可觀測性，確保協調器與子代理之間溝通順暢。
• 把自建於 Messages API 的代理遷移到 Claude 管理的代理（CMA），把基礎設施、擴展、記憶體、安全等雜務卸載，專注在代理架構本身。

詳細內容

00:00 開場：一個「長太大」的代理

講者 Will 自我介紹，他在 Anthropic 的應用人工智慧團隊，時間分配在內部工程與協助客戶建立代理之間。他先描繪一個大家都熟悉的情境：你開發並上線了一個代理來解決某個問題，一開始表現很好；幾週後業務要求加新功能，再過幾週又加更多功能。

這個模式持續下去，不知不覺系統提示就長到數百行，代理手上握有數十種工具與子代理。因為複雜度上升，代理在原本表現不錯的地方反而開始退步。他強調這種情況非常普遍——不只是客戶，Anthropic 自己也常遇到。

04:31 範例代理：Stock Pilot 的問題描述

本次工作坊聚焦一個名為 Stock Pilot 的庫存管理代理，服務對象是中型零售商。它能提醒庫存水位過低、預測需求、自行挑選供應商、送出採購訂單，最終還能為員工產生每週報告。

這些功能單獨看都不算特別複雜，問題出在「只顧加功能、不更新架構」。長期累積下來，複雜度開始引發實際問題。

06:00 現況架構：協調器 + 400 行提示 + 12 種工具

如今的代理由一個協調器（orchestrator，畫面上的 Stock Navigator）統籌運作。它的系統提示已成長到大約 400 行，擁有 12 種工具，其中有 3 個工具其實是「具有完全隔離上下文視窗的子代理」的封裝。倉庫中的 before 資料夾就是這個版本的代理。

這種「協調器 + 冗長系統提示 + 大量工具 + 多個子代理」的組合，正是評估分數開始下滑的原因。而它會變成這樣，是因為預測功能被做成子代理、報告撰寫功能又被做成另一個子代理，一路加上去卻沒有回頭整理架構。

09:00 評估體系：R（回歸）與 F（故障模式）

Stock Pilot 有 12 項評估任務、涉及 5 種評分器。畫面左側以 R 開頭的是回歸（regression）評估：較貼近真實的單輪任務，給模型一個任務、模型呼叫工具並回應，主要評估這個回應。以 F 開頭的是故障模式（failure mode）：較複雜的多輪任務。

評分器分兩類。確定性評分器針對回合數、延遲、完成任務所用的 token 數等指標評分，並追蹤這些指標隨時間變化；非確定性評分器則用「LLM 當評審（LLM-as-judge）」來評估個性、語氣、風格與輸出品質等難以量化的特徵。

13:00 三個失敗案例：F1、F2、R8

• F1（每日低庫存掃描）：代理最後有到正確終點，但走了一條非常繞、效率很差的路徑，因為效率不達標而失敗。
• F2（特定促銷的訂購流程）：子代理其實正確完成了任務，但子代理與協調器之間出現溝通斷裂。講者指出，當系統有大量子代理時，「協調器 ↔ 子代理」的通訊是客戶常見的故障點。
• R8（促銷月份的預測）：系統提示中有兩段策略分處不同位置、彼此矛盾，隨著提示越加越多，模型開始混亂而失敗。

15:36 基準線與 R8 的幻覺根因

README 中這批評估一開始約有 83% 通過率——聽起來還行，但若放到製造業，17% 的失敗率代價非常昂貴。深入看 R8：畫面上模型正確抓到了預測基線（每日 12 單位）與促銷倍數（3.1 倍），但在後續計算時卻出現幻覺，實際用成了 1.35 倍。

關鍵在於：這不是模型問題，而是情境問題。系統提示變得又長又有衝突，讓模型混亂，才導致這次評估失敗。

17:51 方法論：評估爬山（eval hill climbing）

工作坊的核心流程是：跑一整套評估拿到基準線（約 83%），對失敗結果做分類（classification），據此更新代理設計，再重跑評估，讓通過率一步步往上爬。

實驗會從「自建於 Messages API 的代理」（before 資料夾）開始，這是講者圍繞 Anthropic Messages API 自己寫的代理迴圈與框架。

19:09 遷移到 Claude 管理的代理（CMA）

接著他把代理遷移到 Claude 管理的代理（Claude-managed agents，CMA，對應 starter 資料夾）。CMA 讓開發者不必自行維護代理框架，也不用煩惱把代理擴展到成千上萬使用者時的基礎設施、擴展性、記憶體與安全問題。

如講者所說：在本地建一個代理很快，但要遠端託管、讓成百上千使用者同時互動時，各種工程負擔就湧現。CMA 的真正價值，是把代理與「會話細節」以及「實際執行工具呼叫的沙盒環境」分離，讓工程師專注在代理本身的設計——也就是工具、技能、子代理的取捨。

29:21 用 Claude Code 跑評估與分類

講者用 Claude Code 搭配 Opus（把 thinking / effort 開到最高）來跑評估，讓 Claude 幫忙分析發生了什麼。他透過 Claude Code 的 bash 功能執行 uv run evals --agent，重跑後結果只有 62%（12 項通過 7 項），比原本 83% 更差。

Claude 針對未通過的評估給出診斷，歸納出幾個主題：模型承擔了很多本該由工具完成的工作、輸出結構不一致、以及系統提示過長造成的策略衝突與混亂。這正好對應要動手修正的方向。

36:28 解法一：用技能（skill）取代冗長系統提示

講者對技能的定義是：「打包好、可組合的資訊，Claude 在需要完成特定任務時才調用。」技能非常適合封裝那些「偶爾才需要、不是每次都需要」的資訊。以庫存代理為例，它有很多政策與流程，但預測資訊只在被要求做預測時才需要——這類資訊就適合放進技能，用漸進式揭露（progressive disclosure）按需載入。

於是他讓 Claude 檢視 agent.py，把大量系統提示資訊搬進技能。結果把原本約 400 行的系統提示縮短到約 50 行，其餘資訊改由技能補充。

39:49 解法二：優先用類人、原始的內建工具

不論是內部代理還是與客戶合作的代理，Anthropic 都遵循「先給類人基本能力，再按需加自訂工具」的原則。Claude Code 之所以是優秀的編碼代理，本質上是「給了 Claude 一台電腦」：檔案系統、網路搜尋、程式執行、有時再加待辦清單。尤其程式執行能力至關重要——面對 CSV 或 Excel，能寫並執行程式碼是代理最重要的能力之一，對上下文視窗的使用也高效許多。

反面教材是一堆雜亂的 MCP 伺服器：許多客戶最後陷入龐雜的 MCP 生態，缺點是造成上下文污染、占用大量空間。改用一些原始內建工具、替換掉較過時的自訂工具後，這一輪明顯是正確的決定（雖然不保證每次都只升不退）。

42:36 解法三：需要時才用子代理

當問題需要大量平行處理時，子代理是很好的手段：多個實例同時處理以更快完成任務，或用一個不了解主實例上下文的獨立實例來做審查，避免污染主 Claude 實例的上下文。

子代理常見的痛點是：很難確保協調器與子代理之間的通訊準確無縫（如前面 F2 的失敗），而且子代理容易產生大量難以追蹤的資訊。Claude 管理的代理內建了子代理的日誌與可觀測性能力，正是為了解決這些問題。整體原則是：先靠類人的基本能力把代理做強，真的需要時才引入子代理，換取更大的決策彈性。

我的想法

這場分享最值得記住的一句話，是把 R8 的失敗定調為「情境問題，而非模型問題」。在實務上，很多人一遇到代理表現變差就想著換更強的模型，但更常見的真兇其實是被我們自己塞爆、且前後矛盾的系統提示。把「該常駐的規則」與「偶爾才需要的知識」分開——前者留在精簡的提示裡、後者下放到技能按需載入——這個「漸進式揭露」的心法，幾乎適用於任何長期演進的代理，而不只是 CMA。

我也很認同「工具要盡量選類人、原始的內建能力」這個取向。給模型一台電腦（程式執行 + 檔案系統）往往比堆一堆高度客製化的工具更耐用，因為它把「怎麼做」的彈性交還給模型，而不是把每種情況都硬編碼成一個工具。同理，一窩蜂接上大量 MCP 伺服器帶來的上下文污染，是很容易被低估的隱形成本——工具的「數量」本身就是一種需要治理的複雜度。

最後，講者示範的「評估爬山」流程才是真正可遷移的方法論：先用一套涵蓋回歸與故障模式、混合確定性與 LLM-as-judge 的評估建立可量化基準，再靠 Claude 幫忙分類失敗、逐步改架構。值得提醒的是，影片中重跑一度從 83% 掉到 62%——這說明改動不必然是進步，正因為有評估在把關，你才敢大膽重構而不是憑感覺調提示。對任何想把玩具型代理推上生產環境的人來說，先把評估建起來，可能比急著加功能更重要。