x402协议：让AI智能体用稳定币内嵌支付

AI 智能体正在以前所未有的规模上线，"人在回路"支付已变得不切实际，而行业的答案指向了一个出人意料的源头：20 世纪 90 年代的一个休眠 HTTP 状态码。x402 协议重新启用了 HTTP 402 "Payment Required"，让 AI 智能体可以直接用稳定币支付 API、数据和服务的费用，无需账户、无需 API 密钥、无需结账页面——截至 2026 年 7 月，在最早采用该协议的一些平台上，智能体驱动的流量已经超过了人类流量。

为什么智能体需要钱包，而非账户

专为人类互联网设计的每个支付系统都假设有人在场登录、输入银行卡信息或批准 OAuth 提示。自主智能体在完成任务时——获取货运报价、拉取付费数据集、连续调用一百次付费 API——无法在每个操作时都停下来等待人类批准，否则就失去了自动化的意义。智能体真正需要的是钱包：一个由预先设定的规则管控的、可编程的资金存储体，让智能体可以在定义的限额内自主支出，而无需为每笔交易请求授权。

这正是 x402 要实现的转变——机器对机器的支付以内联方式发生，在获取资源的同一个 HTTP 请求周期内完成，而无需人类事先建立单独的计费关系。

x402 的实际工作原理

x402 采用三角色模型：客户端（买方——AI 智能体、应用或脚本）、资源服务器（卖方——API 或付费服务）、以及促进者（结算服务，验证并广播链上支付）。整个流程在一次重试请求周期内完成，无需重定向、webhook 或手动结账：

1. 客户端发起请求。 向付费端点发送普通的 GET 或 POST——无需认证头、无需 API 密钥。

2. 服务器返回 402 Payment Required。 响应包含结构化的支付元数据：价格、接受的稳定币（通常为 USDC）、目标地址，以及要使用的区块链网络。

3. 客户端签署支付授权。 智能体的钱包使用 EVM 链上的 EIP-3009 转账授权，对确切的金额签署一份链下授权——这一步不需要客户端支付 gas 费。

4. 客户端携带签署的支付附加头信息重试请求。（历史上使用 X-PAYMENT，现在 x402 v2 正在向 PAYMENT-SIGNATURE 标准化）

5. 服务器验证并结算。 服务器检查签名——可以在本地验证，也可以调用促进者的 /verify 端点——然后直接通过促进者的 /settle 端点或在链上完成支付结算。

6. 服务器返回 200 OK，附带资源和结算确认头，证明交易已完成。

该设计的精妙之处在于几乎不需要新的基础设施——HTTP 早在几十年前就为这个目的预留了状态码 402；只是直到现在才终于有了与之配对的标准支付机制。

什么让钱包成为"智能体化"钱包

为这个世界构建的可编程钱包在结构上与个人加密钱包截然不同。钱包不是由人类批准每笔交易，而是自动执行策略：

• 支出上限——限制智能体每笔交易、每小时或每天的最大支出金额
• 允许的操作——白名单，规定钱包只能用于哪些场景（例如，仅限数据购买，不能随意转账）
• 已批准的对方——将支付限制在已知且经过审查的服务或域名集合内
• 执行前的策略检查——每次智能体决定需要支出资金时，钱包在签署任何内容之前都会根据策略检查该操作，只有通过检查才会执行

这正是使自主支出能够安全部署的关键：智能体拥有真实的支出授权，但只能在一个由人类或组织预先定义的边界内操作——更像是带有可编程限额的企业采购卡，而非空白支票。

已有真实实现落地

这不是理论。Coinbase 的 Agent Kit 为智能体提供了钱包操作技能库——发送、交易、赚取——并原生集成 x402 用于智能体对服务的支付，包括 Base 上的无 gas 交易。Cloudflare 已将 x402 支持直接集成到其 Agents SDK 中，让任何 Cloudflare Worker 只需几行中间件代码即可接收或发起智能体支付。Coinbase 于 2026 年 7 月 23 日向所有企业客户开放了 x402 USDC 支付，明确指出其开发者文档平台上智能体流量已超过人类流量。

该协议也支持多条区块链——Base、以太坊、Arbitrum、Optimism、Polygon 和 Solana 都支持，这意味着智能体的钱包不会被锁定在某个生态系统的流动性或费用结构中。

x402 与其他智能体支付标准

x402 处于更广泛的智能体支付领域中的一个特定细分市场，与 AP2 或 MPP 等主要关注授权指令和卡网络集成的协议有所不同。

x402 最好被理解为专为智能体和服务构建的结算层，而非消费者结账替代品——它针对高频、低值的机器支付进行了优化，在这种场景下卡网络费用会使交易变得不经济。

用 x402 为自有 API 变现

对于后端开发者来说，为现有 API 添加 x402 支持是一个中间件层面的改动，而非架构级重写。在服务端，添加一个支付检查中间件（Express 等框架已有 @x402/express-style 包），它拦截未付费的请求，返回 402 挑战并附带定价和钱包地址，然后在让请求通过之前验证传入的支付签名。

最小化的服务端定价结构通常涉及定义一个发现文档——一种 OpenAPI 风格的清单，描述哪些端点是付费的、每次调用的价格以及接受的支付方式——这样智能体（或它们使用的 MCP 服务器）可以在发出请求之前以编程方式找到并定价服务。这是 MCP 工具发现中的相同可发现性原则在支付领域的应用：智能体不应该通过试错来猜测定价。

标准成熟过程中值得关注的方向

x402 正在积极演进——v2 版正在标准化头信息命名（PAYMENT-REQUIRED、PAYMENT-SIGNATURE、PAYMENT-RESPONSE）以及使用 CAIP-2 链格式的网络标识符。现在基于该协议构建的开发者应该跟踪其促进者和客户端库实际支持的版本，因为如果 accepts 字段处理不当，v1 和 v2 智能体可能会静默地相互过滤。身份也是一个开放的前沿领域——项目已经在 x402 基础支付流程之上叠加了经验证的身份层，因为该协议本身只证明一笔支付发生了，但并未说明是谁或什么授权了它。

这将走向何方

对于构建金融科技或 API 变现产品的任何人来说，实际的转变是：以每次请求为单位定价、用稳定币计价、可被智能体发现而无需销售对话的服务，正在迅速成为一种可行的收入模式，而非新奇事物。智能体在你的 API 中购买货运报价、天气数据点或单次推理调用，在获取资源的同一请求中支付——这类交易量在卡网络费用下从来都不合理——而这正是 x402 要释放的交易量规模。