WebMCP 是什麼？Shopify、OpenAI、Cloudflare 同時押注的「AI 直接逛你網站」新協定

這幾天，我把 Search Engine Journal 的一篇報導反覆看了兩次，因為裡面提到的三件事湊在一起，感覺跟以往「又一個 AI 新名詞」的新聞不太一樣：Shopify 說 WebMCP 工具已經上線到每一個 Liquid 商店；隔天，Cloudflare 就推出了直接在網路邊緣（edge）加裝 WebMCP 橋接的預覽版；緊接著，OpenAI 在 8 月 25 日把「Site tools」塞進了 ChatGPT 桌面版瀏覽器。三家公司，三種角色，卻像是同一齣戲的三幕（這篇文章整理自 Matt G. Southern 在 SEJ 的原文，加上我的看法跟接著上週那篇 MCP 文章一起看）。

WebMCP 是什麼？先接上週那篇 MCP 文章的比喻

如果你看過上週那篇 MCP 白話文，會記得如果把 MCP 比喻成「AI 世界的萬用充電頭」—— 讓 AI 跟外部服務講同一種語言，不用每次都客製化接一次。WebMCP 可以理解成把這個概念，直接搬進你現在打開的這個網頁分頁裡。差別在於它服務的對象不是遠端的資料庫或 App，而是「此時此刻」在使用者螢幕上開著的這一頁：網站註冊一個帶名字的工具，附上說明跟輸入格式，AI 代理人就能發現它、呼叫它、拿到結構化的回應，不用再用截圖、猜按鈕、模擬打字這種容易出錯的方式操作。Chrome 官方文件裡有一句話講得很精確：「不是你的網站寄居在 AI 代理人裡，而是 AI 代理人寄居在你的網站上。（Instead of your application being a guest within an agent, the agent is a guest on your platform.）」

八月，這件事忽然變得具體

Chrome 其實 2 月就發布過 WebMCP 早期預覽，6 月也開了 Chrome 149 的 origin trial（源頭試驗），規格草案、Demo、瀏覽器測試都有了，但一直缺一塊拼圖：沒有大規模的網站真的部署，也沒有一般人能直接用的代理人客戶端。八月，這塊拼圖被補上了：

• Shopify 提供了 10 種 WebMCP 工具，全面上線到旗下的 Liquid 商店，Hydrogen 開發者預覽版也支援。其中 proceed_to_checkout 這個工具會直接帶著購物車走到結帳頁，但不會幫你完成付款，所有互動都發生在使用者原本開著的那個分頁裡。
• Cloudflare 推出的開發者預覽，讓網站不用改任何原始碼，直接在 Cloudflare 後台開關，Cloudflare 就會在邊緣層的 HTML 回應裡插入一行程式碼，載入一支同源的橋接腳本，工具實際上還是在使用者的瀏覽器裡執行，不是跑在 Cloudflare 的伺服器上。
• OpenAI 讓符合資格的 ChatGPT Work 跟 Codex 使用者，能在桌面版瀏覽器裡發現並呼叫當前網頁提供的工具。Shopify 的工程師 Ilya Grigorik 也提到，ChatGPT 的內建瀏覽器可以用這些工具瀏覽商家的商品目錄、組裝購物車。

老實說，看到 Shopify、Cloudflare、OpenAI 在不到 48 小時內接連出手，我第一個念頭是「這不是在測試水溫了，是真的要推」。

「誰在幫你決定 AI 能做什麼」，這件事值得多想一步

原文裡有一段特別提出來：WebMCP 讓網站可以引導代理人的行為，但目前的實作已經牽涉電商平台、基礎設施供應商、代理人公司三方，網站經營者不見得是唯一能定義這個介面的人。舉例來說，Shopify 是統一在平台層級決定每個商店預設有哪些工具、工具的說明文字怎麼寫，公開的技術文件也沒講清楚個別商家能不能關掉某個工具、或修改它的描述。也就是說，你的品牌網站在 AI 眼中長什麼樣子，可能有一部分是平台幫你決定的，不是你自己寫的。

另外一個容易搞混的地方：WebMCP 解決的是「代理人到了你的網站之後能不能做事」，不是「代理人會不會找到你的網站」。文件裡講得很直接 —— 這不是排名、索引或引用機制，既有的搜尋、推薦系統還是決定使用者怎麼走到你的網站；WebMCP 只負責使用者或代理人抵達之後，接下來能做什麼。跟 MCP 比起來，WebMCP 的工具是暫時性的、綁在當前分頁上的，MCP 的遠端伺服器則可以在沒有開網頁的狀態下提供工具，這是兩者定位不同的地方。

安全疑慮，Chrome 自己都講得很白

代理人在瀏覽器裡運作時，可以直接使用使用者已登入的工作階段（session），這是它方便的地方，卻也代表它是在一個「已授權」的環境裡執行。Chrome 的安全指南點出兩種攻擊路徑：一種是「惡意宣告」—— 工具的名稱、參數或說明文字裡藏著想劫持代理人的指令；另一種是「污染過的回應」 —— 原本可信任的網站，回傳的即時資料裡混進了第三方內容（例如使用者留言）裡的惡意指令。因為語言模型會把所有文字，不管是指令還是資料，都當成同一串 token 來處理，這個區分本來就很難做到。

OpenAI 的作法是把網站提供的工具定義跟回傳結果，一律當成不可信任的內容處理，每一次呼叫都會經過安全審查，涉及購買、傳訊息、刪除、權限異動這類動作有額外規則，使用者也可以在瀏覽器設定裡直接關掉 Site tools。但這些防護不代表問題被解決了—— SEJ 自己另一篇報導的標題就寫得很直白：「Chrome 警告，WebMCP 可能被用來劫持 AI 代理人」。看到 Chrome 官方文件自己在講「這件事沒有 WebMCP 也存在，但用了 WebMCP 之後這幾個技巧特別重要」，結論是：新協定解決了效率問題，但沒有解決信任問題，這兩件事本來就不是同一回事。

整理了網路上怎麼看這件事？

翻了幾篇不同角度的文章，發現大家對 WebMCP 的評價各有不同：

• 樂觀行銷派：像 Semrush 的分析文，直接把 WebMCP 形容成「AI 版的響應式設計時刻」—— 當年手機剛普及，先做響應式設計的網站贏了流量，晚做的只能追著跑；他們認為這次也是同一套劇本，會用 WebMCP 的品牌會拿走更多「意圖明確」的流量，慢的會被跳過。
• SEO 轉型派：像 Neuronwriter 的文章，把這件事定位成從 GEO（生成式引擎優化）走向 AEO（代理人引擎優化）——結構化資料告訴 AI「這是什麼」，WebMCP 則告訴 AI「這裡可以做什麼」，兩者以後要一起做。
• 媒體評論派：像 Shelly Palmer 直接把這篇文章取名叫「行銷給機器人看的協定」，理由很簡單：Chrome 加 Edge 佔了全球瀏覽器將近四分之三的市占率，只要正式推出，這會是繼結構化資料之後 SEO 圈最大的一次技術轉變。
• 保守實證派：這也是 SEJ 這篇原文自己的立場——目前沒有任何官方數字證明 WebMCP 比模擬點擊更快、更可靠，工具呼叫次數、任務完成率、錯誤率、結帳轉換率統統沒有公開資料，Cloudflare Radar 也只追蹤「有沒有部署」，不追蹤「有沒有真的被用、有沒有帶來生意」。
• 標準未定派：WebMCP 目前只是 W3C Web Machine Learning 社群小組發布的規格草案，還不是 W3C 標準，也沒有進入標準軌道。Mozilla 對此立場中立，WebKit（Safari 背後的引擎）則明確表態反對，理由列了一長串：API 設計、功能重複、國際化、可攜性、隱私、安全、使用情境、討論場域都有意見。目前有支援的幾乎都是 Chromium 系瀏覽器加上 OpenAI 的桌面應用，Firefox 跟 Safari 都還沒跟進。

把這些立場排在一起看蠻有意思的：同一件事，行銷圈覺得是機會來了要快跑，工程標準圈卻連要不要做都還沒有共識。這種落差在新協定剛出來的階段其實很常見，但放在一起看，才會知道自己看到的只是其中一種聲音。

我的建議：先懂，不急著做

上週那篇 MCP 文章的結尾提到一種矛盾感 —— 開放標準是好事，但很多品牌根本還沒意識到「AI 讀不讀得懂你」已經變成基礎能力。但看完 WebMCP 這一輪的資訊之後，我自己多了一個保留：跟 MCP 不一樣，WebMCP 目前連跨瀏覽器支援都沒有，Safari 明確反對、Firefox 中立觀望，這代表現在就投入資源幫網站裝 WebMCP 工具，能觸及的使用者其實還很有限，比較像是「卡位」而不是「馬上見效」。

提醒你，如果你的網站是架在 Shopify 上，WebMCP 工具其實已經預設打開了，工具的說明文字是平台幫你寫好的，不是你自己決定的 —— 這代表你可能得主動去了解目前開放了哪些工具、寫的描述合不合理，而不是假設「反正沒開就沒事」。

提醒你第二點，如果你負責的是品牌官網或電商後台，現在還沒有一套業界公認的方法可以追蹤「這筆訂單是不是 AI 代理人幫忙下的」，這代表就算你真的做了 WebMCP，短期內也很難在報表上看到明確的成效數字，這點要有心理準備，不要期待馬上看到轉換率的變化。

說了這麼多，其實心裡的感覺是這股趨勢應該是擋不住的，三家公司在一週內同時出手不是巧合；但同時，一個連瀏覽器都還沒談攏的協定，到底會走多快、走多遠，我也沒有答案。與其急著找工程師去裝一個現在效果還無法驗證的功能，會先建議把「懂它在解決什麼問題」這件事做好，等它真的成為像 RWD 一樣的基礎建設時，至少不會是最後一個知道的人。