WebMCP 是 Google I/O 的靜悄悄宣布，可能讓網頁應用程式達到 Agent-Ready 狀態

這是一份提交給Google I/O寫作挑戰

在Google I/O 2026上，那些響亮的宣布很容易被發現：Gemini 3.5、Antigravity 2.0、Android agents、AI Studio升級，以及許多使用AI構建軟體的新方法。

我反覆提及的宣布則相當安靜：

WebMCP。

Chrome 文件描述它為一個建議的開放網路標準，可以在 Chrome flag 背後本地測試並透過示範應用程式探索.

但背後的理念很重要:

如果網站停止強制代理程式猜測按鈕和表單的含義，並開始直接暴露結構化、類型的動作呢?

這聽起來很小的，直到你與當前存在的工具相比較:Chrome DevTools MCP，是Google官方的MCP伺服器，讓程式代理能透過DevTools控制及檢查Chrome。

在比較過兩者後，我的看法很簡單：

Chrome DevTools MCP幫助代理了解我們已經建構的網路。WebMCP則要求我們建構一個代理人能夠無需猜測即可使用的網路。

這個差異對每一位網路開發者都很重要。

當前網絡仍然為眼睛和手指而建

大多數網絡應用假設使用者是人類，正在看像素並一次點擊地通過用戶介面.

這種模式對人類有效。但它對代理來說可靠度低得多。

代理人可以嘗試檢查 DOM。它可以使用無障礙樹。它可以截圖。它可以點擊按鈕。它可以填寫欄位。但除非應用程式暴露更清晰的意圖，代理人仍然必須推斷很多：

這個按鈕是破壞性的还是可逆的？
這個日期欄位期望 MM/DD/YYYY，YYYY-MM-DD，還是自訂的選擇器流程？
可見價格是最終價格，還是稅務稍後才出現？
此表單是立即提交，還是保存草稿？
此已停用按鈕是在等待驗證、權限、庫存，還是 JavaScript 狀態？

人類藉由語境處理模糊性。代理則藉由重試、脆弱的啟發式方法，以及偶爾的胡言亂語來處理模糊性。

WebMCP 很有趣，因為它嘗試在源頭減少那種模糊性.

WebMCP 帶來的改進

Chrome WebMCP 文檔描述 WebMCP 是一種讓網頁能夠為 AI 機器人暴露結構化工具的方式。一個頁面可以註冊 JavaScript 函數或註釋 HTML 表單，以便一個機器人能夠發現可用的動作、理解輸入模式，並在當前瀏覽器上下文中調用這些動作。

换句話說，該網站可以說：

// Conceptual example, not exact production code
registerTool("searchFlights", {
  description: "Search available flights",
  input: {
    origin: "string",
    destination: "string",
    date: "string",
    passengers: "number"
  }
});

這是一份不同的合約，與「尋找一個可能代表原始值的文字方塊，輸入它，按Tab鍵到某處，希望自訂日期選擇器能正常運作，然後點擊藍色按鈕」不同。

官方文件提到支援探索、JSON Schema 和頁面狀態。它們也提供了支援流程、旅遊訂票、結構化表單、日期選擇器和隱藏的診斷動作等範例。

重要的詞是結構化.

網絡已經有 API。但 WebMCP 不是後端 API。它在瀏覽器上下文中運行。工具調用可以更新使用者看到的相同 UI。這讓使用者保持參與，並保留可見的產品體驗，同時給代理一條比原始操作更可靠的途徑.

為何我將其與 Chrome DevTools MCP 相比

Google I/O 開發者主題演講將 WebMCP 和代理的 Chrome 開發工具放在同一個更廣泛的部分：「重新定義智能代理時代的網頁開發」。這種搭配很有用.

代理的 Chrome 開發工具給程式代碼代理程式提供與 Chrome 互動、檢查頁面、偵錯執行時行為、模擬真實世界用戶體驗、執行審計、檢查控制台訊息、分析網絡請求、擷取可訪問性樹狀結構快照，以及執行效能工作流程的能力。

GitHub 的 README 檔案為chrome-devtools-mcp 將其描述為一個MCP伺服器，讓代理如Antigravity、Claude、Cursor、Copilot和Codex能夠控制並檢查一個實時的Chrome瀏覽器。該工具參考包括導航、輸入自動化、模擬、網絡檢查、控制台檢查、截圖、可訪問性快照、Lighthouse審計、性能追蹤、記憶工具、擴展工具，以及實驗性的WebMCP工具。

這可是相當大的權力。

但它是一個不同的層次.

Chrome DevTools MCP 主要是一個開發者端的調試和自動化工具.

WebMCP 是一個網站端的能力合約.

一個允許代理檢查當前情況。另一個允許網站聲明可以執行什麼.

我的小型測試

我想要實際檢查一下，而不是寫另一篇「AI 將改變一切」的文章.

WebMCP 文件指出有示範涵蓋了命令式和宣告式的實現:

WebMCP zaMaker，它使用 WebMCP 命令式 API.
一個旅遊示範，也使用 WebMCP 命令式 API.
Le Petit Bistro，它使用 WebMCP 宣告式 API。

我從 WebMCP zaMaker 開始，因為命令式版本讓核心概念非常明顯。不是要求代理從像素推斷披薩控制，頁面註冊了檢查器可以發現的明確工具。

我在 Chrome 中啟用了 WebMCP 測試，打開了 zaMaker 示範，並使用了 WebMCP - 模型上下文工具檢查器 插件.

該插件浮現了數個頁面定義的工具，包括：

add_topping
manage_pizza
remove_topping
set_pizza_size
set_pizza_style

那就是點到即通的部分。這些不是像 "在座標 X 點擊" 或 "在輸入 Y 中輸入" 這樣的通用瀏覽器動作。它們是頁面暴露的產品級功能.

例如，偵錯工具顯示了 add_topping，其模式包括了 topping 枚舉和一個size 列舉。它也顯示了 set_pizza_size，帶有結構化的 size 輸入，以及一個 number_of_persons 欄位，可以幫助推斷正確的大小。

接著我在檢查器中使用自然語言提示：

add pizza with large toppings

檢查器將其翻譯為工具調用：

{
  "size": "Large",
  "topping": "🍕"
}

然後我嘗試了：

make the pizza extra large

擴充功能的名稱為：

{
  "size": "Extra Large"
}

頁面透過更改披薩狀態來回應。

那個小型示範比單獨看文件更能說明問題。一個瀏覽器自動化代理可以點擊披薩建構器。一個了解 WebMCP 的頁面可以說，"這是這款產品支援的操作，這是允許的參數，這是你調用其中一個時發生了什麼。"

為了對比，Chrome DevTools MCP 感覺像是一個開發者端的鏡頭。它可以檢查頁面、讀取無障礙樹狀結構、查看控制台輸出、自動化互動，並幫助代理程式調試 Chrome 中已渲染的內容。

這很強大，但它仍然從外部來查看頁面。zaMaker 示範展示了這個想法的另一面：頁面本身可以發布一組有意義的動作供代理程式使用。

所以我的實際結果是：

Chrome DevTools MCP 在今天實用於檢查和測試頁面。WebMCP 檢查器顯示頁面本身暴露產品級工具時發生了什麼變化。

WebMCP 與 Chrome DevTools MCP

這是我現在認為的最乾淨的區別說法：

問題	WebMCP	Chrome DevTools MCP
誰揭露了這項功能？	網站或網應用程式	瀏覽器 / 开发工具层
這主要為誰設計？	在網站內操作的瀏覽器用戶代理	編碼代理、測試代理和開發者工作流程
它使什麼變得明確？	應用程式定義的工具、輸入、輸出和頁面狀態	瀏覽器狀態、DOM/a11y 快照、控制台、網絡、效能、螢幕擷取
它解決什麼問題？	代理人猜測如何使用產品	開發人員手動檢查和調試瀏覽器行為
目前最佳用途	實驗性代理人準備好的產品流程	真實調試、測試、效能、無障礙檢查
最大限制	需要瀏覽器支援和應用程式實現	有時仍透過頁面結構、快照和推斷用意來運作

如果代理程式嘗試調試為何結帳頁面出現問題，Chrome DevTools MCP 是正確的工具

若代理正在嘗試預訂行程、提交支援請求、設定儀表板，或完成應用程式內的多步工作流程，WebMCP 是更具趣的長期解決方案.

為何這比「AI 可以點擊按鈕」更重大

在 WebMCP 出現之前，默認的瀏覽器代理路徑看起來像這樣：

查看頁面.
猜測用戶的下一步操作。
點擊或輸入.
觀察結果.
若錯誤，請重試.

這可行，但它很脆弱。它也很慢且昂貴，因為每個步驟都增加了模型推理、視覺解析、DOM 解釋或兩者.

WebMCP 提出了一種不同的路徑：

發現網站的可用工具.
選擇符合使用者目標的工具。
傳送輸入的參數.
讓網站在前端瀏覽器上下文中執行動作.
返回結構化輸出或清晰的錯誤.

這更接近一個API，但用戶仍然在查看產品。

我認為 WebMCP 很重要。這不僅僅是關於讓代理更強大。這是關於將責任恢復給應用程式開發者。如果我們希望代理能夠安全可靠地行動，我們不能讓它們從像素中逆向工程每一個工作流程。

我們需要暴露意圖。

在 WebMCP 到處都是之前，開發者能做什麼

我們大多數人都無法明天就發送生產 WebMCP 流程。瀏覽器支援剛剛起步，而且提案仍在變更中.

不過我們可以開始建立讓人類和代理更容易理解的網站.

我從這裡得到的實用清單是：

在自訂組件之前使用語義 HTML.
讓重要的按鈕和表單在無障礙樹中清晰顯示。
給輸入穩定的名稱和標籤.
避免僅僅在視覺風格中隱藏關鍵狀態.
將破壞性操作放在明確確認後.
清楚區分「預覽」、「保存草稿」、「提交」和「購買」流程.
讓驗證錯誤既可被機器讀取也可被人類讀取.
使用瀏覽器自動化、無障礙快照和Lighthouse測試重要流程
思考哪些應用程序操作後來應該有結構化工具

如果我正在為WebMCP準備一款產品，我不會一開始就將每個按鈕作為工具暴露出來。我會從那些模糊不清最傷害工作流程的地方開始：

搜索
結帳
預訂
支援建立服務單
啟動退貨/退款程序
儀表板篩選
診斷
帳戶設置變更

這些是代理人透過介面猜測可能造成真實用戶痛苦的場合.

安全問題

這裡有一個明顯的風險：如果網站向代理暴露操作，糟糕的工具設計可能會讓壞的操作更容易。

這就是為什麼我喜歡 WebMCP 模型將操作保留在瀏覽器上下文中，而不是將每個網站轉變成一個盲目的後端 API。敏感操作仍然可以要求可見的 UI、用戶確認和頁面級別的狀態。

但開發者需要自律。

一個好的 WebMCP 工具應該具備：

明確的目標
清晰的標名
嚴格的架構
有用的錯誤訊息
可見的執行過程
對不可逆操作的確認
沒有出乎意料的副作用

目標不應該是「讓代理隨意操作」。

目標應該是「讓代理能夠以更少的猜測做正確的事。」

我的看法

Chrome開發工具MCP感覺像是網頁開發者現在可以使用的工具.

WebMCP感覺像是網頁開發者未來可能需要設計的合約.

那就是為什麼我认为它是Google I/O 2026上更重要的網頁宣布之一。它指向了一種轉變：

代理作為更好的螢幕擷取器

至

代理作為結構化網頁能力的頂級用戶

這種轉變不會一夜之間發生。它需要瀏覽器支援、標準制定工作、開發者工具、安全模式，以及大量的實際測試。

但方向很明確。如果代理人要代表我們使用網絡，網站應用程式需要不只是視覺上可用的.

它們需要變得容易理解.

它們需要變得可以檢查.

最終，它們需要變得代理人準備好的.

推薦訂閱源

DEV Community