阅读时长 4 分钟
x402 与 AP2 详解：智能体支付协议如何分工
超过 100 家支付服务提供商和科技公司 已经加入了 AP2 阵营。Coinbase 的 x402 已在 Base 上处理超过 1.19 亿笔交易。如果你正在为智能体构建支付基础设施，这两个协议是你必须理解的。
x402 是 Coinbase 开发的基于 HTTP 的支付原语。当服务器返回 HTTP 402 状态码（"Payment Required"，需要付款）时，智能体会读取响应中嵌入的支付指令，签署一笔稳定币交易，附上付款证明，然后重新发起请求。无需用户会话，无需登录流程。结算在链上几秒内完成。
AP2（Agent Payments Protocol，智能体支付协议）是 Google 面向智能体发起商务的开放标准。它负责的是会话层面的信任与授权：在智能体可以进行任何支出之前，用户必须签发一份经过密码学签名的 Mandate（授权委托）来证明意图。AP2 包含一个 x402 扩展，由 Coinbase、以太坊基金会和 MetaMask 共同开发，使 x402 成为 AP2 体系内的加密资产/稳定币支付方式。
两者并非竞争关系，而是解决同一问题的不同层面。
x402 是什么，如何运作
x402 是面向机器对机器 API 调用的支付协议。其设计刻意保持极简。它重新启用了 HTTP 402 状态码——该状态码自 1991 年起就存在于规范中，但直到现在才被标准化。
流程如下：
- 智能体调用一个 API 端点。
- 服务器返回 HTTP 402 及支付载荷：金额、币种、目标地址、可接受的稳定币、网络。
- 智能体的钱包签署一笔满足这些条款的稳定币交易。
- 智能体重新发送原始请求，并在请求头中附上支付证明。
- 服务器验证证明并执行该请求。
无需登录，无需信用卡，无需 OAuth 令牌。支付本身就是凭证。
截至 2026 年 3 月，x402 协议零手续费，年化交易量约 6 亿美元，覆盖 Base 和 Solana。随后 Coinbase 将 x402 移交给 Linux 基金会，并获得 Google、Stripe 和 Visa 的支持。这一举动在运营层面意义重大：治理如今是中立的，协议风险低于单一企业赞助下的情形。
如果你的 API 直接服务智能体，而你希望实现按量计费、无摩擦的支付，又不想构建订阅或会话管理层，x402 就是那套机制。它不管理跨会话的信任，不验证用户意图，也不知道当前执行操作的智能体是否获得了最终用户的授权。这是有意为之的范围界定。
AP2 是什么，如何运作
Google 的AP2 发布吸引了 Coinbase、Mastercard、PayPal、American Express、Revolut、Shopee、Salesforce、Worldpay、Adyen、Etsy、JCB 和 UnionPay 等 60 多家创始合作伙伴。短短六周内，该联盟的合作伙伴就已超过 100 家。规范已公开，可在此查阅。
AP2 的核心概念是 Mandate（授权委托）：一份经过密码学签名的数字合约，记录用户在任何交易发起之前授权智能体做什么。Mandate 可以指定支出限额、批准的商户、有效时间窗口和支付方式。没有有效的 Mandate，智能体无法在 AP2 下发起支付。
其信任模型的工作方式如下：
- 用户或企业配置一份 Mandate：范围、限额、有效期。
- Mandate 经签名后颁发给智能体。
- 智能体在发起支付时出示该 Mandate。
- 支付服务提供商在处理之前对 Mandate 进行密码学验证。
AP2 可跨传统支付渠道（银行卡、银行转账）运行，并通过 AP2 x402 扩展支持稳定币和链上结算。这一扩展正是两个协议直接交汇之处。
AP2 是规模化智能体商务的授权与信任层。如果你正在构建供智能体购买商品或服务、调用付费 API 或代表用户执行定期支付的基础设施，你就需要 Mandate 框架。x402 支付可以在该框架内作为结算方式运行。
x402 与 AP2 如何相互配合
理解两者关系最清晰的方式是通过协议栈来看。
AP2 运行在会话与授权层：它回答的是"这个智能体是否被允许支出、代表谁、受什么约束？"x402 运行在调用层：它回答的是"智能体现在如何为这次具体的 API 调用付款？"
AP2 x402 扩展将两者融合。当一个在 AP2 Mandate 下运行的智能体需要使用稳定币为 API 调用付费时，x402 机制负责按次结算。Mandate 为 AP2 提供授权上下文，x402 负责结算机制。
两个协议都不是执行层。它们定义的是接口、消息格式和验证逻辑。它们规定支付请求长什么样，以及有效响应必须包含什么。执行交易需要协议之下的工作：保管密钥、以可审计的轨迹进行签名、筛查目标地址、调度资金。这些全部发生在位于两个协议之下的钱包基础设施中。
有无合适基础设施的场景对比
设想一个 AI 智能体，被企业授权调用某个数据 API 并按查询次数付费。该智能体在 AP2 Mandate 下运行，并为每次调用发起一笔 x402 支付。
在没有足够钱包基础设施的情况下：智能体生成支付证明并提交。你的后端收到一个已签名的稳定币交易请求。如果你的提现流程没有自动签名、可配置的审批阈值和实时 KYT 筛查，你就只能在人工审核（会完全破坏延迟模型）与盲目执行（带来合规和欺诈风险敞口）之间做选择。
在底层接入 WaaS 管道的情况下：请求到达 CoinSend，后者在发出交易前将其路由到 CoinSign 进行 RSA/HMAC-SHA256 授权。CoinGet 的自动 KYT 会在资金转移前筛查目标地址。签名、筛查和调度全部发生在基础设施层，位于协议层之下，不会破坏 x402 所设计的亚秒级延迟模型。
这就是执行层的区别所在。x402 和 AP2 描述的是接口，而 CoinGet、CoinSend 和 CoinSign 是底层管道。
CoinsDo WaaS 是非托管的：私钥由运营方持有，而非 CoinsDo。CoinSign 的 RSA/HMAC-SHA256 签名为每笔交易提供不可伪造的授权轨迹。平台支持智能体部署钱包的各类用例，覆盖 ETH/ERC-20、TRX/TRC-20、BNB/BEP-20、Polygon、Solana 以及其他多条链，按客户端需求提出的链集成大约以一个月为周期推进。
如果你的智能体需要跨链运行，这种覆盖范围就很重要。x402 起步于 Base 和 Solana，AP2 在框架层面与链无关。你的基础设施需要匹配你的智能体实际会使用的链。
想深入了解这在 WaaS 场景中如何运作，请阅读此处
关于这些协议带来的基础设施决策（密钥托管、审批流程、合规自动化和链覆盖），请阅读此处
常见问题
我是否需要同时实现 x402 和 AP2？
不一定，也不必同时进行。如果你的用例是 API 变现——智能体按调用付费且你不需要会话级授权——仅用 x402 可能就足够了。如果你在构建智能体对商户的商务场景，需要用户意图和支出限额在多笔交易之间可被密码学验证，AP2 为你提供 Mandate 框架。对于任何有实际规模的稳定币结算智能体商务，你最终很可能两者都要实现：AP2 负责信任与授权，x402（通过 AP2 x402 扩展）负责结算机制。
钱包基础设施在协议栈中处于什么位置？
在区块链之上，在协议之下。x402 和 AP2 定义消息格式和验证逻辑。它们不保管密钥，不签署交易，也不筛查交易对手。这些工作属于钱包层：充值地址生成、交易签名、KYT 筛查和自动调度。两个协议都没有规定这一层应该是什么样子，由你自己搭建。
x402 现在是否已足够稳定，可以基于其构建？
在 Stripe、Google 和 Visa 的支持下移交给 Linux 基金会，是协议稳定性的强烈信号。x402 GitHub以及在 Base 上超过 1.19 亿笔交易的记录，表明核心机制已走出实验阶段。治理模式如今是中立的。不过，你应该预期 AP2 x402 扩展会随着 AP2 本身的成熟而演进，因此请基于规范构建，而不是绑定某家特定供应商的实现。
AP2 Mandate 如何防止智能体未经授权的支出？
Mandate 经过密码学签名，而不仅仅靠令牌门控。智能体必须出示有效的 Mandate 才能发起任何符合 AP2 的支付，支付服务提供商会在处理前验证密码学签名。支出限额、商户限制和有效期窗口都嵌入在 Mandate 本身之中，而非在应用层执行。即使智能体被攻破，它也无法在 Mandate 范围之外支出，因为服务商端的验证会拒绝任何超出授权参数的交易。
