像素風格的藍色 Agent 單膝跪在終端機畫面之前，背景是星空與雪山，用來示意 WebMCP

WebMCP 是一項提案中的瀏覽器 API，能代替使用者去探索、描述並執行提供給 AI Agent 的結構化工具。網站宣告每個動作在做什麼、接受哪些輸入；Agent 直接呼叫這個工具，不必再猜要點哪個按鈕或欄位。這能讓表單、訂房流程或診斷任務更快也更可靠，但它並不是瀏覽器自動化的全面替代品。 Chrome 的 WebMCP 文件

實務上的選擇是架構問題。WebMCP 是伺服器端的合作：網站擁有者發布一份面向 Agent 的契約。瀏覽器自動化則是客戶端的觀察：Agent 操作既有的介面，包括已獲授權的登入工作階段。當你掌控網站、能定義安全工具時，用前者；當你必須面對今天的網頁時，用後者。安全工具指引

Key takeaways

WebMCP 以探索機制、JSON 結構定義與共用頁面狀態來提供頁面工具；對網站而言它是一種漸進增強。
目前 Chrome 的實作仍屬實驗性質：Chrome 149 的 origin trial，或本機測試旗標，而且 API 仍可能變動。
在一次 Chrome 152 的測試中，具名工具推動了一條看得到的飯店流程，從搜尋一路走到由人工確認的合成訂房。
已發布的 JSON 結構定義描述了契約，但我們的負向測試顯示，應用程式碼仍必須自行強制合法值。
瀏覽器自動化不需要網站配合，也能重用一組明確佈建的實際登入狀態，包括透過 ego (lite) 與 ego-browser skill。
涉及敏感操作的工具需要確認、最小權限、精簡的結構定義，以及不受信任內容的標記；WebMCP 不是繞過權限的途徑。

什麼是 WebMCP？

WebMCP（Web Model Context Protocol）是由 Chrome 團隊與 WebMCP 社群提出的瀏覽器端 API 提案。Chrome 的文件將它描述成一種為 Agent 建構並提供結構化工具的方式，同時保留看得見的網頁應用程式與使用者的主控權。網站可以把搜尋、結帳、日期選擇、客服或診斷工具當成漸進增強來發布；沒有 Agent 在場時，人依然可以繼續使用同一個頁面。 Chrome 的 origin trial 公告

Chrome for Developers 的 WebMCP 文件，顯示定義、導覽與頁面大綱 — Chrome 的官方文件將 WebMCP 描述為一項向 AI Agent 提供結構化工具的提案標準。這是來源背景，不是我們的行為測試。

WebMCP 的運作方式

WebMCP 頁面會向瀏覽器註冊工具。每個工具都有名稱、說明、輸入結構定義，以及一段在頁面內執行的實作。命令式 API 用 JavaScript 撰寫自訂動作；宣告式 API 則是標註一般的 HTML 表單。Chrome 的文件點出對 Agent 重要的三件事：探索、輸入與輸出的 JSON 結構定義，以及描述當前頁面能做什麼的狀態。

結果可能是一條更短的操作路徑。Agent 不必讀取龐大的 DOM、推測某個按鈕代表 submit_application，再祈禱選擇器撐得過一次改版，而是可以直接呼叫具名工具，並帶入由結構定義描述的欄位。動作仍然在網站上看得見地執行，因此頁面可以顯示進度，並在購買或其他會改變狀態的操作之前要求確認。

Chrome Labs 的 Hotel Chain 示範，旁邊是列出 lookup_amenity、search_location 與 view_hotel 結構定義的 WebMCP Inspector — 在我們的執行中，Inspector 1.9.15 直接從看得見的 Hotel Chain 示範頁面探索到具名工具及其輸入結構定義。

我們實測 WebMCP：一次飯店訂房流程的逐步紀錄

2026 年 9 月 11 日，我們在官方 Chrome Labs Hotel Chain 示範上做了一次引導式測試，環境是 macOS 上的 Google Chrome 152.0.7977.76 與 WebMCP Model Context Tool Inspector 1.9.15。操作者使用合成的旅客資料、沒有 Gemini API 金鑰，也沒有任何真實的飯店、付款或帳號憑證。這是一次行為走查，不是速度或可靠度基準測試。

Inspector 探索到頁面的工具與結構定義。我們以 search_location 查詢巴黎、9 月 18 日、三晚、一位成人；頁面顯示兩間住宿。
我們以 breakfast 呼叫 filter_search_results。畫面上可見的結果數量從兩筆變成了一筆，只剩下 Montmartre Suites。
我們打開那間飯店、開始訂房流程，並填入合成身分 Alex Chen。工具準備好了表單，但沒有完成訂房。
頁面停在 Confirm Reservation。直到操作的人親自按下那個控制項，示範才顯示 Reservation Confirmed。

呼叫 WebMCP 早餐篩選工具後，Hotel Chain 的巴黎結果縮減為 Montmartre Suites — 一次合法的工具呼叫改變了畫面上可見的頁面狀態：早餐篩選把巴黎的結果從兩間住宿縮減為一間。

訂房確認頁面，在 WebMCP complete_booking 工具的輸入旁顯示 Confirm Reservation 按鈕 — 工具填入了合成的旅客資料，但帶有後果的動作仍留在一個看得到的人工確認控制項之後。

Hotel Chain 示範在人工核准合成訂房之後顯示 Reservation Confirmed — 人工點擊之後，示範顯示 Reservation Confirmed，Inspector 也回報成功。沒有建立任何真實訂房。

還有一項工具限制也值得注意：在我們手動執行 Execute Tool 流程之後，Inspector 的 Copy trace 動作回傳了空的 JSON 陣列。因此我們以截圖與結構化的步驟紀錄作為這次執行的證據，並且不把這個 trace 結果類推到 Inspector 的其他模式。

WebMCP 與瀏覽器自動化的關係：是另一條通道，不是替代品

WebMCP 與瀏覽器自動化解決的是不同的失效模式。當網站發布一份好的契約時，WebMCP 消除了模糊空間。傳統自動化，包括 Playwright、Selenium、browser-use，或是由 Agent 驅動真實瀏覽器，則是靠讀取算繪後的頁面並與之互動，來處理沒有發布契約的網站。因此 WebMCP 是補足自動化：用戶端在工具可用時呼叫頁面工具，不可用時退回一般瀏覽。

最容易稽核的方式，是把它看成能力邊界。選路線之前，正反兩欄都要看。

做法	它能做什麼	它不能做什麼
WebMCP	呼叫頁面所提供的具名、有結構定義描述的工具	觸及沒有註冊工具、或無法帶入另一組瀏覽器登入狀態的頁面
以 DOM 為基礎的自動化	用選擇器、截圖或無障礙狀態操作幾乎任何算繪後的頁面	在不解讀介面的情況下得知網站預期的動作
重用真實瀏覽器工作階段	使用一組明確佈建、已獲授權的登入瀏覽器狀態	保證能存取、繞過 CAPTCHA，或凌駕網站政策

務實的導入方式是先做一個唯讀工具、一個支援的瀏覽器，以及一個看得見的確認步驟。等退路走得通，再擴大範圍。

工作階段邊界同樣重要。WebMCP 執行在用戶端造訪的頁面中，不會把使用者的 Chrome Cookie 轉移到新的雲端工作階段。對於沒有 WebMCP 的網站，ego (lite) 是一款本機 Chromium AI Agent 瀏覽器：瀏覽器狀態由你明確提供，相容的 Agent 透過 ego-browser 在專用、可見的 Space 中操作網站。Space 會將任務分頁和控制權與你正在進行的工作分開，但它不是遠端 VM 或多租戶隔離邊界。這條路徑改變的是瀏覽器的執行方式，而不是網站的介面契約。 OpenClaw 2.0 的版本說明

用這張評估表把決定講清楚，而不是把 WebMCP 當成全面升級。

評估問題	以下情況選 WebMCP...	以下情況選瀏覽器自動化...
網站是否由你掌控？	是；你能發布並保護頁面工具	否；你需要跟第三方網站打交道
這項任務需要既有的登入狀態嗎？	頁面本身的已驗證工作階段就夠了	Agent 必須重用另一組佈建在本機的工作階段
部署目標是什麼？	為支援的用戶端提供穩定、有型別的契約	不必等網站配合就能跨頁面立即作業

什麼時候該用 WebMCP？

當應用程式屬於你、你能定義穩定的任務邊界，而且希望 Agent 完成結構化工作時，選 WebMCP，例如客服表單、旅遊搜尋、結帳或內部診斷。對於人知道預期動作、但 Agent 否則得解讀大量點擊的複雜介面，它特別有用。工具要維持得小、有型別、可觀察。

當你不掌控網站、需要既有的授權登入、必須跨許多互不相關的網站作業，或需要在今天就有流程而不是等網站採用之後，選真實瀏覽器自動化。對於已投入的 CI 腳本，確定性的自動化仍然合適；對於互動式的登入工作，一個看得見的本機瀏覽器能讓 Agent 取得與人相同的帳號和頁面狀態，方便人審閱。

WebMCP 的安全界線

WebMCP 本身不授予權限。Chrome 以來源隔離與 tools 權限政策來管制這些 API；跨來源 iframe 預設停用。網站只能把工具提供給自己信任的來源，而 Chrome 的安全指引建議對不變更狀態的工具使用 readOnlyHint，並在輸出含有使用者產生或外部文字時使用 untrustedContentHint。

提示詞注入仍然可能發生，因為 Agent 會把指令與網頁內容一起處理。讓說明與輸出保持精簡、在伺服器端驗證輸入、對帶有後果的動作要求使用者確認，並且只提供所需的最小來源與工具集。WebMCP 是更清楚的介面，不是省略驗證、授權、稽核紀錄或人工審閱的理由。

WebMCP 的挑戰與限制

WebMCP 最主要的限制是採用：用戶端必須造訪支援的頁面，瀏覽器也必須實作這項實驗性 API。Chrome 也指出，無頭情境不是主要的設計目標、複雜應用程式可能需要重構狀態，而且提案仍在變動。

這在可預見的未來會形成混雜的技術堆疊。網站可能提供一個很棒的結帳工具，卻把帳號設定留成一般的 DOM 控制項；瀏覽器可能在測試中支援 WebMCP，卻不在你的正式機隊裡。請保留一般的自動化退路，並在反覆執行中量測工具錯誤、確認率與人工接手的情況。

今天就能試 WebMCP 嗎？

若要在本機實驗，請在 Chrome 啟用 chrome://flags/#enable-webmcp-testing 後重新啟動。若要進行實測，Chrome 的文件會請開發者參考 Chrome 149 的 origin trial。使用官方示範與 Model Context Tool Inspector 擴充功能來查看已註冊的工具、手動呼叫它們，並同時測試合法與不合法的輸入。由於提案仍在熱烈討論中，請固定瀏覽器版本並預期 API 會變動。 OpenAI 的 WebMCP Challenge

如果你是使用 Agent 的人而不是網站擁有者，你不需要等待 WebMCP 被採用。在支援的程式開發 Agent 中執行 /ego-browser，描述界線明確的任務，並讓瀏覽器工作階段與權限保持明確。兩種做法會並存：WebMCP 讓願意配合的網站更容易操作；真實瀏覽器自動化則觸及剩下的部分。

常見問題

WebMCP 跟 MCP 伺服器是同一件事嗎？

不是。傳統的 MCP 伺服器是一個外部行程或服務，向用戶端提供工具。WebMCP 則是從網頁本身，把工具提供給瀏覽器裡的 Agent，並以瀏覽器來源與權限政策為界。

WebMCP 能自動化不支援 WebMCP 的網站嗎？

不能。用戶端必須造訪一個有註冊工具的頁面。對於尚未採用 WebMCP 的網站，請使用一般的瀏覽器自動化；當驗證或挑戰要求人工介入時，就停下來等待。

誰需要實作 WebMCP？

由網站擁有者實作 WebMCP 工具；Agent 用戶端與瀏覽器則必須能夠取用。訪客無法把工具加到別人的網站上。

WebMCP 的主要好處是什麼？

WebMCP 給 Agent 具名動作、有結構定義描述的輸入，以及頁面狀態，這在願意配合的網站上減少了猜選擇器與解讀點擊的需求。應用程式仍然必須驗證每一份內容。

WebMCP 的主要限制是什麼？

WebMCP 需要頁面採用與瀏覽器支援，在 Chrome 仍屬實驗性，也沒有解決無頭環境的一致性、驗證政策或提示詞注入。

WebMCP 工具可以在沒有人員參與的情況下執行嗎？

有些低風險工具可以自動執行，但敏感動作應該要求使用者互動與確認。Chrome 的設計針對的是有人留在流程中的本機瀏覽器工作流程。

WebMCP 會把工具提供給每一個 iframe 嗎？

不會。來源隔離與 tools 權限政策會管制註冊；跨來源 iframe 需要明確授權與可信任的提供方式。

WebMCP API 會維持穩定多久？

目前還沒有任何穩定度保證。Chrome 把 WebMCP 標示為仍在熱烈討論中的提案標準，因此請固定版本，並持續關注 explainer 與 origin trial 的說明。

我可以在登入狀態下使用 WebMCP 嗎？

頁面可以在自己的已驗證工作階段內提供工具，但 WebMCP 不會把 cookie 轉移到另一個瀏覽器。請把授權與確認留在網站的安全模型中。

當網站還沒有 WebMCP 時，我該用什麼？

使用一般的瀏覽器自動化。對於已獲授權的本機工作階段，ego (lite) 讓支援的 Agent 透過 /ego-browser 操作另一個獨立佈建的真實瀏覽器。

我可以在哪裡讀到實作指引？

先看 Chrome 的 WebMCP 文件、安全工具指引、origin trial 頁面，以及 GitHub 上的 WebMCP explainer；連結都列在下面的來源註記中。

All articles Try ego (lite)