WebMCP 讓網站向 AI 代理暴露結構化工具：告別 DOM 猜測，Chrome 149 源碼試驗開跑

重點摘要

瀏覽器裡的 AI 代理，長期靠「看畫面、猜按鈕」完成下單、填表、預約。一改 class 名稱、跳出一個 modal，流程就容易斷。Google Chrome 開發者文件確認，WebMCP 是一項仍在討論中的擬議網頁標準，目標是讓網站用 JavaScript 與 HTML 標註，向代理註冊可呼叫的結構化工具，由頁面本身執行既有邏輯，而不是靠代理反覆解析 DOM。本文已對照 Chrome for Developers 官方說明與公開技術報導核實，重點整理其機制、與伺服器端 MCP 的分工，以及對香港企業與開發者的含義。

WebMCP 讓網站向 AI 代理暴露結構化工具：告別 DOM 猜測，Chrome 149 源碼試驗開跑

WebMCP 讓網站向 AI 代理暴露結構化工具：告別 DOM 猜測，Chrome 149 源碼試驗開跑

瀏覽器裡的 AI 代理，長期靠「看畫面、猜按鈕」完成下單、填表、預約。一改 class 名稱、跳出一個 modal，流程就容易斷。Google Chrome 開發者文件確認，WebMCP 是一項仍在討論中的擬議網頁標準，目標是讓網站用 JavaScript 與 HTML 標註，向代理註冊可呼叫的結構化工具，由頁面本身執行既有邏輯，而不是靠代理反覆解析 DOM。本文已對照 Chrome for Developers 官方說明與公開技術報導核實，重點整理其機制、與伺服器端 MCP 的分工，以及對香港企業與開發者的含義。

一、核心事件：從「猜介面」到「呼叫工具」

技術細節

據 Chrome 文件（Alexandra Klepper，2026 年 5 月 18 日刊出、2026 年 8 月 7 日更新），WebMCP 要解決的是 agent actuation 的可靠度：代理不再只靠檢視按鈕或欄位來「理解」用途，而是由網站明確宣告工具用途與輸入輸出。標準支援三類能力：

  1. Discovery：頁面以標準方式註冊工具，例如 checkout、filter_results。
  2. JSON Schema：明確定義輸入與預期輸出，降低幻覺與誤用。
  3. State：代理與頁面共享當前脈絡，知道此刻可對哪些資源採取行動。

Chrome 自 149 起提供 WebMCP origin trial；本機開發亦可在 chrome://flags/#enable-webmcp-testing 開啟測試旗標後重啟瀏覽器。工具註冊受 origin isolation 與 Permissions Policy 的 tools 政策約束（預設 self），跨來源 iframe 需額外 allow="tools"。

API 有兩條路徑：

  • Imperative：以 JavaScript（例如 document.modelContext.registerTool）註冊工具與 execute 回呼，直接重用站內既有函式。
  • Declarative：在標準 HTML 表單加上標註，由瀏覽器合成 schema，門檻較低。

Chrome 亦提供 Model Context Tool Inspector 擴充功能，方便列出已註冊工具、手動呼叫並檢查 schema。文件強調：WebMCP 主要面向「人在迴路」的本機瀏覽器工作流程，而非把無頭環境當成首要場景。

公開技術報導指出，產業端已出現早期採用與實驗：Shopify 商店、Cloudflare 儀表板切換、OpenAI 以「site tools」名義在 ChatGPT 桌面內建瀏覽器接通 WebMCP，以及 Brave Nightly 對 Leo 助理的測試。規格本身仍屬社群草案，細節可能變動；上述產品整合屬報導所述進展，實作前仍應以各廠商文件與 Chrome Status 為準。

二、技術原理深度解析

把代理行為拆開，現行常見路徑是：截圖或 DOM 觀察 → 語言模型推論下一步 → 模擬點擊／輸入 → 再觀察結果。每一步都消耗 token，且對 UI 變動敏感。WebMCP 把「可做什麼」收成契約：代理讀工具名稱、描述與 schema，呼叫一次；執行發生在使用者已登入的分頁內，站點沿用自己驗證過的前端程式，結果以結構化形式回傳。

這與伺服器端的 Model Context Protocol（MCP） 互補而非取代。Chrome 文件脈絡下，MCP 適合在任意環境提供後端工具；WebMCP 則活在瀏覽器分頁，重用頁面狀態與使用者工作階段。實務上，旅遊站可同時用 WebMCP 處理介面操作，再用 MCP 查庫存。

安全面同樣是設計重點。Chrome 以來源隔離與 permissions policy 限制註冊範圍；敏感操作（例如付款）可要求使用者確認對話框。學術與產業討論亦提出工具描述／輸出中的提示注入、跨信任邊界的歸因與生命週期問題——這提醒產品團隊：暴露工具等於擴大攻擊面，需要分級（唯讀、可逆、需確認）與稽核，而不是「全部開放給代理」。

對開發者而言，成本結構也在改變：少做反覆 DOM 讀取，理論上可降低觀察迴圈的延遲與 token；但複雜介面仍可能要重構狀態管理，才能穩定暴露工具。規格未定稿、瀏覽器支援仍集中在 Chrome／相關試驗生態，亦是現階段評估門檻。

三、日常應用場景

1. 開發者與技術團隊

可先為除錯頁、內部控制台註冊 run_diagnostics 這類工具，讓代理在嵌套選單裡少走冤枉路；或以表單宣告式 WebMCP，把既有申請／預約流程變成可測的 agent surface。Chrome DevTools／Inspector 擴充可驗證代理「看到」的工具清單是否與預期一致。

2. 企業與隱私敏感行業

金融、法律、醫療若已在香港部署私有模型與代理編排，WebMCP 的價值在於：代理操作發生在使用者瀏覽器工作階段內，站點仍掌控業務邏輯與確認閘門，較易對齊內部合規流程。重點不是「讓代理自由點遍全站」，而是只暴露經審批的工具，並把後果性操作留在人工確認。

3. 一般用戶

支援工單、多城邦旅行預訂、複雜日期選擇等流程，理論上可由代理填對欄位、少點錯按鈕；使用者仍應能在分頁中看見執行過程並中斷。規格與產品實作仍在演進，現階段宜視為可觀察的試驗能力，而非全面取代人工操作。

4. 香港與亞洲市場視角

香港企業網站大量仍是「為人設計」的表單與後台，短期內不易全部改寫成純 API。WebMCP 若成為瀏覽器層標準，有機會讓長尾站點在不大改後端的前提下，對 AI 代理變得可呼叫。本地團隊若已評估私有 LLM、客服代理或內部流程自動化，可把「哪些動作可註冊成工具、哪些必須人審」納入產品 backlog，並同步留意 Chrome origin trial 與 W3C／社群討論進度。

四、專業評價與潛在考量

優勢

  • 把脆弱的視覺／DOM 推測，換成站點宣告的工具契約，執行路徑更可預期。
  • 與 MCP 分工清楚：後端能力走 MCP，瀏覽器內工作階段走 WebMCP。
  • 人在迴路、可見執行，有助品牌流程與信任；權限政策與來源隔離提供基礎防護。

需要留意的地方

  • 規格仍是擬議標準，API 命名與行為可能調整；生產依賴需跟 Chrome Status 與各瀏覽器時程。
  • 工具描述與回傳內容可成為提示注入載體；跨框架／多來源場景需要額外硬化。
  • 無頭、大規模批次自動化未必是首要設計目標；Firefox／Safari 等時程仍不明朗時，覆蓋率要保守評估。
  • 公開報導中的效能倍數與個別廠商整合細節，未必寫進官方規格——對外溝通應分開「標準能力」與「某產品實驗」。

結語

WebMCP 要回答的問題很具體：當 AI 代理開始代勞網頁任務，網站要不要用標準方式「說清楚自己會做什麼」。Chrome 149 的源碼試驗、文件化的 imperative／declarative API，以及產業端的早期試驗，顯示方向已從截圖點擊，轉向可發現、可驗證的工具介面。對香港團隊而言，下一步通常不是一次改完全站，而是選出高頻、低風險的唯讀與可逆操作先註冊，把後果性動作留在確認閘門之後。

若企業需要在香港境內編排私有模型與代理工作流，並把瀏覽器內工具與後端系統接好，可參考 YSK Limited 的企業私有 LLM 全託管（Dataset → QLoRA/LoRA → 私有 API，年費 HK$88,000 起，強調數據不出境）：https://ysk.hk/services/ai-automation 。亦可以 WhatsApp +852 6160 4242 或 [email protected] 討論代理與站點工具面的落地範圍。

參考來源

延伸閱讀 · 相關服務與產品

相關文章