文章作者：Nick Sawinyh，defiprime.com

文章编译：Peggy，Blockbeats

编者按：围绕 Agent 如何支付这一问题，x402 与 MPP 给出了两种几乎相反的路径。

x402 走的是协议最小化：把支付直接嵌入 HTTP 请求，用最简单的方式实现请求即付费。没有账户、没有中间商，更像互联网早期那种开放、无许可的设计，适合长尾开发者和去中心化场景。

MPP 则是系统最大化：通过会话（sessions）、流式支付与合规体系，解决高频交易、风控和法币接入问题。它不追求纯粹，而是优先满足现实商业需求，更适合企业级与规模化应用。

两者的差异，本质上是同一个问题的两种解法：是把支付做成协议的一部分，还是做成系统的一层。

也正因此，它们并非完全竞争关系，而更像分布在不同区间，x402 覆盖开放网络的长尾需求，MPP 承接高频与商业化流量。在一个尚未成型的 Agent 经济里，这种分化或许是必然的。

以下为原文：

HTTP 状态码 402 自 20 世纪 90 年代末在 HTTP/1.1 规范中被定义以来，就一直在等待一个用武之地。它的含义是需要支付（Payment Required）。当初的设想是：将支付能力嵌入到 Web 的协议层，让机器能够像请求网页一样去购买资源。

但这一设想大多并未实现。多年来，这个状态码只在一些边缘场景中偶尔出现，比如 Shopify 的限流响应、Apple Mobile Me 的计费错误等，却始终没有人真正构建出它所暗示的微支付未来。取而代之的，是信用卡、订阅制付费墙，以及 API Key 机制，这些系统本质上都是为有人手操作的人类设计的。

而今天，这一未来出现了两种彼此竞争的实现路径，并且在同一天发布。接下来，我想梳理它们分别是什么、有什么差异，以及为什么 Stripe 会同时押注这两条路线。

x402：更简单的一种方案

Coinbase 于 2025 年 5 月正式推出了 x402，其核心思路几乎可以说是极简到激进。客户端请求一个资源；服务器返回 HTTP402，并告知客户端：需要支付多少费用、使用什么代币、在哪条链上完成支付。客户端在链上完成支付后，将支付凭证附在重新发起的请求中，服务器随即交付资源。

就这么简单。没有账户体系，没有 API Key，也没有订阅机制。只是一次 HTTP 请求往返，中间插入了一笔支付。

如今，Stripe 已在其支付体系中提供对 x402 的原生支持，商家可以通过现有后台直接接收这类支付。不过，从本质上来说，x402 仍然是 Coinbase 主导的协议，由其与 Cloudflare 于 2025 年 9 月共同发起的 x402 Foundation 负责治理。该协议完全开源（Apache 2.0 许可），并提供 TypeScript、Go 和 Python 等多语言 SDK。

在支持范围上，Coinbase 的官方文档显示，目前已在 Base、Polygon 和 Solana 上支持 ERC-20 支付。同时，生态也在探索将其扩展至 Avalanche、Sui 和 Near 等其他链，但成熟度不一。

再来看 adoption 数据，这部分就稍微复杂一些。Coinbase 表示，x402 已通过其 Agentic Wallet 基础设施处理了超过 5000 万笔交易。听起来很亮眼，但根据 CoinDesk 在 3 月 11 日援引 Artemis 的链上分析数据：日交易量约为 13.1 万笔，总金额约 2.8 万美元，单笔平均支付仅约 0.20 美元，其中大约一半更像是测试或游戏化行为，而非真实商业交易。

但这未必是坏事。因为这个协议本来就是为一个尚未真正存在的市场设计的，一个由 AI agent 进行微额支付（甚至低于 1 美分），用于 API 调用和数据查询的世界。而服务这一市场的商家，也才刚刚开始出现。

例如，Google 的 Agentic Payments Protocol（AP2，属于 A2A 框架）已经集成了 x402；Lowe's Innovation Labs 还展示了一个 demo：AI agent 可以在一个流程中完成商品发现、调研到下单的全过程。同时，World（由 Sam Altman 发起）本周发布了 AgentKit，为 x402 钱包增加人类身份证明能力。

其背后的核心假设是：只要把支付变得像 HTTP 请求一样轻量，应用场景自然会出现。至于这是否成立，还有待验证。

MPP：全栈方案

Stripe 和 Tempo 选择了一条不同的路径。Machine Payments Protocol（MPP）于今日随 Tempo 主网上线一同发布。与作为现有区块链之上轻量封装层的 x402 不同，MPP 是专门为高频交易的智能体（agents）这一场景而设计的。

其核心机制是会话（sessions）。不同于每次请求资源都要发起一笔链上交易，agent 可以先一次性授权一个支出额度，然后在该额度内持续进行微支付。如果你是一个每小时需要查询上千次数据源的 AI，就绝不希望每次都签名并广播一笔链上交易，而 sessions 正是为了解决这一问题。

Tempo 这条链也是围绕这一需求构建的。它支持每秒数万笔交易，具备亚秒级确认时间，而且没有原生 gas 代币。用户可以直接用稳定币支付手续费，省去了为了转账还要先购买某种随机代币的繁琐步骤。

另一个值得理解的组件是：Stripe 的 Agentic Commerce Suite 中包含 Shared Payment Tokens（SPTs）。这并不是 MPP 本身的一部分，而是 Stripe 的扩展机制，但可以与其协同使用。SPT 允许 agent 在不暴露真实数据的情况下，将用户的银行卡或钱包凭证安全地传递给商家。这些凭证仅限单次交易、且有时间限制，可以理解为一种可编程、自毁式授权。在实际使用中，这意味着一个通过 MPP 支付的 agent，既可以使用 Tempo 上的 USDC，也可以使用用户绑定的 Visa 卡，甚至两者结合。

根称，MPP 上线时支付目录中已有超过 100 项服务，包括 Alchemy、Dune Analytics、Merit Systems 和 Parallel Web Systems。Tempo 与 Paradigm 的联合创始人 Matt Huang 在接受《Fortune》采访时表示，这一领域仍处于早期阶段，MPP 的设计目标是未来可以扩展到 Tempo 之外的更多链上环境。

为什么 Stripe 同时支持两者

如果你已经接入了 Stripe，最实际的答案是：你不需要在两者之间做选择。

Stripe 通过两条独立的集成路径分别支持 x402 和 MPP，而不是将它们抽象成一个统一接口。对于 x402，其文档主要涵盖充值地址生成、链上监控以及资金结算至 Stripe 账户的流程——你负责返回 402 响应，底层的加密支付基础设施由 Stripe 处理。目前支持 Base 上的 USDC，未来还会扩展。对于 MPP，商家则可以通过同一套 PaymentIntents API，接收基于会话的流式支付。

Stripe 于 2025 年 12 月发布的 Agentic Commerce Suite 构建在这两条支付轨道之上。商家只需上传商品目录，选择希望接入的 AI agents，Stripe 就会负责商品发现、结账流程、反欺诈以及税务处理。目前，URBN、Etsy、Coach、Kate Spade 和 Ashley Furniture 已经在使用，Wix、WooCommerce、BigCommerce、Squarespace 和 commercetools 等平台也已完成集成。

其策略其实很清晰：掌控抽象层，让底层协议自由竞争。

对比来看

从宏观上看，这两种协议在做同一件事：让机器可以通过 HTTP 为资源付费。但真正的差异，体现在细节之中。

x402（由 Coinbase 主导）vs MPP（Stripe + Tempo）

标准化

x402：完全开源（Apache 2.0），由 x402 Foundation 推动多方参与（Coinbase、Cloudflare、Visa、Google）。

MPP：开放标准，由 Stripe 与 Tempo 共同制定，属于 Stripe Agentic Commerce Suite 的一部分。

HTTP 机制

x402：复活 HTTP 402，通过 PAYMENT-REQUIRED 头发起请求，使用 PAYMENT-SIGNATURE 完成重试。

MPP：同样采用 challenge-response 机制，但使用的是 Payment HTTP Authentication Scheme（IETF 草案），通过 HMAC 绑定 challenge ID。

支付底层（Rails）

x402：设计上链无关，目前在 Base、Polygon、Solana 上已有支持，其他链仍在探索中。

MPP：基于 Tempo 区块链——一个为支付优化的 L1，支持 1 万+ TPS、亚秒级确认，无原生 gas 代币；长期目标是实现跨链兼容。

支付方式

x402：纯稳定币，完全链上。

MPP：支持 Tempo 上的 USDC + SPT（Stripe 的机制），实现加密与法币混合（银行卡、钱包、BNPL）。

结算方式

x402：按链上结算（约 200ms 至数秒），由 Coinbase 等 facilitator 负责验证与结算。

MPP：Tempo 亚秒级确认，Stripe 自动入账并处理合规。

商户接入

x402：开源中间件（Express、Hono、Next.js 等），可自建或使用 facilitator。

MPP：直接接入 Stripe 的 PaymentIntents API，风控、税务、退款、报表全部内置。

核心创新

x402：极致简洁、无厂商绑定，类似支付领域的 Unix 哲学。

MPP：高吞吐 + 法币融合，通过 session 实现流式支付、微支付聚合，以及基于 SPT 的可编程支出控制。

关键合作方

x402：Coinbase、Cloudflare、Google（A2A/AP2）、Visa、World、Anthropic（MCP）。

MPP：Stripe、Visa、Lightspark、Anthropic、DoorDash、Mastercard、OpenAI、Shopify、Revolut、渣打银行。

x402 更像是你在构建开放系统时的首选方案：独立开发者 API、去中心化数据市场，或者任何不希望依赖支付处理商的服务。它的规范可以写进一篇白皮书，接入只需要一个中间件和一个钱包地址。这种纯粹性很有吸引力——尽管纯加密的限制也意味着它的受众更窄。

MPP 则是另一种完全不同的范式。如果你的 agent 需要在一次会话中进行数百甚至上千次交易，而不希望每次都上链，那么它就是更合理的选择。session 机制让大部分交互保持在链下，直到最终结算；Stripe 的合规体系负责风控和税务；而 SPT 的混合模式，则让 agent 不再局限于稳定币，还可以直接调用用户的 Visa 等支付方式。它不那么优雅，但更贴近现实。

有意思的是，它们其实并不完全是竞争关系。x402 覆盖长尾开放场景，MPP 覆盖企业级高频流量。Stripe 的策略也很明确：不押注单一协议，而是确保无论哪条路径胜出，资金最终都流入 Stripe 的账户体系。

现实情况：现在到底发展到哪一步了？

说实话，目前几乎还没有真正的规模化交易。

根据 Coinbase 的 x402 发布信息，早期合作方包括 Hyperbolic（GPU 推理付费）和 Anthropic（MCP 协议集成）。Stripe 的博客提到按 API 调用付费的 agent 场景（例如 CoinGecko）。Tempo 上线时目录中有 100+ 服务。Cloudflare 的 Agents SDK 已原生支持 x402，一些 Base L2 上的小项目也在尝试用 x402 做付费网关。

但整体来看：交易量很小，商户数量有限，大多数活动仍停留在实验阶段。

这其实并不意外。任何新的支付基础设施，早期都是这样。所谓合作伙伴名单，有时从签了意向书到已经上线生产之间差距很大，而这些发布通常不会特别区分。

更值得关注的是基础设施背后的重量级参与者。Stripe 在 2025 年处理了 1.9 万亿美元的支付，总量同比增长 34%。同时，Coinbase、Cloudflare、Visa、Google，以及 Tempo 的一整套合作网络都已入场。

也就是说，轨道已经铺好。问题只剩一个：2026 年，AI agent 是否真的需要在这个轨道上大规模交易？还是这更像 1998 年铺设光纤——需求还没来，但基础设施先行。

那该选哪一个？

如果你在构建一个开放、无需许可的系统——x402 是更自然的选择。无需注册平台、无需对接支付商，导入中间件、绑定钱包即可收款。代价是：合规、风控、法币结算都要自己处理。

如果你已经在 Stripe 体系内，并希望接入 agent 流量——MPP 更合适。session、流式支付、法币+加密混合，以及完整的合规体系，本质上更像配置升级，而不是系统重构。

如果你只关心一件事：不管 agent 用哪种协议，我都能收钱。那答案其实就是：用 Stripe。它两边都支持。

HTTP 402 终于派上用场了。只不过，它等了差不多 27 年。