安安～我是ChiYu～
昨天做完交付檢查，最後留下的答案有點不乾脆：如果交付的是 Demo、Tool 設計方法與可查核
紀錄，我敢；如果要宣稱所有模型、瀏覽器與環境都會得到相同結果，證據還不夠。
今天是最後一天，我想回到一個月前輸入的那句話：
幫我找台北、免費，而且適合入門者的活動。
第一次看到 Agent 自己選中 search_events 時，我最直接的反應是：網站真的開始會說話了。
現在再看同一份 trace，我注意的東西完全不同：它在哪個版本執行？Input 有沒有保留全部條件？
回答能不能對回 result？畫面有沒有更新？如果下一步變成報名，Agent 又會停在哪裡？
「會呼叫」仍然值得開心，只是它已經不是終點了。
今天不部署「大結局版」。開發里程碑保存在 v3-day-*，正式發布使用 release tag，真實 Agent
結果則各自綁定 0000006 到 0000010 的 revision。它們是不同座標，不是一個可以互相覆蓋
的最新版。
最後留下的 Agent-ready 方法可以整理成四層：
圖 1：人類 Journey、Tool contract、安全執行與可重播證據形成一個循環。
人類先能完成任務
→ 網站把任務整理成 Tool contract
→ Server 與人類確認守住副作用
→ 固定版本與 trace 檢查網站有沒有說大話
搜尋表單要有 label，錯誤要顯示在畫面上，鍵盤也能完成操作。瀏覽器不支援 WebMCP 時，網站
不能跟著罷工。
系列一開始，我先走人類 Journey，再用 Playwright 固定行為。當時只把按鈕從「搜尋活動」
改成「探索場次」，舊 locator 就找不到目標。那次失敗讓我看見 UI automation 對可見介面的
依賴，也把 WebMCP 的位置說清楚：它增加任務契約，沒有取代語意 HTML、可用性或 browser
test。
人類介面不是 Agent 出錯時才拿出來的備案。它一直都是完整產品。
產品最後固定保留：
search_events
get_event_details
save_event
prepare_event_registration
prepare_registration_cancellation
它們對應三條 Journey：
搜尋 → 詳情 → 收藏
準備報名 → 人類送出
準備取消 → 人類確認
這五個名稱不是每頁都要同時出現。Active catalog 會跟著 route 與狀態改變：
| 情境 | 主要契約 |
|---|---|
/events |
搜尋取得 opaque ID，詳情沿用 ID，收藏只能作用於已顯示的同一活動 |
/events/:eventId |
get_event_details 綁定 route，只接受 {} |
| 報名頁 | Agent 只準備可見欄位，不送出正式報名 |
| 我的報名 | 對象唯一時可用 {}，多筆時要求頁面提供的 registration ID |
get_event_details 沒有做成一份「event_id 可填可不填」的萬用 schema。列表頁需要 ID，詳情
頁則由 route 提供 context。這看起來比一支萬用 Tool 麻煩，卻少了 current、null 與跨頁
舊狀態一起猜題的空間。
表單原本就能表達的能力使用 Declarative Tool；需要 route context、結構化 result 或生命週期
管理時，再用 Imperative Tool。兩種入口最後都回到同一套 action 與 server rule。
真正花時間的地方，往往不是 registerTool() 那幾行，而是 name、description、schema、
result、route 與目前狀態有沒有指向同一項任務。
Schema 可以限制格式，annotation 可以提示唯讀或不可信內容。授權與副作用仍由 server 處理：
這些規則讓 Agent 可以準備報名與取消，卻不能替使用者按下最後確認。
Demo 也不宣稱 server 能從一個 request 證明「真人真的按了按鈕」。Confirmation intent 只是
這條受控 Journey 中可測的停點；付款、寄信或不可逆交易，仍可能需要重新驗證、WebAuthn、
交易簽章與更完整稽核。
能力宣告不是授權。這條界線如果省掉，前面的 Tool 寫得再漂亮都沒有用。
這三十天一路測過 Tool selection、arguments、歧義、順序、重複執行、不可信內容與 recovery。
報名和取消還得檢查可見停點、Network mutation 與 server state。
每種證據回答不同問題：
Unit／API／Browser test
→ 程式與商業規則是否符合固定斷言
公開部署座標
→ 哪一份程式正在執行
Inspector Copy trace
→ 模型是否真的從自然語言選 Tool、送 input 並使用 result
少看任何一層，都可能把「程式做得到」寫成「Agent 已經做到」。
版本結果也不能相加成一張漂亮成績單：0000008 的 8 PASS／5 FAIL 原樣保留；0000009、0000010 的 targeted recovery 5／5 回答的是修正後的新 case，不會讓舊 FAIL 自動變色。
REPEAT-01 雖有真實 Agent trace，卻沒有綁定 immutable revision，因此只能替當次行為作證，
不能借給其他版本升級。
目前公開版本座標是：
commit 243a8d343b346ba43178dd95bd825c9a56f122b3
revision ca-agentready-events--0000010
image digest sha256:1630235f9ad2a8cbab5ade3e582d6dd564d7a5e7d229cc08f6cd785fb0ffaddb
workflow run 30893507987
這些連結比「最新版請看 main」麻煩一點，卻能讓讀者拿到我當時真正測過的程式。
這次遇過：
event_id:null，還沒碰到預期的 API 故障；最後一個問題尤其直接：測試亮綠燈，環境卻被測試資料污染。後來 smoke 改成同一個 session
完成 8 → 7 → 8，先報名再取消，並把狀態恢復列入發布門檻。
這些失敗最後整理成六層診斷順序：
environment
→ selection
→ arguments
→ execution
→ grounding
→ human authority
沒有 Tool call 先查環境；Tool 選錯再看 catalog；input 錯回到 schema；result 錯查 server；
result 正確但回答走樣才處理 grounding；寫入越過停點則回頭檢查 human authority。
至少下一次看到「Agent 又失敗了」，我不用先從改 Prompt 開始亂槍打鳥。
第一，人類介面始終是完整產品。 WebMCP 掛掉時，網站不能一起失去搜尋、報名與取消。
第二，報名與取消不讓 Agent 直接完成。 它可以準備資料、整理影響、打開確認畫面，最後
一步仍由使用者負責。
第三，沒有執行就是 not_run。 Playwright、API test 或 UI 截圖可以補充程式證據，
不能冒充真實 Agent invocation。
這三個選擇少了一點「AI 自動幫你全部做完」的戲劇效果，卻讓我知道出事時該去哪裡查，也
知道哪些能力現在真的能交出去。
參加鐵人賽時，我原本只想把一個很新的 API 做成網站，讓讀者看見 Agent 自己找到並呼叫
Tool。寫到後來，我更在意的是：讀者拿到相同版本與 trace 後，能不能得到和我一樣的判斷。
下一個網站若也要加入 Agent 能力，我不會先規劃十支 Tool。我會：
挑一條高頻、低風險 Journey
→ 確認人類流程與 server rule
→ 決定產品名稱與每個 route 的 context
→ 寫清楚 input、result 與人類停點
→ 部署固定版本
→ 用自然語言留下完整 trace
第一支 Tool 如果還說不清楚，第十支通常也不會突然開竅。
我也想把同一份五支 Tool 契約交給另一個模型與瀏覽器重新實作，檢查 route context、人類確認
與錯誤復原。那會是一批新測試，不會回頭替這次缺少的證據補分。
截至今天，WebMCP 仍是 Draft Community Group Report，不是 W3C Standard，也沒有進入 W3C
Standards Track。Chrome 將它列為 proposed web standard，可透過 Origin Trial 或本機 testing
flag 試用，API 仍可能持續變動。
因此這 30 天不能替所有 Agent、模型或瀏覽器作保，也不能把 Demo 的 confirmation intent
直接外推到付款與不可逆交易。這個系列完成的是一套可查核的實作與測試方法，不是替仍在演進
的標準宣布結案。
一個月前，我想知道網站能不能「說出自己會做什麼」。現在的答案是可以，但網站說得清楚只是
第一步。工程師仍要替人類流程、安全邊界與每一份成功證據負責。
五支 Tool 就先停在這裡。網站已經會說話，接下來要做的，是繼續確認它沒有說大話。
iThome鐵人賽
看影片追技術