Tool、skill 還是 subagent？拆解一個已經撐爆 prompt 的 agent（第 1/4 段）
🏦 台灣Pay 銀行轉帳 💙 PayPal
用 Stock Pilot 示範 agent 越長越複雜導致 eval 退步，以及怎麼重新設計
- 00:21 講者 Will 是 Anthropic 工程團隊成員，隸屬 Applied AI 團隊，時間分給內部工程工作和跟客戶一起打造 agent；這場在 Code with Claude London
- 05:30 R 開頭的 eval 代表 regression：比較貼近實際情況的 single-turn 任務，評的是 agent 呼叫 tool 之後給出的回應
- 10:37 再做 Anthropic 內部叫 hill climbing 的方法：從約 83% 的 baseline 開始，一邊優化架構一邊重跑 eval，讓通過率一路往上爬
💡 你可以怎麼用：如果你有長期在用的 AI 指令，例如 Claude Project 或自訂 GPT 的說明，可以定期整理：刪掉重複的內容，找出互相矛盾的規則。再準備 5～10 個固定的測試問題，每次改完指令都重問一遍，對照前後的回答，確認有沒有變好。
看全部 34 條重點
🧑🏫 這支是 Anthropic（開發 Claude 的公司）開的實作課，主題是 agent 越改越差時怎麼重新設計。agent 指能自己呼叫工具、把任務完成的 AI 助手。功能一直加、表現反而下滑，這種狀況很多人都碰過。第一段用一個庫存管理 agent 示範問題怎麼出現，也教你用測試分數找出原因。
- 00:21 講者 Will 是 Anthropic 工程團隊成員，隸屬 Applied AI 團隊，時間分給內部工程工作和跟客戶一起打造 agent；這場在 Code with Claude London↳ 講者 Will 在 Anthropic 的 Applied AI 團隊，時間一部分做公司內部工程，一部分陪客戶實際打造 agent。這場是在倫敦 Code with Claude 大會上的課程。
- 00:52 常見情境：agent 上線後表現很好，接著不斷被要求加功能，最後 system prompt 長到好幾百行↳ 很常見的過程：agent 剛上線很好用，大家就不斷要求加功能。每加一個就往 system prompt（寫給 AI 的工作說明書）塞幾段，最後長到好幾百行。
- 01:23 agent 累積了幾十個 tool 和 subagent，太複雜之後，原本表現好的地方開始出現 regression↳ agent 能用的 tool（可呼叫的功能，例如查庫存）和 subagent（另外開的小幫手 AI）也累積到幾十個。系統太複雜後，原本做得好的事反而變差，這就叫 regression。
- 01:23 這種狀況在客戶身上很常見，Anthropic 自己也會遇到↳ 這不只是客戶才會犯的錯，Anthropic 自己做 agent 也會遇到。功能一路往上疊，很自然就會走到這一步。
- 01:53 workshop 會模擬一個複雜到效能退化的 agent，再走過工程師和架構師會做的設計決策，在保留新功能的同時把效能救回來↳ 這場 workshop（實作工作坊）會先做出一個被功能拖垮的 agent，再示範工程師怎麼重新規劃：新功能一個都不砍，同時把表現救回來。
- 02:23 核心問題：什麼時候該用 tool、什麼時候用 skill、什麼時候用 subagent，也就是在對的時機用對的 agentic primitive↳ 核心問題是 tool、skill、subagent 各該在什麼時候用。skill 是跟前兩者並列的另一種元件。三者合稱 agentic primitive，意思是組成 agent 的基本積木。
- 02:23 這場是 hands-on 實作課↳ hands-on 就是實際動手：觀眾會拿到程式碼自己跑、自己改，不是只坐著聽概念。
- 02:23 範例 agent 叫 Stock Pilot，是替一家中型零售商、也給這家零售商使用的庫存管理 agent↳ 示範用的 agent 叫 Stock Pilot，幫一家中型零售商管庫存，使用的人就是這家零售商的員工。
- 02:55 Stock Pilot 的功能：標記低庫存、預測需求、挑選供應商、開 PO、幫員工寫每週報告↳ 它會提醒哪些貨快沒了、預估之後賣多少、挑選進貨的供應商、開 PO（採購單），還會幫員工寫每週報告。
- 02:55 每個功能單獨看都不複雜，問題是功能一直硬接上去，架構卻沒有跟著更新↳ 這些功能單看都不難。問題是一個接一個硬接上去，整體設計從來沒有跟著重新整理，功能之間就開始互相干擾。
- 03:25 現在的架構：由單一個 Stock Pilot orchestrator 負責，system prompt 大約 400 行↳ 目前所有事都由一個 orchestrator 扛。orchestrator 是總指揮，負責判斷該做什麼、把工作分派出去，它的 system prompt 大約 400 行。
- 03:25 共有 12 個 tool，其中 3 個是 subagent 的包裝，這些 subagent 的 context window 完全獨立↳ 12 個 tool 裡有 3 個其實是包起來的 subagent。subagent 有自己獨立的 context window（AI 當下看得到的內容範圍），跟總指揮互不相通。
- 03:57 repo 裡的 before 資料夾就是這個還沒改過的 agent↳ 課程的 repo（放程式碼的專案資料夾）裡，before 資料夾就是還沒整理、問題一堆的原始版本，當作改造的起點。
- 03:57 結果就是 eval 分數開始下滑↳ 這樣一路加下去的結果：eval 分數開始往下掉。eval 是事先設計好、用來替 agent 打分數的測試題。
- 04:29 怎麼走到這一步：要加預測功能就開一個 forecaster subagent，要加寫報告功能又再開一個 subagent，越接越複雜，eval 跟著往下掉↳ 演變過程很典型：要做預測就多開一個預測用的 subagent，要寫報告再開一個。每次都只顧當下方便，累積起來越來越亂，分數跟著掉。
- 04:59 這個 agent 有 12 個 eval 任務，用 5 種不同的 grader 評分↳ 這個 agent 共有 12 道測試題，用 5 種 grader（評分方式）來打分數。
- 04:59 講者的同事在這場之前講過 eval；這場 workshop 會用到 eval，但不是主軸↳ eval 怎麼設計，講者的同事在前一場講過了。這場只拿 eval 當量尺，檢查改完架構有沒有變好，重點放在架構本身。
- 05:30 R 開頭的 eval 代表 regression：比較貼近實際情況的 single-turn 任務，評的是 agent 呼叫 tool 之後給出的回應↳ R 開頭的題目測 regression，屬於貼近日常的 single-turn 任務：只問一次，agent 用完 tool 回答，就評這一次的回答。
- 05:30 F 開頭的 eval 代表 failure mode：評的是比較複雜的 multi-turn 任務↳ F 開頭的題目測 failure mode（容易出錯的情境），屬於 multi-turn 任務：要來回好幾輪才能完成，比較複雜。
- 06:00 grader 有 deterministic 和 non-deterministic 兩類↳ 評分方式分兩類：deterministic 是能直接量、每次結果都一樣的數字；non-deterministic 是沒有標準答案、要靠判斷的特性。
- 06:00 deterministic grader 評 turn 數、latency、token 用量等指標，並且長期追蹤↳ deterministic 這類看的是對話來回幾輪、latency（多久才回應）、token 用量（AI 處理的文字量，也關係到費用），而且會長期追蹤變化。
- 06:30 用 LLM as a judge 評 non-deterministic 的特性，例如個性、語氣、風格、輸出品質↳ 語氣、個性、風格、輸出品質這種要判斷的，就用 LLM as a judge：請另一個大型語言模型當評審來打分數。
- 07:01 F1 模擬每天的低庫存盤點：agent 最後做對了，但繞了很遠的路、效率不夠，所以 eval 沒過↳ F1 模擬每天盤點低庫存。agent 最後答對了，但繞了很多冤枉路、效率太差，所以還是判不及格。
- 07:31 F2 評某個促銷方案下的訂購流程：subagent 其實做對了，但它跟 orchestrator 之間溝通出問題，所以沒過↳ F2 測促銷期間的訂貨流程。subagent 自己的工作其實做對了，但把結果交回給總指揮時出了差錯，整題還是失敗。
- 08:01 subagent 跟 orchestrator 溝通出錯，是 subagent 很多的複雜系統常見的失敗點，這段溝通一定要設計好↳ 小幫手很多的系統，最常出問題的地方是交接：要傳什麼、怎麼傳回來。這段溝通沒設計好，前面做對也沒用。
- 08:34 R8 檢查促銷月份的需求預測：system prompt 裡兩條放在不同位置的政策互相矛盾，模型搞混了，所以沒過↳ R8 測促銷月份的需求預測。system prompt 裡有兩條規定寫在不同地方，內容互相矛盾，模型不知道該聽哪條，結果算錯。
- 09:04 照 README 跑 eval，一開始通過率大約 83%↳ 照 README（專案附的說明文件）的步驟跑完測試，一開始大約 83% 的題目通過。
- 09:04 講者說在製造業 83% 不夠好，17% 的失敗率代價非常高↳ 83% 聽起來不錯，但講者說在製造業不夠。17% 的失敗率等於大約每 6 次就錯 1 次，出錯的代價非常高。
- 09:34 R8 細看：agent 抓對了預測基準值（每天 12 個）和促銷乘數（3.1x）↳ 細看 R8 會發現，agent 其實資料都抓對了：預測基準是每天 12 個，促銷期間要乘上 3.1 倍。
- 09:34 但計算時出現幻覺，沒用 3.1x，而是用了 1.35↳ 但計算時出現 hallucination（AI 講出沒有根據的內容）：它沒用 3.1，改用 1.35 去乘，答案就錯了。
- 10:06 原因是 context 問題，不是模型問題：system prompt 太長、太混亂，又有互相衝突的內容↳ 講者強調這不是模型能力不夠，而是 context（餵給模型的資訊）有問題：說明書太長、太亂、又自相矛盾，模型自然容易抓錯。
- 10:06 workshop 流程：先跑整套 eval、分類問題、依問題修改 agent 設計↳ 課程的步驟是：先把所有測試跑一遍，把失敗原因分類，再針對每一類問題去改 agent 的設計。
- 10:37 再做 Anthropic 內部叫 hill climbing 的方法：從約 83% 的 baseline 開始，一邊優化架構一邊重跑 eval，讓通過率一路往上爬↳ 接著做 hill climbing：以大約 83% 當 baseline（起始分數），每改一次架構就重跑一次測試，讓通過率一步步往上爬。
- 10:37 這個 lab 一開始的 agent 是直接用 Messages API 自己寫的，在 repo 的 before 資料夾↳ 起點的 agent 是直接用 Messages API 從頭寫的，就放在 before 資料夾。Messages API 是讓程式直接跟 Claude 對話的介面。
📘 術語
system prompt（系統提示）：agent 的指令內容；範例中越加越長，到約 400 行，還出現互相矛盾的政策
tool（工具）：agent 可以呼叫的能力；範例 agent 有 12 個，其中 3 個是 subagent 的包裝
skill（技能）：字幕只說它是跟 tool、subagent 並列、要判斷何時使用的 agentic primitive 之一
subagent（子代理）：有自己獨立 context window 的 agent；範例中被包成 tool 給 orchestrator 呼叫
agentic primitive（agent 基本元件）：指 tool、skill、subagent 這類構成 agent 的基本元件，要在對的時機用對的
orchestrator（協調者）：坐在架構最上層、統籌整個 agent 的角色，例如 Stock Pilot orchestrator
context window（上下文視窗）：字幕提到 subagent 的 context window 跟 orchestrator 完全隔開
regression（退化）：原本表現好的地方變差；R 開頭 eval 就是 regression，屬於 single-turn 任務
eval（評估）：用來替 agent 評分的測試任務；範例有 12 個任務、5 種 grader
grader（評分器）：評分的方式，分成 deterministic 和 non-deterministic 兩類
failure mode（失敗模式）：F 開頭的 eval，評比較複雜的 multi-turn 任務
single-turn / multi-turn（單輪／多輪）：single-turn：給一次任務、評它的回應；multi-turn：比較複雜、要來回好幾輪的任務
deterministic grader（確定性評分器）：評 turn 數、latency、token 用量等可以量化的指標
LLM as a judge（以 LLM 當評審）：用 LLM 評個性、語氣、風格、輸出品質這些 non-deterministic 的特性
latency（延遲）：deterministic grader 會追蹤的指標之一
hallucination（幻覺）：R8 中 agent 沒用抓到的 3.1x，而是用了 1.35 去計算
hill climbing（爬坡法）：Anthropic 內部的叫法：先有 baseline，再反覆優化並重跑 eval，讓通過率往上爬
baseline（基準線）：第一次跑 eval 得到的分數，約 83%
PO（採購單）：Stock Pilot 的功能之一是 file POs（開採購單）
Messages API（Messages API）：這個 lab 一開始的 agent 就是直接用 Messages API 自己寫的
tool（工具）：agent 可以呼叫的能力；範例 agent 有 12 個，其中 3 個是 subagent 的包裝
skill（技能）：字幕只說它是跟 tool、subagent 並列、要判斷何時使用的 agentic primitive 之一
subagent（子代理）：有自己獨立 context window 的 agent；範例中被包成 tool 給 orchestrator 呼叫
agentic primitive（agent 基本元件）：指 tool、skill、subagent 這類構成 agent 的基本元件，要在對的時機用對的
orchestrator（協調者）：坐在架構最上層、統籌整個 agent 的角色，例如 Stock Pilot orchestrator
context window（上下文視窗）：字幕提到 subagent 的 context window 跟 orchestrator 完全隔開
regression（退化）：原本表現好的地方變差；R 開頭 eval 就是 regression，屬於 single-turn 任務
eval（評估）：用來替 agent 評分的測試任務；範例有 12 個任務、5 種 grader
grader（評分器）：評分的方式，分成 deterministic 和 non-deterministic 兩類
failure mode（失敗模式）：F 開頭的 eval，評比較複雜的 multi-turn 任務
single-turn / multi-turn（單輪／多輪）：single-turn：給一次任務、評它的回應；multi-turn：比較複雜、要來回好幾輪的任務
deterministic grader（確定性評分器）：評 turn 數、latency、token 用量等可以量化的指標
LLM as a judge（以 LLM 當評審）：用 LLM 評個性、語氣、風格、輸出品質這些 non-deterministic 的特性
latency（延遲）：deterministic grader 會追蹤的指標之一
hallucination（幻覺）：R8 中 agent 沒用抓到的 3.1x，而是用了 1.35 去計算
hill climbing（爬坡法）：Anthropic 內部的叫法：先有 baseline，再反覆優化並重跑 eval，讓通過率往上爬
baseline（基準線）：第一次跑 eval 得到的分數，約 83%
PO（採購單）：Stock Pilot 的功能之一是 file POs（開採購單）
Messages API（Messages API）：這個 lab 一開始的 agent 就是直接用 Messages API 自己寫的
✏️ 小考一題
講者說 R8 eval（促銷月份需求預測）失敗的根本原因是什麼？
A. 模型本身能力不夠，需要換更強的模型B. agent 繞了很遠的路，效率不夠C. subagent 跟 orchestrator 之間溝通出問題D. system prompt 太長，而且兩條放在不同位置的政策互相矛盾，屬於 context 問題看答案
答案：D。[08:34] R8 失敗是因為 system prompt 裡兩條政策互相矛盾；[10:06] 講者明確說這是 context 問題，不是模型問題。溝通問題是 F2 的原因，效率不夠是 F1 的原因。
💛 覺得有幫助？支持一下
課本免費、沒有廣告，支持與否都能照常讀 🐰