Tool、skill 還是 subagent？拆解一個已經撐爆 prompt 的 agent（第 4/4 段）

🧑‍🏫 這段講的是：一支庫存管理 agent（能自己分好幾步把任務做完的 AI 助理）的指示越寫越長、越來越難管，講者把它拆開重做，然後比較改前改後的成效。改完之後更省 token、更便宜，也跑得更快。最後講者整理出三個做 agent 的原則，想自己設計 AI 工作流程的人可以直接拿來用。

• 33:49 前後比較最明顯的是 token 用量：改之前某個任務要用超過 200,000 tokens，改用 file system primitives 之後大幅下降
  ↳ token 是 AI 計算讀進、寫出多少文字的單位，用越多越貴。改之前一個任務要用掉 20 萬個以上；改成只給 Claude 讀寫檔案這類基本能力（primitives）之後，用量大幅下降。
• 33:49 token 下降是讓 agent 能做 code execution 的直接結果
  ↳ token 會降，主要是因為 agent 學會了 code execution，也就是自己寫程式、自己執行，不用什麼都靠「讀」來處理。
• 34:21 做法是不把整份 CSV 讀進 context，而是讓 agent 寫 Python 並執行，用程式在資料之間找資訊
  ↳ 以前是把整份 CSV（類似 Excel 的表格檔）讀進 context，也就是 Claude 當下看得到的內容。現在改成讓它寫 Python 小程式，去表格裡撈出需要的那幾筆。
• 34:21 agent 寫程式、執行、再讀結果，比把所有資料塞進 Claude 腦中再做判斷省下很多 token
  ↳ 就像在一大份名單裡找一個人，不用整份讀完，用搜尋功能查一下就好。Claude 只要讀程式跑出來的結果，不用把所有原始資料都消化一遍。
• 34:21 token 用得少，成本也跟著下降
  ↳ Claude 是照 token 算錢的，token 用得少，帳單自然跟著變小。
• 34:52 執行時間也變短了
  ↳ 要處理的資料量變小，任務從頭到尾花的時間也跟著縮短。
• 34:52 這次整體都變好，但不一定每次都這樣，有些情況可能反而退步；這個案例用 primitives 取代比較僵化（stagnant）的 tools 明顯是對的選擇
  ↳ 講者提醒：這次剛好每一項都變好，但換架構不保證每次都贏，有時反而會退步。這個案例是用有彈性的基本能力，取代寫死、難調整的 tools（事先做好、讓 AI 呼叫的固定功能），明顯是對的。
• 35:23 原本 agent 有 12 個 tools，其中 3 個其實是包著 subagent：Claude 呼叫 tool，tool 再去叫用 subagent
  ↳ 原本的 12 個 tools 裡，有 3 個其實是轉包：Claude 呼叫 tool，tool 背後再去叫另一個 Claude 做事。被叫來的這個 Claude 就是 subagent（子代理）。
• 35:54 subagent 第一個常見用途：想丟很多個 Claude 去解同一個問題，例如 deep research、web search，或 Claude Code 裡的 codebase 探索
  ↳ subagent 的第一種用法：問題太大，就派好幾個 Claude 分頭處理，例如深度研究、上網搜尋，或在 Claude Code（寫程式用的 Claude 工具）裡翻遍整個專案。
• 35:54 subagent 可以平行處理，讓問題解得更快、更有效
  ↳ 好幾個 Claude 同時各做一塊，像分組作業一樣，整件事就能更快完成。
• 36:25 subagent 第二個常見用途：需要一個全新的腦袋來看問題。講者舉例：開發者不會想自己寫 code 又自己 review
  ↳ 第二種用法：需要一個沒有先入為主想法的腦袋。講者舉例，寫程式的人不會想自己寫完又自己審，因為很難看出自己的盲點。
• 36:25 在 Claude Code 裡，可以讓一個 Claude 寫 code，再讓另一個不知道前面 context 的 Claude 來 review，也就是 code review subagent
  ↳ 在 Claude Code 裡，可以讓一個 Claude 寫程式，再叫另一個完全不知道前面過程的 Claude 來檢查，這就是 code review（程式碼審查）subagent。
• 36:56 這個 inventory management agent 改完之後，只留下一個 subagent：專門做 forecasting 的
  ↳ 這支庫存管理 agent 改完之後，只剩下一個 subagent，專門負責 forecasting，也就是預測未來需求，例如下個月該進多少貨。
• 37:26 forecasting 要和主要的 Claude 分開，避免初始 context window 裡的內容扭曲預測過程
  ↳ 預測要獨立出去做，是因為主 Claude 的 context window（它當下看到的全部內容）裡已經塞了很多東西，可能讓預測結果偏掉。
• 37:26 另外有一個 skill，寫了建立預測的步驟與講者偏好的準則；但跟客戶對話的 Claude 不應該同時負責寫預測
  ↳ 另外寫了一個 skill（教 Claude 做某件事的說明包），裡面有做預測的步驟和講者偏好的準則。但負責跟客戶對話的那個 Claude，不應該同時兼做預測。
• 37:56 其他 subagent 都拿掉，改成 primitive tools，只保留 forecasting subagent，這屬於「需要全新腦袋」的用途
  ↳ 其他 subagent 全部拿掉，換成基本能力。只留下預測這一個，因為它正好屬於「需要全新腦袋」的用途。
• 37:56 forecasting subagent 不再包成 tool，改用 Claude managed agents 內建的 subagent 功能，logging 和 observability 都做得很好
  ↳ 預測 subagent 不再包成 tool，改用 Claude managed agents（Anthropic 代管 agent 的平台）內建的 subagent 功能。執行紀錄（logging）和監看它在做什麼（observability）都做得很完整。
• 38:26 subagent 的問題一：多個 Claude 同時跑時，orchestrator 和 subagent 之間的溝通很難確保準確、順暢，很多東西會在轉述時走樣，就像同事之間互相誤解一樣
  ↳ subagent 的麻煩一：orchestrator（負責指揮的主 agent）和 subagent 之間傳話很容易失真，就像同事轉述需求，傳一傳意思就變了。
• 38:57 subagent 的問題二：logging 很難做，因為要去收集好幾個 agent 的 transcript
  ↳ 麻煩二：紀錄很難整理。每個 agent 都有自己的 transcript（完整的對話紀錄），要一份一份收齊，才看得出整件事發生了什麼。
• 38:57 Claude managed agents 有 callable agents 功能，基本上就是受管理的 subagent
  ↳ Claude managed agents（簡稱 CMA）有一個 callable agents 功能，基本上就是由平台幫你管好的 subagent。
• 39:27 用 callable agents，session 資訊裡就有 subagent 的 observability 和 metrics，準確度和 orchestrator 本身一樣
  ↳ 用了它，subagent 做了哪些事、各項數據（metrics）怎麼樣，都直接記在同一次執行紀錄（session）裡，而且跟主 agent 的紀錄一樣準確。
• 39:58 subagent 也可以直接定義成 tool，這是他們之前的做法，後來改用 CMA 的原生功能
  ↳ subagent 也可以自己包成 tool 來用，他們以前就是這樣做，後來才改用 CMA 內建的功能。
• 39:58 很多情況下可以乾脆不要 subagent，把能力直接給主要 agent。很多客戶就是把能力併進 orchestrator
  ↳ 很多時候乾脆不用 subagent，直接把能力交給主 agent 就好。不少客戶就是把各種功能都收進 orchestrator 裡。
• 39:58 這麼做的原因是 frontier models 已經聰明到能處理更多資訊，不需要那麼多 subagent
  ↳ 原因是 frontier models（目前最先進的 AI 模型）已經聰明到一個就能處理更多資訊，不用再拆出那麼多小幫手。
• 40:28 複習：問題大到想丟很多 Claude 去解，或需要另一個 Claude 來檢查自己或其他 Claude 的成果，這兩種時候適合用 subagent
  ↳ 複習一下：問題大到要派好幾個 Claude 分頭處理，或需要另一個 Claude 來檢查成果，只有這兩種情況才適合用 subagent。
• 40:28 原始架構：orchestrator system prompt 約 400 行，12 個 tools，其中 3 個是 subagent
  ↳ 改之前：主 agent 的 system prompt（開工前給 AI 的總指示）大約 400 行，配 12 個 tools，其中 3 個是 subagent。
• 40:59 最終版還是有 orchestrator，但部署在 Claude managed agents 上，這樣就不用管 infrastructure、scaling、security，只專心做 agent
  ↳ 改之後還是有主 agent，但放到 CMA 上執行。伺服器等基礎設施、用量變大時怎麼擴充、資安問題，都交給平台處理，團隊只要專心把 agent 做好。
• 41:30 tools 精簡成 3 個：bash、read、write
  ↳ tools 只剩 3 個：bash（下指令、跑程式）、read（讀檔）、write（寫檔），就是最基本的電腦操作。
• 41:30 agent 開始執行時，會先把資料同步到 Claude managed agents 的環境，讓它能針對這些資料推理
  ↳ agent 一開始執行，會先把資料同步到 CMA 的工作環境裡，讓 Claude 可以直接對這些資料分析、推理。
• 41:30 system prompt 精簡到 15 行，所有 business logic 都改成 skills
  ↳ system prompt 從大約 400 行減到 15 行，所有 business logic（公司的業務規則，例如庫存怎麼算）都搬進 skills。
• 41:30 以前是把需求一條條塞進 system prompt；改包成 skills 後，Claude 只在發現解題需要時才把資訊拉進來
  ↳ 以前是把規則一條條全塞給 Claude，不管這次用不用得到；現在包成 skills，Claude 判斷這題需要時，才把相關內容拿出來看。
• 42:00 用 eval 做 hill climbing，看出隨時間的進步；最後 eval 分數約 92%
  ↳ 他們用 eval（一套固定的考題，用來幫 agent 打分數）反覆測試、反覆修改，一步步把分數往上推，這叫 hill climbing。最後分數大約 92%。
• 42:31 eval 結果：速度更快，而且因為用了 code execution，token 用得更少
  ↳ 測出來的結果：速度變快，而且因為改成寫程式處理資料，token 也用得更少。
• 42:31 turn count 大致不變；但 token 和成本都在下降，所以講者可以接受 Claude 多跑幾個 turn
  ↳ turn count（Claude 來回動作的次數）大致沒變。不過 token 和成本都在下降，所以講者不介意它多跑幾輪。
• 42:31 有時候 latency 降得不如預期；但像 forecasting 這種需要高智力的 agent，講者願意用稍高的 latency 換成效提升和成本下降
  ↳ latency（等回應的時間）有時沒有降得像預期那麼多。但像預測這種很吃腦力的工作，講者願意多等一點，換到更好的成效和更低的成本。
• 43:02 重點一：從單一 agent loop 開始，配上簡單的 primitives，讓 Claude 有類似人的能力：file system、web search、code execution，有時加上 to-do list，再視需要擴充
  ↳ 重點一：先從單一 agent loop（AI 想、做、看結果、再做的循環）開始，給它像人一樣的基本能力：檔案、搜尋、跑程式，有時加上待辦清單，不夠再擴充。
• 43:34 重點二：透過 skills 做 progressive disclosure，不把資訊塞進 system prompt，等 Claude 需要時再取用
  ↳ 重點二：用 skills 做 progressive disclosure，意思是資訊不要一開始全給，等 Claude 需要時再提供，不要全塞進 system prompt。
• 43:34 好處是執行更有效率、不會汙染 context window，也給 Claude 更多做決策的彈性
  ↳ 好處是跑得更有效率，Claude 看到的內容不會被用不到的資訊干擾，它也有更多空間自己決定要怎麼做。
• 44:05 重點三：要寫 evals。Anthropic 很倚重 hill climbing：先用 eval 建立 baseline，調整架構，重跑 eval，逐步變好
  ↳ 重點三：一定要寫 eval。Anthropic 很依賴這個循環：先測出起始分數，調整架構，再測一次，慢慢把分數往上推。
• 44:05 產品能力擴充時，evals 也要跟著更新，確保涵蓋你在意、想衡量的東西，才能確認 agent 真的達成目標
  ↳ 產品功能越加越多時，考題也要跟著更新，涵蓋你真正在意、想衡量的事，才能確定 agent 真的達到目標。
• 44:35 這是 Code with Claude London 場次的演講
  ↳ 這段是 Code with Claude 倫敦場的演講內容。

重構完成後，inventory management agent 的 system prompt 精簡到大約幾行？