一文讀懂x402與MPP：Agent支付的兩條路線

原文標題：Stripe 的 MPP vs. x402：今天到底发生了什么
原文作者：Nick Sawinyh，defiprime.com
編譯：Peggy，Blockbeats

編者按：圍繞 Agent 如何支付這一問題，x402 與 MPP 給出了兩種幾乎相反的路徑。

x402 走的是協議最小化：把支付直接嵌入 HTTP 請求，用最簡單的方式實現請求即付費。沒有帳戶、沒有中間商，更像互聯網早期那種開放、無許可的設計，適合長尾開發者和去中心化場景。

MPP 則是系統最大化：通過會話（sessions）、流式支付與合規體系，解決高頻交易、風控和法幣接入問題。它不追求純粹，而是優先滿足現實商業需求，更適合企業級與規模化應用。

兩者的差異，本質上是同一個問題的兩種解法：是把支付做成協議的一部分，還是做成系統的一層。

也正因此，它們並非完全競爭關係，而更像分佈在不同區間，x402 覆蓋開放網絡的長尾需求，MPP 承接高頻與商業化流量。在一個尚未成型的 Agent 經濟裡，這種分化或許是必然的。

以下為原文：

HTTP 狀態碼 402 自 20 世紀 90 年代末在 HTTP/1.1 規範中被定義以來，就一直在等待一個用武之地。它的含義是需要支付（Payment Required）。當初的設想是：將支付能力嵌入到 Web 的協議層，讓機器能夠像請求網頁一樣去購買資源。

但這一設想大多並未實現。多年來，這個狀態碼只在一些邊緣場景中偶爾出現，比如 Shopify 的限流響應、Apple Mobile Me 的計費錯誤等，卻始終沒有人真正構建出它所暗示的微支付未來。取而代之的，是信用卡、訂閱制付費牆，以及 API Key 機制，這些系統本質上都是為有人手操作的人類設計的。

而今天，這一未來出現了兩種彼此競爭的實現路徑，並且在同一天發布。接下來，我想梳理它們分別是什麼、有什麼差異，以及為什麼 Stripe 會同時押注這兩條路線。

x402：更簡單的一種方案

Coinbase 於 2025 年 5 月正式推出了 x402，其核心思路幾乎可以說是極簡到激進。客戶端請求一個資源；伺服器返回 HTTP 402，並告知客戶端：需要支付多少費用、使用什麼代幣、在哪條鏈上完成支付。客戶端在鏈上完成支付後，將支付憑證附在重新發起的請求中，伺服器隨即交付資源。

就這麼簡單。沒有帳戶體系，沒有 API Key，也沒有訂閱機制。只是一次 HTTP 請求往返，中間插入了一筆支付。

如今，Stripe 已在其支付體系中提供對 x402 的原生支援，商家可以通過現有後台直接接收這類支付。不過，從本質上來說，x402 仍然是 Coinbase 主導的協議，由其與 Cloudflare 於 2025 年 9 月共同發起的 x402 Foundation 負責治理。該協議完全開源（Apache 2.0 許可），並提供 TypeScript、Go 和 Python 等多語言 SDK。

在支援範圍上，Coinbase 的官方文件顯示，目前已在 Base、Polygon 和 Solana 上支援 ERC-20 支付。同時，生態也在探索將其擴展至 Avalanche、Sui 和 Near 等其他鏈，但成熟度不一。

再來看 adoption 數據，這部分就稍微複雜一些。Coinbase 表示，x402 已通過其 Agentic Wallet 基礎設施處理了超過 5000 萬筆交易。聽起來很亮眼，但根據 CoinDesk 在 3 月 11 日援引 Artemis 的鏈上分析數據：日交易量約為 13.1 萬筆，總金額約 2.8 萬美元，單筆平均支付僅約 0.20 美元，其中大約一半更像是測試或遊戲化行為，而非真實商業交易。

但這未必是壞事。因為這個協議本來就是為一個尚未真正存在的市場設計的，一個由 AI agent 進行微額支付（甚至低於 1 美分），用於 API 調用和數據查詢的世界。而服務這一市場的商家，也才剛剛開始出現。

例如，Google 的 Agentic Payments Protocol（AP2，屬於 A2A 框架）已經集成了 x402；Lowe's Innovation Labs 還展示了一個 demo：AI agent 可以在一個流程中完成商品發現、調研到下單的全過程。同時，World（由 Sam Altman 發起）本周發布了 AgentKit，為 x402 錢包增加人類身份證明能力。

其背後的核心假設是：只要把支付變得像 HTTP 請求一樣輕量，應用場景自然會出現。至於這是否成立，還有待驗證。

MPP：全棧方案

Stripe 和 Tempo 選擇了一條不同的路徑。Machine Payments Protocol（MPP）於今日隨 Tempo 主網上線一同發布。與作為現有區塊鏈之上輕量封裝層的 x402 不同，MPP 是專門為高頻交易的智能體（agents）這一場景而設計的。

其核心機制是會話（sessions）。不同於每次請求資源都要發起一筆鏈上交易，agent 可以先一次性授權一個支出額度，然後在該額度內持續進行微支付。如果你是一個每小時需要查詢上千次數據源的 AI，就絕不希望每次都簽名並廣播一筆鏈上交易，而 sessions 正是為了解決這一問題。

Tempo 這條鏈也是圍繞這一需求構建的。它支持每秒數萬筆交易，具備亞秒級確認時間，而且沒有原生 gas 代幣。用戶可以直接用穩定幣支付手續費，省去了為了轉帳還要先購買某種隨機代幣的繁瑣步驟。

另一個值得理解的組件是：Stripe 的 Agentic Commerce Suite 中包含 Shared Payment Tokens（SPTs）。這並不是 MPP 本身的一部分，而是 Stripe 的擴展機制，但可以與其協同使用。SPT 允許 agent 在不暴露真實數據的情況下，將用戶的銀行卡或錢包憑證安全地傳遞給商家。這些憑證僅限單次交易、且有時間限制，可以理解為一種可編程、自毀式授權。在實際使用中，這意味著一個通過 MPP 支付的 agent，既可以使用 Tempo 上的 USDC，也可以使用用戶綁定的 Visa 卡，甚至兩者結合。

根據 Tempo 主網上線博客披露，其合作方包括 Anthropic、DoorDash、Mastercard、Nubank、OpenAI、Ramp、Revolut、Shopify、渣打銀行（Standard Chartered）和 Visa。《The Block》則報導稱，MPP 上線時支付目錄中已有超過 100 項服務，包括 Alchemy、Dune Analytics、Merit Systems 和 Parallel Web Systems。Tempo 與 Paradigm 的聯合創始人 Matt Huang 在接受《Fortune》採訪時表示，這一領域仍處於早期階段，MPP 的設計目標是未來可以擴展到 Tempo 之外的更多鏈上環境。

為什麼 Stripe 同時支援兩者

如果你已經接入了 Stripe，最實際的答案是：你不需要在兩者之間做選擇。

Stripe 通過兩條獨立的整合路徑分別支援 x402 和 MPP，而不是將它們抽象成一個統一介面。對於 x402，其文件主要涵蓋充值地址生成、鏈上監控以及資金結算至 Stripe 帳戶的流程——你負責返回 402 響應，底層的加密支付基礎設施由 Stripe 處理。目前支援 Base 上的 USDC，未來還會擴展。對於 MPP，商家則可以通過同一套 PaymentIntents API，接收基於會話的流式支付。

Stripe 於 2025 年 12 月發布的 Agentic Commerce Suite 構建在這兩條支付軌道之上。商家只需上傳商品目錄，選擇希望接入的 AI agents，Stripe 就會負責商品發現、結帳流程、反詐騙以及稅務處理。目前，URBN、Etsy、Coach、Kate Spade 和 Ashley Furniture 已經在使用，Wix、WooCommerce、BigCommerce、Squarespace 和 commercetools 等平台也已完成整合。

其策略其實很清晰：掌控抽象層，讓底層協議自由競爭。

對比來看

從宏觀上看，這兩種協議在做同一件事：讓機器可以通過 HTTP 為資源付費。但真正的差異，體現在細節之中。

x402（由 Coinbase 主導）vs MPP（Stripe + Tempo）

標準化
x402：完全開源（Apache 2.0），由 x402 Foundation 推動多方參與（Coinbase、Cloudflare、Visa、Google）。
MPP：開放標準，由 Stripe 與 Tempo 共同制定，屬於 Stripe Agentic Commerce Suite 的一部分。

HTTP 機制
x402：復活 HTTP 402，通過 PAYMENT-REQUIRED 頭發起請求，使用 PAYMENT-SIGNATURE 完成重試。
MPP：同樣採用 challenge-response 機制，但使用的是 Payment HTTP Authentication Scheme（IETF 草案），通過 HMAC 綁定 challenge ID。

支付基礎（Rails）
x402：設計上鏈無關，目前在 Base、Polygon、Solana 上已有支援，其他鏈仍在探索中。
MPP：基於 Tempo 區塊鏈——一個為支付優化的 L1，支援 1 萬+ TPS、亞秒級確認，無原生 gas 代幣；長期目標是實現跨鏈兼容。

支付方式
x402：純穩定幣，完全鏈上。
MPP：支援 Tempo 上的 USDC + SPT（Stripe 的機制），實現加密與法幣混合（銀行卡、錢包、BNPL）。

結算方式
x402：按鏈上結算（約 200ms 至數秒），由 Coinbase 等 facilitator 負責驗證與結算。
MPP：Tempo 亞秒級確認，Stripe 自動入帳並處理合規。

商戶接入
x402：開源中介軟件（Express、Hono、Next.js 等），可自建或使用 facilitator。
MPP：直接接入 Stripe 的 PaymentIntents API，風控、稅務、退款、報表全部內建。

核心創新
x402：極致簡潔、無廠商綁定，類似支付領域的 Unix 哲學。
MPP：高吞吐 + 法幣融合，通過 session 實現流式支付、微支付聚合，以及基於 SPT 的可編程支出控制。

關鍵合作夥伴
x402：Coinbase、Cloudflare、Google（A2A/AP2）、Visa、World、Anthropic（MCP）。
MPP：Stripe、Visa、Lightspark、Anthropic、DoorDash、Mastercard、OpenAI、Shopify、Revolut、渣打銀行。

x402 更像是你在構建開放系統時的首選方案：獨立開發者 API、去中心化數據市場，或者任何不希望依賴支付處理商的服務。它的規範可以寫進一篇白皮書，接入只需要一個中介軟件和一個錢包地址。這種純粹性很有吸引力——儘管純加密的限制也意味著它的受眾更窄。

MPP 則是另一種完全不同的範式。如果你的 agent 需要在一次會話中進行數百甚至上千次交易，而不希望每次都上鏈，那麼它就是更合理的選擇。session 機制讓大部分互動保持在鏈下，直到最終結算；Stripe 的合規體系負責風控和稅務；而 SPT 的混合模式，則讓 agent 不再局限於穩定幣，還可以直接調用用戶的 Visa 等支付方式。它不那麼優雅，但更貼近現實。

有意思的是，它們其實並不完全是競爭關係。x402 覆蓋長尾開放場景，MPP 覆蓋企業級高頻流量。Stripe 的策略也很明確：不押注單一協議，而是確保無論哪條路徑勝出，資金最終都流入 Stripe 的帳戶體系。

現實情況：現在到底發展到哪一步了？

說實話，目前幾乎還沒有真正的規模化交易。

根據 Coinbase 的 x402 發布資訊，早期合作夥伴包括 Hyperbolic（GPU 推理付費）和 Anthropic（MCP 協議集成）。Stripe 的部落格提到按 API 調用付費的 agent 場景（例如 CoinGecko）。Tempo 上線時目錄中有 100+ 服務。Cloudflare 的 Agents SDK 已原生支持 x402，一些 Base L2 上的小項目也在嘗試用 x402 做付費網關。

但整體來看：交易量很小，商戶數量有限，大多數活動仍停留在實驗階段。

這其實並不意外。任何新的支付基礎設施，早期都是這樣。所謂合作夥伴名單，有時從簽了意向書到已經上線生產之間差距很大，而這些發布通常不會特別區分。

更值得關注的是基礎設施背後的重量級參與者。Stripe 在 2025 年處理了 1.9 萬億美元的支付，總量同比增長 34%。同時，Coinbase、Cloudflare、Visa、Google，以及 Tempo 的一整套合作網路都已入場。

也就是說，軌道已經鋪好。問題只剩一個：2026 年，AI agent 是否真的需要在這個軌道上大規模交易？還是這更像 1998 年鋪設光纖——需求還沒來，但基礎設施先行。

那該選哪一個？

如果你在構建一個開放、無需許可的系統——x402 是更自然的選擇。無需註冊平台、無需對接支付商，導入中間件、綁定錢包即可收款。代價是：合規、風控、法幣結算都要自己處理。

如果你已經在 Stripe 體系內，並希望接入 agent 流量——MPP 更合適。session、流式支付、法幣+加密混合，以及完整的合規體系，本質上更像配置升級，而不是系統重構。

如果你只關心一件事：不管 agent 用哪種協議，我都能收錢。那答案其實就是：用 Stripe。它兩邊都支持。

HTTP 402 終於派上用場了。只不過，它等了差不多 27 年。

[原文連結]