header-langage
简体中文
繁體中文
English
Tiếng Việt
한국어
日本語
ภาษาไทย
Türkçe
掃碼下載APP

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

閱讀本文需 18 分鐘
x402做協議內支付,MPP做系統級支付
原文標題: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 年。


[原文連結]



歡迎加入律動 BlockBeats 官方社群:

Telegram 訂閱群:https://t.me/theblockbeats

Telegram 交流群:https://t.me/BlockBeats_App

Twitter 官方帳號:https://twitter.com/BlockBeatsAsia

举报 糾錯/舉報
選擇文庫
新增文庫
取消
完成
新增文庫
僅自己可見
公開
保存
糾錯/舉報
提交