代理商商務將會為 AI 原生交易解鎖雙層支付架構嗎？

隨著原生於 AI 的交易從概念走向落地，代理式商務（agentic commerce）迫使人們對數位支付與清算（settlement）基礎設施的運作方式進行根本性重新思考。

從以人為中心的支付到 AI 原生通道（rails）

在 2025 年 9 月到 2026 年 3 月之間，全球支付領域的每一個主要參與者都轉向以 AI 驅動的商務。OpenAI 和 Stripe 推出代理式商務協議（Agentic Commerce Protocol），而 Google 則推出通用商務協議（Universal Commerce Protocol），並向超過 30 家零售與金融科技（fintech）合作夥伴展示。

在同一時期，Visa 和 Mastercard 發布面向代理（agent-focused）的支付框架。Coinbase 推進其 x402 標準，在 Base 上清算超過 1500 萬筆交易。此外，Stripe 與 Tempo 共同署名了機器支付協議（Machine Payments Protocol），並提交以供 IETF 標準化。

時機並非偶然。過去三十年的支付基礎設施是為了人類使用者而建：坐在瀏覽器前、填表單、並進行逐步驗證。然而，AI 代理需要程式化介面、近乎即時的授權與清算，才能在小數點以下分到一分的交易量級上處理交易。

既有堆疊（stack）從未為這種環境而設計，產業也已認識到不匹配。相反，正在浮現的方案是一種雙層架構：上層的協調（orchestration）負責發現（discovery）與發起（initiation），下層的清算（settlement）負責價值轉移（value transfer）。這些層將在不同軌道上演進，並由不同的激勵驅動。

商業協調：代理交易如何匯聚在一起

協調層（orchestration layer）定義代理如何找到服務（service）、管理會話（session），並交接到支付。已出現兩種不同的用例類別，將兩者混為一談會有誤解市場結構的風險。

1.1 代表消費者行事的代理

對於代表人類購買的代理而言，今天最主要的問題並非支付機制，而是存取權（access）。多數電子商務平台都針對人的瀏覽與操作進行最佳化。然而，代理不應該捲動產品頁面、解讀橫幅（banners），或點擊「加入購物車」（add to cart）按鈕。

相對地，商家需要結構化、可供機器讀取的端點（endpoints）。這類端點仍然相當罕見，因而限制了原生代理互動。此細分領域的第一波協議來自 OpenAI、Stripe 與 Google，各自採用不同的控制與開放方式。

OpenAI 與 Stripe 於 2025 年 9 月推出代理式商務協議（ACP）。該協議的核心是在結帳（checkout）時進行安全的支付委託（payment delegation）：使用者的支付方式被儲存在 ChatGPT 中，並在購買確認後，Stripe 會發出共享支付代幣（Shared Payment Token，SPT），作為單次使用憑證（single-use credential），且其範圍限定於商家與購物車總額（cart total）。

該 token 透過 API 交付給商家；商家保有完整的商家記錄（Merchant of Record）身份，並透過既有的 Stripe 基礎設施處理付款。就本文撰寫之時而言，Stripe 的 SPT 是此委託設計的第一個現場（live）落地實作，並且相容於 OpenAI 的委託支付規範（Delegated Payment Spec）。其他支付服務提供商（PSP）也可以實作該規格，使 ACP 在支付層面保持開放。

ChatGPT 即時結帳（Instant Checkout）於 2025 年 9 月推出供美國用戶使用，但在 2026 年 3 月因幾乎為零的轉換率而停止。OpenAI 隨後轉向「發現」：ChatGPT 現在會展示產品，並將用戶導流至商家網站或應用程式進行結帳。ACP 仍以較狹窄的角色存續，為少數大型零售商提供專用的內嵌應用（in-ChatGPT apps）。

商家必須申請參與，且 OpenAI 控制哪些商家會出現、以及其排名方式。然而，這種精選（curated）的模式讓 OpenAI 能掌握助理（in-assistant）體驗的端到端控制，同時將清算委託給像 Stripe 這樣的第三方處理器。

Google 的通用商務協議（UCP）則採取截然不同的策略。2026 年 1 月 11 日，Sundar Pichai 在 NRF 會議上宣布 UCP。UCP 與 Shopify、Etsy、Wayfair、Target 和 Walmart 共同開發，並獲得超過 20 家合作夥伴背書，包括 Adyen、American Express、Best Buy、Mastercard、Visa、Stripe 和 The Home Depot。

UCP 明確與 Google 自家的代理支付協議（AP2）、代理對代理（A2A）標準，以及模型上下文協議（MCP）保持對接（interoperability）。這種互通性推動，旨在刻意佔據「高地」：用於索引（indexing）與存取（access）。Google Pay 作為預設支付方式，並宣布 PayPal 將成為即將提供的選項。

技術上，UCP 透過一種稱為 UCP profile 的能力（capability）宣告（manifest）運作。商家在其網域下的 /.well-known/ucp 發佈結構化 JSON 文件，說明傳輸方式、結帳能力以及支援的付款處理器（payment handlers）。代理會直接讀取這些宣告，不需要透過中介。

此架構反映了 Google 的策略性優先順序。Google 對促成（brokering）交易幾乎沒有興趣，因為這會引入利潤壓力（margin pressure）、責任（liability）與監理（regulatory）審查。相反地，它希望能完全掌握整個商務網（commerce web）。UCP 將 Gemini 定位為代理購物的主要發現層（discovery layer），但在清算層面則多半保持「不顯眼」。

與 ACP 的對比非常鮮明。ACP 是一個精選環境（curated environment），其中 OpenAI 充當把關者（gatekeeper），商家必須申請，且流程在 ChatGPT 內進行最佳化。UCP 則像開放型目錄（open catalogue）：商家自行發布（self-publish），任何相容的代理都能消費（consume）這些 profiles，而 Google 控制的是發現面（discovery surface），但不控制支付本身。

在 UCP 下，上線（onboarding）摩擦更低、潛在觸及（reach）可能更廣，但商家得到的直接陪跑（hand-holding）更少。總的來說，ACP 以開放換取控制，而 UCP 以控制換取更廣的索引範圍（index breadth）與協議層級的標準化（protocol-level standardisation）。

1.2 代理與其他代理進行交易

第二大類別在結構上完全不同：交易的雙方都是自治型代理（autonomous agents），不會有任何人類商家參與。在這種環境下，傳統的信任錨（trust anchors）消失了，留下的熟悉防護機制也所剩不多。

沒有可依賴的消費者保護法規或信用卡拒付（chargeback）權利。此外，雙方或許從未互動過，但仍必須能安全地交換價值。這正是新的以太坊（Ethereum）標準試圖解決的問題。

由 Ethereum 基金會（Ethereum Foundation）dAI 團隊與 Virtuals Protocol 於 2026 年 3 月 10 日共同提出，ERC-8183 將每一筆交易結構化為三方工作（three-party job）：委託方（Client）委託工作（work），提供方（Provider）交付工作，評估方（Evaluator）驗證完成（completion）。

資金存放在智能合約托管（smart-contract escrow）中，只有在評估方簽核（sign-off）後才會釋放。委託方與提供方都不需要評估對方的可信度；合約會機械式（mechanically）執行結果（outcome）。與此同時，ERC-8004 定義支撐此機制的身分層（identity layer）。

在 ERC-8004 下，代理會在鏈上註冊，並從交易歷史建立聲譽分數（reputation score）。這會產生一個可攜帶（portable）的可信度信號（credibility signal），能在不同互動中持續。理論上，此設計相當健全；但在規模上引入（bootstrapping）採用（adoption）仍是實務上的瓶頸。

目前，多數實際應用集中在 Virtuals Protocol 平台內。一個名為 Butler 的協調代理（orchestrator）會將複雜任務拆解成子任務（sub-jobs），並路由給專家代理（specialist agents）。更廣泛的開發者社群尚未以相當規模投入。ERC-8183 實質上是一個讓此模式開放、無需許可（permissionless）的嘗試。

一個結構性要點也很直觀：零售電子商務可以在卡通道（card rails）上較為輕鬆運作，因為人類買家仍在環路中。純粹的代理對代理（agent-to-agent）商務，則很可能需要穩定幣（stablecoin）清算，因為在交易金額極小且頻繁的情況下，卡費（card fees）會變得不經濟。

清算協議：誰真正移動資金

若協調層（orchestration）決定了「什麼、在哪裡交易」，清算層（settlement）則決定「價值是否真的移動」。目前有五個主要協議在此競爭，每個都針對不同的用例與經濟限制進行調整。

2.1 Delegated Payment Spec 與 SPT（Stripe）

Stripe 的 Delegated Payment Spec 延伸的是卡支付基礎設施，而非取代它。當客戶授權代理時，Stripe 會配置（provision）一個 SPT，供代理儲存。在交易時，代理會向商家出示此具有時效限制（time-limited）、金額上限（amount-capped）的 token。

清算則透過 Stripe 現有的卡支付堆疊（stack）進行。在後端，Stripe 連接到 Visa 智能商務（Visa Intelligent Commerce）與 Mastercard 代理支付（Agent Pay），由這些系統簽發代理式網路（agentic network）token。商家看到的是單一的整合界面，不管其底層使用哪個卡網路。

此模型適用於一般零售購買，以及許多高價值的代理對代理付款；在這些情境中，拒付（chargebacks）與其他消費者保護措施仍然是理想選項。然而，它不適用於高頻率、微額（micro-value）模式，例如機器對機器（machine-to-machine）的串流付款（streaming payments）。

在這些情境中，交易金額常常只有幾分之一美分，且每分鐘的交易量可達數千次。卡費與授權（authorization）成本很快就會變得不可持續，即使技術上可行。

2.2 Visa 智能商務與 Mastercard 代理式 token

Visa 與 Mastercard 都已重構其 token 化（tokenisation）層，以支援代理發起（agent-initiated）付款。真實卡號被動態加密成 token，並內嵌與授權代理相關的元資料（metadata），包括身份（identity）、消費限制（spend limits）與有效期限（validity windows）。

允許的商家也會被寫入 token 的元資料中，讓控制可以細到「代理可以在哪裡付款」。清算仍然在傳統卡支付通道（legacy card rails）上進行，保持整合路徑的熟悉，避免完全建立新基礎設施。

兩個網路都已經超越概念驗證（proof-of-concept）。Mastercard 在 2025 年 9 月完成了第一筆完全識別（fully identified）的代理交易，與澳洲的聯邦銀行（Commonwealth Bank）合作。Visa 也透過其代理式就緒（Agentic Ready）計畫，在歐洲市場完成初步部署。

基礎設施看起來具備能力，但費用下限（fee floor）是一個結構性限制。兩個網路都無法在未來代理商務可能需要的高密度（density）下，有效支援低於一美元的微支付（sub-dollar payments）。此外，監管與合規層（regulatory and compliance layers）也進一步限制了在極小交易額範圍內的實驗空間。

2.3 x402（Coinbase）

相較之下，x402 是從 HTTP 協議的狀態碼 402「Payment Required（需要付款）」起步，這個狀態碼自 1997 年起就存在於 HTTP 規範中，但幾乎未被使用。當代理請求一個付費資源時，伺服器會回傳一個 402，並附帶付款參數（payment parameters）。

代理簽署授權（authorization），然後由 Facilitator 在 USDC 或其他支援的 token 中完成原子性（atomic）的鏈上清算（settlement），通常約在兩秒內完成。協議層級（protocol level）沒有帳號設置（account setup）、API 金鑰（API key）分發，也沒有 KYC 強制規定。治理由 x402 基金會（由 Coinbase 與 Cloudflare 設立）掌控。

到 2025 年底，x402 已在 Base、Solana 和 Polygon 上處理超過 1 億筆交易。然而，2026 年 2 月 Artemis 的分析師估計，其中很大一部分是自我交易（self-dealing）與基礎設施測試，而非真正的商務活動。

該協議的年度化付款量（annualised payment volume）約為 6 億美元，但集中度與「量的品質」（quality-of-volume）問題很嚴重。儘管如此，x402 沒有結構性的費用下限；它被明確設計用於微支付（micropayments）。真正的缺口在於採用深度與真實商務的密度，而非技術設計。

2.4 Nanopayments（Circle）

Circle 的 Nanopayments 協議刻意相容於 x402：使用 HTTP 402 作為觸發（trigger），並加入一層批次（batched）清算（settlement）層。它不再逐筆在鏈上清算付款，而是由買家預先資金存入 Circle Gateway 帳戶，並為每筆交易簽署 EIP-3009 的離鏈訊息（off-chain messages）。

定期的批次清算（periodic batched settlement）將 gas 費用分攤到多筆付款中，使得轉帳金額低至 0.000001 美元也具有經濟可行性。Gas 費用幾乎只在存款（deposit）時支付一次，而非每筆付款都支付，這對超高頻用例是關鍵優化。

缺點是雙方都必須存入 Circle Gateway，形成一個半封閉（semi-closed）網路架構。Nanopayments 於 2026 年 3 月在測試網（testnet）推出，支援 12 條鏈（chains）。此外，如果 Circle 能降低上線（onboarding）摩擦，其費用模型對高頻微支付流（micro-payment flows）將非常有吸引力。

2.5 MPP 機器支付協議（Tempo 與 Stripe）

MPP 由 Tempo 與 Stripe 共同署名，是五種清算方案中最具雄心的設計。它使用 HTTP 402 作為觸發，並允許商家與代理在一個統一框架內，從多條清算通道（settlement rails）中選擇。

開發者在建置（build）時不再需要硬編（hard-code）穩定幣或法幣（fiat）基礎設施。相反，代理可以在執行時（runtime）根據交易需求決定使用哪條通道。可選擇包括：Tempo 穩定幣清算、Stripe SPT 付款、卡網路 token，以及由 Lightspark 支援的比特幣閃電網（Bitcoin Lightning）付款。

關鍵是：MPP 引入一個類似 OAuth 的「會話」（session）原語（primitive）。代理只需授權一次，預先資金配置（pre-fund）帳戶，之後便能在不產生鏈上交易（on-chain transaction per payment）的情況下，享有即時的自動清算（real-time automated settlement）以支援後續互動。

核心規格已提交給 IETF，作為 HTTP 402 的參考實作（reference implementation）。在 2026 年 3 月 18 日啟動主網（mainnet）時，支付目錄（Payment Directory）已整合超過 100 個服務。但採用模式仍處於早期階段。

Stripe 的雙重角色（dual role）在策略上非常重要。它共同署名了該協議，並且也出現在其中的支付選項之一；不管開發者主要是為了彈性（flexibility）還是為了卡支付能力（card capabilities），Stripe 都能從中獲利。

市場現實：協議尚在部署前

3.1 市場現況

儘管過去六個月協議快速推出，商業實現（traction）仍然有限。在清算層面，x402 在交易數量（transaction count）上領先，但實際每日商務量（real daily commerce volume）約在 2.8 萬美元左右。在協調層面，ACP 的即時結帳（Instant Checkout）在幾乎無轉換後就被關閉。

像 ERC-8183 和 MPP 這樣的新標準，呈現出類似的情況：敘事（narrative）超越了實際部署（deployment）。產業已經到了一個轉折點：大量協議架構已經存在，但規模化商業應用尚未開始。

主要瓶頸在於協調層的碎片化（fragmentation）。商家面臨多個獨立標準，每個標準都配有不同的 SDK、驗證流程與合規規則。這會增加整合成本，並抑制實驗意願。

歷史上，這種碎片化通常由一個整合層（aggregation layer）來解決，統一多個競爭標準的存取（access）。但這次可能不同。擁有實質代理流量的平台（如 OpenAI、Google 和 Microsoft）激勵維持封閉界面（closed surfaces），而非將用戶放手給其他平台。

這種邏輯也在區域層面展開。中國、東南亞、韓國與日本各自建立封閉式閉環生態系，依託超級 App（super-apps）或主導平台（dominant platforms）。更可能的結果，是形成多個平行的區域封閉系統，而非單一的開放全球標準。

因此，商家所期待的聚合層（aggregation layer），更可能來自服務商（第三方基礎設施提供者），直接服務商家，而非由競爭代理流量所有權的平台本身提供。平台層面對開放與跨平台觸及（cross-platform reach）的激勵，根本不一致。

3.2 近期的機會所在

從這個局勢中，浮現出兩個不同的機會：清算基礎設施與應用層的代理對代理（agent-to-agent）服務。前者看起來是最確定的短期商機；後者雖然尚未成熟，但可能最具變革潛力。

在清算層面，協調（orchestration）帶來的碎片化，與支付（payment）層的整合壓力（consolidation）形成鮮明對比。每個代理，不論所屬平台為何，最終都面臨同一個問題：如何在不同通道（rails）上高效支付對手。

開發者不可能在每個代理可能運作的「界面」上都維持獨立的支付整合。隨著平台數量增加，經濟壓力會推動向單一、統一的支付整合方案：將底層通道的複雜性抽象化。

這就定義出一個明確的產品需求：為代理提供一個多通道（multi-rail）錢包（wallet）。像 SPT、Visa 代理式 token、Mastercard 代理式 token 這些卡支付通道，將繼續支援傳統商家商務。像 x402 與 MPP session 付款這類穩定幣通道，則會以鏈上 API 與代理對代理轉帳為核心。

這兩類能力目前都已經上線，短期內不太可能合併成單一通道。靈活性的負擔在代理端，而非商家端。商家決定自己支援哪些通道；這是一個相對穩定、可控的決策。

企業接著會為代理配置穩定幣與委託卡（delegated cards）。代理使用對手接受的任一通道進行付款。能在單一整合中無縫處理兩者的錢包，將成為推動多元生態系運作的基礎層（enabling layer）。

這種整合價值會隨著每次交易與每新增平台而疊加，形成一個難以取代的「基礎設施深度（infrastructure depth）」，一旦建立就很難被動搖。此外，它還將錢包提供者定位為分散式協調（decentralized orchestration）環境之間的中立清算層（neutral clearing layer）。

代理對代理商務：尚未充分發展的機會

第二個機會在代理對代理（agent-to-agent）商務的應用層（application layer）。目前，大多數 A2A 活動仍局限於加密原生（crypto-native）工作流程：代理查詢鏈上資料、與 DeFi 協議互動、執行區塊鏈交易。

市場尚未擴展到廣泛的現實世界服務。然而，從協議層面來看，代理其實已能委託完成資料分析、內容生成、法律研究或程式碼審查等任務，並以「每次呼叫（per-call）」付費。

缺少的關鍵是開發者生態。服務建立者尚未將產品包裝成可由代理支付（agent-payable）的 API，並提供細粒度、用量付費（usage-based）的方案。這才是真正的缺口，目前也是堆疊中最少被爭奪的領域之一。

此領域受到一個冷啟動（cold-start）問題的限制。像 ERC-8004 這樣的身分系統，需要大量交易密度，才能產生可信的聲譽分數。沒有歷史的代理缺乏聲譽權重，限制了願意與其交易的對手數量。

微軟（Microsoft）預測到 2028 年將有約 13 億個活躍 AI 代理（active AI agents）。而目前的安裝基底（installed base）則小得多。這個差距不會自動縮小；正因如此，短期內的競爭較少，早期佈局（early positioning）更具吸引力。

這些影響也超越支付範疇，延伸到商業模式。網路的主流模式——廣告（advertising）與訂閱（subscriptions）——都假設買家是人類。代理既不會被廣告說服，也不需要每月存取方案；它們支付的是特定呼叫的結果。

在這個背景下，HTTP 402 付款創造了一個不同的經濟原語（primitive）。提供者銷售的是結果（results），而非存取權（access）；對重度用戶收取與實際消耗成比例的費用，並停止補貼輕度用戶或過度配置（over-provisioning）稀有高峰（peak loads）。

無論 A2A 經濟是否會超越加密領域、HTTP 402 是否會成為軟體的普遍定價層（general pricing layer），本質上都是同一個問題。兩者都依賴代理成為常態化的經濟行為者（routine economic actors），在規模化交易中，透過豐富的、按次服務目錄（rich, per-call service directories）完成付費。

結論：雙層架構與缺失的原語

展望未來，代理商務（agent commerce）將在兩條獨立軌道上持續發展。面向消費者的代理（consumer-facing agents）為人類購買商品，主要依賴卡支付通道，並由企業授權框架與新支付界面上的用戶信任推動。

同時，軟體對軟體（software-to-software）支付的代理協議堆疊（agentic commerce protocol stack）在穩定幣通道上已具備技術可行性。接下來，只待部署那些需要高頻率、程式化清算（high-frequency, programmatic settlement）之代理與服務。

最終的狀態很可能是雙層堆疊同步演進：協調層（orchestration）負責發現與發起（discovery and initiation），清算層（settlement）負責價值轉移（value transfer）。對建置者（builders）而言，兩層之間的整合範圍（breadth）將是策略性優先。

能在市場擴展時，將任何代理交易路由到對手所需的協議、同時將這份複雜性隱藏於應用層的基礎設施，將在結構上佔據優勢。這一層將對終端用戶隱形，但其重要性會隨著時間越來越高。

推動商業規模的關鍵點，不在於更好的協議，而在於：企業將支出授權委託給代理，並提供可稽核（auditable）軌跡、預算控管（budget controls）與明確的責任（liability）來防止誤導性購買（misdirected purchases）。當這個門檻被跨越，兩個基礎設施位置就變得至關重要。

第一，一個支持多通道（multi-rail）支付的代理錢包（agent wallet），能在單一整合中同時支援穩定幣與卡支付。第二，一個可存取的按次服務目錄（per-call service directory），讓沒有加密背景的開發者也能向代理買家暴露（expose）API。這兩個機會今天都已經開放，一旦支出代理在規模化運作，這兩者都將成為必備。