由 Consensys 打造的領先自託管加密貨幣錢包與 Web3 入口。
閱讀所有文章x402 重新啟用休眠的 HTTP 402 狀態碼,讓伺服器可以請求付款,AI 代理可以即時結算,無需帳戶或每次呼叫的結帳流程。

x402 是一種開放支付協議,利用 HTTP「402 Payment Required」狀態碼,讓伺服器在同一次 HTTP 交換中請求付款,客戶端則以已簽署的付款酬載回應。對 AI 代理而言,這意味著可以直接為 API、資料和運算資源付費,無需建立帳戶、儲存信用卡資訊,也不必在每次呼叫時中斷流程進行結帳——只要代理的錢包已具備消費授權即可。Coinbase 建立了 x402,Linux Foundation 現已托管獨立的 x402 Foundation,該協議也已成為機器對機器支付領域中最具代表性的新興基礎設施之一。
閱讀什麼是代理錢包?和 2026 年最佳代理錢包,深入了解 x402 如何作為代理與代理錢包互動的獨立層運作。為什麼每個 AI 代理都需要錢包和AI 代理如何在不接觸您私鑰的情況下進行交易則探討錢包如何決定託管、權限與簽署,而 x402 如何決定付款的定價與結算。本文將深入介紹 x402 的本質、付款流程的運作方式、建立者與治理架構,以及哪些產品支援它,填補上述內容的空白。
現行 HTTP 語義規範 RFC 9110 仍將 402 Payment Required 列為保留供未來使用。x402 以具體的付款流程啟用了這個保留狀態碼:伺服器聲明其接受的付款方式,客戶端附上已簽署的付款酬載,伺服器在返回資源前驗證並完成結算。
根據 x402 的客戶端/伺服器文件,典型的交換流程分為以下幾個步驟:
客戶端——由人操作的應用程式或自主代理——向伺服器請求資源。
伺服器回應 402 Payment Required 狀態,並附上標頭說明其接受的付款條件:價格、網路及目標地址。
客戶端建立符合其中一個接受選項的已簽署付款酬載,並將該酬載附加於請求中重新提交。
伺服器在本地或透過促進者驗證酬載,並在鏈上完成結算。
伺服器返回所請求的資源,並附上確認結算的標頭。
在 x402 V2 中,該交換流程以三個 Base64 編碼的 JSON 標頭進行標準化,取代了 V1 中已棄用的標頭:
標頭 | 方向 | 內容 |
PAYMENT-REQUIRED | 伺服器至客戶端 | 接受的付款選項:方案、網路、價格、目標地址 |
PAYMENT-SIGNATURE | 客戶端至伺服器 | 客戶端已簽署的付款酬載 |
PAYMENT-RESPONSE | 伺服器至客戶端 | 結算結果,成功或失敗 |
大多數賣家不會自行驗證和結算付款。促進者是一種可選但廣泛使用的服務,代表伺服器核對付款酬載是否符合要求,並在鏈上提交結算,讓伺服器無需自建區塊鏈基礎設施。促進者負責驗證並執行已簽署的酬載——不持有買家資金,也不擔任託管方。促進者目前已在 Base、Solana、Polygon、Avalanche 及其他網路上線運作。
並非每筆 x402 付款都在同一次往返中完成鏈上結算。該協議支援多種結算方案:exact 和 upto 通常立即結算,而批次結算則讓買家一次性將資金存入鏈上託管,為每個請求簽署鏈下憑證,並讓賣家稍後以單筆鏈上交易兌換多張憑證——專為高頻、計量制 API 呼叫設計,避免逐筆鏈上結算帶來的速度或成本問題。
Coinbase 建立了 x402,其基礎源自該公司自稱自 2015 年起持續推動的網際網路支付標準工作。Cloudflare 與 Coinbase 於 2025 年 9 月 23 日宣布成立 x402 Foundation 的意向,Coinbase 將目標定位為透過中立、開放的治理架構,而非 Coinbase 主導的標準,將 x402 確立為「AI 驅動支付的通用標準」。Cloudflare 同日在其 Agents SDK 和 MCP 伺服器中加入了 x402 支援。
2026 年 4 月 2 日,Linux Foundation 在 MCP Dev Summit North America 正式成立 x402 Foundation,接受 Coinbase 的協議貢獻,治理架構進一步完善。
Foundation 成立時獲得 22 個組織的初始支持,涵蓋支付網路、雲端服務供應商及區塊鏈基礎設施,包括 Adyen、Amazon Web Services、American Express、Circle、Cloudflare、Fiserv、Google、Mastercard、Microsoft、Polygon Labs、Shopify、Solana Foundation、Stripe 和 Visa。
x402 與代理錢包解決的是不同問題,這項區別對於建構具備交易功能的代理的開發者至關重要。錢包決定誰持有私鑰、代理被允許消費的範圍,以及交易是否獲得簽署。x402 則決定在錢包或代理已具備付款授權的前提下,特定付款請求如何定價、傳遞和結算。更換錢包不會改變 x402 的運作方式,採用 x402 也不會改變誰控制錢包的私鑰或消費限額——它們是各自獨立的層,只是恰好出現在同一筆交易中。
這種分離正是為什麼買方的 x402 支援是錢包功能,而非錢包架構。MetaMask 的 Smart Accounts Kit 透過 ERC-7710 委託支援 x402 付款,讓智能帳戶授權促進者在結算時兌換已簽署的委託,而無需為每個請求簽署全新的代幣授權。同一份文件也涵蓋定期 x402 付款,使用者只需授予一次週期性預算,代理即可在達到上限前,對符合條件的呼叫重複使用該權限。付款的託管模式、消費限額及人工升級規則仍完全由錢包負責,詳見AI 代理如何在不接觸您私鑰的情況下進行交易。
MetaMask 和 Consensys 並非 x402 的創建者——那是 Coinbase 的成果。他們的角色是讓該協議在自我託管的錢包基礎設施上運作。在《AI 代理時代的自我託管》一文中,Consensys 公開承諾支援 x402 並為規範的演進做出貢獻,目標是推動其走向多資產、多鏈支付流程,並將其與 ERC-7710 委託消費配對,讓代理能在使用者定義的限額內完成付款。
x402 並非唯一的代理支付協議,釐清它與另一個主要協議的關係十分重要。Google 的代理支付協議(AP2)於 2025 年 9 月 16 日發布,獲得超過 60 個組織的支持,是一個與支付方式無關的框架:它定義了以密碼學簽署的「Mandates」,用以證明使用者授權代理進行特定購買,並可跨信用卡、銀行轉帳及穩定幣等方式運作。
x402 可作為加密貨幣和穩定幣結算的擴充功能嵌入 AP2,而非作為競爭標準。Google 自己的公告指出,A2A x402 擴充功能是「與 Coinbase、Ethereum Foundation、MetaMask 及其他領先組織合作」建立的,Coinbase 也將 x402 描述為 AP2 的首批擴充功能之一,以及其唯一的穩定幣促進者。
MetaMask AI 負責人 Marco De Rossi 在 Google 的公告中直接說明了參與的理由:
「區塊鏈是代理的天然支付層,以太坊將成為其骨幹。透過代理支付協議(AP2)和 x402,MetaMask 將為開發者提供最大的互通性,並讓使用者在保有真正自我託管的安全性與控制權的同時,以完整的可組合性和選擇自由向代理付款。」
x402 的支援現已遠超其 Coinbase 起源,涵蓋錢包、支付網路及基礎設施供應商。
組織 | 角色 | 已推出的成果 |
Coinbase | 創建者、創始參與者 | 創建 x402、推出 AgentKit 和 Agent.market x402 付費牆服務目錄,並與 Cloudflare 共同推動 Foundation 的成立 |
Cloudflare | Foundation 共同創辦人 | 在其 Agents SDK 和 MCP 伺服器中支援 x402,並為其 Pay Per Crawl 測試版提供延遲付款方案 |
Linux Foundation | 自 2026 年 4 月 2 日起擔任治理主機 | x402 Foundation 及協議規範的正式管理者 |
Google Cloud | AP2 整合 | A2A x402 擴充功能,與 Coinbase、Ethereum Foundation 及其他組織共同建立(完整協作者名單請見上方 AP2 章節) |
MetaMask / Consensys | 錢包端支援、規範貢獻者 | 透過 Smart Accounts Kit 提供買方端 x402 支援;Consensys 已公開承諾擴充規範,並表示 DIN 已支援 x402 RPC 存取微支付 |
Solana Foundation | 早期採用網路 | 根據 Foundation 2026 年 4 月的聲明,佔 2026 年 x402 交易量的近 65% |
Visa、Stripe、Mastercard、American Express 及其他支付網路被列為 x402 Foundation 的創始支持者——這反映的是 Foundation 成員資格,而非其自有基礎設施上已確認的 x402 付款實作。
如需完整的各供應商代理錢包託管與付款實務比較,請參閱 2026 年最佳代理錢包。
AI 翻譯。可能包含錯誤。請務必核實資訊。