代理人抵達下單鍵：Shopify 以 WebMCP 開放結帳頁給瀏覽器 AI

多年來，結帳頁一直是網路上自動化的禁區。AI 代理人可以搜尋商品目錄、比較產品、甚至把商品放進購物車——但最後那顆「下單」按鈕，始終屬於拿著滑鼠的人類。2026 年 9 月 28 日，Shopify 跨過了這條線：瀏覽器內的 AI 代理人現在可以在 Shopify 商家的網站上讀取結帳頁面、修改內容並送出交易——而且不是靠截圖和點擊按鈕，而是透過平台直接註冊在瀏覽器裡的一組結構化工具。

這項公告透過開發者 changelog 發布，並由 TechCrunch 記者 Sarah Perez 詳細報導，將 Shopify 的 WebMCP 支援從 8 月 5 日上線的店面與購物車，一路延伸到結帳本身（包含 Shop Pay）。對這個支撐數百萬店家 的電商平台而言，這是全年打造的代理式商務（agentic commerce）技術棧的必然收尾；對整個產業而言，這是「該不該讓代理人買東西」這場分歧中，商業網路選邊站最清晰的一次表態。Amazon 一直在其平台上封鎖代理人的購買行為，Adidas 據報導也是如此。Shopify 選了反方向，而且用了一套設計嚴謹得罕見的技術方案。

四個工具，零爬取

整套機制建立在 WebMCP 之上——這是一個尚在 Chromium origin trial 階段 的提議中網頁標準（Shopify 正與 Google、Microsoft 共同制定規格），讓網頁能直接向瀏覽器註冊工具。在買家瀏覽器中運作的代理人透過 document.modelContext.getTools() 發現工具，用 document.modelContext.executeTool() 呼叫它們。在結帳頁上，共有四個工具可用：

• get_checkout——唯讀地取得目前結帳狀態、訊息與完成後的訂單細節。對 Shop Pay 買家，它會列出可用的已存卡片；在感謝頁上則回傳訂單收據。
• update_checkout——更新支援的欄位：買家聯絡資訊、物流方式、折扣碼、申報欄位與付款方式。它採 PUT 語意，代理人必須以最新的 get_checkout 回應為基礎，送出完整的目標狀態。
• complete_checkout——在買家確認後送出結帳。若出現付款驗證或審核步驟，買家會在同一分頁的頁面上完成；只有 completed 狀態才代表訂單成立。
• navigate_to_storefront——不 下單、不動購物車，把分頁帶回店面。

這些工具作用於買家自己瀏覽器中的有效結帳作業，與結帳 UI 共享同一份狀態，不暴露任何新的伺服器 API，商家也不需任何設定。底層上，Checkout WebMCP 實作的是 UCP 的結帳能力（dev.ucp.shopping.checkout），只是以瀏覽器註冊的工具取代伺服器端的 JSON-RPC，物件模型與 Shopify 既有的 Checkout MCP 伺服器完全對齊。Shopify 代理式商務的產品經理 Gil Greenberg 說得直白：「如果你的代理人在買家的瀏覽器裡運作，就用店面與結帳頁提供的 WebMCP 工具來高效完成下單，而不是去操作為人類設計的 HTML。」

同意是硬性閘門，不是核取方塊

這次發表與天真的「讓機器人買東西」功能最大的差別，在於設計裡有多少篇幅花在人類控制權上。文件明確要求：代理人在呼叫 complete_checkout 之前必須取得買家許可——展示目前的訂單與總額、取得同意，而且總額一變就要重新詢問。值得注意的是，Web Bot Auth 簽章、Shop Pay 授權、甚至 ready_for_complete 狀態，都不構成這份許可。同意是代理人必須主動完成的對話行為，不是它可以繼承的憑證。

付款面也刻意受限。Checkout WebMCP 不接受新卡片資料。依結帳類型不同，payment.instruments 只接受已存的 Shop Pay 卡片、訪客結帳用的 Shop Pay 授權、或僅帳單地址——其他付款方式一律由買家在結帳頁上親自選擇。當 3D Secure 驗證或阻斷式 UI 擴充功能出現時，工具會把控制權交還給人類。代理人無法取消結帳（沒有對應的 cancel_checkout），文件也告誡代理人絕不能繞過工具、自己去操作頁面控制項。

身分驗證同樣走「可驗證身分」的路線。代理人必須以 Web Bot Auth 簽署瀏覽器請求——產生 Ed25519 簽署金鑰、在金鑰目錄中公開公鑰、並向 Shopify 發布該目錄。沒有註冊金鑰，Shopify 的機器人偵測可能會降低代理人請求的優先順序或直接封鎖。還有一個細節會讓所有關注今年多起提示注入（prompt injection）事件的人感到安心：文件指示代理人把工具回應中的商家與第三方文字視為「結帳資料」，絕不能當成指令。

適用範圍與例外

這次推出涵蓋所有符合資格的商家，但「符合資格」有其份量。除非買家使用 Shop Pay，標準三頁式結帳不會註冊工具；B2B 結帳、嵌入式結帳、行動結帳 SDK、跨店家商品、草稿訂單、訂單編輯與收款全部排除在外。App 定義的結帳擴充功能互動，也由買家在頁面上自行處理。對能在遠端運行的代理人，Shopify 建議改用伺服器端的 Checkout MCP——兩條路徑，同一套 UCP 物件模型。

商業脈絡與程式碼同樣重要。Muse 與 Instinct 等頂尖 AI 代理人已與 Shopify 建立代理式商務的直接合作夥伴關係（Instinct 的合作就在同一天宣布），全部架在 Shopify 與 Google 共同開發的 Universal Commerce Protocol 之上。這為產業安排了一場乾淨的自然實驗：一個巨型平台讓代理人走結構化、需身分驗證、以同意為閘門的協定；它最大的對手則把代理人完全擋在外面。最可能的結局不是誰贏，而是分道揚鑣——對代理人友善的商家累積代理式需求，圍牆花園則守護自己擁有的結帳關係。

更深遠的影響在網路本身。如果 WebMCP 從 origin trial 走向正式標準，Shopify 示範的這套模式——網頁在人類 HTML 之外註冊機器可讀的工具，並在協定層強制密碼學代理人身分與同意機制——就會成為任何交易型網站都能採用的範本。下單鍵不再是電商中僅存的人類專屬元素。它現在是一個 API——一個在觸發之前會先徵求許可的 API。

（資料來源列於文章 frontmatter。）