Cloudflare 官方部落格於二〇二六年十月二十一日披露，已與 Commerce.com 合作，把實驗性瀏覽器標準 WebMCP 以邊緣注入方式，啟用於 Commerce.com 近十萬個網店與網域，讓 AI 代理可直接呼叫搜尋商品、加入購物車等結構化工具，而不必靠猜測網頁按鈕。商戶可在平台選擇退出；結帳與付款仍由人類購物者自行完成。來源真實性已驗證。

Cloudflare／官方：Commerce.com 近十萬網店啟用 WebMCP——邊緣注入結構化購物工具；商戶可選擇退出；結帳仍由人類完成

網站長期為人類瀏覽而設計，AI 代理若要代客買鞋，往往只能解析 HTML、猜測按鈕位置再反覆點擊；主題一改、Cookie 橫幅或人機驗證一出，流程就容易斷。Cloudflare 於二〇二六年十月二十一日在官方部落格說明，如何與 Commerce.com 把 Google 提出、仍屬實驗預覽的瀏覽器標準 WebMCP，以邊緣層一次開通至該平台近十萬個網店／網域，讓代理改為呼叫結構化工具（例如 search_products、add_to_cart）。本文以 Cloudflare 官方部落格為第一手來源，來源真實性已驗證；並簡要對照本站過往對 Chrome WebMCP 實驗（#467、#582）與 Shopify Checkout WebMCP（#1160）的報導——那些屬瀏覽器／單一平台實驗敘事，與今次「Commerce.com 整隊店舖經 Cloudflare 邊緣大規模啟用」並非同一事件，亦與 Mastercard Agent Pay（#1736）不同。

一、核心事件：近十萬店舖一次開通，但保留商戶退出權

技術細節

根據 Cloudflare 官方說明：

WebMCP 是什麼：由 Google 提出的實驗性瀏覽器標準，讓頁面暴露結構化工具給 AI 代理，而非依賴脆弱的 HTML 點擊模擬。現階段可經 Chrome 實驗旗標、Origin Trials、部分 agentic 瀏覽器，以及 Cloudflare Kitesurf 等開發環境接觸。
Cloudflare 邊緣實作：八月起推出邊緣 WebMCP beta；開啟後由 Cloudflare 在邊緣注入極小腳本，商戶無需改寫主題或自行接線即可暴露工具。
Commerce.com 的規模訴求：該平台已在 Cloudflare 上運行近十萬個網域，並要求一次為所有店舖開啟 WebMCP。
共用 zone 難題：WebMCP 原本是 zone 級開關；Commerce.com 以 Cloudflare for SaaS 承載大量商戶 vanity domain，多個網店共用 zone，不能簡單「全 zone 開／關」又兼顧個別商戶控制。
解法：把 WebMCP 接到既有的 Configuration Rules 與 custom hostname metadata。平台為主 zone 開啟後，邊緣規則檢查商戶 metadata；若商戶在 Commerce.com 後台打開退出開關（webmcp_opt_out），該店舖即繞過 WebMCP——官方強調評估在邊緣完成，不會多一段延遲、也不會注入腳本。
可設定 MCP 路徑與安全後備：預設橋接曾假設 MCP 伺服器在 /mcp；Commerce.com 實際位於 /api/mcp，因此新增 zone 級可設定 MCP URL，並寫入注入腳本。若 MCP 離線或瀏覽器不支援 WebMCP，腳本直接退出，人類購物體驗不受影響。

Commerce.com 產品管理總監 Kristina Pototska 在文中指出，商戶希望當購物者要求代理找商品時，自己的店能出現在答案裡，同時保留顧客關係與結帳控制，且不必重建網站；WebMCP 協助代理以真實工具搜尋、查詳情、組購物車並取得結帳連結，而人類購物者仍留在商戶站內。

二、技術原理深度解析：瀏覽器內工具 vs 伺服器端 MCP

此整合的兩條原則，決定了安全邊界與「誰看到什麼價」：

工具在購物者活躍瀏覽器工作階段、於店舖網域內執行：代理看到的價格與購物車狀態與當前訪客一致；該路徑不把憑證交給第三方，造訪仍發生在商戶站上。
Cloudflare 作邊緣傳遞層：代理 Commerce.com 後端 MCP 伺服器的工具定義與動作，商家仍掌控工具邏輯。Commerce.com 另有 server-side MCP，供代理直接連線商店（例如跨多站助手）；WebMCP 則服務「在購物者瀏覽器內工作」的代理。兩邊工具集合相同，商戶不必二選一或分開維護。

文中舉例：用戶要求代理找一雙防水越野跑鞋、預算一百四十美元內、十號碼並加入購物車。沒有 WebMCP 時，代理可能被 Cookie 橫幅、款式下拉選單或人機驗證卡住；有 WebMCP 時，代理可在 document.modelContext 發現工具，再以結構化呼叫完成搜尋與加入購物車。購物車即時更新；完成購買時仍由人類自行點擊結帳，付款資料留在購物者控制範圍。

對工程團隊而言，重點不是「AI 代付」，而是把「可機器讀取的商業能力」從脆弱 DOM 猜測，升級為可版本化、可觀測的工具介面，並用邊緣規則把大規模預設開啟與單店退出併存。

四、日常應用場景

1. 開發者與技術團隊

若平台以 Cloudflare for SaaS 承載多租戶 vanity domain，可參考把實驗性瀏覽器能力掛在 Configuration Rules 與 hostname metadata，而不是只做 zone 級總開關。MCP 端點路徑、toolpack（文中提到 mcp-server-client）與注入腳本的 data-mcp-url 應可設定；並預設「瀏覽器不支援或後端離線就安靜退出」，避免把實驗標準變成前台故障。

2. 企業與隱私敏感行業

對零售與品牌而言，代理購物若走「在商戶網域、訪客工作階段內」的路徑，較易對齊「顧客與結帳控制權留在自家站」的合規敘事，亦減少把第三方憑證交接寫進流程。企業仍應分開評估：伺服器端 MCP（代理直連）與 WebMCP（瀏覽器內）的存取控制、稽核日誌與工具權限範圍，以及結帳／支付永不交給代理自動完成的產品政策。

3. 一般用戶

對一般購物者，短期可見變化取決於所用瀏覽器／代理是否支援 WebMCP。理想情況是代理更快、更準地找貨與組車，但付款與最終下單仍需自己確認。若某店已選擇退出，或瀏覽器尚未支援，網站應如常可人手購物——這正是 Cloudflare 強調的後備行為。

4. 香港與亞洲市場視角

香港與亞洲大量中小網店依賴 SaaS 電商與 CDN／邊緣平台。今次案例顯示：平台方若能以邊緣一次開通實驗標準，再以 metadata 讓個別商戶退出，可降低「每個主題都要改碼」的門檻。本地品牌若正規劃代理可發現的商品目錄與結帳流程，應優先釐清工具是否在自家網域工作階段執行、結帳是否仍由人類完成，以及與既有伺服器端 API／MCP 如何並存；同時留意 WebMCP 仍屬實驗預覽，生產採用需有可關閉與可觀測的回退路徑。

五、專業評價與潛在考量

優勢

以官方部落格清楚交代「近十萬」規模、邊緣注入、opt-out 機制與可設定 MCP URL，便於工程與產品轉述。
把「代理可發現工具」與「人類保留結帳／付款」分開，降低把 agentic shopping 誤解成無人值守代付的風險。
WebMCP 與 server-side MCP 並列，覆蓋瀏覽器內與直連兩類代理路徑，減少商戶雙軌維護成本。
退出店舖強調零額外延遲、無注入腳本，符合大規模預設開啟時對商戶自主權的務實要求。

需要留意的地方

WebMCP 仍是實驗性提出標準與早期預覽；可用性取決於瀏覽器旗標、Origin Trials 與代理實作，不宜寫成已全面普及。
「近十萬」為 Cloudflare 對 Commerce.com 網域／店舖規模的表述，本文不另推算 GMV、轉換率或延遲毫秒數。
工具暴露面擴大後，平台需同步處理工具權限、濫用偵測與與既有 bot 挑戰的互動；官方文以購物流程為主，細節需各平台自行加固。
本站過往已報 Chrome WebMCP 實驗與 Shopify Checkout WebMCP；讀者應分開理解「標準／單一平台實驗」與「Commerce.com × Cloudflare 邊緣艦隊啟用」兩條時間線。

結語

Cloudflare 與 Commerce.com 把 WebMCP 以邊緣腳本推到近十萬網店，核心不是讓 AI 取代結帳，而是讓代理用結構化工具在商戶站內搜尋與組車，同時用 metadata 保留退出權，並在不支援時安靜回退。對正把商品目錄、客服與營運流程接上代理工作流的企業而言，下一步往往是：哪些能力適合瀏覽器內工具、哪些適合私有模型與伺服器端編排，以及如何在不交出結帳控制權的前提下提高可發現性。

如需在香港規劃企業私有 LLM、資料不出境的模型微調，或把內部流程編成可稽核的代理工作流，可參考 YSK Limited 的企業私有 LLM 全託管與 AI 自動化服務：https://ysk.hk/services/ai-automation

參考來源

Cloudflare Blog（官方，第一手）：How Commerce.com and Cloudflare are getting storefronts ready for AI agents（2026-10-21）— https://blog.cloudflare.com/webmcp-commerce/