Day 01｜網站真的會被 Agent 使用嗎？我先丟了一句自然語言

本文同步自 2026 iThome 鐵人賽原文 ，發布日期為 2026-08-03。完整系列可見 iThome 系列頁 。

安安～我是ChiYu～

今年我想拿一個很新的 Web API，做一件很老派的事：實際把它做完，再看看它到底有沒有 簡報上那麼神。

我先對 WebMCP Inspector 丟了一句很普通的需求：

幫我找台北、免費，而且適合入門者的活動。

沒有 Tool 名稱、沒有 JSON，也沒有先替 Agent 把答案圈起來。幾秒後，Inspector 的 黑色 trace 裡冒出 search_events，taipei、free、beginner 也各自跑進正確欄位。

最後找到的是「WebMCP 入門工作坊」。答案本身沒有特效，活動卡片也沒有突然旋轉三圈； 真正讓我停下來看的，是答案出現以前，網站和 Agent 到底交換了什麼。

圖 1：左側是活動搜尋頁，右側 Inspector 保存了 User prompt、Tool call、input、Tool result 與 AI result。先別只看最後一段回答，真正的線索都在前面。

這一幕很接近我想像中的「網站終於會說話」。但工程師看到成功畫面的習慣，通常不是立刻 開香檳，而是先問一句：真的假的？

網站原本就有表單、按鈕和 REST API，為什麼還要多一層 WebMCP？Agent 是真的理解了 「搜尋活動」，還是剛好猜中某個可以呼叫的函式？更麻煩的是，搜尋選錯頂多找不到活動， 報名與取消如果也一路自動到底，事情就已經超出 Demo 好不好看的範圍。

圖 1 把這些前提全部藏在一張成功畫面裡。只截最後答案，很容易寫成「裝好 Inspector， Agent 就會操作網站」；這種文章大概五分鐘能看完，也會讓人五分鐘後完全不知道系統為什麼 能動。

所以今天先把完成版端上桌，但不准它直接畢業。後面 29 天，我會把這張圖拆開，逐一 補回人類流程、Tool contract、安全停點、部署版本和失敗紀錄。成功要留下，翻車也不能 偷偷掃到地毯底下。

WebMCP 如何讓 Agent 知道網站能做什麼？

WebMCP 的完整名稱是 Web Model Context Protocol。它是一項正在發展中的 Web API，也是一份 proposed web standard，目標是讓 網站把功能整理成結構化 Tool，提供給瀏覽器裡的 AI Agent 使用。

如果只記一句話：WebMCP 是網站寫給 Agent 的「能力說明書」。它告訴 Agent 這個頁面 能做什麼、需要哪些輸入、會回傳什麼，以及做到哪一步必須停下來等人類確認。

這裡的 Model Context 不是把整張網頁、所有 cookie 和聊天紀錄一口氣塞給模型。以 WebMCP 的核心用途來說，context 主要是目前 Document 願意公開的 Tool definition： 名稱、用途、輸入格式、執行方式與行為提示。網站自己決定哪些能力可以被看見。

這句話有幾個主角，先排好位置：

• 網站決定要公開哪些任務，並實作 Tool。
• Document 保存目前頁面的 Tool context。
• 瀏覽器或 Agent Host 負責把 Tool 提供給 Agent。
• Agent 讀取使用者需求，選擇 Tool、準備 input，再根據 result 回答。

WebMCP 要處理的，是「Agent 怎麼知道網站能做什麼」。沒有這層契約時，Agent 通常只能 觀察畫面，模擬點擊、輸入和捲動。這種方式不是不能用，但它得從 DOM、按鈕文字、頁面 排列和目前狀態一路猜。按鈕從「搜尋活動」改成「探索場次」，人類可能毫無感覺，依賴 文字定位的 automation 卻可能當場迷路。大後天開始，我會花兩天親手讓它迷一次。

WebMCP 沒有把畫面拿掉。人類照樣使用原本的 HTML、表單與按鈕；支援 WebMCP 的 Agent 則多拿到一份比較明確的任務說明。 Chrome 官方的 WebMCP 說明 把這種作法定位成 progressive enhancement：瀏覽器不支援時，網站仍然是正常網站， 不會退化成一張「請改用 AI 開啟」的告示牌。

WebMCP Tool 會告訴 Agent 哪些資訊？

WebMCP Tool 不是單純把 JavaScript function 名稱丟給 Agent。以 Imperative API 為例， 一份 Tool definition 會包含：

名字和 description 幫 Agent 判斷「要不要選它」，schema 管的是「參數怎麼填」， execute 才負責「選中以後真的做什麼」。把三件事混成一句「這支 Tool 可以搜尋」， Agent 猜錯時就很難知道該修名稱、schema，還是商業邏輯。

以活動搜尋為例，人看到「地點」「費用」「程度」和「搜尋活動」，大概就知道要怎麼填； Agent 取得的則是一份明確契約：

Tool name    search_events
用途         依條件搜尋公開活動
input        location、price、level、query
result       活動 ID、名稱、時間、地點與詳情網址

從一句自然語言到 Tool result，中間怎麼走？

拿開頭那句「幫我找台北、免費，而且適合入門者的活動」來看，一次呼叫大致會走過這條 路：

使用者自然語言
    ↓
瀏覽器中的 Agent 觀察目前 Document 公開的 Tool
    ↓
選中 search_events，依 inputSchema 組出參數
    ↓
網站執行 Tool callback，沿用既有 action／REST API／server validation
    ↓
Tool result 回到 Agent，Agent 再整理成最後回答

Tool 活在頁面的 Document context 裡。Imperative Tool 會透過 document.modelContext.registerTool() 註冊；瀏覽器 Agent 如何取得並交給背後模型， 則由瀏覽器實作決定。規格沒有要求一定得使用 MCP wire protocol，也沒有規定只能接某個 模型。

這條流程也不會把模型變成 deterministic。名稱、description 和 schema 寫得清楚，能讓 Agent 少猜一點；同一句 prompt 仍可能因模型、context 或工具選擇而得到不同結果。 WebMCP 提供的是比較可控、可追查的互動介面，可靠度還得靠 eval、trace 與失敗案例驗證。

原本的 client action、REST API、session 和 server validation 都還在。WebMCP 不會 因為名字很新，就順便幫我們重寫商業邏輯；它補的是一個任務入口，讓 Agent 不必從畫面 猜測「這顆藍色按鈕可能可以做什麼」。

所以先把三個常見誤會收掉：WebMCP 不是新的 AI 模型，不會自己理解整個網站；它不是 REST API 的替代品，不會接管既有資料交換；它更不是權限捷徑，不能因為 Agent 選對 Tool 就繞過 session、CSRF 或商業規則。它做的事很專一：把網站願意提供的任務，變成 Agent 比較不需要猜的結構化契約。

這也說明 WebMCP 和 REST API 的分工。REST API 處理資料交換與 server operation； WebMCP Tool 描述的是使用者任務，執行時可以呼叫原本的 API。前者不用為了迎接 Agent 全部重寫，後者也不能繞過原有驗證直接摸資料庫。

用 HTML 表單或 JavaScript 公開 Tool

實作上有兩條路。 Declarative API 可以替既有 HTML form 加上 toolname、tooldescription 等註解，表單欄位會被整理成 Tool parameters，很適合搜尋這類原本就有表單的任務； Imperative API 則用 JavaScript 動態註冊能力。像 get_event_details 只該出現在活動詳情 route，進頁面時註冊，離開時 就該下班。前面的地基打穩後，我會各做一個最小 Lab；今天先不用把兩套 API 全塞進來 嚇人。

名字裡雖然有 MCP，先別急著多申請一台主機。WebMCP 不要求網站另外架設 MCP Server； 它的能力跟著目前頁面、route 與使用者正在看的內容存在。MCP Server 則由 client 建立 連線，可在頁面之外提供服務。兩者可以一起使用，並不是誰要把誰趕下班。再過幾天，我會 把兩者攤開比較。

Tool 只描述能力，權限仍由網站與 Server 把關

網站宣告某支 Tool 是唯讀，不代表 server 就可以相信它永遠不會寫入；description 寫著「只收藏活動」，也無法保證 callback 沒有偷偷做別的事。規格裡的 annotations 是給 Agent 判斷的 metadata，不是 authorization。

真正的 session、CSRF、ownership、輸入驗證與商業規則，仍然要由網站和 server 執行。 Chrome 的 WebMCP 安全指引 也把 prompt injection、敏感資料、參數驗證與高風險操作列為實作時必須面對的問題。報名、付款、 刪除或取消這類有副作用的操作，需要清楚的人類確認點。WebMCP 可以讓 Agent 走到門口， 不能因為 Tool 名稱取得很有禮貌，就順便把門鎖拆掉。

這也是本系列刻意把 prepare_event_registration 和 prepare_registration_cancellation 命名成 prepare 的原因：Agent 可以填資料、整理 影響並開啟確認畫面，最後送出仍留給人類。

WebMCP 還在實驗期，別把能測試寫成已普及

有件事要先踩煞車。WebMCP 目前是 W3C Web Machine Learning Community Group 發布的 Draft Community Group Report，還不是正式 W3C Standard。Chrome 也把它放在實驗功能 裡，本機測試需要啟用 WebMCP for testing flag。

document.modelContext 也屬於 Secure Context API。公開環境應使用 HTTPS，網站還能透過 Permissions Policy 限制 Tool 暴露的 origin。能被 Agent 看見以前，瀏覽器這一層也有 自己的門禁。

換句話說，現在很適合實驗，不適合把「我這裡能跑」寫成「所有瀏覽器都已支援」。這條 界線後面會一直出現，因為新技術最容易在成功截圖旁邊突然長出過度自信。

網頁公開 Tool，也不代表任意聊天機器人都能直接呼叫，中間仍需要支援這項能力的瀏覽器 或 Agent Host。本系列使用 Chrome、WebMCP Inspector，以及 Inspector 整合的 Gemini 測試 Agent，分別觀察 discovery、手動執行與自然語言 invocation。三種畫面長得很像， 證明的事情可不一樣。

讀 Inspector trace：Agent 選對 Tool，也填對參數了嗎？

回到剛才那句搜尋。我先跳過最後回答，直接看 Inspector 留下的 input：

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

使用者輸入的是中文，Tool 收到的卻是 taipei、free 和 beginner。這些值來自 Tool contract。Agent 得先從目前頁面的 catalog 選中 search_events，再把「台北、 免費、入門者」翻成網站吃得下的 input。Tool 選對但參數亂填，一樣不算會做事。

所以我把 prompt 和 input 逐欄對照：

參數沒有偷放寬，我才繼續往下看 Tool result。網站回傳一筆活動，裡面有固定活動 ID、 相對網址、名稱、開始時間、地點、費用與程度。最後回答提到的「WebMCP 入門工作坊」、 台北、免費與入門，都能在 result 找到來源；詳情連結也沿用網站回傳的 /events/evt-webmcp-intro，沒有現場發明一條看起來很像真的網址。

這裡如果只驗活動名稱，很容易被綠燈騙走。Agent 可能選對 Tool，卻偷偷放寬使用者條件； 也可能拿到正確 result，最後回答時又改錯日期，或補上網站根本沒提供的資訊。答案讀起來 越順，不代表它越老實。

如果我在 Inspector 下方手動挑 search_events，再自己貼上 JSON，那等於考試前先幫 Agent 把答案圈好。這只能證明 Tool 可以執行，不能證明 Agent 會選。

這次 trace 多了最重要的前半段：自然語言進來後，Agent 自行選擇並呼叫 search_events。

整條 trace 應該能一路對回五件事：User prompt、Tool call、input、Tool result 和最後 回答。少看任何一段，都可能把「剛好答對」誤認成「整條鏈路可靠」。

Agent-ready 網站的背後，UI、Tool、Agent 與人類各有責任

我原本很容易把圖 1 簡化成「Agent 會操作網站」。真的往下拆，才發現至少有四層責任 疊在一起：

• 人類 UI 要先能用。沒有 WebMCP，人仍然可以搜尋、閱讀、收藏與填寫表單。
• 網站用 Tool 說清楚自己願意提供哪些任務，而不是把所有內部函式端出去。
• Agent 負責從自然語言選 Tool、組 input，再根據 result 回答。
• 報名與取消的最後決定要回到人類看得見、按得到的畫面。

其中任何一層偷懶，最後答案都可能看起來正常。這也是 Agent 類功能最麻煩的地方：畫面 很會演，責任邊界不一定有跟上。

AgentReady Events 最後留下五個 Tool：

我沒有把每顆按鈕都包成一支 Tool。那樣 catalog 看起來很熱鬧，Agent 也會多五次猜錯 的機會。每支 Tool 都要代表一個完整任務，說清楚輸入、結果，以及走到哪裡必須停下來。

圖 2：首頁把五個 Tool、三條使用者 Journey 與人類停點放在同一張畫面。收藏可以完成，報名與取消則必須停在最後確認以前。

這張圖真正要看的是右邊的人類停點。網站願意讓 Agent 幫忙，不代表連決定權也一起 打包寄出去。

先看完成版，再回頭補齊 30 天的實作地基

圖 2 是整個系列完成後的網站，不是今天要從頭實作的起始版本。照一般教學順序，我也可以 先寫 Hello WebMCP，接著介紹 schema，再慢慢走到產品。技術上沒有問題，閱讀體驗大概 會像先看二十頁螺絲規格，最後才知道我們要組一台腳踏車。

所以今天先看終點，讓大家知道這些地基最後要撐住什麼。但這張完成圖暫時只能當預告， 不能當結論。明天會回到還沒有 WebMCP Tool 的最小可執行版本；人類流程、Tool contract、安全邊界和真實 Agent trace，都得重新一層一層補回來。

圖 3：先看一次完成後的使用方式，再回頭打地基。中段每完成一項能力就立刻留下測試，不等到快結尾才突然宣布 Agent 可以用了。

這 30 天不會一路加功能。每一段都要產出下一段用得到的證據：

search_events 通過，不代表另外四支 Tool 也過關

search_events 這次成功，能證明的事情很具體：在當時保存的版本、頁面、prompt 與 Agent 環境裡，確實發生過一次自然語言選擇與呼叫。

句號應該先停在這裡。它沒有順便替另外四支 Tool 通過驗收，也不能保證換一個 Chrome profile、模型或日期後仍會得到相同結果。成功畫面很容易膨脹，工程證據最好不要。

後面每一題都會用同一個最小單位保存：明確任務、Tool call、input、result 和最後回答。 成功照原樣留下，失敗也一樣。只有這樣，幾天後回頭看才知道是網站進步了，還是截圖角度 變好了。

回到開頭那句搜尋，現在我們已經知道它不是一句 Prompt 配一個漂亮回答。中間還站著 網站契約、Agent 選擇、結構化 input、可追溯 result，以及不能越過的人類權限。

但目前所有東西都擠在一張完成圖裡，還看不出哪些是必要地基，哪些只是我電腦上的幸運。 明天先把完成版收起來，從固定 tag 取得一個還沒有 WebMCP Tool 的基本網站。第一個問題 很樸素，也比 Agent 會不會選 Tool 更早發生：離開我的電腦後，你能不能把同一個網站、 API、測試與 build 跑起來？