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

原文標題：Stripe's MPP vs. x402: What Actually Happened Today
原文作者：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，其核心思路幾乎可以說是極簡到激進。 客戶端請求資源；伺服器回傳 HTTP402，並告知客戶端：需要支付多少費用、使用什麼代幣、在哪條鏈上完成付款。 客戶端在鏈上完成付款後，將支付憑證附在重新發起的請求中，伺服器隨即交付資源。

就這麼簡單。 沒有帳戶體系，沒有 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 基礎設施處理了超過 5,000 萬筆交易。 聽起來很亮眼，但根據 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：完全開源（Apache 2.0），由 x402 Foundation 推動多方參與（Coinbase、Cloudflare、Visa、Google）。
MPP：開放標準，由 Stripe 與 Tempo 共同製定，屬於 Stripe Agentic Commerce Suite 的一部分。

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

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 年。