Commerce.com 與 Cloudflare 推出 WebMCP，將購物工具帶到網店

Commerce.com 與 Cloudflare 於 10 月 21 日宣布推出以瀏覽器為本的購物工具，Cloudflare 表示服務覆蓋近 100,000 個網域。Commerce.com 的 WebMCP 推出計劃讓相容的 AI 代理可執行結構化網店操作，同時將結帳程序保留給商戶。WebMCP 是一種建議中的瀏覽器介面，讓網站可向 AI 助理公開可呼叫的工具。

眼前的改變關乎代理如何與商店互動。助理不再需要解讀按鈕和產品頁面，而是可要求網店執行受支援的操作。這令界定代理實際可做事項的責任，更多落在商戶和平台身上。

核心張力在於結構化購物工具，與代理從供人使用的介面推斷操作之間的差異。Shopify 和 Google 亦正透過其 Universal Commerce Protocol 推動結構化商務，該協議將商業系統之間的互動標準化。Commerce.com 的瀏覽器部署處理了這一轉變中的特定部分：協助助理在現有網店內操作，而毋須每個商戶重新建置網店。

Commerce.com 的 WebMCP 推出計劃改變網店介面

這項部署令代理存取成為平台功能，而不是每個參與商戶各自進行的獨立項目。

Cloudflare 對其網店部署的說明提到，系統透過邊緣網絡交付腳本，即經由提供網站服務的基礎設施加入程式碼。Commerce.com 已透過該基礎設施服務近 100,000 個網域。

兩家公司描述了一道連接 Commerce.com 現有購物工具與訪客瀏覽器的橋樑。Cloudflare 負責交付連線，而 Commerce.com 保留底層購物邏輯。個別商戶可透過設定選擇退出，該設定會告知 Cloudflare 對其主機名稱套用的規則。

這種架構相當重要，因為平台層級的開關否則會形成非此即彼的選擇。共用基礎設施需要能夠分辨參與商店，以及其擁有人拒絕此功能的商店。在這裏，分發與商戶意願一併處理。

Commerce.com 的瀏覽器購物公告表示，合資格的 BigCommerce 商戶會預設獲得此功能。公告提到產品搜尋、比較、建立購物車，以及交由商戶處理結帳。

公告中購買外套的例子屬說明性質，而非量度客戶成果的證據。購物者要求助理尋找合適商品，助理則準備購物車。買家隨後在商店完成結帳。

這個區分令範圍保持清晰。尋找產品、選擇款式、準備購物車和授權購買，代表不同責任。一個成功的購物助理，必須如同謹慎處理個別步驟般，審慎處理這些責任的界線。

對商戶而言，有用的改變是通過商店既有營運方式新增了一條路徑。助理成為購物體驗的另一名參與者。商戶仍需決定這名參與者可呼叫哪些操作。

對平台營運者而言，這項部署顯示了代理支援的另一種分發模式。為眾多商店提供服務的基礎設施可交付共用介面，而商務平台則提供商業行為。這減少了各個網店分別修改的需要。

不過，共同交付並不代表每間商店在商業上都相同。銷售可配置設備的商店，與銷售直接明瞭服裝目錄的商店，面對不同要求。公開操作的質素仍取決於這些差異。

因此，Commerce.com 的 WebMCP 推出計劃值得作為一項基礎設施決策而受到關注。其重要性來自將代理介面置於平台的日常交付流程之中。商戶獲得一項預設功能，同時可決定是否保留它。

這亦改變了問責應歸屬何處。若助理遇到錯誤的產品描述，便需要處理產品目錄。若它錯誤呼叫某項操作，調查必須同時審視助理的請求和商店的回應。

共用介面令這種分工更清晰。相比一段無法解釋的點擊記錄，它為參與者提供了更明確的位置調查失敗原因。它是否能持續改善結果，仍需要實際購物過程的證據。

平台現在必須界定購物代理可做甚麼

結構化購物將可靠性問題的一部分，從頁面解讀轉移至商業操作的設計。

壓力首先落在商務平台及建立其購物介面的開發人員身上。吸引人的網店可協助人們瀏覽。代理同樣需要對可用操作及其後果有明確描述。

Google 的 WebMCP 文件說明了工具探索、已定義的輸入資料及共用頁面情境。文件亦指出限制，包括需要直接造訪網站以探索工具，以及複雜介面所需的額外工作。

這些限制有助解釋為何這項公告現時具有意義。瀏覽器工具已進展至足以讓商務平台嘗試大規模分發。然而，能否使用仍取決於相容的瀏覽器，以及代理是否選擇使用此介面。

商戶不能僅因有工具存在便推斷需求。商店可公開出色的購物操作，卻只從助理獲得少量流量。同樣地，當可用操作無法表達買家需求時，流入的代理流量價值不大。

實際回應需要產品目錄、網店和平台團隊協調。產品屬性必須支援有意義的比較。購物車操作必須保留選擇。即使由助理執行中間工作，面向客戶的說明仍必須易於理解。

試想一位假設中的購物者，要為雨天通勤尋找一件外套。產品搜尋可能同時返回防水和抗水款式。助理仍需要區分這些特性，並說明結果是否符合要求。

結構化操作可更直接地返回產品資訊。這並不代表資訊完整，也不代表助理正確理解購物者。介面改善了取得證據的途徑；判斷仍是另一項工作。

這令產品目錄質素變得更為關鍵。遺漏物料細節或尺碼標籤不一致，會影響助理能否有把握地作出推薦。零售商應將這些弱點視為營運問題，而不是假定瀏覽器介面會作出補償。

同樣的道理亦適用於人類購物者的無障礙體驗。清晰屬性、易明的錯誤訊息及可預期的購物車行為，有助人們評估購買決定。代理支援為維持這些基礎提供了另一個理由。

購物代理的開發人員亦面對相應壓力。他們需要識別可用工具、遵守其限制，並在不誇大完成情況下處理失敗。助理表示商品已準備好時，應對應可驗證的購物車狀態。

用戶體驗亦需要清晰地轉交回買家。購物車交接應說明已選商品、尚未解決的選擇及餘下步驟。否則，自動化只會將混亂推近付款環節。

對產品經理而言，這建立了一個更具體的評估框架。相關問題變成助理能否準確完成明確界定的購物任務。單憑令人信服的對話，無法證明已達成該結果。

記錄這些測試的團隊，可將規格和發現保留在共用審查流程中。可搜尋的技術知識庫有助工程師將失敗情況與預期行為作比較。

更廣泛的影響是責任的轉移。平台日益需要向軟件參與者以及人們解釋其商店。Commerce.com 的部署將這項要求帶入日常網店營運。

結構化操作處理的問題，與自主結帳不同

明確的購物操作可縮窄模糊空間，但買家的意圖仍需要詮釋。

在概念層面，這個機制很直接。網站聲明一項可用操作及其預期資訊。代理可呼叫該操作，而毋須從周遭視覺元素重建其用途。

這改變了進入商店功能的路徑。它不會消除商店規則、取代產品目錄，或判定哪項產品最能滿足買家需要。這些責任仍然各有不同。

這種分離提供了一種有用方式，以評估有關 AI 購物的說法。某個系統可能改善產品檢索，卻對推薦質素幫助不大。另一個系統可能準確準備購物車，卻產生遺漏重要限制的說明。

因此，評估應區分互動準確度與購買適切性。前者關乎所要求的操作是否正確發生。後者關乎該操作是否推進了購物者的實際目標。

例如，一個假設中的助理可能正確加入所需尺碼的外套。若它忽略最終銷售限制，即使其技術執行無誤，買家仍未獲得足夠資訊。購物成果取決於兩個面向。

Commerce.com 的 WebMCP 推出計劃正處於邁向明確商業介面的更廣泛趨勢之中。Shopify 提供了有用的比較，因為它同樣將商戶能力視為軟件可探索及使用的事物。

Shopify 的 Universal Commerce Protocol工程說明提到，這是一項與 Google 共同開發的開放商務標準。商戶聲明能力，代理協商受支援功能，而交易可涉及由人員接手。

這些方式在不同層面處理相關問題。WebMCP 關乎網頁應用程式在瀏覽器情境中公開的工具。UCP 描述參與系統之間的商業能力和互動。

這個區分避免了誤導性的非勝即敗比較。瀏覽器介面與商務協議未必需要互相取代。其實際價值取決於它們能否在不同入口點保留一致的商業行為。

商務能力模型將平台定義為能力的使用者，企業則是提供者。這個框架突顯了介面之下的商業關係：一個系統要求執行某項操作，而另一個系統控制該操作。

對商戶而言，重要的架構問題在於一致性。在瀏覽器內運作的助理，以及透過獨立整合連接的另一個助理，應遇到相容的規則。否則，購物結果便取決於買家恰好使用了哪一條路徑。

支援服務的一致性同樣重要。當某項選擇無法提供，或購物車需要補充資料時，客戶應收到清晰易明的解釋。回應應反映商戶的實際政策。

正是在這裏，結構化操作帶來更佳工程設計的機會。請求與回應可根據既定預期進行評估。團隊可以檢視失敗是源於資料不足、輸入被拒，還是不支援的操作。

然而，定義完善的操作仍可能範圍過廣。將選擇、購物車變更與確認購買結合在一起的工具，會增加誤解的空間。職責劃分得更清晰，會令後果更容易說明及評估。

因此，對這項部署最有力的解讀是務實的：它為代理提供了更明確的方式與商店互動。至於自主購買、更佳推薦或商業回報的說法，則需要各自的證據支持。

對買家而言，這項區分有助建立知情的預期。助理可以減少重複互動，同時讓重要決定保持清晰可見。這種安排的質素，取決於介面如何清楚保留買家的角色。

商戶可選擇退出，並不能解決採用、安全或準確性問題

商戶控制權屬於部署層面的特性；值得信賴的購物體驗需要整個互動過程的證據。

已公布的退出選項回應了一個特定問題：個別商戶能否拒絕瀏覽器整合？這是一項有用的控制措施，但不能證明參與的代理行為有多準確，亦不能說明購物者如何理解其操作。

已公布的網域數目同樣需要審慎解讀。網域反映的是所報告的部署覆蓋範圍，並不代表活躍購物者、已完成購物車、獨立商戶，或可歸因於此功能的購買數目。

在商業角度評估這項公告時，這些區分十分重要。廣泛的介面部署代表潛在觸及範圍，但實際使用量、成功結果及新增商業價值仍有待衡量。

截至 10 月 22 日，本文檢視的公告未有提供受控比較，以評估購物結果。它們沒有證實轉換率有所提升，亦沒有量化參與商店之間的失敗情況。這些結果仍是有待報道的問題。

瀏覽器相容性構成另一項界線。商戶可以在購物者所選瀏覽器支援預期工作流程之前啟用整合。網站上的部署與訪客實際可用性，是兩個不同條件。

現行的 WebMCP draft 明確指出，它並非 W3C Standard。其安全討論亦指出惡意指令、誤導意圖及不必要資訊披露等風險。

這些疑慮需要精確處理。提示詞注入是指不受信任的內容試圖改變助理的行為方向。結構化工具為代理提供更清晰的操作，但代理仍會遇到需要設立適當信任邊界的描述與結果。

有用的介面應讓商業後果清晰可見。搜尋目錄與更改購物車應有可區分的含義。買家應了解助理何時只是收集資訊，以及何時已改變其購物狀態。

舉例而言，購物者可能會問某個配件是否適用於現有裝置。該請求不應在未經明確同意下，變成將配件加入購物車的授權。即使工具完全按實作執行，問題仍在於意圖。

資訊分享同樣值得仔細審視。購物請求應只提供完成工作所需的資料。額外的個人背景資料應有合理原因，而非成為使用助理的自動後果。

因此，商戶退出選項與買家授權處於不同層面。商店擁有人可決定是否開放某項功能；買家在瀏覽期間，仍需要對助理的行為擁有實質控制權。

準確性亦取決於底層資訊的新鮮度及完整性。商店的直接回應是有用的證據來源，但不能保證每項產品屬性都能回答購物者的問題。

這為獨立測試建立合理標準。評估者應包括含糊的請求、缺貨款式、被中斷的工作階段，以及從被拒操作中復原的情況。簡單示範展示的是預期路徑；困難案例則揭示界線所在。

商業衡量同樣需要審慎處理。由代理協助建立的購物車，可能屬於本來就會購買的購物者。歸因分析需要分辨助理的參與，與其對結果的實際貢獻。

這些不確定性並不會抹殺這項部署的重要性。它們界定公告所證實的事項，以及仍未量度的部分。基礎設施的說法與客戶結果的說法，應分開評估。

對商戶而言，維持這項區分有助作出更佳決策。保留此功能可以是合理的實驗；擴大預期則應建基於客戶體驗、營運影響及復原可靠性的證據。

Commerce.com WebMCP 推出後值得留意的事項

下一項有用的證據，將依次連結瀏覽器可用性、購物準確性及商戶決策。

未來數月的第一個訊號是實際的瀏覽器存取能力。留意有文件支持的相容性，讓一般購物者毋須特殊測試設定也能使用支援的操作。這決定了部署有多大部分可被觸及。

更廣泛存取的證據，會加強將此介面視為營運渠道的理由。若仍依賴專門環境，其短期相關性便會受限。兩種結果都比單看網域數目更具參考價值。

瀏覽器公告亦應說明使用者體驗。購物者需要理解助理如何發現可用操作，以及何時會要求確認。若可用性欠缺易明的互動模式，商戶所面對的渠道仍不完整。

第二個訊號是有關任務完成情況的獨立證據。有用的測試會讓相同購物請求在可比較的商店中進行，並記錄錯誤。測試應檢視助理是否選擇了預期產品，並保留所要求的選項。

最具參考價值的結果會包括復原情況。當商品無法提供時，系統應給出易於理解的回應。當購物車操作被中斷時，購物者應清楚知道已改變甚麼，以及哪些事項仍未完成。

這些證據有助區分結構化存取帶來的改善，與助理本身的改善。改良後的模型可以令任何一種介面看似表現更佳。審慎的比較應說明改變的是哪個組成部分。

結果亦應保留購物車準備與完成購買之間的區別。將兩者合併成單一成功指標，會掩蓋購物者在哪個環節介入，也可能模糊助理是完成了任務，還是將任務交還給使用者。

互動錯誤減少的證據，將支持這項部署的技術理據。若款式、購物車狀態或交接環節持續存在含糊之處，便可顯示介面需要改進的地方。對正在評估是否參與的商戶而言，兩種結果都有參考價值。

第三個訊號是商戶在接觸實際使用情況後的行為。留意商店為何保留此功能、停用它，或要求修改的具體說明。其決策可揭示全平台推出未必能捕捉到的要求。

單看保留功能仍需要背景資料。商戶可能在未見明顯流量下維持預設啟用。更有力的證據會將參與情況與已記錄的使用量、客戶回饋及營運影響說明配對。

同樣地，停用功能並不會自動證明該方法失敗。商店可能有專門要求或不相容的工作流程。原因比開關方向的標題式結論更重要。

對開發者而言，這些訊號提供了一種聚焦的追蹤方式：追蹤相容性變化、比較任務結果，並記錄商戶決策背後的條件。合併來看，它們比零散示範提供更有用的圖像。

對企業買家而言，相同證據可支持採購討論。要求供應商以平實語言說明支援的操作、授權邊界及失敗處理方式。方案應將整合與可觀察的客戶結果連結起來。

Commerce.com WebMCP 的推出，令支援代理的店面成為具體的平台決策。下一章取決於這種分發是否能帶來商戶與買家願意持續使用的購物體驗。公開證據可以在不預設結果的情況下，釐清這個進程。

如果你管理網店，先記錄客戶實際難以完成的購物任務。向你的平台查詢助理可執行哪些操作，以及買家在哪裏重新接管控制權。然後根據這些預期，檢視具代表性的工作階段，包括未成功的個案。在評估時，將瀏覽器相容性、購物車準確性及客戶理解分開處理。開放工具的商店已踏出技術一步；協助人們完成預期任務的商店，才帶來客戶效益。在擴大助理角色前，先追蹤連結這些步驟的證據。你的購物體驗中，哪個部分最能受惠於更清晰、明確定義的操作？