x402 解析：面向智能体的 HTTP 402 支付

x402 是一个通过 HTTP 支付 Web 资源的协议。服务器通过 HTTP 402 返回支付要求；兼容的客户端授权支付并带有支付负载进行重试。

对于智能体来说，这可以将一次付费的 API 查询转化为任务的一部分。钱包仍需支出权限，且服务仍需交付结果。

HTTP 402 成为价格报价

HTTP 402 是“需要支付”的状态码。x402 在其周围增加了一个定义的支付交换；普通浏览器不会因为网站返回该状态就自动变成自主购买者。

在当前的 V2 流程中，服务器通过 PAYMENT-REQUIRED 通信要求。客户端在 PAYMENT-SIGNATURE 中回复支付负载。服务器通过 PAYMENT-RESPONSE 报告结算结果。请求头名称描述的是独立步骤，而非三次支付。HTTP 402 与 V2 请求头。

想象一个研究智能体为路线规划任务购买一次天气观测。一个虚构的报价要求 0.001 USDC，指明卖家的接收地址，并指定支持的网络和精确支付方案。支付客户端需要在继续操作前识别这些条款。此价格仅为示例，并非实际的服务报价。

价格报价并非支出权限。钱包或应用程序策略应检查金额、商户和请求的资源是否符合任务。服务器可以报价不合理的价格，就像人类卖家一样。

追踪一次付费请求

客户端请求资源。服务器返回付款要求。客户端选择一个支持的选项，并为该选项创建授权或付款负载。它带着负载重复资源请求。

服务器检查付款，并在选定的方案和付款流下处理结算。默认授权在资源处理器之前验证并在之后结算；预付流在处理器运行前结算。基于托管的流引入了资金余额，并在随后进行捕获或赎回。仅凭准确的价格无法告诉你计算相对于结算何时开始。方案和付款流概述。

这种分离对于理解故障非常有用。被拒绝的授权意味着服务尚未接受提议的付款。等待确认的广播交易意味着资金可能仍在移动中。已完成付款但缺失资源的状况是交付问题。

将这些状态合并为“付款失败”的接口会促使昂贵的重试。客户端应保留请求标识，并在授权下一次购买之前核对之前的尝试。软件比人类能更快地重复错误的结账操作。

促进者处理付款管道

协调方可以验证支付负载、提交结算交易并报告其状态。资源服务器可以使用托管生产提供商、运行自己的服务或自行处理这些功能。不应假设公共快速启动协调方是每个网络的生产路径。协调方文档。

所选的协调方会影响服务的运行依赖。卖家需要对其网络、代币和支付方案提供支持。当提供商缓慢或不可用时，它还需要一个可行的响应。

非托管验证并不意味着业务的每个部分都是独立的。提供商可能在不持有客户资金的情况下无法提交交易。API 网关可以在不控制钱包的情况下停止交付资源。这些故障属于事故计划的不同部分。

在启动付费端点之前，我会使用生产提供商和真实的合约配置来测试该路线。成功的测试网支付证明了集成可以在该环境中运行。它并不代表生产环境的流动性、定价或可靠性。

当资金移动时方案会发生变化

一个精确支付指定了定义金额。一个最高限额支付授权了使用的上限，其最终成本可能更低。批量结算分组为稍后的链上赎回收费，而授权捕获支持托管且可退款的模式。这些是卖家按请求或按工作单位收费的不同选择。支付方案。

固定价格的数据查询适用于与生成计算成本取决于输出长度的答案不同的计费问题。后者需要明确的最大值和可衡量的最终费用。买方应当知道卖家如何计算该费用。

在记录的 EVM 批量模式中，买方为托管资金提供资金并签署累积凭证。卖家可以稍后领取款项，并通过单独的结算操作提取收益。这解释了如何让延期费用保持可收集，同时增加了需要检查的资金和赎回规则。批量结算机制。

这就是为什么一百万次付费请求不应自动被描述为一百万次区块链交易。微支付经济学文章遵循每一层的成本，而不是将请求数量作为链上收入的代理指标。

AI 模型不是支付签名者

模型可以决定某个资源是有用的，并将购买请求传递给工具。钱包服务或签名组件负责创建授权的财务操作。这些角色应当在系统设计中清晰可见。

给模型提供诸如“明智消费”之类的任务指令，其提供的保护比强制性的交易限制要弱。更强大的设置是在签名者批准请求之前，先检查商家、货币、最大金额和剩余预算。

单次购买与持续授权之间也存在区别。为单一资源支付费用不应悄悄授予卖家访问不受限余额的权限。我们的智能体钱包文章解释了托管和支出权限如何塑造这一边界。

智能体的身份是另一个独立的问题。支付证明了相关机制下的财务操作。它并不能证明买家是一个独特的、胜任的或诚实的智能体。ERC-8004 关注的是围绕智能体的身份识别和信任信号，而不是取代支付交换。

支付和有用的交付需要收据

服务应当清晰地识别资源和计价单位。“一次响应”可能意味着一个搜索结果、一个完整的数据集或一页记录。模糊的计费让人类和智能体都难以进行比较。

签名报价和收据可以帮助将购买与声明的条款和记录的结果绑定。它们仍然不能证明交付的数据集中每一个事实都是正确的。买家需要一种方法来评估新鲜度、来源以及响应是否符合任务。签名报价和收据。

对于昂贵或变动的任务，应定义什么算作可计费的成功。空结果可能是对查询的有效答案，但该规则应在购买前说明。同样的情况也适用于计算失败或上游源不可用的情况。

卖家的分发问题依然存在。启用 x402 并不会让端点变得可发现或值得付费。向智能体出售数据涵盖了业务的这一侧。

在 x402 演示中需要检查的内容

寻找可见的报价、受限的授权和明确的结算结果。要求团队在模拟超时后重试请求，并展示原始购买不会被重复扣费。然后询问如果支付成功但响应丢失会发生什么。

有用的演示应在这些条件下完成客户的任务。转账浏览器截图证明的要少得多。购买资源的软件需要围绕交易建立可靠的商业交换。

有关替代协议和商户集成方法的方案，请阅读 x402 vs MPP。选择始于服务的计费模式及其客户可使用的支付方式。

一次超时需要两个独立的答案

假设卖家接受了天气观测的付款，但客户端从未收到响应。下一步取决于两个记录：购买是否已结算，以及该观测是否已交付？

已结算但响应丢失的购买需要一条交付恢复路径。在接受前被拒绝的授权需要对支付失败的解释。结果仍不明确的支付在进行下一次授权前需要对账。

当扩展功能实现时，支付标识可以帮助将重试与原始购买关联起来。卖家仍需要一条返回或恢复已购买资源的规则。支付标识扩展。