AI 代理幫人購物時，多半還在「看網頁、猜按鈕、點錯重來」。Cloudflare 與 Commerce.com 在 10 月 21 日分享，如何在邊緣網路一次為近 10 萬個商店網域開啟 WebMCP，讓代理直接呼叫搜尋商品、加入購物車等工具，結帳仍由顧客自己按下，店家也能一鍵選擇退出。給品牌電商與工作室的「代理友善」入門指南。
Cloudflare 這篇文章的開場白實在太好笑，我們決定直接借用：AI 可以寫程式、可以通過律師考試，但它還是很難在網路上買一雙鞋。
聽起來很荒謬，但想想 AI 代理現在怎麼逛網店：它看著頁面的 HTML，猜哪個按鈕是「加入購物車」，點下去，發現點到「加入收藏」，再試一次。中間還要閃過 Cookie 橫幅、搞懂尺寸下拉選單、被機器人驗證擋在門外。網站換個佈景主題，它可能就全部重學。
這就像請一位很聰明、但完全看不懂中文的朋友，幫你在夜市買東西。他很努力，只是每一步都在比手畫腳。
10 月 21 日，Cloudflare 與電商平台 Commerce.com 分享了一個解法：WebMCP。而且他們不是在一家店試，而是一口氣開在將近 10 萬個商店網域上。
WebMCP 是什麼？
依 Cloudflare 的說明，WebMCP 是 Google 提出的瀏覽器標準，讓網頁提供結構化的「工具」給 AI 代理使用，例如 search_products。代理不用再猜按鈕，而是直接呼叫需要的工具，讓購物更快、更省、更可靠。
有個重要但書：WebMCP 目前仍是實驗中的標準提案，處於早期預覽階段。現在可以在 Chrome 實驗旗標（chrome://flags/#enable-webmcp-testing）、Chrome Origin Trials、部分代理型瀏覽器，以及 Cloudflare Kitesurf 等開發環境中使用。所以這不是「明天所有消費者都在用」的東西，而是一個值得提早準備的方向。
Cloudflare 在 8 月推出了邊緣版 WebMCP（beta）：開啟之後，Cloudflare 會在邊緣注入一小段腳本，自動讓這些工具可用，店家不需要寫任何一行程式碼。
代理實際看到什麼？
文章舉了一個例子。你對 AI 代理說：「幫我找一雙 140 美元以下、10 號、防水的越野跑鞋，加入購物車。」
沒有 WebMCP 時：代理模擬人類點擊，被 Cookie 橫幅擋住、誤讀尺寸選單、被機器人驗證攔下。
有 WebMCP 時：代理在 document.modelContext 上找到商店提供的工具，乾淨俐落地呼叫兩次：
search_products({ query: "trail running shoe", max_price: 140, size: 10 })add_to_cart({ product_id: "shoe_123" })
因為代理是在你正在使用的瀏覽器工作階段、在商店自己的網域裡運作，購物車會即時更新。要結帳時，由你自己按下結帳，付款資料留在你手上，最後一步的決定權也在你手上。
為什麼這個設計對店家很重要？
Commerce.com 產品管理總監 Kristina Pototska 在文中說，商家一直在問怎麼跟上代理購物：當顧客請代理找東西時，商家希望自己的店出現在答案裡，同時留住顧客、保有結帳控制權，而且不用重做網站。她認為 WebMCP 三者都能滿足：代理有真正的工具可以搜尋商品、查看細節、建立購物車、取得結帳連結；顧客留在商家網站上，商家保有與顧客的關係。
這個整合有兩個關鍵原則：
- 工具在顧客的瀏覽器中執行，在商店網域上，代理看到的價格和購物車跟顧客一樣；憑證不會交給第三方，造訪仍然發生在商家網站。
- Cloudflare 是邊緣傳遞層，把 Commerce.com 後端 MCP 伺服器的工具定義和動作原封不動地轉送，商家仍完整掌控工具邏輯。
Pototska 也提到，WebMCP 可以和伺服器端 MCP 並存：伺服器端 MCP 服務直接連線商店的代理，例如跨多個網站幫人購物的助理；WebMCP 則服務在顧客瀏覽器裡工作的代理。兩邊是同一套購物工具，商家不必二選一，也不用分開管理。
10 萬家店一起開，怎麼讓每家店能說「不要」？
技術上最有意思的部分在這裡。WebMCP 原本的設計是整個網域區域（zone）一個開關。但 Commerce.com 用 Cloudflare for SaaS，把數千個商家自訂網域放在共用的 zone 上，平台想一次開啟，又要讓個別商家能退出。
他們沒有做複雜的白名單，而是利用 Cloudflare 既有的 Configuration Rules 和自訂主機名稱中繼資料：商家在 Commerce.com 後台打開「退出」開關，邊緣規則讀到中繼資料，就對那家店關閉 WebMCP。因為規則在邊緣、在送出頁面前就判斷，退出的店家沒有額外延遲、沒有遠端查詢、也不會被注入腳本。
另外兩個實戰中才發現的細節：
- 自訂 MCP 路徑：原本假設每個網站的 MCP 伺服器都在
/mcp，但 Commerce.com 放在/api/mcp，於是 Cloudflare 加了 zone 層級的自訂 MCP URL 設定。 - 安全退回：如果商店的 MCP 伺服器離線，或顧客的瀏覽器不支援 WebMCP，腳本就直接結束，網站照常載入，人類顧客完全不受影響。
給品牌電商與工作室的實務建議
WebMCP 還在實驗階段，但「讓網站對代理友善」這件事，現在就可以開始準備：
- 先盤點「代理會想做的事」：搜尋商品、查規格與庫存、加入購物車、取得結帳連結。這些就是未來工具的雛形。
- 把商品資料整理乾淨：尺寸、顏色、價格、庫存若在後台本來就結構化，之後要包成工具會容易很多。
- 守住結帳這一步：Commerce.com 的設計讓顧客自己按結帳。自建方案也應該堅持：代理可以幫忙找、幫忙放購物車，但付款要人確認。
- 保留退出權與開關：如果你是平台或多品牌集團，學習這次「預設開啟、每家可退出」的思路，尊重每個品牌的決定。
- 確保失敗時不影響人類顧客：任何代理功能都應該「壞了就安靜退場」，不能拖慢正常購物流程。
- 小規模實驗：用 Chrome 實驗旗標或 Origin Trials 在測試環境試做，觀察代理實際怎麼使用你的工具。
情境演練：一家咖啡豆網店（假設案例）
假設一家台灣的精品咖啡豆網店，商品有產區、烘焙度、研磨方式、包裝重量等規格。過去 AI 代理要幫顧客買「淺焙、衣索比亞、半磅、手沖研磨」，得在一堆下拉選單間摸索，很容易選錯。
如果網店提供 search_products 和 add_to_cart 這類工具，並清楚定義烘焙度、研磨方式等參數，代理就能一次放對商品；顧客回到畫面確認、自己按下結帳。對店家來說，少了選錯規格的客訴，也多了一個「被代理推薦」的機會。
你可能會問
Q：我的顧客現在會用 WebMCP 嗎？ A：還不普遍。依 Cloudflare 的說明，WebMCP 目前仍是實驗性標準提案，需要實驗旗標、Origin Trials 或特定代理型瀏覽器。現在適合做準備和小規模實驗。
Q：代理會不會直接幫顧客付錢？ A：在這次 Commerce.com 的設計中不會。代理可以搜尋和加入購物車，結帳由顧客自己點擊完成。
Q：開啟 WebMCP 會讓網站變慢嗎？ A：Cloudflare 表示，退出的店家不會有額外延遲或注入腳本；若 MCP 伺服器離線或瀏覽器不支援，腳本會直接結束，網站正常載入。
Q：WebMCP 和 MCP 有什麼不同？ A：依文中說法，伺服器端 MCP 服務直接連線商店的代理，WebMCP 服務在顧客瀏覽器中運作的代理；兩者可以共用同一套購物工具。
結語：網站的新訪客，不一定是人
過去二十年，我們為人類設計網站，也學會為搜尋引擎爬蟲優化。現在，第三種訪客正在出現：替人辦事的 AI 代理。
Cloudflare 與 Commerce.com 的做法很值得參考：給代理清楚的工具，把最後的決定留給人，讓每個商家保有選擇權，並且確保失敗時不打擾任何人。
如果你是品牌主，下次和網站團隊開會時，可以先問三個問題：我們的商品資料夠結構化嗎？代理如果來了，能做哪些事、不能做哪些事？萬一這個功能壞了，人類顧客會不會受影響？這三題答得出來，你的網站就已經比多數對手更接近代理時代。WebMCP 或許還在實驗室裡，但「對代理友善」這門課，現在開始修，剛剛好。
來源：How Commerce.com and Cloudflare are getting storefronts ready for AI agents（Jenny Lea、Max Brosnahan、Matthew Conroy，Cloudflare Blog，2026/10/21）。