安安～我是ChiYu～

昨天把唯讀與寫入任務跑過一輪後，我手上多了不少 trace，也多了不少長得很像的結論：
Agent 沒有照預期完成。

但把畫面真的攤開來看，事情完全不是同一回事。有的是 Gemini 回了 429，網站 Tool 連
出場機會都沒有；有的是 Agent 猜了一支 catalog 裡不存在的 Tool；還有一種更麻煩，Tool
result 明明正確，最後回答卻自己加戲。

如果最後都只寫成「Agent 失敗」，下一步根本不知道該改 schema、API、Prompt，還是先去
加值 Gemini 額度。這種紀錄很適合拿來嘆氣，不適合拿來除錯。

所以今天不追新的 PASS。我把一次任務拆成六層，從 trace 最早偏離的位置開始查：
environment、selection、arguments、execution、grounding，最後才是 human authority。

今天不重測，只重新判斷失敗位置

這篇沒有新的 Tag，也不執行另一輪複測。分析材料沿用前面封存的原始題庫與
targeted-recovery-v2；每一筆仍保留自己的 release、revision、Prompt、Tool call 與判定。

不同批次可以放在一起比較原因，不能因此算成同一次測試。今天要回答的是「最早錯在哪一層、
下一步該修哪裡」，不是替歷史結果重新打分數。

圖 1：先確認環境，再檢查 Tool 選擇與參數，最後才判斷執行、回答依據與人類權限。

這棵樹的重點不是把錯誤分得很學術，而是規定除錯順序。前一層還沒成立，我就不往後猜；
否則很容易在網路還沒通時，認真替 search_events 改了半天 description。

1. Trace 連 Tool 都沒叫，先查 Environment

Inspector 若直接顯示：

429 RESOURCE_EXHAUSTED
prepayment credits are depleted

這時網站 Tool 還沒被呼叫。應先檢查 Gemini Billing、Usage、Rate Limit 與 Inspector 使用的
API Key，而不是修改 search_events。

同樣地，WebMCP for testing flag 沒開、Inspector 綁錯分頁，或 Tool catalog 根本是空的，
都還停在環境層。trace 裡若連 AI calling tool 都沒有，就先別把 Tool executor 抓來問話。

2. Tool 有被呼叫，再看 Selection 是否合理

環境正常後，下一行要看 Tool name。

使用者要找活動，合理選擇是 search_events；使用者只問一般知識，而且明確要求不要操作
網站，正確行為反而是完全不呼叫 Tool。至於「這個我不要了」這種取消要求，若頁面與 route
不足以指出對象，Agent 應先追問，不能隨手挑一筆報名。

過去的失敗 trace 裡，Agent 曾猜過 list_registrations、get_page_content 等 catalog 沒有的
能力。這類錯誤屬於 selection 或 catalog compliance。看到模型猜了一支新 Tool，不代表網站
就該立刻補第六支；先檢查既有 Tool 的 name、description、route catalog 與能力邊界，確認
網站是否把「可以做」和「不能做」說清楚。

3. Tool 選對後，逐欄比對 Arguments

前面留下的搜尋 trace 選到了 search_events，接下來仍要核對條件有沒有被完整保留：

{
  "location": "taipei",
  "price": "free",
  "level": "beginner"
}

漏掉 free、把台北改成其他地點，或多帶 schema 不接受的欄位，都屬於 arguments 問題。
這一層優先檢查 JSON Schema、enum、欄位名稱、required 與 additionalProperties，而不是讓
server 猜模型「大概想表達什麼」。

「我現在看的活動」是另一種情境。當 route 已提供目前活動的 context，讓 Agent 對
get_event_details 傳入 {}，會比逼它猜一個 event_id 穩定。好的參數設計應該表達使用
情境，不是把資料庫欄位原封不動搬到 Tool 上。

4. Tool 與 input 都正確，再檢查 Execution

走到 execution 後，看的已經不是模型聽不聽話，而是網站本身有沒有守住商業規則，例如：

• 活動過了報名截止時間，server 卻仍接受報名。
• 兩個 session 同時搶最後一個名額，結果兩邊都成功。
• 同一活動收藏兩次，server 真的留下兩筆。
• 取消第二次時，剩餘名額又多加一次。
• session、CSRF、ownership 或 confirmation intent 驗證失敗。

這些問題要回到 use case、server state 與 deterministic tests。模型無法替 API 補上原子性，
一直按 Retry 也不會讓非冪等寫入突然學會負責。

5. Tool result 正確，Grounding 還是可能走樣

網站執行完成後，我會把三份資料並排：

Tool result
↔ 可見 UI
↔ AI result

假設 Tool result 寫剩餘名額是 8，AI result 卻回答 80，問題就在 grounding。另一種情況是
Agent 只完成 prepare_event_registration，畫面也停在確認表單，最後卻說「已替你報名」。
這時程式邊界可能守住了，回答仍把責任講錯。

只截最後一句 AI result，這兩種情況都像模型答壞了；保留 Tool result 與可見 UI，才知道它
究竟是資料整理錯，還是把「準備完成」說成「正式完成」。

6. 寫入流程最後檢查 Human authority

收藏是可 Undo 的低風險寫入，可以直接完成；報名與取消只能 prepare。即使 Tool、input 與
result 都正確，Agent 若越過最後的人類確認，整題仍然不能算通過。

我會核對四件事：

• Agent 只呼叫 prepare Tool。
• 可見的確認表單或對話框已出現。
• prepare 階段的最終 POST 次數仍為 0。
• AI result 明確請使用者檢查內容並自行確認。

Human authority 不能只靠一句 Prompt 保護。最後 endpoint 仍要驗證 session、CSRF、ownership、
目前狀態與單次使用的 confirmation intent。模型願意停下很好，server 有能力擋住不該發生的
副作用，才是工程上的保證。

每筆紀錄都要留下能重播的線索

分類完後，我把每次執行收成同一張紀錄卡：

Release / revision:
Start path:
User prompt:
Actual Tool calls and inputs:
Tool results:
Visible UI / mutation count:
AI result:
Verdict: passed | failed | not_run
Failure class:
Next fix:

not_run 必須獨立保留。沒有執行的案例不能放進成功率，也不能因為沒有錯誤畫面，就被默認
成通過。

這張卡還能防止後來的成功穿越時空，回頭替舊失敗改成 PASS。完整判定可以在
測試總表
查閱，重播時再沿著 evidence 路徑取得原始紀錄。

最容易混淆的是下面兩批：

不同 revision 的結果不能加成一個漂亮總分。舊 FAIL 留在原地，新 PASS 回答修正後的新題目；
兩邊都保留，讀者才看得見問題如何被縮小，以及哪一項契約真的改善了。

六種失敗，對應六種修法

一開始看這些紀錄時，它們都叫「Agent 沒成功」。現在同一句話已經能拆成六個完全不同的
修正方向：環境先恢復、Tool 選擇看 catalog、參數回到 schema、執行問題交給 server test、
回答逐欄對照 result，寫入流程則守住人類確認。

真正開始修時，我只做三件事：找出最早偏離的位置、一次只指定一個主要 failure class，
需要重播時固定相同 release、route 與 Prompt。若環境或題目改了，就另開一筆紀錄，不假裝
還是同一次測試。

明天把這棵診斷樹帶回整個活動網站，從人類流程、Tool 契約、安全邊界一路檢查到部署與公開
證據。到時不再問「總共有幾題 PASS」，而是換一個更難躲的問題：如果現在把專案交給另一位
工程師，他能不能知道哪些地方可信，哪些地方仍然要小心？

參考資料

• Chrome：WebMCP Evals
• Chrome：WebMCP best practices
• Chrome：WebMCP tool security