WebMCP 落地 Chrome 149：網站對 AI 代理人說話，不再是猜謎遊戲

Chrome 團隊在 2026 年 5 月 21 日 Google I/O 開發者主題演講中確認 WebMCP origin trial 開啟，二十四小時之內，實作指南就在 Hacker News、X、以及我關注的每一個前端 Discord 上開始流傳。機制不複雜，影響不小。從 Chrome 149 開始，你的網站可以宣告一組結構化工具——以 JavaScript 函式、加上有註解的 HTML 表單為主——讓住在瀏覽器裡的 AI 代理人（首發是 Gemini Spark，其他生態系會跟上）直接呼叫。代理人不再猜像素。網站直接回答。

如果你在 2026 年還在公開 web 上出貨，唯一正確的動作是這個週末把規格讀完，下週在 staging 分支試做一個工具暴露點。下面是這個標準實際做什麼、為什麼比你看到的標題更重要、以及禮拜一該蓋什麼。

一、WebMCP 到底是什麼（三句話）

WebMCP 是仿照 Anthropic Model Context Protocol 設計的提案中開放 web 標準，讓網站可以對瀏覽器內任何 AI 代理人宣告「可被機器呼叫的工具」。工具透過兩個表面暴露：一個是命令式 JavaScript API（navigator.modelContext.registerTool(...)），對應搜尋、過濾、購物車操作這類動態行為；另一個是宣告式 HTML 註解（<form data-mcp-tool="checkout">），對應網站本來就有的表單。代理人讀工具註冊表，依照使用者意圖挑出正確工具，用結構化參數呼叫，把結果回報給使用者——不需要任何螢幕擷取。

二、「不需要螢幕擷取」這件事改變一切

過去兩年，「AI 代理人 + web」這個故事的版本一直是 computer-use 的各種變體：代理人擷取螢幕、丟給模型辨識正確按鈕、點像素、等頁面 settle、再擷取一次、重複。慢、脆、行銷一改 hero 圖就壞掉。更糟糕的是不安全——代理人沒辦法知道它剛剛送出的表單，是聯絡表單還是轉帳授權。

WebMCP 把這套換成一份契約。網站說：「這是我支援的動作、每個動作要哪些參數、回傳的結構長這樣。」代理人讀完契約、呼叫動作、拿到結構化回應。互動更快（一次函式呼叫 vs. 一輪螢幕擷取）、更可靠（不用找像素）、安全性顯著提高（代理人不能呼叫網站沒宣告的工具）。這禮拜在流傳的早期 benchmark 顯示，在同一頁面上，WebMCP 啟用站 vs. 視覺式代理人，端到端任務完成速度快 8 到 12 倍。

三、你實際會實作的兩個工具表面

命令式路徑長這樣：你 import navigator 擴充、用 JSON schema 註冊工具的輸入、提供一個 handler 做你原本既有的 JavaScript 在做的事——打 API、改狀態、回傳結果。Handler 在頁面正常的安全環境內執行，權限跟使用者一樣。使用者登入了，代理人就以使用者身分行動；沒登入，就不行。

宣告式路徑更短。任何既有表單只要加一個屬性——data-mcp-tool="newsletter-signup"——再加兩三個 data-mcp-description 字串，Chrome 就自動把它註冊成可呼叫工具。對於本來就有良好語意 HTML 的網站，這常常只是「半小時就能讓網站上每個有意義的動作對所有瀏覽器內代理人開放」。

四、這禮拜看到漲幅最大的三種模式

origin-trial 合作夥伴的早期生產資料指向三個贏的模式。把「搜尋」做成單一工具的網站，長尾搜尋流量在一夜之間從 Google 移到 Chrome 內代理人呼叫——代理人替特定意圖挑了更對的工具，沒有把使用者推回搜尋引擎。把結帳做成宣告式表單的網站，在代理人主導的 session 裡放棄購物車比例下降：代理人填表、使用者確認、交易在 Chrome 內完成。把「過濾」做成工具的網站（房屋平台、求職板、商品網格）回報，代理人在執行使用者根本不會自己打進搜尋框的多條件查詢。

模式是一致的。會贏的工具，是「包住一個具名的使用者意圖」——「幫我訂閱 X」、「給我看 Y」、「買 Z」——並回傳一段代理人能總結出來的結構化結果。

五、必須做對的資安表面

兩個真實風險。第一是透過工具描述的 prompt injection：如果你的工具描述含有攻擊者可控的文字（例如使用者產生內容），代理人可能把那段文字當成指令照辦。把工具描述當 HTML 一樣去 sanitize，絕對不要把不受信任的字串直接內嵌到工具註冊表。第二，交易層級的工具（任何花錢、改變所有權、發送訊息的工具）必須明確要求一次使用者確認步驟。WebMCP 透過工具定義上的 requiresUserApproval: true 旗標支援這件事；對所有財務、身分、破壞性工具，把它當成強制必填。

Chrome 團隊文件強調 WebMCP 跑在網站既有的 same-origin sandbox 之內——沒有額外的權限提升。但也沒有額外的保護來擋住「開發者自己沒搞懂就把工具註冊出去」這件事。威脅模型已經從「我的 UI 能做什麼」變成「一個有心的代理人，能用我的 UI 的 API 做到什麼」。請把工具目錄當成一個公開 API 表面去建——因為 WebMCP 把它變成那個。

六、這禮拜該出貨什麼

實際可執行的七天計畫：

禮拜一： 讀完 developer.chrome.com 的 WebMCP 文件。在一台 staging 機上啟用 Chrome 149 dev channel。打開 origin-trial flag。
禮拜二到三： 從網站挑一個高價值動作（搜尋、過濾、註冊），用命令式 API 暴露。寫清楚輸入與輸出的 JSON schema。
禮拜四： 把網站上「不需要破壞性確認」的每一個表單，加上 data-mcp-tool 宣告式註解。每張表單 8 分鐘。
禮拜五： 用 Gemini Spark 或任何支援 WebMCP 的代理人測。記下代理人哪裡卡住；幾乎每一個卡住的點都可以用更好的工具描述修掉。
下週： 申請 origin-trial token。掛在 token 後面推到 production。對既有分析資料比對代理人呼叫量。

我的觀點

WebMCP 真正有意思的地方不是技術——它是一層薄薄、範圍清楚的表面，疊在 web 早就支援的模式上。真正有意思的是它把網站推到的策略位置。2026 上半年的問題一直是：「我們要怎麼避免 AI 代理人因為點錯按鈕把我們的網站搞壞？」Chrome 149 之後，問題變成：「我們要怎麼讓代理人偏好用我們的網站？」

六月底把這件事做對的網站，七月會是代理人預設選用的那個。等規格穩定再說的網站，第四季會花時間跟管理層解釋，為什麼 ChatGPT、Gemini、Claude 一致推薦的是競爭對手 X，自家目錄被忽略。WebMCP 是一週的實作，補的卻是一年級的策略缺口。排進行事曆。

給 PHP / Laravel 團隊：同一個 Laravel controller 用五行條件 rendering，就能同時服務「人類的 HTML 路由」和「WebMCP 的工具端點」。不需要另一份 codebase。工具成本實質上是零。略過的競爭成本不是。