安安～我是ChiYu～
昨天才把 click_blue_search_button 請出 catalog，我差點又用同一套方法，把剩下的按鈕
全部包成 Tool。
我先把網站上看得到的操作列出來：展開篩選器、切換頁籤、查看詳情、收藏、關閉 dialog、
送出報名、準備取消、確認取消。清單愈寫愈長，看起來很有進度，實際上比較像是在替 DOM
做戶口名簿。
昨天留下的 search_events 能成立，是因為「搜尋活動」本身就是使用者會提出的任務。至於
「展開篩選器」和「按下藍色按鈕」，只是目前這版 UI 完成任務的方式。把兩者混在一起，
Agent 就得先學會網站的操作零件，再猜這些零件怎麼拼成使用者真正想做的事。
活動網站剛好很適合拿來做這次取捨。同一個產品裡有唯讀查詢、可以復原的收藏，也有會占用
名額的報名與影響既有權益的取消。它不需要硬塞付款、後台或第六支 Tool，就已經能讓我們
看見不同程度的風險。
Chrome 的 WebMCP 最佳實務
建議先規劃 Tool strategy，避免功能重疊，並在能力不再可用時解除註冊。每支 Tool 都會占用
Agent 的 context；規格沒有替 catalog 設定固定上限，不代表我們可以把所有按鈕都搬進去。
我把候選操作放進同一張矩陣，先看完整任務，再看它是否值得成為 Tool：
圖 1：保留的是使用者想完成的任務；淘汰的是目前 UI 恰好採用的操作步驟。
使用者會說「幫我找台北的入門活動」，不會說「打開左側篩選器、選第三個下拉選單，再按
藍色按鈕」。後面那串只是這一版畫面的操作說明。
因此每個候選能力，我都先問下面五個問題：
| 判斷面向 | 要問的問題 |
|---|---|
| 任務價值 | 使用者能不能用一句自然語言要求這件事？ |
| 穩定性 | 頁面改版或文案調整後，這項能力仍然成立嗎？ |
| 上下文 | 必要的 route、ID、session 或狀態能明確驗證嗎？ |
| 副作用 | 它會改資料、占名額或影響使用者權益嗎？ |
| 可復原性 | 發生誤操作時，有 Undo、確認停點或補救方法嗎？ |
拿「關閉 dialog」和「收藏活動」相比就很清楚。前者只在特定畫面狀態下有意義，dialog 換個
版型，這支 Tool 可能立刻失業；後者有明確結果，也能讓使用者 Undo。兩顆都是按鈕，但只有
其中一顆承接了完整任務。
篩選後，我把 catalog 收斂成五支 Tool：
| Tool | 風險 | 為什麼保留 | 人類控制 |
|---|---|---|---|
search_events |
R0 | 唯讀搜尋，有獨立活動清單 | 結果同步更新到畫面 |
get_event_details |
R0 | 取得目前活動完整公開資訊 | route 與 opaque ID 必須一致 |
save_event |
R1 | 收藏是明確任務，重複執行安全 | 畫面顯示狀態並提供 Undo |
prepare_event_registration |
R2 | Agent 可替人準備表單，減少重填 | 最終 POST 由人類按下 |
prepare_registration_cancellation |
R3 | Agent 可先整理取消對象與後果 | 取消 mutation 由人類確認 |
這裡的 R0～R3 是本系列用來討論風險與人類停點的標籤，不是 WebMCP 官方認證等級。R0 是
唯讀操作，R1 會改變可復原狀態；到了 R2、R3，操作開始碰到名額或既有權益，Agent 能做的
事情就必須停在「準備完成」。
五支 Tool 最後組成三條 Journey：
搜尋 → 詳情 → 收藏
準備報名 → 人類送出
準備取消 → 人類確認
你會發現清單裡沒有 submit_registration，也沒有 cancel_registration。Agent 可以整理
資料、打開表單、說明影響，但最後一次 POST 或取消 mutation 必須留給人類。我刻意把這個
控制點留在人類手上。
有些操作對人類很好用，卻沒有必要升級成 Tool：
| 候選操作 | 決定 | 原因 |
|---|---|---|
| 展開篩選器 | 不做 Tool | 只是搜尋流程中的版面步驟 |
| 切換「活動／我的報名」Tab | 不做 Tool | route 或導覽已能表達目的地 |
| 展開活動卡 | 不做 Tool | 沒有獨立結果，改版後也可能消失 |
| 關閉確認 dialog | 不做 Tool | 應由人類決定保留或確認 |
| 直接送出報名 | 禁止 | 會建立名額與個人報名資料 |
| 直接取消報名 | 禁止 | 會影響既有權益，不應由 Agent 自行完成 |
「不做 Tool」不等於刪掉功能。人類 UI 繼續保留適合滑鼠、鍵盤與視覺判斷的互動；Agent
拿到的則是較穩定、能被驗證的任務介面。兩邊使用同一套產品能力，入口不必長得一模一樣。
如果我真的照按鈕做 catalog，一次搜尋可能會變成：
open_filter_panel
select_free_price
select_beginner_level
click_search_button
open_first_card
原本一次 search_events 能完成的工作，現在要連續呼叫五支 Tool。Agent 還得記住面板有沒有
打開、欄位是否已選取、第一張卡是不是剛才那一場。UI 只要換個排序，最後一步就可能打開
不同活動。
稽核紀錄也會跟著變模糊。一筆 search_events 很容易看懂使用者要求了什麼；五筆 UI 操作
只告訴我們 Agent 動過哪些零件，卻不一定說得清楚它想完成哪個任務。這種設計只是替 Browser
Automation 的步驟換上 Tool 名稱，能力邊界並沒有因此變好。
catalog 固定為五支，不代表每個頁面都要一次擠出五支：
search_events。get_event_details 與 save_event。prepare_event_registration。prepare_registration_cancellation。這樣可以縮小 Agent 當下的選擇，也避免它離開活動頁後，還拿著已經過期的 Tool 繼續操作。
專案再用 APPROVED_TOOL_NAMES 凍結正式名稱，測試也明確拒絕加入第六支 finalization Tool。
包含 catalog 與相關契約的聚焦測試共 11 項通過，但這份結果仍是 E2 harness：它證明程式與
契約一致，還不能替真實 Chrome 宣布發現成功。
今天，我沒有替網站增加任何新功能，反而把候選清單刪到只剩五支。刪完之後，每支 Tool
都能回答「使用者到底想完成什麼」，高風險操作也各自留下了人類停點。
紙上的 catalog 已經定案，下一個問題很直接：Chrome 看得到嗎？明天我會安裝 WebMCP
Inspector、啟用 testing flag，先從一片空白的側邊面板開始查起。
iThome鐵人賽
看影片追技術