x402 vs MPP：比較 agent 付款協議

發布於 2026年3月18日閱讀時間 2 分鐘

自主代理需要為所使用的服務付費。不是將來,是現在。每當一個 agent 查詢區塊鏈資料、串流 LLM tokens、或呼叫付費 API 時,總得有人處理計費問題。目前的做法是 API 金鑰、計費儀表板、以及人工設定帳號。有兩個協定正試圖解決這個問題:x402 和 MPP。

2024 年底,Coinbase 推出了 x402:一個開放協定,讓 AI agent 可以呼叫 API、收到「先付款」的回應、以 Base 上的 USDC 結算、再重試,整個過程不需要 API 金鑰、計費帳號、或人工介入。之後 Tempo 和 Stripe 將這個理念進一步發展,提出了 Machine Payments Protocol(MPP)。MPP 定義在一份 IETF Internet-Draft 中,將 402 模式概化為一個與付款方式無關的框架,透過單一協定就能支援 stablecoins、信用卡、銀行轉帳、以及未來任何的支付管道。

本文將比較這兩個協定的差異、重疊之處、以及各自適用的場景。

概覽

	x402	MPP
Payment rails	USDC on Base and other networks	Stablecoin, card, bank: pluggable
Payment models	One-shot (exact)	One-shot (charge) + sessions
Session support	No	Yes (escrow + signed vouchers)
Protocol primitives	Implementation-defined	Standardized (idempotency, expiry, receipts, replay protection)
Transport	HTTP	HTTP + MCP
Standardization	Open-source, community-adopted	IETF Internet-Draft (co-authored by Tempo and Stripe)

x402 和 MPP 如何處理核心付款流程?

從核心來看,兩個協定遵循相同的流程:agent 呼叫 API,伺服器回應付款挑戰,客戶端付款後重試,並取得回應。簡單、優雅、且原生支援 HTTP。

兩者的差異在於範疇、彈性、以及各自選擇標準化的內容。

x402 和 MPP 如何處理付款管道?

x402 圍繞鏈上 stablecoin 付款建構,主要是 Base 及其他支援網路上的 USDC。如果你的使用場景是原生加密貨幣的 agent 用 stablecoin 付款,x402 提供了一條直接的路徑。

MPP 採取不同的做法:協定本身與付款方式無關。核心規格定義了伺服器與客戶端如何協商、發出挑戰、並結算,但實際的付款管道是一個可插拔的層。目前 MPP 提供兩種正式運作的付款方式:Tempo(stablecoin 付款)和 Stripe(信用卡、電子錢包、以及其他傳統付款方式),伺服器可以同時宣告支援這兩種。客戶端則選擇自己支援的方式。

任何人都可以透過指定 request schema 和 payload schema 來定義新的付款方式,不需要基金會或中介機構的核准。付款方式之間比拼的是採用率,而非許可權。

如果你是為原生加密貨幣的使用者建構產品,x402 能讓你最快上手。如果你面對的是企業客戶、傳統支付整合商、或混合的使用族群,MPP 支援多種付款管道意味著你不必二選一。對於需要直接與傳統商家交易的 agent,AgentCard 這類專案提供了互補的做法:發行 agent 可用於任何線上購物的信用卡,並內建支出限額和即時追蹤。

兩者支援哪些付款模式?

x402 專注於「exact」付款模式:一次請求、一次付款、一次回應。這種模式簡潔明瞭,容易理解,適合離散的 API 呼叫。

MPP 透過其 charge intent 支援相同的流程,事實上,x402 的 exact 流程可以直接對應到 MPP 的 charge,使兩個協定在這一層具有相容性。

但 MPP 還引入了 sessions:一種為高吞吐量使用場景設計的全然不同的付款模式。使用 sessions 時,客戶端一次性將資金存入託管合約,然後透過鏈下的簽署憑證(signed vouchers)發出多次請求。伺服器定期在鏈上結算累積的憑證。

以下是各流程的簡化示意:

X402:一次請求、一次付款

text

Copied

# Step 1: Call the API
GET /v2/eth-mainnet/getTokenBalances HTTP/1.1

# Step 2: server responds with payment challenge
HTTP/1.1 402 Payment Required
X-Payment-Challenge: {"amount": "0.001", "currency": "USDC", "address": "0x..."}

# Step 3: client pays on-chain, retries with receipt
GET /v2/eth-mainnet/getTokenBalances HTTP/1.1
X-Payment: {"txHash": "0x...", "signature": "0x..."}

# Step 4: server verifies and responds
HTTP/1.1 200 OK

MPP session:一次存款、發出上千次請求

text

Copied

# Step 1: Open a session (deposit funds to escrow once)
POST /mpp/sessions HTTP/1.1
{"amount": "10.00", "currency": "USDC", "method": "tempo"}

HTTP/1.1 201 Created
{"sessionId": "sess_abc123", "balance": "10.00"}

# Step 2: make requests with signed vouchers (no on-chain tx per request)
GET /v2/eth-mainnet/getTokenBalances HTTP/1.1
MPP-Session: sess_abc123
MPP-Voucher: {"amount": "0.0001", "nonce": 42, "sig": "0x..."}

HTTP/1.1 200 OK  # Sub-100ms, no waiting for chain confirmation

MPP sessions 可以做到:

每次請求最低 $0.0001 的付款
低於 100 毫秒的延遲:每次請求不需要鏈上確認
近乎零的每次請求手續費:只有淨結算會上鏈

這為何重要: 按 token 計費的 LLM 串流、高吞吐量的資料饋送、以及即時鏈上監控,都因此變得具有經濟可行性。若每一次互動都要在鏈上付款,gas 費用可能會超過資料本身的價值。sessions 徹底改變了這個成本結構,讓大規模的微支付存取變得實際可行。

各自提供哪些協定層級的基礎功能?

MPP 將多項生產環境中的考量直接內建於協定規格中,因此每個實作都能直接繼承,而不必自行重新發明:

冪等性(Idempotency): 安全重試,不會重複扣款
過期機制: 挑戰會逾時,避免使用過期的付款
請求主體綁定: SHA-256 摘要防止挑戰與付款之間遭到竄改
重放保護: 以 HMAC 綁定挑戰 ID
結構化錯誤: 採用 RFC 9457 格式,便於機器可讀的錯誤處理
正式收據: 標準化的付款收據,方便稽核

x402 在實作層級處理其中部分項目,其餘則交由個別開發者自行解決。MPP 將這些統一標準化,讓每個伺服器與客戶端一開始就能使用相同的語言溝通,這在不同廠商的 agent 需要可靠互通時尤其重要。

MPP 是否能在 HTTP 之外運作?

x402 運作於 HTTP 之上。MPP 也運作於 HTTP,但額外加入了 MCP(Model Context Protocol)傳輸綁定。

這代表 MCP 工具伺服器可以直接將工具呼叫貨幣化。AI agent 呼叫付費工具時,會在工具回應中收到付款挑戰,付款後重試,整個過程都在 MCP 訊息流程中完成。不需要 OAuth,不需要設定帳號,也不需要 HTTP 層。

在此之前,將 AI 工具呼叫貨幣化需要仰賴帶外(out-of-band)計費或平台協議。透過 MPP 的 MCP 傳輸,開發者可以發布一個付費工具,任何相容 MCP 的 agent 都能自主發現、付款、並使用,不需要人工介入。

兩者在標準化方面有何差異?

x402 是一個開放原始碼協定,採用度持續成長。它已在 Coinbase 的正式環境中經過實戰驗證,並在整個生態系中獲得越來越多的支援。

MPP 的核心規範,Payment HTTP Authentication Scheme,已提交為 IETF Internet-Draft,由 Tempo 和 Stripe 共同撰寫。付款方式(payment methods)與付款意圖(intents)則是各自獨立的規格,任何人都可以自行撰寫並發布。這與網路本身的運作方式相似:HTTP 是標準化的,但內容類型與驗證機制各自獨立演進。

Internet-Draft 是一份工作中的文件,尚未進入標準軌道成為 RFC,但提交至 IETF 這件事本身,顯示了朝向長期互通性與穩定性的意圖。

x402 和 MPP 是否相容?

是的。MPP 向後相容於 x402。x402 核心的「exact」付款流程可以直接對應到 MPP 的 charge intent,因此 MPP 的客戶端能夠直接使用既有的 x402 服務。如果你已經以 x402 為基礎建構,MPP 是在既有基礎上擴展,而不是取而代之。

開始使用 Alchemy 建構

Alchemy 的 API 平台同時支援 x402 和 MPP。這代表你的 agent 可以存取區塊鏈資料(代幣餘額、NFT metadata、交易紀錄、智能合約讀取、價格饋送等等),並透過任一協定按請求付費,不需要 API 金鑰,不需要計費儀表板,只需要一個錢包和一次 HTTP 呼叫。

透過 x402,agent 可以用 SIWE(Sign-In with Ethereum)或 SIWS(Sign-In with Solana)進行驗證,以 Base 上的 USDC 付款,並取得 Alchemy 端點的存取權限。透過 MPP,同一個 agent 可以在多種付款方式之間協商(透過 Tempo 使用 stablecoin、透過 Stripe 使用信用卡),並針對高吞吐量的工作負載(如索引流程或即時鏈上監控)使用 sessions。

你可以建構的內容包括:

自主區塊鏈 agent,可查詢鏈上資料並為每次呼叫付費,不需要人工設定帳號
多鏈資料管線,可從 Ethereum、Base、Polygon、Solana 等鏈拉取資料,並透過 MPP sessions 以低於一分錢的費率按請求付費
AI 驅動的錢包與助理,可取得投資組合資料、模擬交易、監控地址,且完全自行支付費用
MCP 工具伺服器,可將 Alchemy 端點封裝為付費工具,讓任何相容 MCP 的 agent 都能隨需存取區塊鏈基礎設施

從終端機試用

安裝 Alchemy CLI,然後加入 Alchemy Skills 並連接 MCP server:

bashCopied
npm i -g @alchemy/cli@latest
alchemy auth
npx skills add alchemyplatform/skills --yes

# Claude Code
claude mcp add alchemy --transport http https://mcp.alchemy.com/mcp

# Codex
codex mcp add alchemy --url https://mcp.alchemy.com/mcp

alchemy --json --no-interactive balance vitalik.eth -n eth-mainnet

準備好開始了嗎?前往 alchemy.com/agents 探索平台,開始建構能為自身基礎設施付費的 agent。

常見問題

我可以同時使用 x402 和 MPP 嗎?

可以。由於 MPP 的 charge intent 向後相容於 x402,你可以同時支援兩者。伺服器可以同時宣告支援這兩種協定,並讓客戶端選擇自己支援的一種。

我該選擇哪一個?

如果你正在建構一個原生加密貨幣、以 stablecoin 付款的 agent,並希望以最簡單的方式投入生產環境,可以從 x402 開始。如果你需要多種付款管道的支援、適用於高吞吐量工作負載的 sessions、MCP 傳輸整合、或標準化的協定基礎功能,MPP 會是更適合的選擇。你不需要放棄既有的 x402 投入就能轉換過去。

x402 會被 MPP 取代嗎?

不會。MPP 的設計目標是與 x402 相容,而非取而代之。可以把 MPP 視為一種演進,增加了 x402 原本未打算提供的能力。x402 社群仍持續獨立成長。

MPP 目前支援哪些付款方式?

MPP 提供兩種正式運作的付款方式:Tempo 用於 stablecoin 付款,Stripe 用於信用卡、電子錢包、以及其他傳統付款方式。由於付款方式是可插拔的,任何人都可以透過指定 request schema 和 payload schema 來定義並發布新的付款方式。

我需要自行架設基礎設施才能使用這些協定嗎?

不需要。Alchemy 的 API 平台同時支援 x402 和 MPP,因此你可以開始建構能為區塊鏈資料付費的 agent,而不需要自行架設任何付款基礎設施。前往 alchemy.com/agents 開始使用。