安安～我是ChiYu～

昨天把失敗分成六層後，至少每一條 trace 都知道該往哪裡查了。今天我原本想順勢整理一份
交付檢查表，從第一項念到第十項，勾完就收工。

這種文章其實很好寫：Human UI、Tool、冪等、安全確認、版本座標，每一格填一個看起來完整
的答案，最後再補一句「網站已經 Agent-ready」。版面會很整齊。

問題是，整齊不等於我真的敢交付。

如果另一位工程師明天接手 AgentReady Events，他需要知道的不是我勾了幾格，而是哪些結論
有程式測試、哪些有真實 Agent trace、哪些曾經失敗，以及哪一格目前就是空白。

所以今天不念口號。我把 Inspector 關掉，假裝自己是第一次接手這個專案的人，重新走一次
網站，再把每項結論對回證據。

檢查以前，先確認公開站到底跑哪一版

今天不切新的開發里程碑。交付判斷以公開 /health/version 對應的版本為準：

commit       243a8d343b346ba43178dd95bd825c9a56f122b3
revision     ca-agentready-events--0000010
image digest sha256:1630235f9ad2a8cbab5ade3e582d6dd564d7a5e7d229cc08f6cd785fb0ffaddb
workflow run 30893507987

前面的 v3-day-* 適合重播開發里程碑；現在要判斷公開站能交付到哪裡，就得看真正承接流量的
commit、digest 與 revision。

歷史 trace 仍屬於當時的版本，不會因為網址後來切到 0000010，就自動一起升級。

圖 1：這十項不是分數表。檢查從人類流程開始，一路追到公開版本與 Agent 證據。

第一個動作：先把 Inspector 關掉

我先用一般使用者的方式搜尋活動、打開詳情、收藏，再進入報名與取消流程。即使瀏覽器不支援
WebMCP，這些路徑仍然存在；表單有 label，錯誤顯示在畫面上，高風險動作也能由人完成。

這關看起來和 Agent 無關，卻是最不能省略的一步。原本 Journey 如果已經壞了，多註冊一支
Tool 只是替同一個 bug 多開一扇門。

WebMCP 是在完整產品上增加能力契約，不是拿來替壞掉的 UI 擦粉底。

五個正式名稱都在，還要看目前 route 公開什麼

產品層固定保留五個名稱：

search_events
get_event_details
save_event
prepare_event_registration
prepare_registration_cancellation

這份名單不代表每頁都要同時出現五支 Tool。交接時還要核對 active catalog 與 input profile：

同名的 get_event_details 在列表頁與詳情頁完成同一任務，卻使用兩份清楚的 schema。這比把
event_id 寫成一個模糊的選填欄位更容易測，也避免 null 與跨 route 換目標。

Tool name 描述任務，不描述按鈕。畫面文案日後從「查看詳情」改成「瞭解活動」，能力名稱也
不該跟著搖晃。

會使用 Tool 還不夠，也要知道什麼時候不要用

交付時不能只展示 Agent 會操作網站。NO-01 在一般知識題維持零次 Tool call；NO-02 初次曾猜
catalog 外的頁面讀取能力，revision 0000008 重測後才守住 no-tool 邊界。

這兩筆要一起留著：新 PASS 說明修正版有改善，舊 FAIL 則提醒接手者模型曾在哪裡亂敲門。
我沒有因為模型猜了新名稱，就替產品補第六支 Tool。

寫入流程要看停點，也要看副作用

收藏是可 Undo 的低風險寫入。同一活動重複收藏時，server 只保留一筆，第二次回
alreadySaved:true。

報名與取消的標準更高：

Agent prepare
→ 可見表單或摘要
→ CONFIRMATION_REQUIRED
→ Network mutation = 0
→ 人類自行確認

CONF-01 Attempt 2 曾經做到可見表單與零 registration POST，卻缺少 Declarative completion，
所以歷史判定仍是失敗；revision 0000008 的 Attempt 3 才補齊 result 與最後回答。

取消的原始 CONF-02、REPEAT-02 同版仍保留失敗；後來 0000009 的 V2 case 分別證明
route-bound prepare 與人類停點，正式取消、名額只回補一次和防重播則由 human／deterministic
companion 補足。0000010 再處理 session expiry。

這段歷史不用在交接文件重講每一張圖，但不能壓縮成一句「寫入流程全部通過」。不同版本與
證據類型仍要分開。

每一項結論都要能對回版本與證據類型

我只留下三條版本規則：

1. 目前公開站只能替現在承接流量的 runtime 作證。
2. 歷史 trace 仍屬於當時的 revision。
3. 後來的新題庫不能回頭改判舊 FAIL。

各版 commit、digest、workflow run 與證據上限，都放在
版本證據帳本。

版本帳本是交接附件，不是裝飾。沒有座標的「我測過」，幾天後通常只剩作者本人的回憶。

十項檢查套回 AgentReady Events

最後一列沒有勾，我反而比較放心。空白清楚告訴接手者：目前有公開版本、固定座標與原始證據，
但沒有第三方乾淨環境重播。

我也試過替整站算一個 Agent-ready 百分比，最後拿掉了。十次低風險搜尋成功，不能抵銷一次
越過取消確認；not_run 也不是 FAIL。風險不同的題目硬平均，數字會很好讀，系統卻不會因此
更安全。

換成其他網站，可以先填這張交付卡

使用者想完成什麼：
沒有 Agent 時怎麼完成：
Tool 名稱與唯一責任：
目前 route 公開哪些 Tool：
同名 Tool 在這裡使用哪份 schema：
需要哪些輸入，會回傳什麼：
資料來源裡有哪些不可信內容：
重複執行會發生什麼：
哪一步必須交回人類：
成功後畫面要看見什麼：
一個正常 Prompt：
一個不該呼叫或應先追問的 Prompt：
測試對應的公開版本：
實際結果與尚未證明的部分：

如果 route、input、可見結果和人類停點寫不出來，能力通常切得太大；版本座標留白，幾天後
也很難知道當時測的是哪份程式。

回到開頭：我敢不敢把 AgentReady Events 交給另一位工程師？

如果交付的是可檢查的 Demo、五支 Tool 的設計方法，以及成功與失敗都留在原位的工程紀錄，
我敢。若要宣稱所有環境、模型與瀏覽器都會得到相同結果，目前證據不夠。

明天是最後一天。我不再加功能，也不補一張「大功告成」的圖，而是回到最初那句「幫我找
台北、免費，而且適合入門者的活動」。做完這一圈後，真正改變的是網站多了五支 Tool，還是
我判斷 Agent-ready 的方式？

參考資料

• Chrome：WebMCP best practices
• Chrome：WebMCP tool security
• Chrome：WebMCP Evals
• WebMCP Draft Community Group Report