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 表單加兩個屬性就好
最簡單的方式。如果你的網站已經有表單,只需要加上 toolname 和 tooldescription 屬性:
<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-activeCSS 偽類,讓你可以視覺化標示「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 已經支援:
- 打開
chrome://flags - 搜尋 「WebMCP for testing」,啟用
- 重新啟動 Chrome
- 安裝 Model Context Tool Inspector Extension 來檢視和測試工具
- 試玩 官方旅遊 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 的歷史上有幾個關鍵的互動範式:
- 靜態 HTML(1990s)— 人讀頁面
- REST API(2000s)— 程式呼叫後端
- SPA + GraphQL(2010s)— 前端呼叫後端
- WebMCP(2026)— AI agent 呼叫前端
每一次轉變都讓 Web 多了一種「消費者」。WebMCP 加入的這個新消費者——AI agent——可能最終比人類使用者的請求量還大。
如果 WebMCP 成為正式標準,每個認真的 web 應用都需要有兩個介面:
你的網站
├── 給人看的:UI、動畫、設計
└── 給 AI 呼叫的:tool contract、JSON schema、結構化回傳
就像每個 web 應用今天都要考慮 SEO 和行動裝置一樣,未來你也要考慮「Agent 體驗」。而最早支援 WebMCP 的網站,會在 AI agent 時代獲得巨大的先發優勢——因為 agent 會優先使用能被可靠呼叫的網站,而不是需要截圖猜測的網站。
- MCP:AI 的 USB-C 標準(WebMCP 的伺服器端對應)
- Google MCP:雲端巨頭擁抱 AI 代理新標準
- Claude Code Desktop 重大更新(AI agent 開發工具鏈)
參考資料
- Chrome for Developers, "WebMCP is available for early preview", 2026/2/10
- W3C Community Group, "WebMCP: Official W3C Standard for AI Agent Browser Interaction"
- Scalekit, "WebMCP: The missing bridge between AI agents and the web"
- MarkTechPost, "Google AI Introduces the WebMCP", 2026/2/14
- VentureBeat, "Google Chrome ships WebMCP in early preview"
- DEV Community, "Chrome's WebMCP Early Preview: the end of AI agents clicking buttons"
- Arcade.dev, "WebMCP: Making Every Website a Tool for AI Agents"(Alex Nahas 訪談)