安安～我是ChiYu～
昨天把 source commit、image digest 與 Azure revision 對齊後，我終於可以放心按下
Inspector 的 Send。
這句話聽起來有點奇怪。按一顆按鈕而已，到底有什麼好不放心？
因為今天要驗證的不是「Inspector 能不能動」，而是固定公開版本上的 Agent，能不能讀懂
自然語言、自己決定是否使用 Tool、組出正確參數，最後再用 Tool result 回答。只要測試前
偷偷從下拉選單指定 Tool，最重要的 selection 就被我親手代勞了。
所以今天不改 Prompt、不改程式，也不手動選 Tool。我把之前用過的兩句話原封不動搬到
公開網址，重新留下一份能對回部署版本的紀錄。
今天沒有新的程式版本。昨天確認過的 v3-p0-release.1 就是測試對象；接下來只增加同一
版本上的 Inspector trace，不讓 Prompt 微調或臨時部署混進結果。
我先固定這次測試的座標：
tag v3-p0-release.1
commit 8e89e6519406388a0de8c456a890d6fcc8cc5544
digest sha256:8f43bff7fad16300e6eb534cbacda4f4e1969112da0be2e0997773cff77aee41
revision ca-agentready-events--0000006
run 30549409859
URL https://ca-agentready-events.jollyfield-623e719e.eastasia.azurecontainerapps.io
Chrome 150
Inspector 1.9.12
Inspector 的 Copy trace 會保存 Prompt、Tool call、input、result 與最後回答，卻不會順手替我
附上 commit、digest 和 Azure revision。這些部署資訊必須在測試前另外核對/health/version，再和起始網址、Chrome、Inspector 及模型環境放進同一份紀錄。
這張表記錄的是測試當下的部署，不是承諾這個 FQDN 永遠停在 0000006。Azure Container
Apps 後續部署新 revision 時，同一個網址會跟著流量切換；讀到文章時再查/health/version，很可能已經是新版。要查歷史部署，就回到
workflow run 30549409859；
要看當次 Agent 行為，則以本文保存的兩張 trace 為準。
少了這一步，成功畫面只能證明「某個網站曾經成功」。網址長得一樣，並不代表背後還是昨天
驗過的程式；這種靠長相認版本的方法，跟在便利商店門口認雙胞胎差不多刺激。
search_events？先開啟公開活動列表，按一次 Reset，再輸入：
幫我找台北、免費，而且適合入門者的活動。
這句話沒有提到 search_events。在 revision 0000006 的 /events，active catalog 當時
只有這支 Declarative Tool；所以這題驗證的是 Agent 會不會判斷需要使用網站能力，並把三個
條件放進正確欄位，不是比較它能否從三支 J1 Tool 裡選出第一支。
實際呼叫送出了：
{
"location": "taipei",
"level": "beginner",
"query": "",
"price": "free"
}
Tool result 回傳一場「WebMCP 入門工作坊」，最後回答裡的活動名稱、時間、地點、費用與程度
也能逐項對回 result。
圖 1：左側是公開搜尋頁，右側保留 Prompt、Tool 名稱、input、result 與最後回答。測試過程沒有手動指定 Tool。
這題在題庫裡叫做 SEL-01。它證明的是：在這個 release、瀏覽器與固定 Prompt 下，Agent
自行決定使用 search_events，而且沒有漏掉使用者說出的篩選條件。
範圍就到這裡。換一種問法、加入相對日期，或要求 Agent 自行放寬條件，都要另外測；一題
通過不能直接替所有搜尋句型蓋章，也不能拿來證明後來才完成的多 Tool Journey。
接著我開啟活動詳情頁：
/events/evt-webmcp-intro
按下 Reset 後輸入：
請整理我現在看的活動名稱、地點、時間與剩餘名額。
Agent 這次選中 get_event_details，實際呼叫是：
AI calling tool "get_event_details" with {}
這個 {} 不是漏填，也不是 Inspector 把參數吃掉了。revision 0000006 的詳情 Tool 已經
從目前 route 取得 evt-webmcp-intro；當時的 schema 仍保留一個選填 event_id，但 Agent
可以不提供欄位，直接使用頁面 context。
若硬塞另一個 ID，Tool 會因目前 route 與輸入目標不一致而拒絕。要查看別場活動，應先前往
那場活動的詳情頁；不能留在這一頁，把 route-bound Tool 當成任意活動查詢器。
Tool result 回傳 2027 年 1 月 23 日、台北前端共學空間與剩餘 8 名，最後回答也逐欄一致。
圖 2：Agent 用空物件呼叫 get_event_details，網站再從目前詳情 route 提供正確活動 context。
這題叫 SEL-02。它不只驗證 Agent 選對 Tool，也驗證當時的契約有把瀏覽器已知的頁面 context
用起來，而不是逼模型重新猜一次。
SEL-02 在 0000006 使用 {} 成功，不代表「選填 event_id」就是最終設計。後面的錯誤
復原測試很快暴露另一種行為：模型沒有省略欄位，而是送出 {"event_id": null}。請求還沒
碰到預期的暫時失敗，就先被 input validation 擋下來。
因此，後續 revision 0000008 把同名 Tool 拆成兩個明確的 route profile：
/events
get_event_details({ "event_id": "evt-webmcp-intro" })
→ 列表頁要求搜尋結果提供的 opaque ID
/events/evt-webmcp-intro
get_event_details({})
→ 詳情頁只接受空物件，目標由 route 綁定
同一版也讓 /events 同時公開 search_events、參數化的 get_event_details 與save_event，補上 search → details → save 的合法同頁 handoff。save_event 雖然看得見，
仍會檢查目前畫面顯示的活動是否和輸入 ID 相同，不能跳過詳情直接收藏。
這才是系列最後採用的產品契約，但它不會穿越回去改寫今天的兩份 trace。SEL-01 與 SEL-02
仍然只替 revision 0000006 作證：前者在只有搜尋 Tool 的列表頁完成一次自然語言搜尋；
後者在仍含選填欄位的詳情 schema 中，正確使用 {} 讀取目前活動。
這兩題跑完後，我會再回頭檢查四件事：
/health/version 是否對得上固定 commit、digest 與 revision；只留下最後回答不夠，因為模型可能碰巧說對；只有 Tool result 也不夠，因為 Agent 最後可能
整理錯。完整 trace 的價值，就是讓讀者能看見答案到底在哪一段開始偏掉。
版本也必須算進 trace 的上下文。同一句 Prompt 在 0000006 與 0000008 面對的 catalog
不同，不能只因 Tool 名稱一樣，就把兩次執行當成同一份契約。
0000006 的唯讀呼叫作證SEL-01 與 SEL-02 都在 revision 0000006 通過。依前面定義的證據分級，這兩題可以列為
E4：真正的 Agent 在公開 HTTPS 網站上，從自然語言自行選擇並呼叫 WebMCP Tool，而且完整
trace 能對回固定部署版本。
這仍然不是 E5，也不是整個網站的通行證。今天只重播兩個唯讀任務，沒有串成完整的
「搜尋 → 查看詳情」多步驟 Journey，更沒有碰收藏、報名或取消。後來的 0000008 雖然
補上三支 Tool 的同頁 Journey，也必須使用自己的 trace 重新驗收，不能借用今天的兩張綠色
結果代考。
明天就要進入比較容易留下後遺症的路徑：收藏能不能重複執行而不多生一筆資料，報名與取消
又會不會真的停在人類確認之前。到了那裡，Agent 最後說「完成」反而不是第一個要看的地方；
我會先盯著 UI、audit trail 與副作用到底發生了幾次。
iThome鐵人賽
看影片追技術