WebMCP:當網站不再需要被「看」,而是被「呼叫」 Web 標準

重點摘要:Google 與 Microsoft 在 2026/2/10 共同發布 WebMCP(Web Model Context Protocol),一個讓網站主動向 AI Agent 宣告「我能做什麼」的 W3C 提案標準。不再截圖猜按鈕,改為結構化工具呼叫。兩種整合方式:HTML 表單加屬性(Declarative)或 JavaScript API navigator.modelContext(Imperative)。Chrome 146 Canary 已可試用。這可能是 Web 自 REST API 以來最重要的互動範式轉變——網站從此有兩個介面:一個給人看,一個給 AI 呼叫。

一個問題:AI Agent 是怎麼「用」網站的?

你有沒有看過 AI agent 操作網頁?它的流程大概是這樣的:

1. 對網頁截圖
2. 把截圖丟給 vision model
3. Vision model 標記出所有 UI 元素(按鈕、輸入框、連結...)
4. 猜測「訂票」按鈕在哪個座標
5. 模擬點擊那個座標
6. 等頁面載入,再截一次圖
7. 重複以上步驟...

這個方法有三個致命問題:

  • :每個動作都要截圖 → 上傳 → 視覺辨識 → 回傳指令,一個簡單操作 30-60 秒
  • 脆弱:按鈕往右移 5px,agent 可能就找不到了。跑 9 次成功,第 10 次失敗
  • :高解析度截圖是大量的 token 消耗,每個動作都在燒錢

現在想像另一種方式:

網站:「嗨 Agent,我是機票預訂網站。我有這些工具:
  - searchFlights(origin, destination, date)
  - bookFlight(flightId, passengerName)
  - cancelBooking(bookingId)
  你需要用哪個?」

Agent:「searchFlights('TPE', 'NRT', '2026-03-15')」

網站:「這是結果:[{flightId: 'CI100', price: 8500, ...}, ...]」

沒有截圖。沒有猜測。沒有座標。直接呼叫函式,拿回結構化數據。

這就是 WebMCP。

WebMCP 到底是什麼?

WebMCP(Web Model Context Protocol)是一個 W3C 提案標準(Draft Community Group Report),由 Google Chrome 團隊、Microsoft Edge 團隊和 Alex Nahas(前 Amazon,MCPB 的創造者)共同開發。2026/2/10 發布 Early Preview,目前可在 Chrome 146 Canary 中試用。

核心概念用一句話:

讓網頁本身變成一個工具提供者——AI agent 訪問你的網站時,不需要「看」你的 UI,而是直接「讀」你宣告的工具清單,然後呼叫它們。

跟 MCP 是什麼關係?

如果你熟悉 Anthropic 提出的 Model Context Protocol (MCP),你可能會問:這不是一樣的東西嗎?

不一樣。它們是互補關係:

項目 MCP(Anthropic) WebMCP(Google + Microsoft)
執行位置 伺服器端(你部署 MCP server) 瀏覽器端(網頁本身就是 tool provider)
通訊協定 JSON-RPC over stdio/HTTP Browser API(navigator.modelContext
認證 需自建 OAuth/API key 繼承瀏覽器的 session cookies、SSO、RBAC
範圍 Tools + Resources + Prompts 目前只有 Tools
Agent 類型 CLI agent、桌面 agent、任何 client 瀏覽器內的 agent(需要可見的 tab)
使用場景 後端 API、headless 操作、跨平台 網頁應用、Dashboard、電商、表單
狀態管理 Stateless 或自建 state 天生帶使用者 session(cookies、localStorage)

最關鍵的差異:MCP 需要你額外架一個 server;WebMCP 讓你的網頁本身就是 server。而且它天生繼承瀏覽器的認證機制——不用重新處理登入、SSO、權限,瀏覽器已經幫你搞定了。

兩者可以同時使用:MCP server 處理後端 API 操作,WebMCP 處理前端 Dashboard 互動。

兩種整合方式

1. Declarative API — HTML 表單加兩個屬性就好

最簡單的方式。如果你的網站已經有表單,只需要加上 toolnametooldescription 屬性:

<form toolname="book_table"
      tooldescription="Reserve a table at the restaurant">
  <input name="party_size"
         tool-param-description="Number of guests" />
  <input name="date" type="date"
         tool-param-description="Reservation date (YYYY-MM-DD)" />
  <button type="submit">Reserve</button>
</form>

就這樣。WebMCP agent 訪問你的頁面時,會自動發現這個工具,推斷出 input schema,然後直接呼叫。不需要寫 JavaScript。

幾個重要細節:

  • Agent 填完表單後,預設不會自動送出——使用者仍需點「提交」。除非你加上 toolautosubmit
  • SubmitEvent.agentInvoked 告訴你的後端「這次送出來自 AI agent,不是人」
  • SubmitEvent.respondWith() 讓你回傳結構化結果給 agent(而不是導向新頁面)
  • 瀏覽器會套用 :tool-form-active CSS 偽類,讓你可以視覺化標示「AI 正在操作這個表單」

2. Imperative API — JavaScript 完整控制

複雜的多步驟互動用這個:

navigator.modelContext.registerTool({
  name: 'add_to_cart',
  description: 'Add a product to the shopping cart',
  inputSchema: {
    type: 'object',
    properties: {
      product_id: { type: 'string' },
      quantity: { type: 'number' }
    }
  },
  execute: async ({ product_id, quantity }) => {
    await cart.addItem(product_id, quantity);
    return { success: true, cart_total: cart.getTotal() };
  }
});

四個核心方法:

方法 用途
registerTool() 註冊一個工具,不影響已有工具
unregisterTool() 移除指定工具
provideContext() 替換整個工具集(狀態變更時使用)
clearContext() 清除所有工具和 context(隱私保護)

最被低估的特性:工具可以隨頁面狀態動態變化。在搜尋結果頁,agent 看到篩選和排序工具;導航到產品頁,看到加入購物車;到結帳頁,看到付款工具。工具集永遠跟當前 context 吻合,不是一次倒出所有功能。

效能與成本的巨大差距

一個實際的比較:開發者說「新增一間商店叫 Drugstore,加入護唇膏」。

指標 傳統 DOM Scraping WebMCP
完成時間 30-60 秒 ~5 秒
準確率 ~90%(UI 變了就壞) ~98-100%
Token 消耗 大量(截圖 + DOM dump) 極少(JSON schema)
計算成本 高(vision model) 低(純文字)
穩定性 UI 改版就壞 只要 tool contract 不變就穩

對單次操作來說,差距可以忍。但如果 agent 在做批量操作——處理幾百筆交易、更新商品目錄、管理 CRM 資料——這個差距就是「能用」和「不能用」的分界線。

不只是電商:B2B 才是主戰場

早期 demo 都是訂機票、買東西。但 WebMCP 最大的價值其實在 B2B:

企業 Dashboard

每個 SaaS 都有 Dashboard。分析平台、CRM、專案管理、帳務系統——全是 web-based。WebMCP 讓 agent 直接操作這些 Dashboard:「顯示所有 Q1 續約的帳戶,標記使用率低於 50% 的」。不用學 UI 在哪,用自然語言就行。

內部工具

WebMCP 的前身 MCPB 就是 Alex Nahas 在 Amazon 內部開發的。原因很現實:內部服務太多,每個都要架 MCP server、每個都要處理認證。但瀏覽器天生就有 SSO 和 session cookies——WebMCP 直接繼承,不用從頭建認證層。

財務與會計

貼上六筆信用卡交易,讓 agent 自動分類入帳。比對供應商清單。標記超過門檻的未核准發票。這些高頻、重複、context-heavy 的工作,正是 WebMCP 的甜蜜點。

安全機制

WebMCP 從設計上就是 「permission-first」

  • 瀏覽器是中介者——agent 不能繞過瀏覽器直接操作
  • 敏感操作會跳出確認:「允許 AI 訂這班機票嗎?」
  • clearContext() 可以清除所有共享的 session 數據
  • SubmitEvent.agentInvoked 讓後端區分人類和 agent 的請求
  • 工具在使用者的現有 session 中執行——agent 不需要額外登入或繞過安全 headers

現在可以試了嗎?

可以。Chrome 146 Canary 已經支援:

  1. 打開 chrome://flags
  2. 搜尋 「WebMCP for testing」,啟用
  3. 重新啟動 Chrome
  4. 安裝 Model Context Tool Inspector Extension 來檢視和測試工具
  5. 試玩 官方旅遊 Demo

目前的限制

限制 說明
需要可見的 tab 沒有 headless mode。工具呼叫需要在可見的瀏覽器 tab 中執行
只有 Tools 目前不支援 MCP 的 Resources 和 Prompts 概念
可發現性未解決 Agent 不知道哪些網站支援 WebMCP,必須先訪問才知道
UI 同步責任在開發者 Agent 透過 tool 修改狀態後,你的 UI 要自己更新來反映變化
複雜應用可能需重構 如果你的前端邏輯緊耦合 UI 操作,拆成工具會需要重構
僅 Chrome/Edge 目前只有 Chrome 146 Canary。Edge 預計跟進,Safari 和 Firefox 態度不明

為什麼說這是 Web 最重要的範式轉變?

Web 的歷史上有幾個關鍵的互動範式:

  1. 靜態 HTML(1990s)— 人讀頁面
  2. REST API(2000s)— 程式呼叫後端
  3. SPA + GraphQL(2010s)— 前端呼叫後端
  4. WebMCP(2026)— AI agent 呼叫前端

每一次轉變都讓 Web 多了一種「消費者」。WebMCP 加入的這個新消費者——AI agent——可能最終比人類使用者的請求量還大。

如果 WebMCP 成為正式標準,每個認真的 web 應用都需要有兩個介面:

你的網站
├── 給人看的:UI、動畫、設計
└── 給 AI 呼叫的:tool contract、JSON schema、結構化回傳

就像每個 web 應用今天都要考慮 SEO 和行動裝置一樣,未來你也要考慮「Agent 體驗」。而最早支援 WebMCP 的網站,會在 AI agent 時代獲得巨大的先發優勢——因為 agent 會優先使用能被可靠呼叫的網站,而不是需要截圖猜測的網站。

延伸閱讀:

參考資料

  1. Chrome for Developers, "WebMCP is available for early preview", 2026/2/10
  2. W3C Community Group, "WebMCP: Official W3C Standard for AI Agent Browser Interaction"
  3. Scalekit, "WebMCP: The missing bridge between AI agents and the web"
  4. MarkTechPost, "Google AI Introduces the WebMCP", 2026/2/14
  5. VentureBeat, "Google Chrome ships WebMCP in early preview"
  6. DEV Community, "Chrome's WebMCP Early Preview: the end of AI agents clicking buttons"
  7. Arcade.dev, "WebMCP: Making Every Website a Tool for AI Agents"(Alex Nahas 訪談)