在目前的 AI 發展趨勢中，讓 AI Agent（AI 代理人）能夠像人類一樣操作瀏覽器（例如自動訂機票、填表單）是一個核心目標。然而，過去 AI 操作網頁的方式非常低效且不穩定。Google 最近在 Chrome 149 推出的 WebMCP 標準提案（目前處於 Origin Trials 試用階段），旨在解決這個問題，為 AI Agent 提供一套標準化的通訊協定。
過去 AI Agent 操作網頁的痛點
在沒有 WebMCP 之前，AI Agent 如果想在網頁上執行動作，通常採取的是視覺與結構分析法。AI 必須下載整個 DOM（文件物件模型，即網頁的 HTML 結構）、分析按鈕的名稱、拍攝螢幕截圖，最後推算出滑鼠點擊的座標。
這種方式存在三個重大缺陷。首先是不可預測性，只要網頁版面稍微跳動（Layout Shift）或廣告延遲載入，AI 可能會點錯位置。其次是高昂的成本，將截圖與大量 HTML 傳給大型語言模型（LLM）會消耗極多 Token。最後是高延遲，影像處理與反覆的截圖分析讓操作速度緩慢。
WebMCP 的核心概念與運作方式
WebMCP 全名為 Web Model Context Protocol，它是 Model Context Protocol (MCP) 的瀏覽器版本。簡單來說，WebMCP 不再讓 AI 去猜測網頁怎麼用，而是讓網頁開發者直接告訴 AI：我的網站提供哪些功能（Tools），以及如何呼叫它們。
這就像是將網頁從一個需要 AI 觀察的視覺介面，變成了一個 AI 可以直接讀取的 API 選單。WebMCP 完全在客戶端（Client-side）運行，讓 AI Agent 能以機器友好的方式呼叫函數，而非模擬人類點擊。
WebMCP 提供的兩套實作 API
為了讓開發者方便導入，WebMCP 提供了兩種定義工具的方式。
第一種是宣告式 API（Declarative API）。開發者可以直接在現有的 HTML 表單中加入自定義屬性，例如 toolname 定義工具名稱，tooldescription 描述該表單用途。這樣 AI 看到該表單時，就能立即理解其功能並直接填寫提交。
第二種是指令式 API（Imperative API）。開發者透過 JavaScript 的 modelContext.registerTool 介面來註冊工具。這需要定義工具名稱、詳細描述、輸入參數的 Schema（結構定義）以及執行邏輯（execute 函數）。例如，你可以定義一個切換披薩配料的工具，AI 只需要傳入配料名稱與動作（增加或刪除），後端 JavaScript 就會直接處理 UI 狀態更新。
實務影響與效能提升
根據早期實作者的回饋，將傳統的截圖分析循環改為 WebMCP 工具呼叫後，LLM 的 Token 消耗量最高可降低 90%。這不僅大幅降低了運算成本，更顯著提升了操作的確定性（Determinism）與執行速度。
安全風險與開發限制
雖然 WebMCP 提升了效率，但直接將網站 API 開放給 AI 呼叫會帶來安全隱患。
首先是間接提示詞注入（Indirect Prompt Injection）。如果 AI 讀取了惡意網頁內容，可能會被誘導去呼叫敏感的 WebMCP 工具。因此，開發者應使用 untrustedContentHint 標記外部來源數據，提醒 AI 需嚴格審查；對於不修改數據的操作，則可使用 readOnlyHint 讓 AI 在無需人類確認的情況下執行。
其次是業務邏輯漏洞。如果 AI 能夠直接呼叫退款功能，但它無法判斷最新的退款政策，或者它繞過了原本由人類判斷的權限門檻，可能會導致錯誤的業務執行。因此，Google 建議開發者針對特定使用者路徑進行 AI 評估（AI Evals）。
為了確保 LLM 能高效處理，WebMCP 對描述長度有嚴格限制，例如工具名稱上限 30 字元，工具描述上限 500 字元，這強迫開發者必須撰寫精簡且明確的定義。
總結
WebMCP 將網頁操作從視覺模擬轉向 API 驅動，將 AI Agent 從一個觀察者變成了協作執行者。這不僅是效能的提升，更是 Web 開發範式的轉移：未來開發網頁時，我們可能需要同時考慮人類看到的 UI 以及 AI 讀取的 MCP 工具集。
來源：infoq.com (WebMCP Standard Proposal for Agentic Web Actuation Now Available in Chrome)
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。