AI 代理的商務協定版圖：UCP、ACP、AP2 與 MCP——協定堆疊如何組合

要點

• UCP 擁有 11 個共同開發夥伴，包括 Google、Shopify、Amazon、Meta 和 Stripe——它正從購物擴展到住宿與餐飲領域，使其成為截至 2026 年 8 月涵蓋面最廣的商務協定聯盟。
• ACP 由 OpenAI 與 Stripe 治理（Meta 現已加入），目前處於測試階段，自 2025 年 9 月起已在 ChatGPT 中上線——它涵蓋代理驅動的結帳，但不涉及 B2B 採購流程。
• AP2 為 60 多個組織的代理主導付款提供保障，Coinbase x402 是其穩定幣延伸方案——截至 2026 年，x402 已在 Coinbase Base 上處理超過 1 億筆代理付款。
• MCP 是 UCP 與 ACP 底層共用的智慧層——每一家採用 UCP 的 Shopify 商店都會公開一個即時的 MCP 端點，而 ACP 的三層架構將 MCP 置於中間層。
• 這四個協定都沒有涵蓋 B2B 語意層——客戶分級定價、大量 RFQ 報價、針對 ERP 的庫存預留，以及跨通路的訂單歸屬，這些都需要在其之上疊加一個自訂 MCP 模組。

2025 到 2026 年間，兩項開放標準在短短數月內相繼推出，從不同方向切入同一個問題：在不需要有人為每一家商店手動搭建客製整合的前提下，AI 代理要如何發現商品、議價、完成結帳並付款？通用商務協定（UCP）由 Google 和 Shopify 共同開發，並聯合了包括 Amazon、Meta、Microsoft、Salesforce 和 Stripe 在內的 11 個共同開發夥伴。代理商務協定（ACP）由 OpenAI 與 Stripe 維護，自 2025 年 9 月起已在 ChatGPT 中上線。第三個協定——代理付款協定（AP2）——負責保障付款授權層，已有 60 多個組織參與。這三者都建立在模型情境協定（MCP）之上，MCP 提供了代理與商店資料之間的智慧層連接。

本文梳理這幾個協定各自的定位、彼此的重疊之處，以及 B2B 商務的缺口所在——因為這四個協定都是為消費者的發現與結帳場景所設計，而不是為中型 B2B 經銷商在 NetSuite 或 BigCommerce 上實際需要的報價、分級定價與庫存預留工作流程而設計。

四層協定堆疊

商務協定的版圖並非單一標準，而是由四個互補協定組成的一套堆疊，各自解決代理交易中的不同層面：

層級	協定	治理方	作用	生產狀態
發現與商務	UCP	Google、Shopify，共 11 個共同開發夥伴	代理發現商品、建立購物車、移交商家完成結帳、追蹤訂單	已上線（Shopify 2026 春季版）；正擴展至住宿與餐飲領域
結帳互動	ACP	OpenAI、Stripe、Meta	代理驅動的購買互動模型；三層架構（互動層 → 智慧層 → 商務層）	測試階段；自 2025 年 9 月起已在 ChatGPT 中上線
付款授權	AP2	Google、60 多個組織、FIDO 聯盟	可驗證憑證、付款授權令、代理主導付款的加密稽核軌跡	v0.2；正於 FIDO 聯盟內推動標準化
智慧與工具	MCP	Anthropic（最初提出）	代理與工具的連接：讀取商品資料、查詢庫存、呼叫商店 API	規格已於 2026-07-28 定案；已註冊約 2 萬個伺服器

MCP 本身並非商務協定——它是 UCP 與 ACP 都依賴的智慧層。UCP 的規格文件明確指出「內建 MCP 支援」。ACP 的三層架構將 MCP 置於中間：上層是互動層（代理與買家之間），中間的智慧層（MCP）負責連接代理與商店資料，下層的商務層負責履約。每一家實作 UCP 的 Shopify 商店都會公開一個即時的 MCP 端點，供代理查詢商品目錄、管理購物車並取得訂單狀態。

UCP——從發現到結帳的標準

UCP 是涵蓋面最廣的聯盟。ucp.dev 網站列出橫跨三個產業的 11 個共同開發夥伴：購物領域（Google、Shopify、Etsy、Wayfair、Target、Walmart、Amazon、Microsoft、Meta、Salesforce、Stripe）、住宿領域（Amadeus、Booking.com、Expedia、Hilton、Marriott、Trip.com）以及餐飲領域（DoorDash、Square、Toast、Uber Eats）。認可合作夥伴名單則包括 Visa、Mastercard、Coinbase、PayPal、Adyen、Klarna 和 Worldpay。

UCP 支援 REST 與 JSON-RPC 傳輸方式，並內建對 AP2、A2A 和 MCP 的支援。Shopify 開發者文件證實，Shopify 的 MCP 工具在買家旅程的每一步都實作了 UCP：協商與身分驗證（基於信任等級的檔案）、商品發現（在數億筆商品清單中檢索）、購物車與結帳（建立購物車、轉換為結帳、移交商家完成付款），以及訂單監控（訂單 webhook，以及透過 get_order MCP 工具依需求取得訂單狀態）。

通用購物車 API 讓 AI 代理能夠透過 UCP，將來自任意商家（不論是否在 Shopify 上）的商品彙整到單一統一購物車中。Shopify 的認證計畫（Shopify + OpenAI + Google，目前處於封閉測試階段，2026 年第三季將擴大開放）實際上為代理打造了一個新的發現層：結構清晰的資料決定著代理能否找到並與某家商店完成交易。

ACP——結帳互動模型

ACP 採取了不同的架構路徑。它不是一個涵蓋多產業的廣泛聯盟，而是由 OpenAI 和 Stripe 治理（Stripe 的文件現已將 Meta 列為共同創建方）作為創始維護方，並規劃朝向更廣泛的社群治理過渡。該規格目前處於 Apache 2.0 授權下的測試階段。

ACP 定義了用於代理驅動商務的可組合建構區塊。Stripe 的 Agentic Commerce Suite 提供了參考實作：代理發現商品、將其加入購物車，並使用 Stripe 的付款基礎設施完成購買。BigCommerce 透過與 Stripe 的合作走上了 ACP 路線，而非自建第一方的商店資料 MCP 伺服器——BigCommerce 連接器文章對此有深入分析。

ACP 的三層架構——互動層 → 智慧層（MCP）→ 商務層——意味著 MCP 是其中的連接組織。代理並不會繞過 MCP 去使用 ACP；它使用 MCP 與商店對話，同時使用 ACP 來組織購買互動。

AP2——付款授權層

AP2 位於 UCP 和 ACP 之下，充當付款信任協定。Google 於 2025 年 9 月宣布推出 AP2，並有 60 多個合作組織參與。目前它正於 FIDO 聯盟內推動標準化。AP2 在 A2A（代理間通訊）的基礎上延伸出結構化的付款授權令——意圖授權令、購物車授權令和付款授權令——藉此提供可驗證、不可否認的證明，證明使用者已授權代理進行某筆特定購買。

Coinbase x402 是 AP2 的穩定幣延伸方案，其名稱源自 HTTP 狀態碼 402（「需要付款」）。x402 讓代理能夠透過 HTTP 直接以穩定幣支付 API 呼叫、服務與微交易的費用。Chainalysis 報告指出，x402 在 Coinbase Base 上已處理超過 1 億筆代理付款，證明該穩定幣通道正以生產規模運作。

圍繞代理商務，三個相互競爭的付款網路已經成形：Visa Trusted Agent、Mastercard Agent Pay（30 多個產業合作夥伴，透過 MDES 提供 Agentic Tokens）以及 Coinbase x402。Stripe 正同時配置來自 Mastercard 和 Visa 的代理網路令牌，將自身定位為傳統卡組織通道與代理付款層之間的橋樑。

下圖展示了四層商務協定堆疊，以及需要自訂 MCP 模組補上的 B2B 語意層缺口：

堆疊的交會之處——以及尚未交會的地方

這四個協定正朝著一套共享架構收斂：UCP 或 ACP 負責商務互動，AP2 負責付款授權，MCP 負責智慧層，A2A 負責代理間的委派協作。UCP 規格明確將 AP2、A2A 和 MCP 列為內建整合。AP2 文件也明確引用了 A2A 和 UCP。整套堆疊本就是為了互通而設計。

但這種收斂是圍繞消費者場景展開的。這些協定解決的是一個特定問題：代理發現一件商品、議價、完成結帳並付款。這是消費者的旅程。而一家每週處理 200 份 RFQ 的中型 B2B 經銷商，面對的並不是結帳問題——而是分級定價問題、庫存預留問題，以及 ERP 回寫問題。

其缺口正是 B2B 語意層：

• 客戶分級定價。 UCP 和 ACP 公開的是商店對外公告的價格。而 B2B 經銷商的價格是按客戶、按合約、按量級劃分的——存放在 NetSuite 或 BigCommerce 的客戶分組中，而非公開目錄裡。沒有任何商務協定能夠議定分級定價。
• 大量 RFQ 報價。 消費者協定處理的是單件商品的購買。而 B2B 採購運行在 RFQ 之上：買家提出一份 500 件商品、附帶交期的請求，供應商回覆報價，買家再進行議價。RFQ 引擎架構一文對這個工作流程有深入分析。
• 針對 ERP 的庫存預留。 消費者結帳會在購買當下預留庫存。而 B2B 報價需要的是一種可用性預留——對 NetSuite 或 Brightpearl 庫存的限時預留，若報價未被接受則自動失效。沒有任何 UCP 或 ACP 工具能提供這項能力。
• 跨通路訂單歸屬。 由代理下達的 B2B 訂單，需要歸屬到正確的客戶帳戶、正確的業務代表，以及 ERP 中正確的合約。而消費者協定假定的是單一買家身分。

自訂 MCP 模組正是用來補上這個缺口。MCP 模組程式碼標準定義了其結構模式：型別化的工具定義、代理與 ERP 之間的語意層轉譯、速率限制治理，以及稽核軌跡。該模組疊加在商務協定之上——它並不取代 UCP 或 ACP，而是將其延伸至消費者協定未曾設計涵蓋的 B2B 工作流程中。

相關閱讀

• 用 MCP 將 AI 代理連接到 BigCommerce：Stripe 合作未解決的問題——針對 BigCommerce 的連接器專項分析，探討其 ACP 路線與 B2B 語意層缺口
• 當 AI 代理代你銷售：將 Shopify 接入 B2B 技術堆疊——Shopify 符合 UCP 標準的 MCP 伺服器如何涵蓋消費者半場，以及自訂模組在何處延伸至 B2B
• MCP + A2A：支撐每一個生產級代理 AI 系統的兩個協定——本文正是在這篇協定堆疊總覽的基礎上延伸至商務層

代表性案例

一家線上目錄跑在 BigCommerce、ERP 跑在 NetSuite 的中型工業經銷商，每週透過電子郵件收到 150 份 RFQ。每份 RFQ 都需要一次客戶分級價格查詢、一次庫存可用性預留，以及一份引用客戶合約條款的報價。而消費者商務協定——用於商品發現的 UCP、用於結帳的 ACP、用於付款的 AP2——都不涉及這些環節。自訂 MCP 模組補上了這個缺口：它公開型別化工具，用於分級定價查詢、可用性預留建立與報價組裝，供代理在透過標準商務協定完成商品發現後呼叫。代理端到端處理整個 RFQ——發現、定價、預留、報價、人工核准——而 MCP 模組則負責治理 ERP 回寫與稽核軌跡。首個代理可在 5 到 8 週內上線。

請求一個範圍明確的建構。 一週 Discovery。你獲得系統清單、工作流圖和固定範圍——無論你是否與我們合作建構。