x402 代理支付详解:当 AI Agent 自己会花钱,企业要建什么
一周之内,AWS 与 Cloudflare 两大云厂商在边缘网络落地同一套 x402 代理支付协议,AI Agent 已能不用账户、不用 API key 就自主用 USDC 付款。技术层云厂商已替你建好,真正没人管的是发票、增值税与合规归属——这才是企业当下要自己补的部分。
TL;DR: x402 是把一个从 1997 年起就写进 HTTP 标准、却始终没有落地方案的「402 需要付款」状态码激活而成的代理支付协议——它让 AI Agent 无需注册账户、也无需 API key,就能直接用稳定币 USDC 为单次请求付款。据 InfoQ 的报道,Coinbase 称该协议上线第一年已处理 1.69 亿笔支付、覆盖 59 万买家与 10 万卖家。据 Cloudflare 官方博客,AWS CloudFront 的 x402 集成已 GA、Cloudflare 变现网关(Monetization Gateway)候补名单于 2026 年 7 月 1 日开放,两大云同周把它从概念推成边缘基础设施。对企业的直接结论是:支付的技术层,云厂商已经替你建好了;真正还没人管的,是发票、增值税与合规归属——这才是企业当下要自己补的部分。
当 AI Agent 开始代表用户去调用别人的 API、抓取付费内容、订用第三方服务,一个被绕过了二十多年的问题突然变得紧迫:机器该怎么为一次请求付钱?x402 给出的答案不是再造一套支付系统,而是把 Web 协议里早就留好的那扇门推开。
x402 是什么?企业怎么让 AI Agent 自己付款?
x402 是一套内嵌在普通 HTTP 请求里的代理支付协议。 据 InfoQ 的报道,它复用的是 HTTP/1.1 里自 1997 年起就保留、却一直没有落地标准的 402 Payment Required 状态码。Cloudflare 官方博客则点明了它的核心设计——「支付本身就是凭证」:无需注册(no signup)、无需 API key、也无需事先建立任何关系,整个握手全部走普通 HTTP,不需要重定向到结算页。
对企业而言,这意味着 Agent 访问一个付费资源时,不再需要人类事先注册、绑卡、拿密钥。握手只有三步:
表 A — x402 握手三步
| 步骤 | 谁发起 | 内容 | 关键点 |
|---|---|---|---|
| ① 请求 | 客户端(Agent) | 发出普通 HTTP 请求索取资源 | 无账户、无 API key |
| ② 402 应答 | 服务器 | 返回 402 + 价格 + 支付方式 |
复用 1997 年起保留的状态码 |
| ③ 带凭证重试 | 客户端(Agent) | 附上支付凭证再次请求并完成验证 | 「支付本身就是凭证」,无重定向、无结算页 |
正因为把支付压缩进了一次协议往返,x402 才适合机器规模的高频微支付场景——这也是 thirdweb 的分析把它称作「Web 的新支付层」的原因。
为什么是现在:AWS 与 Cloudflare 同周落地意味着什么
一个协议值不值得企业现在就上心,要看它是停在白皮书,还是进了主流基础设施。这一周给出了明确信号。
据 Cloudflare 官方博客,AWS CloudFront 的 x402 集成已经 GA(正式可用),除标准 WAF 费用外不额外收费;Cloudflare 变现网关的候补名单则在 2026 年 7 月 1 日开放。 两大云厂商在同一周把同一套协议落到边缘网络,意味着 agent-to-service 微支付已经从概念走向了默认基础设施。
标准层面同样在收拢。同一篇 Cloudflare 官方博客显示,x402 基金会已于 2026 年 4 月在 Linux 基金会下成立(由 Coinbase 贡献协议),官方口径已有 25+ 家成员机构——含 AWS、Cloudflare、Anthropic、Circle 等,Cloudflare 的覆盖已达 330+ 城市。 thirdweb 的分析也印证了同一份名单。一套由竞争对手共同托管的开放标准,通常比任何单家产品更值得企业押注。
背后还有一层商业动因。据 InfoQ 的报道,截至 2026 年 6 月,已有 52% 的爬虫请求用于 AI 训练,而 2025 年春季这一比例仅为 22%。当机器代理正在取代人类成为主导流量,依赖广告与订阅的旧变现模式面临失效——这正是各家云厂商急于给「机器付费」铺路的现实压力。
AI Agent 自己付款,结算安全吗?钱是怎么走的?
企业决策者最关心的往往不是协议漂不漂亮,而是钱到底怎么流、会不会失控。
据 InfoQ 的报道,x402 的结算走 Base 链上的 USDC,亚秒级完成,单笔成本「不到一美分的几分之一」;链上验证与合规审查由 Coinbase 的 x402 Facilitator 负责。 Cloudflare 官方博客同样把单笔成本描述为「fractions of a cent」。也就是说,清算与对账被下沉到了协议与链上,而不是压在企业自己的支付栈里。
安全边界还有一层来自边缘。据 InfoQ 与 Cloudflare 的同批报道,AWS 与 Cloudflare 都要求支付在边缘节点内完成,源服务器永远不会收到未付款的请求。对企业来说,这把「先服务、后追款」的风险挡在了边缘之外:付费校验前置,源站只处理已经付过钱的流量。技术层面的结算安全,基本已由协议与云厂商兜住。
自建支付 vs x402 边缘网关:企业该怎么选
既然云厂商已经把边缘网关做好了,企业还有没有必要自建支付栈?下面这张对比可以帮决策层快速定位。
表 B — 自建支付 vs x402 边缘网关
| 维度 | 自建支付栈 | x402 边缘网关(AWS/Cloudflare) |
|---|---|---|
| 接入方式 | 账户体系 + API key + 结算页 | 类 WAF 规则,边缘节点内完成 |
| 结算速度/成本 | 卡组织清算、按笔手续费 | Base 链 USDC 亚秒级,单笔「不到一美分的几分之一」 |
| 未付款请求 | 到达源服务器后再拦截 | 边缘拦截,源服务器永不收到未付款请求 |
| 对账凭证 | 需自建 | 支付即凭证,链上可验 |
| 合规/发票归属 | 自己掌控 | 未解决——需企业自行补齐 |
结论很清楚:在接入、结算与拦截这三件事上——对照 Cloudflare 官方博客对边缘支付规则的描述,以及 InfoQ 的报道对成本与结算模型的核算——自建几乎没有理由跑赢已经 GA 的边缘网关。企业真正需要自己掌控的,只剩最后一行——合规与发票归属。这与「自建还是采购」的通用决策逻辑一脉相承,值得对照我们此前那篇《企业 AI:自建还是采购(2026)》一起看:把标准化的能力交给平台,把差异化与合规的部分留在自己手里。
agentic commerce,企业现在要准备什么?
这也是全文的落点。技术层被云厂商补齐之后,剩下的缺口恰恰是最不该被忽略的那块。
据 InfoQ 的报道,稳定币微支付的发票、增值税与合规归属至今没有解决方案,Cloudflare 与 AWS 均未回应税务相关问题。 对照 Cloudflare 官方博客——它详尽讲了支付怎么在边缘完成、怎么写规则、怎么亚秒级结算,却对开票与税务只字未提——恰好印证这块缺口要由企业自己补。当一个 Agent 一天替企业完成成千上万笔跨境微支付,「谁来开发票、增值税算在哪、这笔链上入账记进哪个科目」就不再是财务的小事,而是能不能合规上线的前提。
我们建议企业在接入 x402 之前,先把这份落地检查清单过一遍:
- 发票归属——每一笔代理支付由谁开具、开给谁;
- 增值税/税务——跨境稳定币微支付的纳税义务落在哪一方;
- 入账科目——USDC 结算如何映射到现有财务与对账体系;
- 合规审查方——链上验证之外,谁对交易做业务与反洗钱审查;
- 边缘支付规则治理——谁有权修改边缘网关的支付规则、如何留痕与审计。
这五项没有一项是云厂商会替你回答的,它们正是「技术可用」与「企业可上线」之间的真实鸿沟。这也再次印证了《为什么企业 AI 落地这么难》里的判断:难点从来不在能不能跑通 demo,而在把它嵌进企业既有的合规、财务与治理体系。
结语:技术层已备好,合规层才是企业的功课
x402 用一个沉睡了近三十年的状态码,给 AI Agent 打开了自主付款的通道;AWS 与 Cloudflare 则在一周之内把它铺成了边缘基础设施。对企业来说,好消息是支付的技术栈基本不用自己造了;真正的功课,是把发票、增值税、入账与合规这几块「云厂商不管」的部分补齐。
如果你正在评估让 Agent 自主付款、却卡在合规与入账的落地缺口上,可以从我们的 FDE 诊断开始,由驻场工程师帮你把这份清单对到自己的业务系统上;更多常见问题也可参考 FAQ。
