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

🧑‍🏫 這段是工作坊的實作：講者有一個自己寫的庫存管理 agent，越改越臃腫，他把它搬到 Claude 官方的代管平台上，先用測驗打分數，再請 Claude 找出失分原因。值得看的地方是，它示範了「先量分數、再找原因、最後才動手改」的做法。它找到的失分原因之一，也是很多人常犯的：把所有規則都塞進同一份指示裡。

• 11:17 repo 的 before 資料夾裡是用 Messages API 從零打造的 agent，工作坊要把它遷移到 Claude managed agents
  ↳ repo（放專案程式碼的資料夾）裡的 before 版本，是講者直接用 Messages API（呼叫 Claude 的基本介面）從頭寫出來的 agent。工作坊要把它搬到 Claude managed agents 這個官方代管服務上。
• 11:17 Claude managed agents 幫你處理維護 agentic harness 的麻煩事，讓 agent 能安全地擴展到數千、數萬名使用者
  ↳ agentic harness 是包在模型外面、讓 agent 能跑起來的那層框架。自己維護很累，CMA 會幫你處理。使用者從幾個人變成幾萬人，也能穩定又安全地撐住。
• 11:48 在本機建置、執行 agent 很快也很簡單；但要遠端託管並讓大量使用者同時使用，就會遇到基礎架構、擴展、memory、安全性等問題
  ↳ 在自己電腦上跑給自己用很容易。但要放上伺服器給一大群人同時用，就得處理主機、流量擴充、memory（記住對話和資料）、資安等一堆雜事。
• 12:18 把這些問題交給 CMA 處理，開發者就只需要專心在 agent 架構上，決定要用 tools、skills 還是 sub-agents
  ↳ 雜事交給 CMA 後，開發者只要專心設計：能力要做成 tools（可呼叫的功能）、skills（需要時才載入的知識包），還是 sub-agents（專門分工的小 agent）。
• 12:18 CMA 把 agent 本身、session 細節，以及實際執行 tool call 的 sandboxed environment 分開
  ↳ CMA 把三件事分開管：agent 本身、每段對話的 session（一次對話的紀錄），以及實際執行工具的 sandboxed environment（隔離的執行空間，出事不會波及其他地方）。
• 12:48 畫面上有工作坊網址，Code with Claude London 的所有工作坊都放在那裡，之後可以回去看
  ↳ 影片畫面上有工作坊網址，Code with Claude London 的所有工作坊都放在那裡，想重看或補看其他場可以去找。
• 13:18 這次工作坊的主題是 agent decomposition，也就是要操作的資料夾名稱
  ↳ 這場的主題叫 agent decomposition，就是把一個長得太臃腫的 agent 拆成合適的零件。repo 裡要操作的資料夾也叫這個名字。
• 13:18 第一步是建立 baseline：先把 repo clone 到本機
  ↳ 要改進，得先知道現在的程度。所以第一步是量出 baseline（改進前的起始成績），做法是先把 repo clone（完整複製）到自己電腦。
• 13:48 這是一個 UV 專案，執行 uv sync 安裝套件和相依項目，才能呼叫 Anthropic SDK，之後也要用來部署到 Claude managed agents
  ↳ 這個專案用 UV（一種 Python 套件管理工具）。執行 uv sync 會一次裝好需要的套件，才能用 Anthropic SDK（官方程式工具包）呼叫 Claude，之後部署也要靠它。
• 13:48 需要一組 API key：用工作坊一開始拿到的 credits，到 Claude console 帳號建立 API key
  ↳ API key 是讓程式用你的名義呼叫 Claude 的一串密碼，用量也記在它上面。用工作坊發的 credits（使用額度），到 Claude console（開發者後台）建一組。
• 14:18 複製 ENV example 產生 ENV 檔，再手動把 API key 貼進去
  ↳ 專案附了範本檔 ENV example。複製一份做成 ENV 檔（存密碼、設定的檔案），再把 API key 貼進去，程式就讀得到了。
• 14:18 12 個 eval 都已經設定好；執行 uv run evals --agent before 就能取得 baseline，指令都寫在 README 裡
  ↳ eval 是事先寫好、用來替 agent 打分數的測驗。這裡 12 題都備好了，執行 uv run evals --agent before 就能拿到 before 版的 baseline，指令都寫在 README（專案說明檔）裡。
• 14:48 整體流程：先跑 eval，接著用 Claude Code 分析（triage）結果，再依結果改進 agent（hill climbing）
  ↳ 流程是一個循環：跑 eval 考試，再用 Claude Code（在終端機裡寫程式的 Claude）做 triage 找出錯在哪，然後針對問題修改。這樣一步步把分數往上推，就叫 hill climbing。
• 15:18 目前的 system prompt 約 400 行，因為業務需求不斷增加，資訊就一直往 system prompt 裡堆
  ↳ system prompt 是每次對話前先交給模型的整套指示。這個 agent 的 system prompt 約 400 行，因為每來一個新的業務需求就往裡面加一段，越疊越長。
• 15:18 接下來要檢查工具：目前有 12 個 tool，其中 3 個其實是包裝過的 sub-agent，要研究怎麼讓它們更有效率
  ↳ 接著檢查工具。現有 12 個 tool，其中 3 個名義上是工具，其實是包起來的 sub-agent（自己會再呼叫模型的小 agent）。要研究怎麼讓它們更有效率。
• 15:18 最後，如果 agent 真的需要 sub-agent 才能發揮效果，會探討在 Claude managed agents 上建構 sub-agent 的最佳方式
  ↳ 最後會討論：如果某件事真的得靠 sub-agent 才做得好，在 CMA 上該怎麼搭建最恰當。
• 15:49 repo 裡有兩個資料夾：before 和 starter，分別放著兩個不同的 agent
  ↳ repo 裡有 before 和 starter 兩個資料夾，各放一個不同版本的 agent，後面會拿來對照。
• 16:19 before：講者用 Anthropic Messages API 自己寫 agent loop 和 harness 的版本；starter：同一個 agent 部署在 Claude managed agents 上的版本
  ↳ before 是講者自己寫 agent loop（問模型、執行工具、再問模型的循環）和 harness 的版本。starter 是同一個 agent 放到 CMA 上的版本，底層交給平台管。
• 16:19 要部署到 Claude managed agents，就執行 uv run deploy a starter（字幕原文）
  ↳ 要部署到 CMA（放上雲端讓人使用），字幕裡的指令是「uv run deploy a starter」。這是聽寫下來的，實際怎麼打請以 README 為準。
• 16:50 可以用 Claude Code 比較這兩個版本，了解 Claude managed agents 有哪些差異
  ↳ 兩個版本放在一起，可以直接請 Claude Code 比對差在哪。這樣很快就能看懂：交給 CMA 代管後，哪些程式碼省掉了、哪些地方變了。
• 17:21 講者用 Claude Code 跑 eval，因為想請 Claude 協助分析結果
  ↳ 講者讓 Claude Code 去跑 eval，而不是自己手動跑。這樣結果一出來 Claude 手上就有，可以直接接著分析。
• 17:21 講者使用 Opus 4.7，effort level 設為 extra high；他通常設成 extra high 後就不再調整，覺得效能很好
  ↳ 講者用的模型是 Opus 4.7，effort level（模型要花多少心力思考的設定）開到 extra high。他習慣設好就不再動，覺得表現很好。
• 17:51 透過 Claude Code 的 bash 功能執行 uv run evals --agent before，由 Claude 實際跑 eval
  ↳ bash 是用文字下指令給電腦的介面。Claude Code 可以自己在 bash 裡執行 uv run evals --agent before，也就是由 Claude 親手把測驗跑完。
• 18:21 這次 eval 結果是 62%，低於一開始的 83%，12 個只通過 7 個；Claude 對失敗的 eval 提供了診斷
  ↳ 這次得分 62%，12 題只過 7 題，比一開始的 83% 還低。Claude 不只給分數，還針對沒過的題目說明可能的原因。
• 18:57 請 Claude 歸納失敗的共同原因：只要你的 agent 有 eval，就能用 Claude 來分析（講者提到 Geary 先前也示範過）
  ↳ 接著請 Claude 從失敗的題目裡歸納共同原因。重點是：只要你的 agent 有 eval，就能這樣請 Claude 幫忙找問題。講者提到 Geary 之前也示範過。
• 18:57 原因一：模型在做一些本該交給工具處理的工作，也就是在沒有適當工具的情況下，靠推理處理資訊
  ↳ 原因一：該交給工具做的事，模型卻自己用想的。因為沒有合適的工具，只好靠推理處理資訊，比較容易出錯。
• 19:29 原因二：輸出結構沒有被確實執行，模型和 sub-agent 產出的格式跟預期不符，影響 agent 表現
  ↳ 原因二：輸出格式沒被強制規定。模型和 sub-agent 交出來的格式跟預期不一樣，下一步就接不上，整體表現被拖累。
• 19:59 原因三：policy 相關問題；system prompt 太長，Claude 看到其中的資訊造成混淆
  ↳ 原因三跟 policy（業務規則）有關：system prompt 太長，Claude 讀到一大堆資訊，反而被搞混了。
• 19:59 找出根本原因後，會逐一處理這些問題，並用 Claude Code 協助 triage
  ↳ 找到根本原因後，會一個一個處理，過程中繼續用 Claude Code 協助 triage（分析失敗原因）。
• 20:31 agent 累積久了，system prompt 往往會變得非常長
  ↳ 這是很常見的狀況：agent 用得越久、需求越多，system prompt 就越堆越長。
• 20:31 第一個 prompt：請 Claude 查看 agent.py（主要的 CMA agent loop 所在檔案）
  ↳ 第一個請求是讓 Claude 看 agent.py。這個檔案就是 CMA 版 agent loop 的主程式。
• 21:02 講者問 Claude 對 system prompt 有什麼看法，並提出能不能改用 skills 取代冗長的 system prompt，達到 progressive disclosure
  ↳ 講者問 Claude 對這份 system prompt 有什麼看法，並提議改用 skills 來做到 progressive disclosure（資訊需要時才給，不一次全塞）。
• 21:02 skills 的定義：打包好、可組合的資訊，Claude 發現完成某項任務需要時，才會把它拉進 context
  ↳ skills 是打包好、可以互相搭配的資訊包。Claude 判斷任務需要時，才把它拉進 context（模型當下讀得到的內容），平常不佔位置。
• 21:32 skills 在 Claude Code 很好用，例如提供測試流程，或把品牌與 UI 元件打包成 skill，需要時再讓 Claude 載入
  ↳ skills 在 Claude Code 裡很實用，例如把測試流程寫成一個 skill，或把品牌規範和 UI 元件打包起來，做到相關工作時才讓 Claude 載入。
• 21:32 skills 也適合用在你為客戶打造的 agent 或產品裡
  ↳ 不只自己用得到，你幫客戶做的 agent 或產品，也很適合用 skills 來整理各種知識和流程。
• 22:02 這個庫存管理系統的 agent 有很多 policy 和作業程序，講者當初沒有做成 skills，而是一直往 system prompt 後面加，讓它越來越長
  ↳ 這個 agent 是庫存管理系統，有很多 policy 和作業程序。講者當初沒有做成 skills，而是一直往 system prompt 後面加，才變得這麼長。
• 22:32 講者表示，一直把需求加進 system prompt 不是他們推薦的做法
  ↳ 講者明講：一直把需求往 system prompt 裡堆，不是他們推薦的做法。前面提到的失分原因三，就跟這有關。

講者用 Claude Code 跑 before 版本的 eval，得到什麼結果？