x402 A2A 传输层实现指南基于 JSON-RPC 与任务状态的 Agent 间支付协议规范【免费下载链接】x402A payments protocol for the internet. Built on HTTP.项目地址: https://gitcode.com/GitHub_Trending/x4/x402x402 是一个构建在 HTTP 之上的互联网支付协议v2 规范在保持核心传输无关transport-agnostic设计的同时定义了多套传输层实现其中 A2AAgent-to-Agent Protocol传输让 AI Agent 能够以链上加密货币结算的方式相互付费。本篇技术文章以 specs/transports-v2/a2a.md 为核心骨架完整讲解 A2A 传输的三类支付消息支付要求、支付载荷、结算回执、六个支付状态与任务状态的映射关系、错误处理规则以及扩展声明与激活机制读完后你可以直接按照规范构造 A2A JSON-RPC 消息理解 x402 v2 各 schema 在 A2A 元数据中的落位方式并与 HTTP 传输、核心 v2 规范 相互印证。1. 为什么 A2A 传输需要独立的规范x402 v2 的核心架构将协议拆分为三层见 specs/x402-specification-v2.md 的 Architecture 一节Types核心数据结构PaymentRequired、PaymentPayload、SettlementResponse与传输机制和支付方案均无关Logic依赖支付方案如exact与网络EVM、Solana的支付构造与验证逻辑Representation支付数据如何传输与信令取决于具体传输机制HTTP、MCP、A2A。A2A 传输正是第三层的实现它通过 A2A 协议的JSON-RPC 消息和基于任务task的状态管理承载 x402 支付流程使 Agent 能在 A2A 框架内借助任务生命周期task lifecycle与元数据metadata系统完成支付协调。规范开篇即点明其定位The A2A transport implements x402 payment flows over the Agent-to-Agent protocol using JSON-RPC messages and task-based state management.与 HTTP 传输用 402 状态码和 base64 头部PAYMENT-REQUIRED/PAYMENT-SIGNATURE/PAYMENT-RESPONSE做信令不同A2A 传输把支付信令放进消息元数据字段并用A2A 任务状态表达支付进展。从源码结构看当前仓库的 TS / Go / Python SDK 均已实现 HTTP 与 MCP 传输如 typescript/packages、go/http、python/x402/httpA2A 传输则由外部的 a2a-x402 扩展规范承载——这也解释了为什么本规范以纯协议文档形式给出而不附带仓库内的 A2A 实现代码。另外需要注意 v2 与 v1 的差异本仓库同时收录了 specs/transports-v1/a2a.mdv1 使用network: base这类扁平字段并把resource内嵌在accepts的每项中v2 则采用 CAIP-2 网络标识eip155:8453、独立的ResourceInfo对象以及PaymentPayload.accepted结构。下文均以 v2 为准。2. 支付要求信令input-required 任务状态 元数据A2A 传输中服务端 Agent 通过 A2A 任务状态input-required配合支付元数据来指示“需要支付”信令机制任务state: input-required 消息元数据x402.payment.status: payment-required数据格式PaymentRequiredschema放在元数据字段x402.payment.required中。完整的 JSON-RPC 响应示例规范原文{ jsonrpc: 2.0, id: req-001, result: { kind: task, id: task-123, status: { state: input-required, message: { kind: message, role: agent, parts: [ { kind: text, text: Payment is required to generate the image. } ], metadata: { x402.payment.status: payment-required, x402.payment.required: { x402Version: 2, error: Payment required to access this resource, resource: { url: https://api.example.com/generate-image, description: Generate an image, mimeType: image/png }, accepts: [ { scheme: exact, network: eip155:8453, amount: 48240000, asset: 0x833589fCD6eDb6E08f4c7C32D4f71b54bda02913, payTo: 0xServerWalletAddressHere, maxTimeoutSeconds: 600, extra: { name: USD Coin, version: 2 } } ] } } } } } }对照核心规范 5.1 节的PaymentRequired字段表可以逐字段解读该元数据对象字段类型必填含义结合 v2 规范字段表x402Versionnumber是协议版本标识v2 中必须为 2errorstring否人类可读的说明解释为何需要支付resourceobject是ResourceInfo对象描述受保护资源acceptsarray是可接受的支付方式数组每项为一个PaymentRequirements对象extensionsobject否协议扩展数据本示例中省略其中accepts数组内每个PaymentRequirements对象的关键字段字段必填说明scheme是支付方案标识当前为exactnetwork是CAIP-2 格式网络标识示例中eip155:8453为 Base 主网amount是以原子单位计的最小/精确支付额示例48240000即 6 位小数的 USDC 计 48.24 USDasset是ERC-20 代币合约地址fiat 场景下可为 ISO 4217 货币码payTo是收款钱包地址或角色常量如merchantmaxTimeoutSeconds是完成支付允许的最大时长示例为 600 秒extra否方案附加信息如代币名称name与版本versionResourceInfo对象包含url必填受保护资源 URL、description可选、mimeType可选期望响应的 MIME 类型。示例中mimeType为image/png与服务端文本部分 Payment is required to generate the image. 呼应展示了一个图像生成 Agent 的收费场景。要点与 HTTP 传输不同A2A 不需要任何 base64 编码——PaymentRequired以原生 JSON 形式直接挂在metadata[x402.payment.required]下人类可读且便于 Agent 解析parts中的自然语言文本则面向人类或供上层 LLM 理解。3. 支付载荷传输message/send taskId 关联客户端使用 A2A 消息元数据携带支付数据并用taskId与服务端此前的任务做关联信令机制消息元数据包含x402.payment.payload字段并通过taskId关联任务数据格式PaymentPayloadschema放在元数据字段x402.payment.payload中。客户端通过message/send方法发起 JSON-RPC 请求规范原文示例{ jsonrpc: 2.0, method: message/send, id: req-003, params: { message: { taskId: task-123, role: user, parts: [ { kind: text, text: Here is the payment authorization. } ], metadata: { x402.payment.status: payment-submitted, x402.payment.payload: { x402Version: 2, resource: { url: https://api.example.com/generate-image, description: Generate an image, mimeType: image/png }, accepted: { scheme: exact, network: eip155:8453, amount: 48240000, asset: 0x833589fCD6eDb6E08f4c7C32D4f71b54bda02913, payTo: 0xServerWalletAddressHere, maxTimeoutSeconds: 600, extra: { name: USD Coin, version: 2 } }, payload: { signature: 0x2d6a7588d6acca505cbf0d9a4a227e0c52c6c34008c8e8986a1283259764173608a2ce6496642e377d6da8dbbf5836e9bd15092f9ecab05ded3d6293af148b571c, authorization: { from: 0x857b06519E91e3A54538791bDbb0E22373e36b66, to: 0xServerWalletAddressHere, value: 48240000, validAfter: 1740672089, validBefore: 1740672154, nonce: 0xf3746613c2d920b5fdabc0856f2aeb2d4f88ee6037b8cc5d04a71a4462f13480 } } } } } } }结合 v2 规范 5.2 节的PaymentPayload字段表其结构要点x402Version必填协议版本resource可选ResourceInfo对象回显所访问资源便于服务端与支付要求中的资源做一致性核对accepted必填客户端从服务端accepts中选定的一份PaymentRequirements原样回传——这是 A2A 传输与 v1 的关键差异之一v1 直接在 payload 顶层平铺scheme/network等字段v2 将其封装为accepted对象payload必填方案特定的支付数据。对于exact EVM 组合按核心规范 5.2.2 字段表包含两个字段signature对authorization的 EIP-712 签名authorizationEIP-3009transferWithAuthorization授权对象字段为from付款方地址、to收款地址、value原子单位金额、validAfter/validBeforeUnix 时间戳构成的有效时间窗、nonce32 字节随机数防重放。extensions可选客户端回显服务端下发的扩展信息可按需追加但不可删改既有 info见核心规范 5.1.2 Extensions 说明。taskId示例中task-123承担请求-支付关联的职责A2A 是任务驱动模型客户端把支付载荷挂回原任务服务端即可将这笔授权与该任务此前下发的PaymentRequired对应起来。同时元数据中的x402.payment.status: payment-submitted声明了当前支付状态供服务端识别消息语义。底层原理佐证authorization各字段的安全作用在核心规范第 10 节Security Considerations中给出了系统说明——EIP-3009 的 32 字节nonce防止重放智能合约层面天然拒绝 nonce 复用、validAfter/validBefore时间窗限制授权生命周期、签名确保授权由付款方本人发起。Facilitator 在验证时执行六步检查签名验证、余额检查、金额精确匹配、时间窗检查、参数匹配、交易模拟这些检查的失败会分别映射为第 5 节所述的不同支付状态与错误码。4. 结算回执投递任务状态更新 receipts 元数据服务端通过任务状态更新投递结算结果元数据字段x402.payment.receipts承载SettlementResponseschema 数组。4.1 成功结算{ jsonrpc: 2.0, id: req-003, result: { kind: task, id: task-123, status: { state: completed, message: { kind: message, role: agent, parts: [ { kind: text, text: Payment successful. Your image is ready. } ], metadata: { x402.payment.status: payment-completed, x402.payment.receipts: [ { success: true, transaction: 0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef, network: eip155:8453, payer: 0x857b06519E91e3A54538791bDbb0E22373e36b66 } ] } } }, artifacts: [ { kind: image, name: generated-image.png, mimeType: image/png, data: base64-encoded-image-data } ] } }对照核心规范 5.3 节SettlementResponse字段表success必填布尔表示结算是否成功transaction必填失败时为空字符串而非缺省network必填CAIP-2 格式errorReason失败时给出payer可选amount可选实际结算金额extensions可选。注意result中的artifacts数组这是 A2A 特有的能力——支付成功后Agent 直接在任务结果里附带交付物示例为 base64 编码的 PNG 图像使“付费 → 交付”在一次任务状态更新中闭环。4.2 支付失败{ jsonrpc: 2.0, id: req-003, result: { kind: task, id: task-123, status: { state: failed, message: { kind: message, role: agent, parts: [ { kind: text, text: Payment verification failed: The signature has expired. } ], metadata: { x402.payment.status: payment-failed, x402.payment.error: EXPIRED_PAYMENT, x402.payment.receipts: [ { success: false, errorReason: Payment authorization was submitted after its validBefore timestamp., network: eip155:8453, transaction: } ] } } } } }失败回执的要点任务状态转failed元数据额外携带x402.payment.error机器可读错误码示例为EXPIRED_PAYMENT对应授权超出validBefore时间窗x402.payment.receipts中success: false、transaction为空字符串并给出errorReason。从源码结构看这类errorReason文案源自 Facilitator/verify、/settle接口的响应见核心规范 7.1/7.2 节A2A 服务端只是将其透传进元数据。5. 支付状态生命周期与任务状态映射A2A 传输用x402.payment.status元数据字段跟踪一条细粒度的支付状态推进每个状态对应 A2A 任务状态规范原文表格完整保留支付状态含义对应任务状态payment-required支付要求已发送给客户端input-requiredpayment-rejected客户端拒绝了支付要求failed或input-requiredpayment-submitted服务端已收到支付载荷input-required→workingpayment-verified服务端已验证支付载荷workingpayment-completed链上结算成功working→completedpayment-failed支付验证或结算失败failed这张表揭示了 A2A 传输的设计精髓支付流程不是独立的 HTTP 往返序列而是被“织入”了 A2A 任务状态机。任务停在input-required意味着服务端在等待客户端输入——在支付语境下等待的就是支付授权客户端提交授权后任务进入working验证与链上结算完成后任务转为completed并携带artifacts交付结果。payment-verified与payment-completed之间的区分也值得注意前者表示签名/余额等校验通过对应 Facilitator/verify成功后者表示交易已上链对应/settle成功两者之间仍存在结算失败的窗口。6. 错误处理x402 错误到任务状态与元数据的映射A2A 传输将 x402 标准错误映射为任务状态 支付状态规范原文表格完整保留x402 错误任务状态支付状态说明Payment Requiredinput-requiredpayment-required访问资源需要支付Payment Rejectedfailedpayment-rejected客户端拒绝支付要求Invalid Paymentfailedpayment-failed支付载荷或支付要求格式非法Payment Failedfailedpayment-failed支付验证或结算失败Server Errorfailedpayment-failed支付处理过程中服务端内部错误Successcompletedpayment-completed支付验证与结算均成功错误响应的具体形态任务状态转failed元数据中携带x402.payment.status、机器可读错误码x402.payment.error以及x402.payment.receipts规范原文示例{ kind: task, id: task-123, status: { state: failed, message: { kind: message, role: agent, parts: [ { kind: text, text: Payment verification failed: insufficient funds } ], metadata: { x402.payment.status: payment-failed, x402.payment.error: INSUFFICIENT_FUNDS, x402.payment.receipts: [ { success: false, errorReason: The clients wallet has insufficient funds to cover the payment., network: eip155:8453, transaction: } ] } } } }这里体现了 A2A 传输的双通道错误表达parts中的自然语言文本Payment verification failed: insufficient funds面向人与 LLM 上下文而x402.payment.error错误码如INSUFFICIENT_FUNDS、EXPIRED_PAYMENT面向程序化决策。核心规范第 9 节定义了 Facilitator 层面的标准错误码snake_case如insufficient_funds、invalid_exact_evm_payload_authorization_valid_before等A2A 层将其归一为 UPPER_SNAKE 风格的传输层错误码实现时可参照核心规范的错误码表建立映射。客户端据此可以做出可区分的动作对EXPIRED_PAYMENT重新签名对INSUFFICIENT_FUNDS提示充值或换用其他accepts项。7. 扩展声明与激活A2A 采用扩展extension机制实现可选能力协商。支持 x402 支付的 Agent 必须在其AgentCard中声明该扩展{ capabilities: { extensions: [ { uri: https://github.com/google-a2a/a2a-x402/v0.1, description: Supports payments using the x402 protocol for on-chain settlement., required: true } ] } }客户端则必须通过X-A2A-ExtensionsHTTP 头部激活该扩展X-A2A-Extensions: https://github.com/google-a2a/a2a-x402/v0.1声明AgentCard 中的capabilities.extensions与激活请求头X-A2A-Extensions两段式协商的意义在于AgentCard 是静态能力发现载体客户端在发起任务前即可判断对端是否支持付费X-A2A-Extensions头部则在具体请求维度显式激活扩展使服务端确定性地知道应当启用 x402 支付流程包括在收费资源上返回payment-required。required: true表示该扩展为 Agent 正常服务所必需未激活该扩展的客户端不应预期能完成付费任务。8. 与 HTTP 传输的对照及实现要点把 specs/transports-v2/http.md 与 specs/transports-v2/a2a.md 并排阅读可以清楚看到 x402 传输层抽象的一致性——三个核心 schema 完全相同变化的只是承载容器环节HTTP 传输A2A 传输支付要求信令402 状态码 PAYMENT-REQUIRED头部base64 编码任务状态input-required 元数据x402.payment.required原生 JSON支付载荷传输PAYMENT-SIGNATURE请求头base64 编码message/send请求元数据x402.payment.payloadtaskId关联结算回执PAYMENT-RESPONSE响应头base64 编码任务状态更新元数据x402.payment.receipts状态表达HTTP 状态码402/200/400/500任务状态机input-required/working/completed/failedx402.payment.status这一对照对实现者有三点直接启示schema 复用A2A 消息元数据中的x402.payment.required/x402.payment.payload/x402.payment.receipts对象就是核心规范 5.1/5.2/5.3 节定义的PaymentRequired/PaymentPayload/SettlementResponse可直接复用现有校验逻辑无需为 A2A 单独定义数据结构。关联模型不同HTTP 靠 URL 与请求-响应配对A2A 靠taskId把支付授权绑定到具体任务实现多任务并发时的支付隔离。交付通道不同HTTP 的交付物是响应体A2A 的交付物是任务artifacts天然适配文件、图像等多模态 Agent 输出。关于适用范围与限制需要说明本规范描述的是协议报文格式仓库当前未包含 A2A 传输的 SDK 实现代码TS/Go/Python 包覆盖 HTTP 与 MCP 传输A2A 扩展的完整外部规范见文档 References 一节指向的 a2a-x402 项目核心 v2 规范 12.5 节也列出了客户端库路线图中 A2A 侧对应 python 的x402_a2a。网络标识须用 CAIP-2 格式如eip155:8453为 Base 主网、eip155:84532为 Base Sepolia 测试网amount一律为原子单位字符串这些约束在构造任何 A2A 支付消息时都同样适用。9. 小结specs/transports-v2/a2a.md 以 A2A 的 JSON-RPC 消息、任务状态机和元数据系统为容器将 x402 v2 的三组核心 schemaPaymentRequired、PaymentPayload、SettlementResponse无缝接入 Agent 间通信input-required任务承载支付要求message/sendtaskId承载 EIP-3009 支付授权任务状态更新承载结算回执与artifacts交付。配合六态x402.payment.status生命周期、错误映射表和 AgentCard /X-A2A-Extensions扩展协商该规范让 AI Agent 之间可以在不脱离 A2A 任务模型的前提下完成链上加密资产结算——这也是 x402 作为“构建在 HTTP 之上的互联网支付协议”向 Agent 通信层自然延伸的样板实现。【免费下载链接】x402A payments protocol for the internet. Built on HTTP.项目地址: https://gitcode.com/GitHub_Trending/x4/x402创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 x402 A2A 传输层实现指南：基于 JSON-RPC 与任务状态的 Agent 间支付协议规范
x402 A2A 传输层实现指南基于 JSON-RPC 与任务状态的 Agent 间支付协议规范【免费下载链接】x402A payments protocol for the internet. Built on HTTP.项目地址: https://gitcode.com/GitHub_Trending/x4/x402x402 是一个构建在 HTTP 之上的互联网支付协议v2 规范在保持核心传输无关transport-agnostic设计的同时定义了多套传输层实现其中 A2AAgent-to-Agent Protocol传输让 AI Agent 能够以链上加密货币结算的方式相互付费。本篇技术文章以 specs/transports-v2/a2a.md 为核心骨架完整讲解 A2A 传输的三类支付消息支付要求、支付载荷、结算回执、六个支付状态与任务状态的映射关系、错误处理规则以及扩展声明与激活机制读完后你可以直接按照规范构造 A2A JSON-RPC 消息理解 x402 v2 各 schema 在 A2A 元数据中的落位方式并与 HTTP 传输、核心 v2 规范 相互印证。1. 为什么 A2A 传输需要独立的规范x402 v2 的核心架构将协议拆分为三层见 specs/x402-specification-v2.md 的 Architecture 一节Types核心数据结构PaymentRequired、PaymentPayload、SettlementResponse与传输机制和支付方案均无关Logic依赖支付方案如exact与网络EVM、Solana的支付构造与验证逻辑Representation支付数据如何传输与信令取决于具体传输机制HTTP、MCP、A2A。A2A 传输正是第三层的实现它通过 A2A 协议的JSON-RPC 消息和基于任务task的状态管理承载 x402 支付流程使 Agent 能在 A2A 框架内借助任务生命周期task lifecycle与元数据metadata系统完成支付协调。规范开篇即点明其定位The A2A transport implements x402 payment flows over the Agent-to-Agent protocol using JSON-RPC messages and task-based state management.与 HTTP 传输用 402 状态码和 base64 头部PAYMENT-REQUIRED/PAYMENT-SIGNATURE/PAYMENT-RESPONSE做信令不同A2A 传输把支付信令放进消息元数据字段并用A2A 任务状态表达支付进展。从源码结构看当前仓库的 TS / Go / Python SDK 均已实现 HTTP 与 MCP 传输如 typescript/packages、go/http、python/x402/httpA2A 传输则由外部的 a2a-x402 扩展规范承载——这也解释了为什么本规范以纯协议文档形式给出而不附带仓库内的 A2A 实现代码。另外需要注意 v2 与 v1 的差异本仓库同时收录了 specs/transports-v1/a2a.mdv1 使用network: base这类扁平字段并把resource内嵌在accepts的每项中v2 则采用 CAIP-2 网络标识eip155:8453、独立的ResourceInfo对象以及PaymentPayload.accepted结构。下文均以 v2 为准。2. 支付要求信令input-required 任务状态 元数据A2A 传输中服务端 Agent 通过 A2A 任务状态input-required配合支付元数据来指示“需要支付”信令机制任务state: input-required 消息元数据x402.payment.status: payment-required数据格式PaymentRequiredschema放在元数据字段x402.payment.required中。完整的 JSON-RPC 响应示例规范原文{ jsonrpc: 2.0, id: req-001, result: { kind: task, id: task-123, status: { state: input-required, message: { kind: message, role: agent, parts: [ { kind: text, text: Payment is required to generate the image. } ], metadata: { x402.payment.status: payment-required, x402.payment.required: { x402Version: 2, error: Payment required to access this resource, resource: { url: https://api.example.com/generate-image, description: Generate an image, mimeType: image/png }, accepts: [ { scheme: exact, network: eip155:8453, amount: 48240000, asset: 0x833589fCD6eDb6E08f4c7C32D4f71b54bda02913, payTo: 0xServerWalletAddressHere, maxTimeoutSeconds: 600, extra: { name: USD Coin, version: 2 } } ] } } } } } }对照核心规范 5.1 节的PaymentRequired字段表可以逐字段解读该元数据对象字段类型必填含义结合 v2 规范字段表x402Versionnumber是协议版本标识v2 中必须为 2errorstring否人类可读的说明解释为何需要支付resourceobject是ResourceInfo对象描述受保护资源acceptsarray是可接受的支付方式数组每项为一个PaymentRequirements对象extensionsobject否协议扩展数据本示例中省略其中accepts数组内每个PaymentRequirements对象的关键字段字段必填说明scheme是支付方案标识当前为exactnetwork是CAIP-2 格式网络标识示例中eip155:8453为 Base 主网amount是以原子单位计的最小/精确支付额示例48240000即 6 位小数的 USDC 计 48.24 USDasset是ERC-20 代币合约地址fiat 场景下可为 ISO 4217 货币码payTo是收款钱包地址或角色常量如merchantmaxTimeoutSeconds是完成支付允许的最大时长示例为 600 秒extra否方案附加信息如代币名称name与版本versionResourceInfo对象包含url必填受保护资源 URL、description可选、mimeType可选期望响应的 MIME 类型。示例中mimeType为image/png与服务端文本部分 Payment is required to generate the image. 呼应展示了一个图像生成 Agent 的收费场景。要点与 HTTP 传输不同A2A 不需要任何 base64 编码——PaymentRequired以原生 JSON 形式直接挂在metadata[x402.payment.required]下人类可读且便于 Agent 解析parts中的自然语言文本则面向人类或供上层 LLM 理解。3. 支付载荷传输message/send taskId 关联客户端使用 A2A 消息元数据携带支付数据并用taskId与服务端此前的任务做关联信令机制消息元数据包含x402.payment.payload字段并通过taskId关联任务数据格式PaymentPayloadschema放在元数据字段x402.payment.payload中。客户端通过message/send方法发起 JSON-RPC 请求规范原文示例{ jsonrpc: 2.0, method: message/send, id: req-003, params: { message: { taskId: task-123, role: user, parts: [ { kind: text, text: Here is the payment authorization. } ], metadata: { x402.payment.status: payment-submitted, x402.payment.payload: { x402Version: 2, resource: { url: https://api.example.com/generate-image, description: Generate an image, mimeType: image/png }, accepted: { scheme: exact, network: eip155:8453, amount: 48240000, asset: 0x833589fCD6eDb6E08f4c7C32D4f71b54bda02913, payTo: 0xServerWalletAddressHere, maxTimeoutSeconds: 600, extra: { name: USD Coin, version: 2 } }, payload: { signature: 0x2d6a7588d6acca505cbf0d9a4a227e0c52c6c34008c8e8986a1283259764173608a2ce6496642e377d6da8dbbf5836e9bd15092f9ecab05ded3d6293af148b571c, authorization: { from: 0x857b06519E91e3A54538791bDbb0E22373e36b66, to: 0xServerWalletAddressHere, value: 48240000, validAfter: 1740672089, validBefore: 1740672154, nonce: 0xf3746613c2d920b5fdabc0856f2aeb2d4f88ee6037b8cc5d04a71a4462f13480 } } } } } } }结合 v2 规范 5.2 节的PaymentPayload字段表其结构要点x402Version必填协议版本resource可选ResourceInfo对象回显所访问资源便于服务端与支付要求中的资源做一致性核对accepted必填客户端从服务端accepts中选定的一份PaymentRequirements原样回传——这是 A2A 传输与 v1 的关键差异之一v1 直接在 payload 顶层平铺scheme/network等字段v2 将其封装为accepted对象payload必填方案特定的支付数据。对于exact EVM 组合按核心规范 5.2.2 字段表包含两个字段signature对authorization的 EIP-712 签名authorizationEIP-3009transferWithAuthorization授权对象字段为from付款方地址、to收款地址、value原子单位金额、validAfter/validBeforeUnix 时间戳构成的有效时间窗、nonce32 字节随机数防重放。extensions可选客户端回显服务端下发的扩展信息可按需追加但不可删改既有 info见核心规范 5.1.2 Extensions 说明。taskId示例中task-123承担请求-支付关联的职责A2A 是任务驱动模型客户端把支付载荷挂回原任务服务端即可将这笔授权与该任务此前下发的PaymentRequired对应起来。同时元数据中的x402.payment.status: payment-submitted声明了当前支付状态供服务端识别消息语义。底层原理佐证authorization各字段的安全作用在核心规范第 10 节Security Considerations中给出了系统说明——EIP-3009 的 32 字节nonce防止重放智能合约层面天然拒绝 nonce 复用、validAfter/validBefore时间窗限制授权生命周期、签名确保授权由付款方本人发起。Facilitator 在验证时执行六步检查签名验证、余额检查、金额精确匹配、时间窗检查、参数匹配、交易模拟这些检查的失败会分别映射为第 5 节所述的不同支付状态与错误码。4. 结算回执投递任务状态更新 receipts 元数据服务端通过任务状态更新投递结算结果元数据字段x402.payment.receipts承载SettlementResponseschema 数组。4.1 成功结算{ jsonrpc: 2.0, id: req-003, result: { kind: task, id: task-123, status: { state: completed, message: { kind: message, role: agent, parts: [ { kind: text, text: Payment successful. Your image is ready. } ], metadata: { x402.payment.status: payment-completed, x402.payment.receipts: [ { success: true, transaction: 0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef, network: eip155:8453, payer: 0x857b06519E91e3A54538791bDbb0E22373e36b66 } ] } } }, artifacts: [ { kind: image, name: generated-image.png, mimeType: image/png, data: base64-encoded-image-data } ] } }对照核心规范 5.3 节SettlementResponse字段表success必填布尔表示结算是否成功transaction必填失败时为空字符串而非缺省network必填CAIP-2 格式errorReason失败时给出payer可选amount可选实际结算金额extensions可选。注意result中的artifacts数组这是 A2A 特有的能力——支付成功后Agent 直接在任务结果里附带交付物示例为 base64 编码的 PNG 图像使“付费 → 交付”在一次任务状态更新中闭环。4.2 支付失败{ jsonrpc: 2.0, id: req-003, result: { kind: task, id: task-123, status: { state: failed, message: { kind: message, role: agent, parts: [ { kind: text, text: Payment verification failed: The signature has expired. } ], metadata: { x402.payment.status: payment-failed, x402.payment.error: EXPIRED_PAYMENT, x402.payment.receipts: [ { success: false, errorReason: Payment authorization was submitted after its validBefore timestamp., network: eip155:8453, transaction: } ] } } } } }失败回执的要点任务状态转failed元数据额外携带x402.payment.error机器可读错误码示例为EXPIRED_PAYMENT对应授权超出validBefore时间窗x402.payment.receipts中success: false、transaction为空字符串并给出errorReason。从源码结构看这类errorReason文案源自 Facilitator/verify、/settle接口的响应见核心规范 7.1/7.2 节A2A 服务端只是将其透传进元数据。5. 支付状态生命周期与任务状态映射A2A 传输用x402.payment.status元数据字段跟踪一条细粒度的支付状态推进每个状态对应 A2A 任务状态规范原文表格完整保留支付状态含义对应任务状态payment-required支付要求已发送给客户端input-requiredpayment-rejected客户端拒绝了支付要求failed或input-requiredpayment-submitted服务端已收到支付载荷input-required→workingpayment-verified服务端已验证支付载荷workingpayment-completed链上结算成功working→completedpayment-failed支付验证或结算失败failed这张表揭示了 A2A 传输的设计精髓支付流程不是独立的 HTTP 往返序列而是被“织入”了 A2A 任务状态机。任务停在input-required意味着服务端在等待客户端输入——在支付语境下等待的就是支付授权客户端提交授权后任务进入working验证与链上结算完成后任务转为completed并携带artifacts交付结果。payment-verified与payment-completed之间的区分也值得注意前者表示签名/余额等校验通过对应 Facilitator/verify成功后者表示交易已上链对应/settle成功两者之间仍存在结算失败的窗口。6. 错误处理x402 错误到任务状态与元数据的映射A2A 传输将 x402 标准错误映射为任务状态 支付状态规范原文表格完整保留x402 错误任务状态支付状态说明Payment Requiredinput-requiredpayment-required访问资源需要支付Payment Rejectedfailedpayment-rejected客户端拒绝支付要求Invalid Paymentfailedpayment-failed支付载荷或支付要求格式非法Payment Failedfailedpayment-failed支付验证或结算失败Server Errorfailedpayment-failed支付处理过程中服务端内部错误Successcompletedpayment-completed支付验证与结算均成功错误响应的具体形态任务状态转failed元数据中携带x402.payment.status、机器可读错误码x402.payment.error以及x402.payment.receipts规范原文示例{ kind: task, id: task-123, status: { state: failed, message: { kind: message, role: agent, parts: [ { kind: text, text: Payment verification failed: insufficient funds } ], metadata: { x402.payment.status: payment-failed, x402.payment.error: INSUFFICIENT_FUNDS, x402.payment.receipts: [ { success: false, errorReason: The clients wallet has insufficient funds to cover the payment., network: eip155:8453, transaction: } ] } } } }这里体现了 A2A 传输的双通道错误表达parts中的自然语言文本Payment verification failed: insufficient funds面向人与 LLM 上下文而x402.payment.error错误码如INSUFFICIENT_FUNDS、EXPIRED_PAYMENT面向程序化决策。核心规范第 9 节定义了 Facilitator 层面的标准错误码snake_case如insufficient_funds、invalid_exact_evm_payload_authorization_valid_before等A2A 层将其归一为 UPPER_SNAKE 风格的传输层错误码实现时可参照核心规范的错误码表建立映射。客户端据此可以做出可区分的动作对EXPIRED_PAYMENT重新签名对INSUFFICIENT_FUNDS提示充值或换用其他accepts项。7. 扩展声明与激活A2A 采用扩展extension机制实现可选能力协商。支持 x402 支付的 Agent 必须在其AgentCard中声明该扩展{ capabilities: { extensions: [ { uri: https://github.com/google-a2a/a2a-x402/v0.1, description: Supports payments using the x402 protocol for on-chain settlement., required: true } ] } }客户端则必须通过X-A2A-ExtensionsHTTP 头部激活该扩展X-A2A-Extensions: https://github.com/google-a2a/a2a-x402/v0.1声明AgentCard 中的capabilities.extensions与激活请求头X-A2A-Extensions两段式协商的意义在于AgentCard 是静态能力发现载体客户端在发起任务前即可判断对端是否支持付费X-A2A-Extensions头部则在具体请求维度显式激活扩展使服务端确定性地知道应当启用 x402 支付流程包括在收费资源上返回payment-required。required: true表示该扩展为 Agent 正常服务所必需未激活该扩展的客户端不应预期能完成付费任务。8. 与 HTTP 传输的对照及实现要点把 specs/transports-v2/http.md 与 specs/transports-v2/a2a.md 并排阅读可以清楚看到 x402 传输层抽象的一致性——三个核心 schema 完全相同变化的只是承载容器环节HTTP 传输A2A 传输支付要求信令402 状态码 PAYMENT-REQUIRED头部base64 编码任务状态input-required 元数据x402.payment.required原生 JSON支付载荷传输PAYMENT-SIGNATURE请求头base64 编码message/send请求元数据x402.payment.payloadtaskId关联结算回执PAYMENT-RESPONSE响应头base64 编码任务状态更新元数据x402.payment.receipts状态表达HTTP 状态码402/200/400/500任务状态机input-required/working/completed/failedx402.payment.status这一对照对实现者有三点直接启示schema 复用A2A 消息元数据中的x402.payment.required/x402.payment.payload/x402.payment.receipts对象就是核心规范 5.1/5.2/5.3 节定义的PaymentRequired/PaymentPayload/SettlementResponse可直接复用现有校验逻辑无需为 A2A 单独定义数据结构。关联模型不同HTTP 靠 URL 与请求-响应配对A2A 靠taskId把支付授权绑定到具体任务实现多任务并发时的支付隔离。交付通道不同HTTP 的交付物是响应体A2A 的交付物是任务artifacts天然适配文件、图像等多模态 Agent 输出。关于适用范围与限制需要说明本规范描述的是协议报文格式仓库当前未包含 A2A 传输的 SDK 实现代码TS/Go/Python 包覆盖 HTTP 与 MCP 传输A2A 扩展的完整外部规范见文档 References 一节指向的 a2a-x402 项目核心 v2 规范 12.5 节也列出了客户端库路线图中 A2A 侧对应 python 的x402_a2a。网络标识须用 CAIP-2 格式如eip155:8453为 Base 主网、eip155:84532为 Base Sepolia 测试网amount一律为原子单位字符串这些约束在构造任何 A2A 支付消息时都同样适用。9. 小结specs/transports-v2/a2a.md 以 A2A 的 JSON-RPC 消息、任务状态机和元数据系统为容器将 x402 v2 的三组核心 schemaPaymentRequired、PaymentPayload、SettlementResponse无缝接入 Agent 间通信input-required任务承载支付要求message/sendtaskId承载 EIP-3009 支付授权任务状态更新承载结算回执与artifacts交付。配合六态x402.payment.status生命周期、错误映射表和 AgentCard /X-A2A-Extensions扩展协商该规范让 AI Agent 之间可以在不脱离 A2A 任务模型的前提下完成链上加密资产结算——这也是 x402 作为“构建在 HTTP 之上的互联网支付协议”向 Agent 通信层自然延伸的样板实现。【免费下载链接】x402A payments protocol for the internet. Built on HTTP.项目地址: https://gitcode.com/GitHub_Trending/x4/x402创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考