摘要： Commerce.com 與 Cloudflare 合作，把 Google 提出的 WebMCP 瀏覽器標準以邊緣注入方式套用到平台上近 100,000 個商店網域，讓 AI 代理能用結構化工具搜尋商品、加入購物車，而不是靠猜測點擊按鈕。商家不用改主題，還能在後台一鍵退出。這是「代理購物」從實驗走向平台級部署的具體案例。
為什麼代理買不到一雙鞋
AI 已經能寫程式、考律師執照，但上網買鞋仍然很吃力。原因在於網站是為人類設計的：多數購物代理只能讀 HTML，猜測哪個按鈕做什麼，點錯了再重試。根據 Cloudflare 的說明，這種做法又慢又耗 token，商家改一次網站主題就可能讓整個流程失效，甚至被 bot 驗證擋在門外。
WebMCP 是 Google 推出的實驗性瀏覽器標準草案，讓頁面向代理提供結構化工具，例如 search_products。代理不再模擬人類點擊，而是直接呼叫需要的工具。這個標準目前仍在早期預覽階段，透過 Chrome 實驗旗標、Origin Trials、部分代理瀏覽器，以及 Cloudflare Kitesurf 等開發環境提供。
Commerce.com 要的三件事
Commerce.com 是一個以 AI 時代為前提的電商平台，本身就用 Cloudflare 經營近 100,000 個網域。他們的 Product Management Director Kristina Pototska 說明，商家想的是三件事：當顧客向代理下指令時，自己的商店要出現在答案裡；要留住顧客關係、掌握結帳流程；而且不想重建網站。
整合依賴兩個關鍵設計。第一，WebMCP 工具直接在使用者的瀏覽器工作階段中、在商店的網域上執行，代理看到的是與真人相同的價格和購物車，任何憑證都不會交給第三方。第二，Cloudflare 作為 Commerce.com 後端 MCP server 的邊緣傳遞層，原封不動地代理工具定義與動作，商家保有完整的工具邏輯控制權。
實際體驗是這樣的：你告訴代理「幫我找一雙 140 美元以下、10 號的防水越野跑鞋並加入購物車」，代理偵測到 document.modelContext 上的工具後，只需兩次乾淨的呼叫——search_products 加上 add_to_cart，購物車即時更新。最後結帳仍由顧客自己按下，付款資訊不經過代理。
從單一開關到平台級部署
工程上的難題在於：WebMCP 原本是整個網域一個開關，但 Commerce.com 用 Cloudflare for SaaS 在共用區域上託管數千個商家自訂網域，需要平台級開啟、又讓個別商家能退出。
雙方的做法不是自訂允許清單，而是接上既有的 Configuration Rules 與自訂主機名稱中繼資料：Commerce.com 在主區域開啟 WebMCP，邊緣規則檢查商家中繼資料，若商家在儀表板翻開退出開關，該商店自動跳過注入。因為規則在邊緣、頁面送出前就評估完畢，退出的商店零額外延遲、零遠端查詢。
實作過程也暴露了預覽版的現實問題：Cloudflare 的 mcp-server-client toolpack 原本預設所有網站的 MCP server 都在 /mcp，而 Commerce.com 的伺服器在 /api/mcp，因此新增了區域層級的自訂 MCP URL 設定，把路徑傳進注入的 script 標籤。另外還加了安全的退場機制——如果 MCP server 離線或瀏覽器不支援 WebMCP，腳本直接退出，店面照常載入。
對打造者的啟示
這個案例值得注意的不是標準本身，而是部署模式：把「要不要讓代理進門」的決定權下放到每個商家，同時讓平台一次搞定。WebMCP 與 Commerce.com 既有伺服器端 MCP 並存，同一組購物工具覆蓋兩種情境——伺服器端 MCP 服務直接連店鋪的代理，WebMCP 服務在使用者瀏覽器裡工作的代理，商家不必二選一。
如果你正在評估 agent 接入自家服務的方式，Cloudflare 8 月推出的邊緣版 WebMCP 目前仍是 beta。工具層的設計思路和 MCP 生態的整體盤點，可以參考先前這篇 12 個 MCP Server 的比較整理。WebMCP 仍是早期預覽標準，規格還會變動，但「結構化工具取代畫面猜測」這個方向，值得在下一輪產品規劃裡認真放進去。