x402：HTTP 原生微支付，让 AI agent 按次付费
x402 复用 HTTP 402 Payment Required 状态码：服务在交付资源前先要求付款。自主 agent 把它当普通 HTTP 响应处理——从钱包拿支付 URL、在 Base 上签一笔最小 USDC 转账、带上支付证明头重试请求。流程保持在标准请求/响应模型内：没有新协议，只是一个约定。
为什么微支付对 agent 重要
agent 常要调外部 API（数据源、LLM、图像生成器、其他 agent）。当调用有成本（如 $0.005/token）时，你要：原子性（拿到资源才付钱，拿不到就不付）、无状态（不为每家厂商管长会话和 API key）、兼容（复用现有 HTTP 客户端栈）。
传统 API-key 计费解决前两点，但迫使你管理 secret、限流处理、和一张与按次使用对不上的月账单。x402 翻转模型：服务器在需要时请求付款，客户端（你的 agent）即时提供。
六步流程
| 步骤 | 角色 | 动作 |
|---|---|---|
| 1 | Client | GET /translate，无 auth 头 |
| 2 | Server | 需付费 → 402 + X-Payments-Required（JSON：金额、token、链、nonce） |
| 3 | Client | 解析载荷，构造最小 ERC-20 转账，钱包签名（Base 上的 USDC） |
| 4 | Client | 提交交易到 RPC（或用 relayer）→ tx hash（Base 上 1–2 块约 2 秒） |
| 5 | Client | 带 X-Payment: <txHash> 重试原请求；server 链上验证金额与 nonce，通过返回 200 + 资源 |
| 6 | Server | 可选缓存已验 tx hash 防重放；payload 的 nonce 保证每次请求唯一 |
唯一新头：X-Payment（客户端→服务器）和 X-Payments-Required（服务器→客户端）。其余全是标准 HTTP/1.1 或 HTTP/2。文内有 Python + httpx + web3.py 的最小可运行示例。
实践建议
- 需要原子、无状态、兼容现有栈的按次计费，x402 比 API-key 账单模型更贴合 agent 场景；
- nonce 防重放 + 链上验证是安全底线：服务器不能只信客户端自报的 tx hash；
- 快速确认（1–2 块）才适合实时推理管线；等几分钟确认的链不匹配 agent 场景。
来源：x402 Explained: HTTP-Native Micropayments for AI Agents (With Real Code) - DEV Community