隨著 AI Agent 從工具屬性向自主經濟主體逐漸演進，AIAgent 成為能夠自主決策、執行操作並進行價值交換的經濟參與者。然而，傳統支付基礎設施無法滿足 Agent 的自主交易、跨生態交互、可驗證身分等一系列核心需求。
這些瓶頸催生了新一代協議的誕生——x 402 、Agent Payments Protocol ( AP 2) 和ERC- 8004 ，為即將到來的機器經濟構建可靠的價值交換基礎。本文將深入解析這三大協議的技術原理、應用場景與生態現狀，揭示它們如何共同塑造未來AIAgent經濟的支付圖景。
![] ( https://img-cdn.gateio.im/social/moments-f 8 a 84661 da 3 b 3223 c 824 ab 2 c 2 cadc 3 f 7)
x 402 由 Coinbase 推出，其核心創新在於激活互聯網未充分利用的 HTTP 402 狀態碼（“PaymentRequired”），將支付邏輯原生嵌入網頁請求-回應流，實現「API 呼叫即支付」，並透過穩定幣或其它加密資產完成結算，以解決傳統支付的高摩擦問題。
由於 x 402 是基於 HTTP 402 狀態碼構建的開放協議，其架構為客戶端/伺服器架構。客戶端為購買服務/商品的買家，伺服器這一端是提供服務/商品的賣家。在客戶端/伺服器架構的基礎上，Coinbase 為賣家提供了促成者 ( Facilitators ) 的服務，以簡化買家和賣家之間驗證和結算付款的過程。
我們以 x 402 scan 中排名第一的伺服器 Canza（提供交易資訊的 AI）為例。首先用戶在客戶端發起請求以存取 Canza 的付費服務。
![] ( https://img-cdn.gateio.im/social/moments- 4 f 562918407 b 8 c 6 d 44 d 85 aaf 72 de 30 b 6)
隨後 Canza 伺服器使用 HTTP 402 Response 定義支付要求：客戶端需要提供 X-PAYMENT Header 並透過 Base 鏈的 USDC 進行支付。如下圖所示：
![] ( https://img-cdn.gateio.im/social/moments- 72 db 5 ed 3693 dcad 8223 f 342 f 1 be 14558)
客戶端解析 402 Response JSON 內容後，錢包將提示需簽署一條 TransferWithAuthorization 的訊息（透過 ERC- 3009 實現）。該訊息允許簽署者透過委託第三方 EOA 地址或合約地址從簽署者地址進行無 Gas 費用轉帳。本例子中，我們將委託 Canza 的收款地址 0 x 4 e 9 bCe 2547 A 9491 b 09 ed 092 c 433 B 19888 e 665 edB 從我們的錢包中轉移 USDC。
![] ( https://img-cdn.gateio.im/social/moments-ced 25702 a 668725 f 0 d 611 e 908 bfaebb 0)
隨後用戶簽署該訊息，客戶端使用 base 64 編碼的 X-PAYMENT Header 提交 Payload，Canza 伺服器收到傳入的 Payload 後會由促成者 ( Facilitators ) 進行驗證，並為伺服器在區塊鏈上結算付款。在 Canza 伺服器確認付款後，Canza 為用戶提供所請求的服務。
透過上述例子，x 402 協議的運作流程可以總結如下：
![] ( https://img-cdn.gateio.im/social/moments-aa 24950 f 66 af 54874 bd 099 ad 64 a 9 dbe 8)
特別值得注意的是，x 402 協議是支援多條區塊鏈（Base、Avalanche 等 EVM 鏈、Solana）的多種加密資產（需支援 ERC- 3009 ，默認為 USDC）用於支付的，只需要伺服器這一端在進行配置即可：
![] ( https://img-cdn.gateio.im/social/moments- 9 bef 6355 fe 7269 cc 5 ac 08 f 119377 c 363)
AP 2 是基於 AgenttoAgent（A 2 A）通信協議與 Model Context Protocol（MCP）擴展的開放支付框架。其核心目標是解決 Agent 商業中的三大核心問題：授權驗證（證明 Agent 獲得用戶許可）、真實性（確保交易反映用戶真實需求）、交易問責（明確糾紛時的責任歸屬），以實現 AIAgent 與任何合規的商家進行安全的交易。
AP 2 協議的工作流程圍繞著數位授權書 ( Mandates ) 這一核心概念構建，這些授權書是防篡改、經過密碼學簽名的數位合約，作為用戶指令的可驗證證據。具體分為三種授權書：
** 1 .意圖授權書 ( Intent Mandate ) **
適用於用戶不在場的自動化交易。用戶預先向 AIAgent 提供的操作指令，包含明確的條件約束，例如「購買演唱會門票，預算不超過 500 元」。
![] ( https://img-cdn.gateio.im/social/moments-a 370234 d 3 d 86 da 6913 cc 5 e 3338930569)
** 2 .購物車授權書 ( Cart Mandate ) **
適用於用戶在場確認的交易。當代理準備好具體的商品和價格供用戶確認時生成。用戶對此的批准會簽署購物車授權書，建立關於確切商品和價格的安全、不可更改的紀錄，確保所見即所付。
![] ( https://img-cdn.gateio.im/social/moments- 720852 d 4 fe 6 f 0636 e 2 d 64271993973 ab )
** 3 .支付授權書 ( Payment Mandate ) **
這是一個獨立的憑證，與支付網路和發卡方共享，旨在傳遞 AI Agent 參與和用戶存在情況的資訊，協助解決交易爭議、進行風險評估和監管。
![] ( https://img-cdn.gateio.im/social/moments- 810 a 9480851 e 7 e 4 ef 2 a 7 ae 46 e 7 eb 4 e 24)
ERC- 8004 是以太坊的去中心化 AIAgent 身分解決方案，旨在解決判斷 AIAgent 身分真實性、行為紀錄可靠性及可驗證性的问题。與 AP 2 不同的是，ERC- 8004 重點在於構建 AIAgent 之間的交互信任，而非用戶-AIAgent-商家三方之間的交易信任。
ERC- 8004 的設計圍繞三個輕量級註冊表構建，每個註冊表負責信任模型的不同方面：
** 1 .身分註冊表（Identity Registry）**
基於 ERC- 721 標準實現，並擴展了 URIStorage 功能，這樣設計可以讓 AIAgent 身分與現有 NFT 生態系統相容。
![] ( https://img-cdn.gateio.im/social/moments- 7251 bc 0031726 b 9 d 8 d 1 acee 3 c 5257 ff 6)
每個 AIAgent 透過呼叫 register 函數註冊，獲得一個唯一的 agentId（即 ERC- 721 的 tokenId）。註冊時，代理需要提供指向其註冊檔（Agent Registration File）的 tokenURI，該檔案遵循標準化 JSON 格式，包含代理的名稱、描述、端點和支援的信任模型等資訊。
** 2 .聲譽註冊表（Reputation Registry）**
提供標準介面用於發布和取得 AIAgent 的服務反饋，支援 0 - 100 的評分反饋系統、標籤分類和支付證明關聯。該註冊表採用鏈上鏈下混合架構，既保證了核心資料的鏈上可組合性，又將複雜聚合計算留給鏈下處理以提高效率。
![] ( https://img-cdn.gateio.im/social/moments- 3 f 55 c 5102 f 78 dd 664 faf 90 fceff 7 f 016)
聲譽註冊表的合約結構與身分註冊表關聯緊密——在部署時需傳入身分註冊表的地址，確保只有已註冊的 AIAgent 才能獲得聲譽記錄。
** 3 .驗證註冊表（Validation Registry）**
提供通用 Hook 用於請求和記錄獨立驗證結果，支援多種驗證機制包括經濟質押（驗證者重新運行任務）和密碼學證明（TEE 證明、 zkML 驗證等）這種設計使得不同安全需求的驗證機制可以共存於同一生態中。
驗證註冊表的合約介面相對簡單，主要包含兩個函數：ValidationRequest 用於提交驗證請求，ValidationResponse 用於記錄驗證結果。
ERC- 8004 是 AIAgent 生態的身分層協議。它為鏈上 AI Agent 提供了可驗證的身分、信譽系統和註冊機制，是建立機器經濟信任基礎的關鍵。
x 402 、AP 2 和 ERC- 8004 三者結合，構成了一個完整的 AIAgent 支付體系：ERC- 8004 解決 AIAgent 的身分問題，x 402 解決「如何使用加密貨幣進行高頻微支付」的問題，AP 2 則為 x 402 這一支付協議提供安全的、標準化的框架，為 AI Agent 設定了獨立的經濟行為邊界，讓它們能處理資訊、持有和支配資產，能夠真正參與到商業的價值交換中，從而催生出由機器自主驅動的新經濟形態。
