x402、AP2、ACP、MPP：唯一会改变你风险的那个差别

如今有四套标准能让智能体付钱，而人人写的对比都在比通道——刷卡对稳定币、HTTP 对结账 API。那是错的坐标轴。它们真正的分歧在于支出上限存放在哪里，而这一个选择就决定了：一个被提示词注入的智能体，在你技术栈里其他任何环节有机会表态之前，最多能花掉多少钱。挑那个把上限放在你守得住的位置的协议，通道问题会自己有答案。

一览

这四者通常被摆成对手。它们不是——它们处在不同的层上，一套真实的部署会同时用到其中两三个。下面先看清各自的形状，再谈真正要紧的那件事。

协议	谁在做	所在层	清算通道
x402	Coinbase Developer Platform；治理已转入 Linux Foundation，背后有 Google、Visa、Mastercard、Stripe、AWS 与 Circle。	传输层。复活了休眠的 HTTP `402 Payment Required`，让智能体按请求付费。	稳定币，以 USDC 为主，运行在 Base 与 Solana 上。协议本身零手续费。
MPP	Stripe 与 Tempo，2026 年 3 月随 Tempo 主网一同上线。	面向机器买方的清算层——API、算力、数字服务。	Stripe 现有通道，经 `PaymentIntents`；另有基于 Visa Intelligent Commerce 的 Visa 卡规范与 SDK。
ACP	OpenAI 与 Stripe 共同维护规范。PayPal 作为第二家合规支付方加入。	结账层。购物车、商品 feed、订单、委托支付，以及一个 MCP 绑定。	买方本来就在用的方式，经由一枚共享支付令牌（Shared Payment Token）中转。
AP2	Google，60 多家首发伙伴；治理已捐给 FIDO Alliance。	授权层。三份签名授权书——Intent、Cart、Payment——以 W3C 可验证凭证承载。	设计上与通道无关：刷卡、银行转账，或通过 x402 扩展走加密货币。

是叠起来的，不是排队等着的。问题是你需要哪一对，而不是谁赢。

唯一会改变你风险的问题

每一个能花钱的智能体身上都挂着一个数字：在人、银行或某台服务器说不之前，它最多能花掉多少。就叫它上限。这四个协议把这个上限存在了各自不同的地方，而存放位置决定了糟糕的那一天会发生什么。

先读最后一行。那是你将来要向某个人解释的那一行。

在 x402 里，上限就是钱包余额。协议刻意不设逐笔授权环节——这正是它的要点，也正是它能以另外三者望尘莫及的量级承接不到一分钱的 API 调用的原因。这同时意味着：一个被攻陷的智能体的支出上限，恰好等于你预先充进去的钱；这些支付不可逆；而且没有第三方站在能够拒付的位置上。安全研究者已经因此发表过针对 x402 流程的攻击族——协议没坏，它只是对"授权"不持立场。

在 MPP 以及它底下的卡规范里，上限是发卡机构的授权规则——就是那套在你于陌生国家刷卡时会拒绝交易的老机器。这是清单上久经实战检验的一项，而且带着另外三者都没有的一个属性：拒付。错走的钱能走回来。

在 ACP 里，上限是那枚共享支付令牌，由支付方针对恰好一次结账、按买家看到的价格铸出。智能体手里从来不会握有一份能用第二次的凭据。爆炸半径是一个购物车。

在 AP2 里，上限跟着请求一起走，装在一份用户以密码学方式签过名的授权书里——"跑鞋，10 码，150 美元以下"——而商家可以独立验证它。这是四者中最紧的作用域限定，也带着本文最大的一个星号。

证据不是执行

AP2 的授权书常被说成一项安全功能。它是一项不可抵赖功能，那是另一回事，失效方式也不同。一份签过名的 Intent Mandate，能在事后证明用户授权了某一类购买、并且智能体待在了范围之内——或者证明它没有。它不阻止任何事。它也做不到：授权书由商家来验，而商家拒绝一笔生意的动力，比你弱。

对照 ACP：支付方会拒绝令牌的第二次使用；或者 MPP：发卡机构会拒绝这笔授权。那些才是执行——一个既不是智能体、也不是商家的第三方，在付款发生的那一刻说不。

所以真正管用的分类不是"刷卡还是加密货币"，而是：

执行——某个独立方能在飞行途中拒绝。ACP 的令牌、发卡机构的规则，以及任何你自己运行的支出代理。
证据——某个人能在事后证明当初授权了什么。AP2 的授权书，以及你自己的审计日志留下的凭证链。

两样你都想要，而这份清单上没有任何单一协议两样都给。用提示词注入对 AP2 做红队的研究把这点讲得很具体：一个伪造不出签名的攻击者，仍然可以影响"用户被要求签什么"。在一段被操纵过的描述之下签出的授权书，是一份完全有效的授权书。

没有哪一行在四列上全强——这正是真实技术栈要把它们组合起来的原因。

Cloudflare 的钱包产品就是这个论点的缩影

"上限存在哪里才是真正的设计问题"，本月最清楚的证据来自一家在 x402 之上、而非取而代之地出货的公司。Cloudflare Wallets 让人先给一个 Account Wallet 充值，再通过 Virtual Wallets 把带上限的支出权委托给智能体，与其 Monetization Gateway 一道、以稳定币经 x402 清算。

看清这个产品的形状。x402 提供支付机制，仅此而已；Cloudflare 补上的正是 x402 刻意省略的那一层——一个按智能体设定的额度，由一个既不是智能体也不是商家的第三方持有，并且能够拒绝。那就是执行层，因为协议不带，就在基础设施厂商这边被重造了一遍。

如果你采用了 x402 却没有自建或采购那一层，那你等于把一条预先充值、不可逆、无人可拒的支付通道，直接接到了一个以读取不可信文本为生的系统上。正确的心智模型是受限作用域凭据：钱包就是一份凭据，而且是一份没有作用域的。

该选哪一个

你在做的是……	从这个开始	再补上
按次为 API、数据或算力付费的智能体	x402——没有别的东西能在那个金额量级上清算，而且它不收协议费	为每个智能体配一个带上限的虚拟钱包。买或自建都行，别跳过。
为消费者购买实体商品的购物智能体	ACP——商家接入与可用入口都已经存在	如果你要向监管机构或保险公司证明"意图"，加上 AP2 授权书。
用公司卡消费的企业智能体	MPP 以及底下的卡组织通道——你直接继承发卡机构的管控与拒付	为超过你设定阈值的部分，加一道你自己的预授权环节。
让第三方智能体与你的商家交易的平台	AP2——你需要逐笔可验证的"谁授权了什么"的证据	你自己的执行层。授权书只能证明，不能阻止。

有一条建议横跨这四行。无论你采用什么，都要把支出决策留在智能体循环之外——一个代理、一个策略服务、超过阈值就交给人——因为这里的每一个协议都假定调用方对"自己在买什么"是诚实的，而调用方是一个正在读陌生人所写文本的语言模型。关于这道闸门放在哪里，见人在环中；关于授权书机制的细节，见 AP2 与智能体商务。

常见问题

我必须从中选一个吗？

不必，而且只选一个恰恰是常见的错误。它们在不同的层上：AP2 授权，ACP 结账，x402 与 MPP 清算。一个购物智能体完全可能在 ACP 结账之上使用 AP2 授权书；一个消费 API 的智能体则在带上限的钱包之下使用 x402。

x402 不安全吗？

它是不持立场的，而当你把它接到一个没有额度层的自主智能体上时，这就变成了不安全。这个协议是为机器对机器的微支付设计的，那里的付款方是你自己写的程序。一个会去读网页的智能体是另一种付款方；在给钱包充值之前，值得读一读已公开的 x402 流程攻击分析。

哪一个有真实的生产体量？

论交易笔数是 x402 遥遥领先——Base 与 Solana 上合计远超一亿笔——因为按请求计费的 API 支付高频而微小。论面向消费者的可见成交，则是 ACP，通过 ChatGPT 里的 Instant Checkout。这是两把不同的尺子，直接相比没有意义。

智能体买错了东西会怎样？

在 MPP 与卡组织通道下：拒付，和任何一笔刷卡争议一样。在 ACP 下：走正常订单流程由商家退款。在 x402 下：稳定币没了。在 AP2 下：你握有当初授权内容的密码学证明，它帮你去讲道理，但本身并不把钱要回来。对任何有财务团队的人来说，这通常就是决定性的一条。