Coinbase将x402推向中立化，Stripe在MPP之外继续双线押注

作者：Charlie Liu，Generative Ventures合伙人

最近，随着agentic commerce的关注度持续升温，市场上的协议和玩家越来越多，让不少人感到困惑。尤其是上周，当大家还在努力理解Stripe/Tempo的MPP时，Stripe却突然加入了Coinbase主导的x402 Foundation。与此同时，Cloudflare也宣布同时支持两套协议，Google则继续推进自己的AP2和UCP，Visa和Mastercard也纷纷入局，但显然它们并非为稳定币站台。

Linux Foundation明确将x402定义为一个中立、行业共治的“大本营”，而Cloudflare更是直接将x402与MPP整合进其Agents SDK。Stripe也在文档中公开表示同时支持MPP和x402。那么，谁在竞争？谁又在叠加？经过深入观察，我认为这种“混乱”并非因为市场没有方向，而是因为市场已经非常清楚——从第一天起，这件事就不会由单一协议统一完成。

这更像是互联网基础设施建设中的常见局面：不同层级同时发展，不同公司在不同层下注，最终通过互操作性让整个系统运转起来。真正的战略核心在于，谁能定义agentic web上paid machine access的默认控制层。而关键玩家显然都在multi-home，因为他们仍在赌未来的瓶颈会出现在授权、分发还是结算环节。

一、Coinbase为何放手将x402基金会交给Linux？

如果x402仅仅是Coinbase的协议，它很难成为行业的默认选项。这不是一句政治正确的话，而是标准化逻辑的现实体现。Linux Foundation此次明确强调了服务商中立、社区治理和共享基建的重要性，而非“某家公司发布了一个产品新功能”。更重要的是，x402 Foundation页面显示该项目仍处于建立期，治理机制和董事会尚未完全搭建完成。

换句话说，这次动作的核心不是宣布“产品成熟了”，而是为协议寻找一个中立的家。背后的逻辑很简单：如果x402始终被视为Coinbase的产品功能（如现在的Base），云厂商、支付公司、卡组织和平台型玩家即便技术上愿意接入，也会在政治上犹豫不决。没有人愿意将未来的paid access layer交到单一平台手中。将其置于Linux Foundation之下，并非因为Coinbase不想控制，而是因为它太想让x402被广泛采用，所以必须先摘掉“这是Coinbase的协议”的包袱。

这一点非常重要，因为很多人容易将基金会的动作简单视为PR或开源姿态。但在协议战中，治理本身就是产品的一部分。尤其是在标准尚处早期、缺乏绝对网络效应的情况下，“中立可信”并不比技术优雅次要。反过来说，如果x402未来能成为某种HTTP-native paid access baseline，很可能不是因为代码最漂亮，而是因为它比其他方案更早降低了政治成本。

二、Stripe的左右互搏到底在做什么？

本次最值得关注的玩家无疑是Stripe，因为它的动作最容易引发困惑。一方面，它在3月18日高调推出MPP，将其包装为机器支付的开放标准；另一方面，它又是x402 Foundation的创始贡献者，并在其文档中明确支持x402 machine payments。Cloudflare的文档甚至直接写道：MPP对x402的核心支付流程是向后兼容的，MPP客户端可以直接消费现有的x402服务。

如果仅从“协议竞争”的框架来看，Stripe似乎在左右互搏。但如果将视角抬高一点，这种做法反而最具商业逻辑。因为Stripe真正想守住的，未必只是402握手本身，而是握手之上的几层：credentials、compliance、risk、reporting、tax、refunds和merchant integration。

Stripe看起来并不是某个单一协议的真正信仰者，而是确保无论哪个handshake标准胜出，Stripe仍然是agent payments的默认抽象层。支持x402是为了不缺席开放生态；自己推MPP是为了参与定义底层语义；再往上推ACP和Shared Payment Tokens，则是为了守住工作流和支付凭证那层更厚的价值。

因此，Stripe此次最“怪异”的地方，其实恰恰是最诚实的地方。它没有假装未来会很快只剩下一个协议，而是用行动表明：至少在这个阶段，谁都不该只押一边。

三、这是一个B2B的基础设施故事

我越来越觉得，很多媒体把焦点放偏了。提到agent payments，人们最容易联想到零售场景：AI帮你买机票、订酒店、下单购物车等。然而，如果你关注眼下已公开落地且具备基础设施雏形的场景，最先跑起来的并不是零售checkout，而是更无聊但也更真实的B2B paid access：付费API、付费数据、付费工具、付费浏览器会话、付费agent workflow。

Cloudflare现在公开支持使用x402和MPP为HTTP内容、API和MCP工具收费。x402最强的采用路径正是在developer-to-developer paid APIs和tools上，因为“无账号+按请求付费”在这里不仅是噱头，而是切实可行的落地方式。

背后的变化意义重大。过去，一个API要收费通常需要走一整套“人类友好”的流程：开账户、绑定billing、发放API key、设置限额、对账并处理支付权限。这对人来说已经够繁琐，对agent来说更别扭。x402最有吸引力的地方，不是它更crypto，也不是它更AI，而是它试图将“付费访问”重新塞回HTTP本身，让准入控制和支付协商像普通request-response一样发生。

服务端返回402，告诉客户端这次请求值多少钱；客户端付完钱后，再用支付凭证重试同一个请求。这个模型如果从B2B软件和machine-to-machine access的角度看，会比从零售角度顺畅得多。

而且，越往B2B这边看，x402的优势越明显，短板也越不致命。因为在consumer commerce中，退款、拒付、merchant-of-record、消费者保护、责任归属等问题都是硬骨头；但在B2B API和工具调用中，这些问题的重要性明显下降。相反，“无账号、按调用付费、拿到结果就走”才是真需求。

零售当然更大、更热闹，也更容易吸引眼球；但真正定义协议长什么样的，往往不是最热闹的场景，而是最早暴露真实需求的场景。对于今天这波agent payments来说，那个场景很可能不是购物车，而是越来越多软件之间、agent之间、工作流之间的paid access。

四、行业发展验证了我的interoperability判断

在我上一篇文章中最核心的判断是interoperability。当时这一判断还带有一点“架构上应该这样”的意味，但现在看来，它越来越像现实约束，因为公开市场已经在用脚投票。

Cloudflare没有选边站，而是直接同时支持x402和MPP，并明确做了兼容映射。Google一边参与x402，一边继续推进AP2和UCP。Visa和Mastercard也没有用“all in one winner”的姿态表达战略，而是一边加入x402，一边继续加码agent token、身份验证、指令校验和dispute signals。

巨头们的多边押注是理性决策，而非商业虚伪。为什么会这样？因为这些协议根本不在同一层。

至少到目前为止，x402和MPP更接近paid HTTP handshake这一层，解决的是“如何让请求带着支付能力回来”。AP2更接近授权和可信意图，解决的是“这个agent是否有资格花这笔钱”。UCP和ACP则更像workflow层，处理discovery、checkout、商户关系、凭证传递等更上层的问题。

许多公司同时支持x402、MPP、AP2、UCP，并不是因为它们自己没想清楚，而是因为赢到最后的架构很可能跨多层，甚至需要多协议共同组成。因此，如果要用一句话回顾我上一篇的判断，我现在更加相信：如果没有interoperability，这一波生态根本起不来。

现在看，市场正在主动验证这个判断。进一步说，这一判断对B2B vs零售尤为重要。因为在零售世界里，最后也许真会被少数大平台和少数大工作流吸进去；但B2B世界不是这样。企业本来就活在多云、多支付方式、多工作流系统、多身份权限系统并存的现实中。谁试图用一个新协议把整个企业栈一把推倒重来，谁大概率先死。

B2B客户真正愿意买单的，往往不是“唯一正确的协议”，而是“让现有系统在多协议环境下还能工作”的能力。这一逻辑，恰恰就是interoperability在企业场景中比在consumer场景中更硬的一点。

五、这不是单纯的协议竞争，而是分层后的stack竞争

一旦你把这件事理解成分层stack，很多原本显得很乱的现象就会立刻顺起来。

最底下一层是paid access handshake。这一层关心的是：HTTP请求如何表达“这里需要付费”，以及客户端付完之后如何将支付凭证带回。x402和MPP主要在这里竞争。MPP试图将402往更正式的HTTP auth semantics上收；而x402则更像在将402平台化，通过自定义header、facilitator、链上结算抽象和生态集成，让它先跑起来。

一个更像标准化语义路线，一个更像平台分发路线。

再往上一层是authority to spend，也就是“谁授权了这笔钱”。这一层才是很多人现在还没完全意识到的关键。机器会付钱，这件事并不难；机器能被可信地授权去付钱，才是真难。AP2之所以重要，就因为它不只是“怎么支付”，而是在解决mandates、verifiable credentials、authenticity、accountability等问题。Visa和Mastercard最近加码的那些agent token、instruction validation、passkeys、dispute signals，本质上也都在这里。

再往上一层是workflow和distribution，也就是discovery、checkout、商户关系、凭证共享、AI surface integration等更接近“谁掌控流量和交易编排”的东西。UCP和ACP更像是在争这一层。

对B2B来说，这层短期没有那么热闹，但从长期看价值可能非常高。因为如果未来越来越多企业软件都由agent协调、调用、采购和支付，那么谁掌握workflow language，谁就不只是管一次付款，而是在管整个工作流。

一旦你把这三层分开，就会发现一个很朴素的事实：根本没必要期待一个协议把所有问题都包了。更现实的路径是这三层各自先长，再通过互操作性慢慢咬合起来。也正因为如此，多头下注不是摇摆，而是理性。

六、x402的真正风险，未必是监管，而是并发下的经济学

如果我们仅仅认识到“多协议并存”，其实还不够深刻。x402最大的风险，未必首先是监管，而可能是verify–settle两步分段带来的time-of-check/time-of-use经济学。

简单来说，就是如果验证支付和最终结算不是一回事，那么在高并发、重试、代理层、缓存层这些真实互联网环境中，就会出现“pay once, access multiple times”的窗口。x402生态现在也在补洞，比如settlement cache、idempotency extension、payment identifier，但这恰恰说明问题不是理论上的。

为什么这一点尤其值得B2B读者在意？因为B2B世界最怕的，从来都不是漂亮demo做不出来，而是edge case太多，最后一上生产环境就开始漏。API monetization表面上看是每次请求付几分钱，挺轻；可一旦你的产品是按调用收费、按结果收费、按工作流收费，那么“付一次拿一次”还是“付一次拿很多次”，就不是产品细节，而是生死线。

因此，如果未来x402真能在B2B中跑出来，一个重要前提不是narrative，而是这些default-safe的机制得被做得足够无脑，否则企业不会放心把真实流量接进来。

七、协议可能是免费的，但收费站不会消失

还有一点，我觉得值得在这篇文章里讲透。很多开放协议最后都会走到一个熟悉的地方：协议本身越来越便宜，甚至免费，但真正的收费站会在旁边长出来。

x402也不例外。标准本身当然强调开放、中立、0 fees built into the standard，但这不等于value capture会消失。如果x402成功，价值不会主要留在协议里，而会往facilitator、钱包和key management、discovery、policy engine、trust wrapper这些相邻层迁移。

这对B2B来说尤其重要。因为企业客户不会为了一个新协议就大规模改造整套系统，他们真正愿意付钱的，是谁能帮他们在多协议环境中把orchestration、policy、risk、compliance、audit、settlement、权限边界这些麻烦事收拾好。

换句话说，协议会越来越像底层语言，但把这些语言翻译成“企业能放心上线”的能力，那一层反而更容易变成新的平台和新的收费站。

这也是我为什么会觉得，今天看x402，不能只盯着Coinbase、Cloudflare、Stripe谁更像“主角”。真正值得盯的，是谁最有机会站到这些相邻层上。Cloudflare有边缘和流量分发的位置，Stripe有支付基础设施和商户关系的位置，Visa和Mastercard有凭证、网络token和consumer trust的位置，Google有workflow和discovery surface的位置。

真正的价值捕获，不一定发生在“谁定义了402”，更可能发生在“谁把402接进了更大的企业系统”。

八、结语

x402 Foundation这件事，并不是在宣布x402已经在所有agentic commerce协议中胜出。它是在公开承认，这一代agent payments从第一天起就不会是单一协议世界。

Coinbase将x402交给Linux Foundation，是为了让它更像中立公共层，而不是独家产品。Stripe一边推MPP一边加入x402，不是摇摆，而是因为它知道现在不该只押一边。Cloudflare同时支持两套，是因为它最接近真实流量。Google、Visa、Mastercard、Adyen这些玩家的动作，也都在说明同一件事：先让系统能互通，再谈谁最后占住哪一层。

如果把视角从零售挪开，这个判断就更顺了。因为最先需要这些协议的，不一定是购物车，而是越来越多按调用、按任务、按结果收费的B2B软件和服务。

零售当然更大，但B2B往往更早暴露真实需求，也更早定义基础设施最后长什么样。我上一篇文章里把interoperability放在中心，我觉得现在市场给出的答案其实很明确：对，而且比当时想的还更早。

从这个意义上说，x402 Foundation不是这场故事的结尾。它只是让我们更早看见，真正的主题一直不是“谁会赢”，而是“这个世界注定要先互通，谁又能在互通之后，占住最值钱的那一层”。