x402(机器支付协议)
| 分类 | 🔗 技术协议 |
| 阅读时间 | ⏱️ 19 分钟 |
| 更新时间 | 📅 2026-09-14 |
| 条目编号 | ENC-PROTOCOL-14-x402 |
关键要点 ✦
- 复用 HTTP 402 状态码,把「付款」变成 HTTP 原生能力,而非外挂的计费系统
- 协议只有三个角色:Client(买方)、Resource Server(卖方)、可选的 Facilitator(验证与结算)
- 已知价格时可一次往返完成付费请求;协议内置重放保护
- v2 拆分为 Types / Logic / Representation 三层,与传输无关,可跑在 MCP、A2A 消息上
- 2026 年 4 月由 Coinbase 捐给 Linux Foundation,基金会于 7 月正式运营,支持组织达 22 家
- 与 AP2(授权层)、MPP(会话式微支付)、ACP(电商结账)是分层互补而非直接竞争;局限是稳定币为主、缺法币通路、按次结算对超高频调用成本敏感
为什么是 402:一个等了二十多年的状态码
HTTP/1.1 规范在 1997 年就定义了 402「Payment Required」,但标注为 reserved for future use,此后三十年几乎没有实现。原因在于传统支付轨道从根上假设「有人在屏幕前」:先要开户与绑卡、信用卡的最小经济单元远大于一次 API 调用的价格、订阅制的前提是持续关系——而一个 Agent 调用某接口可能一生只有一次。
两个条件在 2025 年前后同时成熟:稳定币提供了可编程、7×24、微额可行的结算载体,Agent 则带来了大量「没有人的客户端」。据 Coinbase 官方信息,x402 于 2025 年 5 月开源,采用 Apache 2.0 许可,把这两件事接到那个闲置的插座上。
一次 HTTP 往返怎么完成支付
协议只有三个角色:Client(买方,持有钱包签名)、Resource Server(卖方,保护付费端点)、可选的 Facilitator(替卖方做验签与链上结算,暴露 verify 与 settle 两个端点)。
典型流程是两次往返:Agent 先发裸请求;服务端返回 402 并在响应体里给出机器可读的报价(accepts 数组,含 scheme、network、资产与金额、收款地址);Agent 用私钥签名支付载荷,带上 PAYMENT-SIGNATURE 头重试同一请求;服务端(或 Facilitator)完成验证与结算后返回 200 与资源,并在 PAYMENT-RESPONSE 头中带回结算收据。若 Agent 已从价格清单获知费用,可在初次请求中一并携带付款凭证,一次往返即可完成——这正是 Agent 场景的常态。
报价中的 scheme 支持 exact(精确金额)与 upto(上限金额,按实际用量结算),后者天然契合按 token 计费的大模型 API。
v2 的关键决策:把协议做成传输无关的支付原语
x402 v2 把规范拆成三层:Types 层定义与传输无关的核心数据结构(报价、支付载荷、结算响应);Logic 层实现各 scheme 与链组合的构造、验证与结算逻辑;Representation 层负责传输特定的编码,HTTP 头只是其中一种表示。
这意味着 402 挑战可以是 MCP 工具调用的返回值,也可以是 A2A 中子 Agent 的报价——付费能力顺着既有协议管道流动,无需为支付另拉一条专线。v2 同时补上了钱包身份、收据与重放保护,缓解早期「完全无状态」带来的争议。
治理演进:从一家公司的项目到行业公共设施
时间线是理解 x402 定位的关键:2025 年 5 月 Coinbase 发布 x402;2025 年 9 月 Coinbase 与 Cloudflare 宣布共同发起 x402 基金会;2026 年 4 月 2 日协议被正式贡献给 Linux Foundation,x402 基金会挂牌(在 MCP Dev Summit 北美站宣布);2026 年 7 月 14 日基金会宣布正式投入运营,支持组织达 22 家,名单包含 Visa、Mastercard、American Express、AWS、Google、Microsoft、Stripe、Adyen、Fiserv、Shopify、Circle、Solana Foundation、Polygon Labs、Base、KakaoPay 等。
规模数据方面,据公开统计,x402 在 2025 年内累计处理超过 1.4 亿笔交易、金额超过 6 亿美元,2025 年 10 月峰值约每周 100 万笔;到 2026 年 4 月累计约 1.65 亿笔,接入约 6.9 万个活跃 Agent,平均单笔金额低于 0.31 美元,约 98.6% 的机器支付以 USDC 结算。另有 Solana 基金会披露其链上贡献了约 65% 的 x402 交易量。
与 AP2 / MPP / ACP 的分工
x402 回答的是「钱怎么移动」(结算层),而它刻意不回答「凭什么付」(授权层)。后者由不同协议承担:Google 于 2025 年 9 月联合 Coinbase 发布 AP2(Agent Payments Protocol),用 Intent / Cart / Payment Mandate 三类可验证凭证把用户授权密码学化,声称有 60 余家组织参与;Stripe 与 Tempo 于 2026 年 3 月发布 MPP(Machine Payments Protocol),在 402 之上加会话预授权层,被形容为「钱的 OAuth」,同时支持法币卡与稳定币;OpenAI 与 Stripe 于 2025 年 9 月开源 ACP(Agentic Commerce Protocol),面向 Agent 与商户之间的零售结账而非机器间微支付。
几者多为互补关系:AP2 负责授权、ACP 负责结账、x402 或 MPP 负责结算。有公开分析指出,x402 正是 AP2 已落地的结算轨道之一。
局限与风险
客观看待 x402 需要注意几点。其一,资产与合规:它以稳定币结算为事实主线,缺少原生法币通路,而稳定币支付在全球多地对地域与牌照有明确限制,生产落地前需法务评估。其二,成本模型:每一次请求都是一次独立支付事件,对单会话数千次调用的高频微支付场景,即便在 L2 上也可能累积成本,需依赖 Facilitator 批量结算来缓解。其三,缺少内置托管:协议本身不提供托管与仲裁,复杂多方任务需要在其上叠加额外的合约层。
此外,监管与法律层面的适配仍在演进中:有法律机构在 2026 年 4 月指出,围绕「人类决策交易」建立的现有金融与消费者保护法,可能并不完全适配 Agent 自主发起的支付。相关规范请以 x402.org 与基金会官方公告为准。
🎯 应用场景
✅ 最佳实践
- 先分清授权层与结算层:需要用户委托与可审计授权时叠加 AP2 一类协议,而非只上 x402
- 按量计费场景优先采用 upto 报价,避免预估值与实际用量脱节
- 自建链上节点不是必需项,多数场景使用成熟 Facilitator 更划算
- 务必验证重放保护与收据校验,把结算证据落到可审计的位置
- 生产前评估结算资产在目标司法辖区的合规限制,并保留人工兜底
🔮 未来展望
随着协议中立化与卡组织、云厂商集体入场,机器支付正从加密圈实验变成支付行业共同押注的方向。可以预期的演进是:授权层(如 AP2 的 mandate)与结算层(x402 / MPP)进一步合流并形成组合式栈;发现层出现面向 Agent 的付费服务目录;以及围绕 Agent 支付的争议解决、税务与消费者保护规则逐步补齐。短期内多种协议并存、而非单一标准胜出,仍是较可能的格局。