WooCommerce 代理商務：讓 AI 代理下單的接軌準備

代理商務（agentic commerce）指的是 AI 在商品的推薦、發現與購買過程中扮演主動角色：使用者可向 AI 助理說明需求，由代理協助搜尋、理解商品並引導交易。結帳可在代理介面或商店完成。對 WooCommerce 商店而言，這代表商店要能被代理讀取、被代理信任，接著被代理下單。WooCommerce 官方的 Agentic Commerce 頁已經把這條路拆成四個協定層：兩個已經進到 WordPress 核心與 WooCommerce 主程式，兩個標示為 coming soon，分別接上 Stripe 與 Google 兩大陣營的購物協定。

這份指南從商店端看代理商務：兩套購物協定（Agentic Commerce Protocol 與 Universal Commerce Protocol，下稱 ACP 與 UCP）各自怎麼走完一筆訂單、WooCommerce 官方路線圖走到哪裡、商店經營者現在能做哪些準備，以及資格範圍與第三方外掛的風險評估。協定層的完整總覽與命名辨正，站內另有通用商務協定 UCP 深度解析。對話推薦端的品牌經營，見AI 購物助理優化指南。

代理商務是什麼：AI 從推薦者變成下單者

談 AI 對電商的影響，常被談成推薦與導流：AI 整理商品資訊，使用者自己點進網站完成購買。代理商務把界線往前推了一步。WooCommerce 官方頁對它的定義寫得精簡：AI 在商品如何被推薦、被發現、被購買這件事中扮演主動角色。開發者部落格 2025 年 10 月的路線圖文章描繪的情景更具體：顧客對 AI 助理說要幫愛園藝的妹妹挑禮物，或要補購平常喝的咖啡豆，AI 搜尋你的目錄、理解商品內容，然後在不讓顧客踏進商店網站的前提下完成整筆購買。

這個轉變對商店端有兩層意義。第一層是商品發現：代理要先讀得到、讀得懂你的商品資料，才有機會把你列入候選。第二層是交易完成：代理要能用安全的方式代替使用者結帳，而商店要能接住這筆訂單。同一篇文章把這兩件事並列為代理商務的關鍵能力，並且指出這正是團隊努力的方向。換句話說，被 AI 代理購買聽起來像行銷話術，背後卻是一組要分頭準備的工程與資料功課。

有一個容易混淆的邊界先畫清楚：代理商務處理的是交易與資料介面，不是曝光排名的保證。OpenAI 在公告裡明講，商品結果是自然且無贊助的排序，收費也不影響商品結果。Google 端的結帳功能也同樣建立在既有的商品資料與清單資格上。協定接軌提供交易介面。商品是否進入助理的結果，仍取決於通路資格與對使用者需求的相關性。商品資料品質是商店可先改善的一環。想深耕推薦端的讀者，可以併讀AI 代理的運作原理。

WooCommerce 在這波轉變的位置

2025 年 10 月，WooCommerce 在開發者部落格表示，它是與 Stripe 合作支援 Agentic Commerce Protocol 的平台之一，並預告 WooCommerce 10.3 將引入第一版 WooCommerce MCP（Model Context Protocol）。官方對這條路線的姿態是漸進的：先做讓 AI 讀懂與操作商店的基礎層，再往消費端購物與結帳擴展。這個順序值得注意，因為它決定了商店端準備工作的先後：資料與介面先於交易。官方也同時提到，為了確保交易順暢且安全，已經在嚴格測試 Google 與 Stripe 兩家夥伴的解決方案。

開源是 WooCommerce 在官方論述裡一再強調的優勢。官方的說法是，因為開源，你的商店與開放標準相容，可以快速採用新協定，不必等待單一公司的時程，並且可以按自己的時程採用新協定。對照封閉平台的處境，協定支援取決於平台業者的決策，WooCommerce 商店至少在架構上保有多一層主動權。官方頁還有一句值得記下的大方向：能與每一個 AI 助理合作、而不只服務單一廠商的商店，將有更高的能見度。平台選擇的整體比較，可參考電商平台比較指南。

兩套購物協定：ACP 與 UCP 的分工

商店端要接軌的購物協定，目前公開資料裡與商家直接相關的兩套是 ACP 與 UCP。ACP 的全名是 Agentic Commerce Protocol，Stripe 文件稱它是由 Stripe、OpenAI 與 Meta 建立的開放標準，規格儲存庫顯示它由 OpenAI 與 Stripe 維護、目前為 beta 狀態，採日期版本制，授權是 Apache 2.0。UCP 的全名是 Universal Commerce Protocol，2026 年 1 月 11 日由 Google 在官方部落格正式發表，與 Shopify、Etsy、Wayfair、Target、Walmart 協作開發，並有超過 20 家生態系夥伴背書，名單含 Adyen、美國運通、Best Buy、Flipkart、Macy's、Mastercard、Stripe、Home Depot、Visa 與 Zalando。

WooCommerce 官方 2026 年 8 月的準備指南給了一個好用的心法：把每個協定當成又一條銷售通路，無須把它視為必須押注的競爭標準。原文的類比是，商家同時收 Visa、Mastercard 與 American Express，從不在其間二選一，每張卡觸及不同的顧客群。AI 協定同理：不同協定可接觸不同購物者。商品能否出現在助理的結果中，仍取決於通路資格與相關性。同一篇文章還把四個協定分成兩組：MCP 與 Abilities API 是消費者看不到的幕後基礎，ACP 與 UCP 才是消費者會接觸到的通路。

兩套協定在設計上有共同語彙：都強調商家維持 merchant of record 的身分與完整的顧客關係，付款都以權杖化為設計原則（UCP 規格層以權杖化付款與可驗證憑證通訊，Google 端結帳實作則使用 Google Wallet 已存的付款憑證），OAuth 2.0 在 ACP 用於委託驗證，在 UCP 用於帳號連結，也都相容 MCP 這類代理通訊標準。差異在陣營與入口。ACP 的消費入口是 ChatGPT 這類 AI 助理，UCP 的入口是 Google 的 AI Mode 與 Gemini。對商店來說，兩者各有資格條件，屬於並行的兩條通路。

UCP 採 Apache 2.0 授權，UCP 官方規格站的完整技術規格、文件與參考實作放在公開的 GitHub 儲存庫。協定正朝住宿與餐飲等產業擴展，設計目標是涵蓋從發現到結帳及售後的流程。ACP 規格採 YYYY-MM-DD 日期版本制。2025 年 9 月 29 日為首版，2026 年 4 月 17 日版列有購物車、饋流、訂單、驗證與 MCP。每個版本是該時間點規格的完整快照。規格文件裡的設計提案涵蓋代理商務結帳、能力協商、付款處理器、賣家背書的付款處理器與折扣擴充等主題。對實作者來說，這代表兩套標準都還在移動，整合時要看準版本。

ACP 走完一筆訂單：Instant Checkout 的商店端視角

ACP 最具體的消費端實例，是 2025 年 9 月 29 日上線的 Instant Checkout。OpenAI 的公告寫明當時的範圍：美國的 ChatGPT Plus、Pro 與免費使用者，可以直接在對話中向美國的 Etsy 賣家購買，超過一百萬家 Shopify 商家列為陸續加入，首發只支援單品購買，多品購物車與更多商家、地區在其後的計畫中。同一篇公告給出市場基數：每週有超過 7 億人為日常任務使用 ChatGPT。這個基數，是商店端無法忽視的新櫃位。

從商店端看，這筆交易長什麼樣子？OpenAI 的說明是：使用者看到支援 Instant Checkout 的商品，點下 Buy，確認訂單、運送與付款細節，不離開對話就完成購買。訂單、付款與出貨由商家用既有系統處理，ChatGPT 的角色是使用者的 AI 代理，像一位數位個人採購，在使用者與商家之間安全地傳遞資訊。金流上，商家收到訂單後可以接受或拒絕，用既有的付款業者處理收款，出貨與客服照原本的流程走。

商家的控制權有幾個層次。已經用 Stripe 收款的商家，最快一行程式碼就能啟用代理付款。用其他付款業者的商家也可以參與，走 Stripe 的 Shared Payment Token API，或採用 ACP 規格裡的委託付款設計，不必換掉既有的付款業者。ACP 官方規格站的常見問答也明講，任何 AI 代理都能呼叫支援 ACP 的結帳，商家可以逐代理、逐筆交易或用自訂邏輯決定接不接受。OpenAI 是第一個以 ChatGPT 實作 ACP 的平台，Stripe 則是第一家以 Shared Payment Token 相容的付款業者。規格站對商家價值的主張同樣值得引用：商家保住顧客關係與 merchant of record 的身分，繼續掌控哪些商品可以賣、商品怎麼呈現、訂單怎麼出貨，而且實體商品、數位商品、訂閱與非同步購買都在支援的商務型態內。

信任設計是 ACP 論述的核心，也是商家向顧客解釋時可以引用的框架：使用者明確確認每一個步驟才行動，加密的付款權杖只在使用者許可下、對特定金額與特定商家授權，共用給商家的資料限縮在完成訂單所需的範圍。Stripe 文件把 ACP 拆成五個組成積木：代理商務結帳，負責建立、更新與完成結帳階段，涵蓋購物車管理、運送選項與付款處理。購物車與饋流，讓代理在結帳前瀏覽目錄與管理購物車。委託付款，經付款處理器在買家、代理與商家之間安全傳遞付款權杖。委託驗證，以 OAuth 2.0 讓代理經授權代表買家與商家往來。訂單與 webhook，追蹤訂單確認、出貨、送達與退款的生命週期更新。費用結構方面，OpenAI 的說法是商家對完成的購買支付小額費用，對使用者免費，不影響價格，也不影響商品排序。規格站的授權設計是 PCI 合規訴求：安全地把買家的付款憑證傳給 AI 代理，而不暴露底層的付款憑證。

整合形態上，ACP 對技術棧的態度是開放的。規格站明確標示它相容 REST 與 MCP 兩種發布方式，結帳設定可以用傳統 API 發布，也可以用 MCP 發布，並且與任何整合模式和技術棧一起工作，商家建立的代理端點要接的是既有的商務後端與付款處理器。這一點對 WooCommerce 商店有實際意義：WordPress MCP Adapter 讓代理呼叫商店能力。ACP 也容許用 MCP 發布結帳設定。兩者採用相同通訊標準，具體功能與設定仍須分別依各自文件處理。

UCP 的商店端視角：Merchant Center 饋流是起點

UCP 端的商店側邏輯圍繞 Google 既有的零售基礎建設。Google 開發者文件的定位是：採用 UCP，在 Google 搜尋的 AI Mode 與 Gemini 上啟用代理動作，從直接購買開始。整合之後，商家可以在 AI Mode 與 Gemini 的合格商品清單上實作結帳按鈕。資格方面，Google Merchant Center 說明中心寫明：這套結帳功能目前適用於美國、加拿大與澳洲的商品，且僅限獲選商家與合作夥伴，有意參與的商家需符合要求並提交意向表單，完成技術實作。

消費端體驗的關鍵差異在結帳位置。說明中心的區辨是：既有的結帳按鈕，交易發生在你的網站上。新的結帳體驗，結帳直接發生在 Google 的介面上，而商家維持 seller of record 的身分，並可能透過自訂整合保留特定結帳需求。付款走 Google Pay，使用者在 Google Wallet 裡已存的付款與運送資訊，付款憑證形態是存在 Google Wallet 的標準 FPAN（Funding Primary Account Number），官方部落格另提到 PayPal 支援在其後加入。商品端有一個硬性條件：只有使用 native_commerce(checkout_eligibility) 這個商品屬性的清單，才會顯示這個體驗的 Buy 按鈕。參與不需要在自己的結帳頁放 Google Pay 按鈕，但需要建立 Google Pay 與 Wallet Console 帳號。

整合方式有兩條。原生結帳是把結帳邏輯直接整合進 AI Mode 與 Gemini，這是預設路徑。內嵌結帳是給特定核可商家的選用路徑，適合品牌呈現高度客製或結帳流程複雜、需要 iframe 方案的商家。Google 也特別區辨了兩個名詞：代理結帳功能是 Google 的 AI 代理依顧客指示直接在商家網站上購買。UCP 則是標準化 AI 代理與商家後端之間資訊交換的開放協定，交換通道可以是 API、MCP 或 A2A（Agent2Agent）。

UCP 的規格層還有幾個值得記下的設計。Google 工程團隊的技術拆解說明了動機：傳統基礎設施讓商家面對 N 乘 N 的整合瓶頸，為每個介面建一條客製連線，拖慢整個生態轉向代理商務，UCP 的解法是把 N 乘 N 的複雜度收斂成單一整合點。能力發現採 /.well-known/ucp 的標準 JSON 清單，商家公布支援的服務與能力，代理動態讀取，不必逐一硬整合。付款架構把消費者用來付款的工具與付款處理器分開。結帳能力可以選 REST API binding 或 MCP binding。規格站列出的核心能力有五項：目錄搜尋查閱、購物車建立、身分連結、結帳與訂單管理，並以開放錢包生態為目標，讓買家用自己偏好的付款方式。Google 端的開發者文件也預告了路線圖上的多品購物車、忠誠計畫帳號連結與售後追蹤退貨支援，Google 部落格則表示將逐步擴展到全球、增加相關商品發現與忠誠回饋等功能。

對已經在經營 Google 通路的商家，這裡有一個好消息：UCP 的地基就是你熟悉的東西。開發者文件直接說，用既有的 Merchant Center 帳號購物饋流，在發現階段接住高意圖顧客，並且強調 Merchant Center 會持續扮演備妥商品資料的中樞。WooCommerce 官方也持同一判斷：Google 版本的 UCP 跑在 Merchant Center 上，用你的結構化商品資料，先把饋流備好，通路開放時你已就位。AI Mode 對搜尋整體的影響，可另讀AI Mode SEO 因應指南。

Google 端的周邊佈局：Business Agent 與新資料屬性

Google 在發表 UCP 的同一篇公告裡，還介紹了兩項與商店端直接相關的佈局。第一項是 Business Agent，讓購物者直接在搜尋上與品牌對話，官方的比喻是一位能用品牌口吻回答商品問題的虛擬銷售人員，上線時的合作零售商包括 Lowe's、Michael's、Poshmark 與 Reebok，符合資格的美國零售商可以在 Merchant Center 啟用並自訂這個品牌代理。官方的預告是，商家之後能用自有資料訓練代理、取得顧客洞察、提供相關商品優惠，並在體驗內開放直接購買，含代理結帳。

第二項是 Google 公布的 Merchant Center 數十個新資料屬性，為對話商務時代的發現而設計，適用面涵蓋 AI Mode、Gemini 與 Business Agent。內容方向超出傳統關鍵字，包含產品常見問答的答案、相容配件與替代品，官方規劃先向一小群零售商推出，之後逐步擴大。對商店經營者的意義很實際：商品資料的準備範圍正在從價格、規格、圖片，擴大到常見問答與關聯商品。商家可先整理常見問答、相容配件與替代品資料，待欄位開放後依要求填入。

WooCommerce 官方協定狀態：兩個已內建，兩個 coming soon

WooCommerce 官方頁有一張協定狀態表，把商店要接的四個協定攤開，這是判斷現在能做什麼的最直接依據。狀態分兩組：已上線的 MCP 與 Abilities API 屬於幕後基礎，讓 AI 讀取與操作商店。標示 coming soon 的 UCP 與 ACP 屬於消費者端的購物通路，分別走 Google 與 Stripe 的接軌路線。官方同時承諾，隨新標準出貨會持續更新這張表。

把這張表讀成行動順序：基礎層已經在你升級到新版本 WordPress 與 WooCommerce 時一起進來了，你的責任是保持版本在線與資料乾淨。通路層則要分頭準備：Google 線靠 Merchant Center 饋流，Stripe 線靠付款延伸的安裝與候補名單。WooCommerce 官方準備指南的說法是，幕後這些零組件由 WooCommerce 負責建造，商家要做的是維持在最新版本上、讓資料保持乾淨。官方也提醒，這些協定會分批開放給特定商家群，關注後續的取用資訊與商家要求。

管店層：MCP 與 Abilities API 讓 AI 助理操作你的商店

已經內建的兩個協定，先解決 AI 認識你的商店這件事。Abilities API 是 WordPress 核心的能力登錄機制，官方開發者部落格 2025 年 11 月的介紹文給的定義是：一組一級的跨情境功能 API，讓其他工具與應用程式得以和 WordPress 介接。它提供一個中央登錄表，把 WordPress 的能力以機器可讀、人類也友善的格式註冊，設計目標有三：可發現性，經標準介面列出與檢視能力。互通性，統一 schema 讓互不相干的元件組合工作流。安全優先，明確控制誰或什麼能呼叫能力。伺服器端的註冊、取得與執行，含 REST 支援，已併入 WordPress 6.9，2025 年 12 月初起開箱即用。核心隨附三個預設能力：取得網站資訊、取得目前使用者資訊、取得執行環境資訊。MCP 的整體背景，站內有MCP 協定完整介紹。

MCP Adapter 是疊在 Abilities API 上的翻譯層，2026 年 2 月的官方開發者部落格介紹了它，屬於官方 AI Building Blocks 計畫的套件。它把 WordPress 6.9 引入的 Abilities API 轉成 MCP 的工具與資源，讓 Claude Desktop、Claude Code、Cursor 與 VS Code 這類 AI 工具直接發現並呼叫 WordPress 能力。官方的形容是，如果你的程式已經註冊能力，距離讓 AI 代理使用它只差一步。傳輸方式有 STDIO 與 HTTP 兩種，本地開發環境走 STDIO 加 WP-CLI，對外網站走 HTTP。若要讓能力經 MCP Adapter 預設伺服器供應，註冊時須明確標記該能力可透過 MCP 公開，實際呼叫仍受權限檢查。

WooCommerce 把自己的商店操作註冊成一組專門設計的能力。依官方開發文件的 MCP 整合頁，目前涵蓋商品管理與訂單管理兩組：商品可帶篩選與分頁查詢、可建立、可更新、可刪除。訂單可帶篩選與分頁查詢、可更新狀態、可加上備註。WooCommerce 官方頁的說法更直白：AI 助理已能讀取你的商品目錄、查訂單狀態、理解商店能力，而 WordPress 的 REST 與 Abilities API 讓 AI 讀到完整的商品目錄、頁面、文章與評論來輔助發現。開發者部落格補充了方向：MCP 與既有的 REST 及 Store API 並用，目標是從商店管理擴展到消費購物與結帳，也就是代理商務本身。想看實際把 WordPress 接進 AI 工具鏈的操作，可參考Claude Code 串接 WordPress MCP 的實戰教學。

文件裡還有三個架構決策值得知道。官方首選的實作路徑是專門為代理工作流設計的領域能力，而不是把每個 REST 形狀的 operations 自動投影成 MCP 工具，這代表 AI 拿到的介面是為代理的任務形態量身設計的。第三方外掛可以用 WordPress Abilities API 註冊自己的能力，掛進同一套 MCP 服務，等於整個外掛生態都能長出代理介面。而隨著 WooCommerce 核心與外掛暴露愈來愈多能力，商店擁有者就能用分離的 MCP 客戶端或 WordPress 原生介面與它們互動，開發者部落格連 AI 聊天機器人與命令面板這類原生介面都列進去了。

動手啟用前，有幾個官方標註必須原樣轉述。MCP 整合目前是 developer preview，實作細節、API 與整合模式都可能隨版本變動，可能出現破壞性變更，上線前要充分測試。功能由 mcp_integration 這個 feature flag 控制，可用程式碼或 WooCommerce CLI 開啟。能力供應經 MCP Adapter 的預設伺服器端點，WooCommerce 專屬的舊端點已標為棄用，新整合不該再使用。

安全設計是這一段的重點，也是商家最容易踩雷的地方。遠端 HTTP 連線的驗證使用 WordPress 使用者名稱加應用程式密碼，官方明文警告不要用帳號登入密碼，也不要用 WooCommerce REST API 的金鑰。應用程式密碼在使用者個人資料頁建立，只顯示一次，可獨立撤銷。連線必須走 HTTPS，讓憑證在傳輸中加密。權限上，預設伺服器要求通過驗證且具備 read 能力的使用者，每個 WooCommerce 能力各自執行自己的權限檢查，官方建議為 MCP 客戶端建立專用使用者，只給它需要的能力。資料面還有一條隱私警告：訂單與顧客操作可能暴露姓名、電子郵件、實體地址與付款細節等個人資料，官方建議採最小權限範圍並遵守組織的資料保存政策。定期輪替與撤銷是文件針對 REST API 金鑰的建議，MCP 遠端連線則使用可獨立撤銷的應用程式密碼。

交易層：Stripe 與 Google 兩條官方接軌路

WooCommerce 對兩條路線各有準備建議：ACP 從 Stripe 延伸的代理結帳路徑著手，UCP 從 Merchant Center 的商品饋流著手。往 ACP 走的是Stripe for WooCommerce 延伸。官方頁的說明是：代理結帳功能會進到 Stripe for WooCommerce，現在就可以安裝延伸先做準備，功能上線後，把目錄上傳到 Stripe 的 Agentic Commerce Suite，用單一整合開始經多個 AI 代理銷售。商家可以自己選擇要經過哪些代理銷售，以及購物者在哪裡結帳：在代理內，或回你的商店。

這條路有一個精確的限制必須記下：依 WooCommerce 官方準備指南，這條路徑透過 Stripe 延伸運作，使用 WooPayments 的商店（它由 Stripe 驅動）還不能使用。已經裝了 Stripe for WooCommerce 的商家，官方建議確認自己已列入代理功能的候補名單。還沒裝的，安裝後可以研究通往 Agentic Commerce Suite 的路徑。已用 Stripe 收款的商家還有一個技術優勢可以期待：OpenAI 端的說法是，這類商家最快一行程式碼就能啟用代理付款。

UCP 的商品資料準備可用Google for WooCommerce 延伸，將商品目錄同步至 Google Merchant Center，讓商品對 Google AI 可見。官方對既有用戶的說法是：已經在同步目錄的商家，等於已經為 AI 驅動的發現、Performance Max 的廣告最佳化、資料洞察與定價建議打好地基。串接設定本身屬於電商 SEO 的基本功，商品資料規格與清單品質的完整做法，見電商 SEO 全攻略。

WooCommerce 也透露了還在測試中的新標準，包括 OpenAI 的 Product Feed Spec，目的是當顧客向 AI 助理詢問你品類的商品時，你的目錄已經準備好被發現。官方提醒，商品資料乾淨、組織良好的商店，接每一個新標準都更快，因為最難的部分已經做完。這句話把準備工作的優先順序講得很白：官方的提醒是把商品資料這個共同分母做到位，勝過猜測哪個協定會贏。

Stripe 的另一條支線：機器對機器付款

Stripe 的代理商務總覽還涵蓋機器付款路徑。Stripe 把賣家的 AI 接軌分成兩條路：一條是讓代理幫人買東西，走 UCP 或 ACP，也就是前面兩節的主題。另一條是讓 AI 代理自己成為客戶，走機器付款協定 MPP 或 x402，服務的對象包含賣商品、訂閱、數位內容或 API 的商家，官方舉的例子是把 API 或服務用機器付款直接賣給 Claude Code 這類個人代理。對經營數位產品或 API 服務的 WooCommerce 商家，這條支線值得放進雷達：當你的顧客從人變成代理，計費與交付的介面也要分開準備。Stripe 代理端的功能目前列為私人預覽，採候補名單制。

資料層：AI 讀店的信心層級

無論走哪條協定，AI 代理讀的是資料，不是設計。WooCommerce 官方 2026 年 6 月的商品描述指南提出了一個信心層級的框架，把商店內容分成三層。第一層是結構化資料，例如 schema 標記、Merchant Center 饋流與商品資料欄位，這些是為了讓機器直接讀取而生的，官方舉的例子是一個寫著相容電磁爐的 Product schema 欄位，能幫代理把商品配對到找鑄鐵鍋的查詢。第二層是結構化內容，指以 AI 容易理解的方式組織的資訊，例如規格表、FAQ 區塊、條列的材料與保養說明，清楚的表格比藏在段落裡的細節好讀。第三層是非結構化的行銷文案，官方的說法是這是 AI 代理最不信任的資訊類型，可能直接被忽略。

落到商品描述的改寫，官方給了五個具體技巧。一是寫明使用情境，例如寫給高溫爐上煎炸與進烤箱的料理，而不是寫給現代廚房。二是加入負面限定詞，例如不建議用於玻璃爐面、養鍋期不適合酸性食材，這類資訊幫助代理把你的商品從不合適的查詢中排除。三是相容性精確寫，明寫相容瓦斯、電力與電磁爐，而不是寫適用大多數爐具讓代理用猜的。四是寫明商品為誰設計，因為愈來愈多購物者會對 AI 說自己是新手廚師、家裡是電磁爐、需要可進烤箱的鍋。五是順序，關鍵屬性放前面再講故事，AI 代理先讀描述的頂部，有興趣的人類會繼續往下讀。

官方用一個對照例展示落差。行銷版描述寫著這是廚房裡最受喜愛的鍋具、以匠心打造、世代耐用，這些句子沒有一個可匹配的屬性。改寫版以規格列直述：十二吋鑄鐵平底鍋、烹飪面十吋、重量 7.5 磅、相容瓦斯電力電磁與明火、可進華氏 500 度烤箱、以亞麻籽油預開鍋、不建議玻璃爐面、養鍋期不適合酸性食材，一共八個可匹配屬性。當購物者問代理要一支可進電磁爐的預開鍋十二吋鑄鐵平底鍋，改寫版能在三個點上對上，行銷版一個都對不上。這個例子把資料層準備的回報講得很具體：多一個可匹配屬性，就多一種被代理選中的路徑。

商品頁之外，官方點名兩個商店層的功課，再給了一個原則。分類頁通常只有商品格線沒有文字，在頂部加一段回答採購問題的短文，例如挑選鑄鐵鍋要看什麼，等於給 AI 一份品類摘要，在 WooCommerce 裡的落點是後台商品分類的描述欄，不需要長，一段講使用情境、關鍵規格與品類適用對象的短文就夠。政策頁是信任訊號，退貨政策、出貨時間與保固不要埋在長篇法律文件裡，用清楚標籤加明確數字，例如三十天退貨、兩個工作天內出貨。被 AI 推薦的關鍵，官方的結論也很直白：不在品牌大小或廣告預算，在於讓 AI 容易讀，AI 助理偏好讓它們容易工作的商店。

llms.txt：給 AI 的商店地圖

資料層還有一個輕量的加分題：llms.txt。做法是在網站根目錄放一份同名的純 Markdown 檔，摘要商店賣什麼、重要頁面在哪裡，讓 AI 代理快速掌握全站輪廓。現況要誠實呈現：依 WooCommerce 官方整理，Anthropic 與 Perplexity 支援讀取 llms.txt，Google 不讀，效益限於支援的平台，而且沒有直接證據顯示加上它就會自動提高被推薦的頻率。Yoast SEO 從 22.0 版、Rank Math 從 1 版起內建產生 llms.txt，站內另有llms.txt 的完整做法與評估可延伸。

五步準備清單：把商店推到可接軌狀態

WooCommerce 官方準備指南把商店端的準備收斂成五個步驟，核心原則一句話：當代理回答購物者時，它是在代表你的商店做承諾，承諾背後的資料必須是對的。五步依序整理如下。

清單之外，官方另給了幾個可以今天就做的速贏：檢查庫存同步頻率，日更者趁代理開始查庫存前先改即時。打開任一暢銷商品頁，確認出貨預估與退貨條款就在商品資料裡，而不是只寫在另一份政策頁。還沒接 Stripe for WooCommerce 就裝起來並看通往 Agentic Commerce Suite 的路徑，已接就確認候補狀態。目錄還沒同步 Merchant Center 的，經 Google for WooCommerce 補上。

官方也描繪了準備完成後的樣板：一間戶外裝備專賣店，庫存即時回報，每個商品頁都帶運送與退貨條款，目錄同時流進 Stripe Agentic Commerce Suite 與 Merchant Center。購物者請 AI 助理組一套一週內到貨、不超預算的三季登山裝備，代理查即時庫存、從運送資料確認到貨窗口、成套推薦帳篷背包與衣物，購物者可以直接在助理內完成購買，或回商家網站交易。對照組是每晚才更新庫存、運送條款寫在政策頁的競爭店家，代理做不了保證，只能跳過。同樣的商品，不同的資料準備度，結局就不同。

第三方 ACP 外掛現況與風險評估

在官方 Stripe 路線到位之前，WordPress.org 上已經出現第三方外掛。以 Instant Checkout via ACP Agentic Commerce for WooCommerce 這套為例，WordPress.org 外掛頁宣稱它讓任何 WooCommerce 網站參與 ACP：建立 ACP 所需的 REST API 端點、產生機器可讀的商品饋流、處理結帳流程，付款用 Stripe 的權杖化。功能設計上，它提供逐商品勾選是否開放 ChatGPT 結帳、測試模式與批次操作，設定流程是先向 OpenAI 申請 ACP 核可，核可後從 OpenAI 的 ACP 控制台取得 API 金鑰，再從 Stripe 控制台取得金鑰填入設定頁，商品饋流位於 /wp-json/icvaac/v1/product-feed 這條路徑，再把饋流網址提交給 OpenAI 索引。最低需求是 WordPress 5.0 以上、WooCommerce 5.0 以上、PHP 7.4 以上，開發者自稱獨立於 OpenAI、Stripe 與 WooCommerce。

風險面要攤開講。WordPress.org 對這套外掛掛出了明確警告：它未經最近三個 WordPress 大版本測試，可能不再受維護或支援，與較新版本併用可能有相容性問題。外掛頁上沒有任何一則評論。綜合判斷，這套外掛顯示有開發者嘗試提供 ACP 接口。其功能仍是外掛頁的自述，頁面同時載有新版相容警告，且沒有評論。商家應自行評估交易資料處理與相容性風險，並留意官方 Stripe 路線。

台灣商家的現實評估

把資格範圍誠實攤開：ACP 端，Instant Checkout 首發服務美國 ChatGPT 使用者與美國 Etsy 賣家，WooCommerce 官方在 2026 年 8 月的說法是正陸續開通給美國商家。UCP 端，Google 的結帳功能適用美國、加拿大與澳洲的商品；Business Agent 的第一波是符合資格的美國零售商，新資料屬性則規劃先向一小群零售商推出，之後逐步擴大。公開資料尚未涵蓋台灣市場的開放資格，也沒有可依循的時程。Google 僅表示將逐步擴展到全球。以台灣市場為主的商店，可先做資料與饋流準備，直接結帳資格仍待各通路公告。

但把視角拉到準備成本，結論會不一樣。五步清單裡的每一步，幾乎都是本來就該做的電商基本功：庫存即時、運退資訊清楚、商品描述有可匹配屬性、目錄同步完整。這些投入在既有銷售通路本來就有價值，不因協定何時開放而作廢。Abilities API 已進入 WordPress 核心、MCP 已隨 WordPress 6.9 與 WooCommerce 10.3 出貨，用它們管理商店不需要等任何資格，開店端先熟悉這套介面，等於提前練好代理時代的商店操作。跨境銷售本來就以美國為目標市場的商家，則值得現在就把 Stripe 延伸與 Merchant Center 饋流兩條路鋪好，把候補名單填了，資格開放時才趕得上第一班。

實際排程時，可以把四層工作拆成兩條時間線。資料這條線今天就能動：盤點商品描述的可匹配屬性、補分類頁描述、把政策頁改成明確數字、目錄同步 Merchant Center，全部落在既有的人力與流程裡。介面這條線跟著版本走：WordPress 與 WooCommerce 保持更新，MCP 功能開啟前先規劃專用帳號與權限，Stripe 延伸裝好並列入候補。資料與介面備妥後，商店可依通路資格與技術要求評估接軌。商品是否進入助理結果，還要看與使用者需求的相關性。

判斷節奏可以簡化成一句話：通路等資格，資料不等任何人。把商品資料、饋流與 API 基礎先備好，可讓商店較快評估新協定。實際能否開通，仍須符合各通路公布的資格與技術要求。

結語：通路會輪替，資料是常數

代理商務對 WooCommerce 商店帶來的實際變化，是交易入口正在變多。ACP 把結帳帶進 ChatGPT 這類助理，UCP 把結帳放上 Google 的 AI 介面，兩邊都讓商家維持交易主體身分與顧客關係。WooCommerce 的開源架構讓商店不必等單一公司的時程，已進入 WordPress 核心的 Abilities API 與隨 WordPress 6.9、WooCommerce 10.3 出貨的 MCP，已經把 AI 讀店的第一層介面鋪好。

商店端的功課因此清晰：管店層保持版本與權限紀律，通路層把 Stripe 與 Google 兩條官方路各自鋪到能接上的位置，資料層讓商品描述、饋流與政策資訊都變成可匹配、可驗證的結構。通路開放到哪裡，資格就追到哪裡，而資料這件事，從現在起就開始計分。