Google Chrome 開發者文件與 W3C Web Machine Learning Community Group 規格顯示，WebMCP（Web Model Context Protocol）正以瀏覽器原生 API，讓網站把既有功能註冊成具名稱、自然語言說明與 JSON Schema 的「工具」，供頁內或瀏覽器內的 AI 代理呼叫。工具在用戶已登入的同一頁面執行，與應用程式共用介面與狀態，而不是另開後端 MCP 伺服器、也不是靠截圖猜測該撳哪顆按鈕。本文由 X News 話題頁發現，其後已核對 Chrome for Developers 官方文件、W3C Community Group 草案、GitHub 規格倉及 Chromium blink-dev「Intent to Experiment」紀錄。來源真實性已驗證。
須先釐清邊界：截至 2026 年 8 月 26 日，WebMCP 仍是 Community Group 草案，不是 W3C 正式標準，亦不在 W3C Standards Track。Chrome 自 149 起開放 origin trial；本地開發可開 chrome://flags/#enable-webmcp-testing。第三方流傳的「OpenAI 某人點名」、未標明出處的金句，本文一律不採用。
一、核心事件：網頁變成頁內工具伺服器
技術細節
W3C Web Machine Learning Community Group 於 2026 年 8 月 26 日更新的 Draft Community Group Report 開宗明義：WebMCP API 讓網頁把 JavaScript 功能暴露為 tools——帶自然語言描述與結構化 schema 的函式——供代理、瀏覽器內建代理與輔助科技呼叫。規格把這類頁面形容為「在客戶端腳本實作工具的 MCP 伺服器」，目標是用戶與代理在同一網頁介面協作，沿用現有應用邏輯，並維持共用脈絡與用戶控制。
規格編輯列於 GitHub webmachinelearning/webmcp 的 Bikeshed 源檔：Brandon Walderman（Microsoft）、Khushal Sagar（Google）、Dominic Farolino（Google）。這足以核實「Google 與 Microsoft 工程師共同起草」，但並不代表 Edge 已在穩定版預設開啟同一 API；本文不以未核實的瀏覽器版本表作結論。
Chrome for Developers 於 2026 年 5 月 18 日發布、8 月 7 日更新的〈WebMCP〉指南，把動機寫得很直白：與其讓代理檢視按鈕或欄位再自行解讀用途，不如由網站宣告用途。指南列出三項能力：
- 發現（Discovery）：頁面以標準方式向代理註冊
checkout、filter_results等工具。 - JSON Schema：明確定義輸入與預期輸出，降低幻覺與誤解。
- 狀態（State）：代理與頁面共用當下脈絡，知道此刻可作用的資源。
官方用例包括客服流程導航、複雜表單填寫，以及改善旅遊訂位——協助代理以較少步驟處理多城市、多乘客行程。官方示範包括 Imperative API 的 WebMCP zaMaker、Travel demo（React），以及 Declarative API 的 Le Petit Bistro。
Chromium blink-dev 於 2026 年 5 月 15 日發出 Intent to Experiment：WebMCP；5 月 18 日獲准，origin trial 桌面／Android 為 Chrome 149 至 156，DevTrial 自 146，估計穩定推出目標為 157。實驗目標寫明：評估商務與生產力場景的 API 人體工學，並收集工具使用與延遲指標。Gecko 與 WebKit 在該 Intent 中均標為 No signal。
二、技術原理深度解析
核心介面是安全上下文下的 document.modelContext（ModelContext），不是另起一套雲端協定。Chrome Imperative API 文件（2026 年 5 月 18 日發布、8 月 20 日更新）示範以 registerTool 註冊單一工具：必填 name、description，以及描述參數的 inputSchema，再配上非同步 execute 回呼。代理呼叫時，瀏覽器把結構化參數交給頁面既有邏輯；執行結果在用戶看得見的 UI 上發生，品牌與人工操作流程得以保留。
與後端 MCP 的差異在於生命週期與身分：
- 共用工作階段：工具跑在用戶已登入的分頁，沿用 cookie、表單狀態與頁面資料，不必為代理另做 OAuth 或複製一套 API。
- 人在迴路：Chrome 文件強調 API 主要為本機瀏覽器、有人監督的工作流而設，而非無頭爬蟲。敏感動作（例如付款）可要求確認對話框。
- 權限與來源隔離：APIs 受 Permissions Policy 的
tools功能閘控，預設 allowlist 為'self'。跨來源 iframe 須加allow="tools"，工具預設不暴露給其他來源，須以exposedTo列出可信 HTTPS origin。若文件啟用document.domain（例如Origin-Agent-Cluster: ?0），WebMCP 會被停用，以保持 origin 在工具生命週期內穩定。 - 宣告式與命令式並行：Imperative API 用 JavaScript 註冊導航、表單、狀態管理等工具；Declarative API 則在既有 HTML 表單加註解。React 有實驗套件
usewebmcp，Angular 亦有實驗支援，可把 Signal Forms 轉成工具。Chrome 146 起可用旗標作本地測試；149 起可申請 origin trial，讓真實訪客在未開旗標的情況下啟用實驗 API。
規格亦定義 getTools()、executeTool()、toolchange 事件，以及以 AbortSignal 註銷工具或取消執行。這讓「頁內代理」（寫在 iframe 的 JavaScript 代理）與瀏覽器內建代理，都能以同一套工具表協作。
三、日常應用場景
1. 開發者與技術團隊
對前端與全端團隊，WebMCP 把「給人用的 UI」與「給代理用的契約」拆開：按鈕仍給人撳，工具 schema 給模型填。實務上應把 execute 做成現有 action 的薄包裝，避免維護兩套業務邏輯。Chrome 建議以 Model Context Tool Inspector 擴充功能檢查已註冊工具、手動呼叫，並用自然語言測試代理是否選對工具。開發者亦須處理功能偵測：document.modelContext 不存在時，網站必須維持原本表單與按鈕可用。
2. 企業與隱私敏感行業
工具繼承用戶登入狀態，意味代理一旦被提示注入或過度參數化，可能讀走個人化資料、甚至觸發轉帳、改帳號、下單。規格第 6 章與 Chrome〈WebMCP tool security〉均指出：惡意工具說明、工具回傳值、跨站脈絡都是攻擊面；untrustedContentHint、readOnlyHint 只是提示，不是密碼學保證。金融、法律、醫療與持牌機構若讓代理操作網銀、客戶入口或內部 SaaS，應把可呼叫工具白名單化，敏感動作強制人為確認，並假設工具輸出為不可信內容。
3. 一般用戶
用戶看到的，應是代理在自己正在瀏覽的訂位頁、客服表或購物車上「做看得見的事」，而不是背景另開一個看不見的工作階段。官方預約示範把「代理刮 DOM」對比「代理呼叫工具」：後者步驟較少、較可預測。這對複雜日期選擇、多乘客航班、分欄姓名表單尤其有用——這些介面本來為人設計，模型卻經常填錯。
4. 香港與亞洲市場視角
香港企業的網站與流動應用，大量承載登入後的銀行、保險、旅遊、零售與政府表格。若國際瀏覽器開始讓代理「合法」呼叫頁面工具，本地產品有兩條路：繼續讓代理靠視覺猜測（錯誤率高、客服成本升），或在網頁與 App 內嵌 WebView／PWA 層預先暴露清楚的工具契約。旅遊與跨境商務是最貼近官方 Travel demo 的場景：香港往返亞洲多城市、多乘客、多幣種的訂位流程，正是代理最容易填錯、也最值得用 schema 約束的介面。
同時，《個人資料（私隱）條例》下，代理共用工作階段等於擴大了「誰在用你的登入狀態」的問責範圍。企業應把 WebMCP 當成產品功能與私隱設計一併評估，而不是只交給前端加幾行 registerTool。
四、專業評價與潛在考量
優勢
- 由網站宣告能力，比截圖或 DOM 猜測更可測試、可版本化，亦保留品牌 UI。
- Google 與 Microsoft 共同編輯、Chrome 已開 origin trial，屬於少數已有實作與公開文件的「代理友善網頁」提案。
- 安全模型沿用瀏覽器同源與 Permissions Policy，比另建雲端工具閘道具較清晰的現有邊界。
- 宣告式表單路徑讓中小網站不必重構即可試水。
需要留意的地方
- 仍是 CG 草案，API 可能改；Chrome 文件寫明
navigator.modelContext舊名已棄用，現行表面是document.modelContext。 - Origin trial 不是預設開啟；Firefox／Safari 在 Intent 中尚無公開時程。過早當成「全網標準」會誤導產品排期。
- 工具說明無法被靜態驗證是否與真實行為一致：含糊的
finalizeCart可能實際觸發付款。這是規格自己承認的語意缺口。 - 複雜介面仍可能要為狀態管理補 JavaScript；無頭瀏覽並非設計重心。
- 發現性限制：客戶端與瀏覽器必須實際造訪該頁，才知道有哪些可呼叫工具。
結語
WebMCP 要解決的，不是再做一個聊天框，而是讓公開網頁在瀏覽器裡、用用戶自己的工作階段，向 AI 代理交出結構化、可呼叫的能力。Chrome 149–156 的 origin trial、W3C WebML CG 草案，以及 Google／Microsoft 共同編輯的規格倉，構成目前可核實的事實基礎；其餘傳聞應等到官方文件或 Intent 更新再跟進。
對香港團隊而言，下一步很具體：盤點哪些登入後流程最常被代理填錯——訂位、開戶、申請表、售後——然後以漸進增強方式加上工具契約，並為敏感動作保留人為確認。若需要把網站與 iOS／Android 應用做成同一套可被代理呼叫的產品介面，可參考 YSK Limited 的香港 APP 開發（遠端開發者外判由 HK$2,000／月起，一年約、含 1 部美國 VPS；App Store／Google Play 上架可使用 YSK 開發者帳戶）。涉及客戶數據、登入狀態與境內部署的代理工作流，亦可一併評估企業私有 LLM 全託管（年費 HK$88,000 起，Dataset → QLoRA/LoRA → 私有 API，100% 數據不出境）。
參考來源
- W3C Web Machine Learning Community Group，《WebMCP》Draft Community Group Report（2026-08-26）：https://webmachinelearning.github.io/webmcp/
- Chrome for Developers，Alexandra Klepper，〈WebMCP〉（2026-05-18 發布，2026-08-07 更新）：https://developer.chrome.com/docs/ai/webmcp
- Chrome for Developers，Alexandra Klepper、François Beaufort，〈WebMCP Imperative API〉（2026-05-18 發布，2026-08-20 更新）：https://developer.chrome.com/docs/ai/webmcp/imperative-api
- GitHub，
webmachinelearning/webmcp規格倉：https://github.com/webmachinelearning/webmcp - Chromium blink-dev，Intent to Experiment: WebMCP（2026-05-15；M149–M156 origin trial）：https://groups.google.com/a/chromium.org/g/blink-dev/c/gmYffo5WOE8/m/OJxuQRP3AAAJ
- Chrome for Developers，〈WebMCP tool security〉：https://developer.chrome.com/docs/ai/webmcp/secure-tools
- X News 話題頁（僅作發現，非事實來源）：https://x.com/i/trending/2094543667344158854