AI Agent 能读网页、写报告、调 API，唯独不能付钱。任务跑到付费接口就断了：没有账号、没有信用卡、没有 API Key，也没有人替它扫码。卡住 Agent 经济的不是模型能力，是支付体系——它从头到尾都是为人类设计的。

AI Agent 的支付困境

传统付费链路的每一环都假设“人在现场”：注册要验证邮箱，开户要实名认证，绑卡要输验证码，订阅要确认扣款。Agent 是跑在服务器上的一段代码，哪一环都过不去。更麻烦的是，Agent 的任务里经常撞上从没见过的 API——没有预注册，没有密钥，当场就得停下来等人。

四个结构性障碍

支付体系的结构性问题有四个。

第一个是准入。信用卡、银行账户、PayPal 全部要求实名认证，Agent 没有法定身份，过不了任何一道审核。链上钱包是目前最接近无许可的数字金融工具，但传统支付链路里没有它的位置。

第二个是注册。每个付费 API 都是一整套流程：注册、绑卡、买套餐、生成 Key。Agent 无法独立完成，也维护不起几十个服务商的密钥。任务执行中动态发现的 API 更是无从提前准备。

第三个是算不过账。卡收单的手续费（如 Stripe 的 2.9% 加 0.30 美元固定费）对微支付不经济：一次 1 美分的交易，手续费是交易额的三十倍。服务商只能卖订阅，Agent 为几次调用买一个月的套餐，额度用不完还得续。

第四个是安全。给 Agent 完全自由的支付权，一次提示注入攻击就能在毫秒间掏空钱包；每笔都人工确认，自动化又失去意义。传统体系只有“人确认”和“人不管”两个极端，没有中间选项。

沉睡的 HTTP 402

有意思的是，互联网协议里早就给这个场景留了位置。

1990 年代起草 HTTP 规范时，设计者预留了 402 Payment Required 状态码，准备给数字内容做原生付费。但当时没有低成本、高并发的电子清算体系——没有合适的“钱”，这个状态码就闲置了近三十年，几乎没有被正式使用过。

转机来自两件事：稳定币解决了“互联网上的钱”，Layer 2 和低成本公链把结算费用压到很低。基础设施到齐，402 才第一次有了真正被使用的条件。

x402 的设计动机

2025 年 5 月，Coinbase 发布 x402 白皮书（V1）。它的核心决定是把支付从业务逻辑里拿出来，放进 HTTP 协议本身——整个支付动作压缩进一次请求-质询-重试的交互：

1. 客户端请求受保护端点，不携带任何密钥
2. 服务器返回 402，附上付款条件（价格、收款地址、支持的链与资产）
3. 客户端用钱包私钥自动签名支付授权，放回请求头重试
4. 服务器将签名交由链下 Facilitator 验证并上链结算，返回数据

钱包私钥是唯一的通行证：不需要向任何平台注册 API 密钥，没有人工环节。四条设计正好对应前面的四个障碍：

与传统支付网关的对比

Stripe 这类卡收单网关解决的是“如何让人类安全地付钱”，x402 解决的是“如何让机器自主地付钱”，两者的架构取向完全不同：

Stripe 是把人类引导到收银台的技术，x402 是让机器在取数据的同一瞬间付钱的技术。