網頁也能向AI智慧體提供工具了：W3C孵化中的WebMCP標準輪廓整理

2026年9月1日，中國技術社羣平臺掘金刊登開發者ssshooter的技術文章，介紹一套正在W3C WebML社羣組孵化中的瀏覽器標準提案WebMCP。該提案的核心主張是：讓網頁在前端直接把可用的「工具」結構化地宣告給瀏覽器內的AI智慧體，取代目前以截圖辨識或解析DOM樹為主的網頁操作方式。本臺以回顧角度，綜合該篇文章與公開資料，整理這項提案的技術輪廓、與既有MCP協議的差異，以及目前實際可測試的進度。

名稱造成的誤解：WebMCP並非MCP的網頁版

文章開篇先釐清一個常見誤會。MCP（Model Context Protocol）是運行在伺服器或獨立行程間的後端協議，與瀏覽器本身沒有直接關係；WebMCP則是一套正在W3C WebML社羣組內孵化的瀏覽器標準提案，兩者僅是概念上相近，並非同一套東西的移植關係。

作者將WebMCP定位為「受了MCP啟發的瀏覽器API」。MCP與WebMCP的關係是搭配使用：前者處理後端與核心邏輯的連接，後者處理頁面內的即時互動。換句話說，網頁開發者透過幾行JavaScript，把頁面中的既有函式註冊成帶有名稱、描述與輸入參數結構描述的工具，AI智慧體造訪頁面時可自動發現並直接呼叫，取回結構化的JSON結果。

現行兩條路的困境

文章指出，目前AI與網頁互動主要依賴兩種方式，兩者共同的問題是脆弱且耗費運算資源。第一種是視覺路徑，對頁面截圖後交給多模態模型，由模型「看圖」推斷操作步驟。第二種是語義路徑，解析DOM樹與無障礙樹，模擬點擊與輸入。頁面一旦改版、按鈕挪位，兩種方式都容易失效；涉及複雜登入狀態的場景更是高失敗率區域。

WebMCP的設計思路是反轉責任歸屬：與其讓AI猜測「提交」按鈕在哪裡，不如由網頁自己宣告「我能做什麼、該怎麼呼叫我」。由於呼叫發生在瀏覽器內部，瀏覽器知道當前頁面、session與Cookie狀態，AI等於以「使用者本人已在頁面上」的身份操作，文章認為這比無頭瀏覽器自動化方案更穩定。

MCP與WebMCP的逐項對照

文章以幾個維度並列兩者的差異。就位置而言，MCP在後端與伺服器端，WebMCP在前端瀏覽器內。就生命週期而言，MCP連線持久、常駐存在，WebMCP的工具註冊隨頁面關閉即失效。就連接範圍而言，MCP是全域配置，WebMCP僅作用於當前標籤頁。就互動模式而言，MCP是無頭的API呼叫，WebMCP在瀏覽器內執行、可觸及DOM與會話狀態。就發現機制而言，MCP需要手動配置連接，WebMCP在智慧體造訪頁面時自動發現可用工具。

一句話概括兩者的分工：MCP管核心邏輯，任何環境都能呼叫；WebMCP管頁面內的即時操作，使用者打開網頁的那一刻，AI即可上手。

適用場景與安全設計

文章列舉的適用場景，集中在「使用者已登入、且需要多步操作」的網站功能。例如讓AI理解欄位語義後填寫結構化表單，免去盲目點擊輸入框的過程；搜尋、篩選、下單等多步流程不會因按鈕挪位而中斷；後臺報表可直接輸出JSON，省去AI解析HTML表格的成本。涉及購買等敏感操作時，可加入確認彈窗，工具呼叫在頁面上可見地執行，由使用者監看。

作者歸納此方案的幾項優勢：速度上走瀏覽器內部通道，減少網路往返；穩定性上綁定應用邏輯而非頁面視覺設計，抗改版；主導權上由網站明確定義AI應如何操作，而非期待AI自行找到正確按鈕。

目前可用狀態與限制

文章說明，WebMCP仍處於早期階段，但在特定條件下已可實際測試。Chrome使用者可在位址欄輸入實驗旗標設定頁面，將WebMCP測試選項設為啟用並重新啟動瀏覽器。頁面必須透過HTTPS或localhost提供，且文件需為源隔離狀態，不能設定特定跨源叢集參數，也不能修改document.domain。跨源iframe若要暴露工具，需加上顯式的iframe授權屬性。此外，可安裝Model Context Tool Inspector擴充功能，在開發者工具中檢視頁面註冊的工具清單。

需要說明的是，上述均屬實驗性功能，介面與旗標名稱可能隨瀏覽器版本調整，W3C社羣組的孵化成果也未定案為正式標準。

訊源與可核實邊界

本次整理的主要訊源為掘金平臺上該篇技術文章，內容包含作者對提案的個人解讀與評價。關於W3C WebML社羣組的實際文件進度、各瀏覽器廠商的實作時程，文章未提供官方文件連結佐證，本臺暫無法獨立核實其標準化時程。讀者若需引用具體規格細節，應以W3C社羣組的正式出版文件與瀏覽器官方說明頁為準。