Coinbase将x402推向中性，而Stripe则继续在MPP之外两边下注

作者：Charlie，OSL美洲区负责人，Generative Ventures的风险合伙人。曾任加密货币独角兽Strike的副总裁（参与了萨尔瓦多比特币法案，并负责拉丁美洲的比特币闪电网络和稳定币支付业务），在万亿美元基金Franklin Templeton担任宏观和货币分析师，并且是全球支付巨头Adyen的早期成员。

本文反映了作者的个人观点，并不代表相关公司的立场。

最近，越来越多的朋友开始关注代理商业，但各种协议和参与者变得越来越混乱。

尤其是上周，当每个人忙于理解Stripe / Tempo的MPP时，Stripe意外地加入了竞争对手Coinbase的x402基金会。

此外，Cloudflare现在支持这两个系统。谷歌也参与其中，但它有自己的AP2和UCP。

Visa和Mastercard也已加入，但显然不是为了支持稳定币。

Linux基金会公开将x402定义为一个中性、行业共同治理的“基地营”，而Cloudflare明确将x402和MPP纳入其自己的Agents SDK，Stripe也公开表示支持MPP和x402。

谁在与谁竞争，谁与谁重叠？

然而，最近我越看越觉得，这种“混乱”并不是因为市场缺乏方向，而是因为市场已经非常清晰。正如我之前在x402中提到的，我们可能误解了它的初衷：从第一天起，这件事就不会被一个单一协议统一。

这类似于互联网基础设施中的常见情况——不同层次同时发展，不同公司在不同层次下注，最终，互操作性将使整个事情运转起来。

真正的战略故事是关于谁将定义代理网络上付费机器访问的默认控制层；关键参与者显然是多重居住，因为每个人仍在下注真正的瓶颈将落在哪里——授权、分发还是结算。

1.为什么Coinbase将x402基金会交给Linux？

如果x402仅仅是Coinbase的协议，那么它将很难成为行业的默认选项。

这不是一个政治正确的声明，而是一种现实的标准化逻辑。

Linux基金会这次的声明非常明确；它强调服务提供商的中立性、社区治理和共享基础设施，而不是“某家公司发布了新的产品特性。”

更重要的是，x402基金会页面目前声明该项目处于建立阶段，治理机制和董事会仍在建设中。

换句话说，这一行动并不是主要在宣布“产品已经成熟”，而是在宣布“我们希望给这个协议一个中立的家。”

潜在的含义非常简单。

如果x402继续以Coinbase产品特性的面貌存在（就像当前的Base），那么云服务商、支付公司、卡组织和平台参与者，即使在技术上愿意采用，也会在政治上犹豫。

没有人愿意将未来的付费访问层交给单一平台。将其置于Linux基金会之下并不是因为Coinbase不想控制它；而恰恰是因为它希望x402被广泛采用，必须首先去除“这是Coinbase的协议”的负担。

这一点实际上非常重要，因为许多人将基金会的行为视为仅仅是公关或开源姿态。

但在协议战争中，治理是产品的一部分。

尤其是在标准仍处于早期阶段且缺乏绝对网络效应时，所谓的“中立和可信”并不比技术优雅重要得少。

相反，如果x402确实能够在未来成为某种HTTP原生的付费访问基线，那么很可能并不是因为它的代码是最美观的，而是因为它比其他解决方案更早降低了政治成本。

换句话说，这里的治理并不是一个配角；治理本身就是一个增长引擎。

2.Stripe的双重战略到底在做什么？

这次值得关注的参与者无疑是Stripe，因为它的行为最令人困惑。

一方面，它在3月18日大张旗鼓地推出了MPP，将其包装为机器支付的开放标准。

另一方面，它是x402基金会的创始贡献者，其自身的文档也支持x402机器支付。

Cloudflare的文档更为直接，明确指出MPP与x402的核心支付流程向后兼容，MPP客户端可以直接使用现有的x402服务。

如果仅从“协议竞争”的角度来看，Stripe似乎正在采取双重策略。

但如果你稍微提升一下视角，这种方法实际上是最符合商业逻辑的。

因为Stripe真正想要保护的，不仅仅是402握手本身。

它真正想要保护的是握手之上的层面：凭证、合规、风险、报告、税务、退款、商家集成。

Stripe似乎并不是真正相信任何单一协议；相反，它似乎在确保无论最终哪个握手标准占据主导地位，Stripe始终是代理支付的默认抽象层。

支持x402是为了确保参与开放生态系统；推动MPP是为了帮助定义基础语义；进一步推广ACP和共享支付令牌是为了保护工作流和支付凭证的更厚的价值层。

因此，这次Stripe最“奇怪”的方面实际上是它最诚实的方面。

它并不假装未来会迅速简化为单一协议。它正在采取行动告诉你：至少在这个阶段，没有人应该只押注于一方。

3。这实际上是一个B2B基础设施的故事。

我越来越觉得许多媒体在这个问题上聚焦错误。

谈到代理支付，最容易想到的是零售：人工智能帮助你预订航班、预定酒店、下订单和完成结账。

但如果你看看那些真正已经公开实施并且确实具有基础设施特征的场景，首先起飞的不是零售结账，而是更平凡和真实的B2B付费访问：付费API、付费数据、付费工具、付费浏览器会话、付费代理工作流。

Cloudflare现在公开支持使用x402和MPP对HTTP内容、API和MCP工具收费。

x402的最强采用路径在于开发者与开发者之间的付费API和工具，因为这里的“无账户+按请求付费”不仅仅是一个噱头，而是真正的操作现实。

背后的变化相当显著。

在过去，对API收费通常需要经过一整套“人性化”的流程：开设账户、链接账单、发放API密钥、设置限制、对账，然后处理支付权限。

对于人类来说，这已经相当烦人；对于代理来说，更是尴尬。

x402最吸引人的方面不是它更具加密性或更具人工智能，而是它试图将“付费访问”重新插入HTTP本身，使得访问控制和支付协商像正常的请求-响应一样进行。

服务器返回一个402，告诉你这个请求的费用；客户端支付后，再次使用支付凭证重试相同的请求。

如果从B2B软件和机器对机器访问的角度来看这个模型，它的流畅性远胜于零售视角。

此外，越是关注B2B，x402的优势就越明显，其缺点则不那么致命。

因为在消费者商业中，退款、拒付、商家记录、消费者保护和责任归属都是棘手的问题；但在B2B API和工具调用中，这些问题的重要性显著降低。

相反，“无账户，按次付费，获取结果后离开”是真实的需求。

零售无疑更大、更活跃，更容易吸引注意；但真正定义协议外观的场景往往不是最活跃的，而是那些首先暴露真实需求的场景。

对于今天的代理支付浪潮，这种场景可能不是购物车，而是软件、代理和工作流之间日益增多的付费访问。

4。行业发展验证了我之前对互操作性的判断。

我上一篇文章的核心判断是互操作性。

那时，这个判断听起来有点像“应该这样结构化”。

现在，它越来越像一种现实约束，因为开放市场已经在用脚投票。

Cloudflare没有选择一方，而是直接支持x402和MPP，同时明确进行兼容性映射。

谷歌正在参与x402，同时继续推进AP2和UCP。

Visa和Mastercard也没有以“全能赢家”的方式表达他们的战略；相反，他们都在加入x402，同时继续加大对代理令牌、身份验证、指令验证和争议信号的投入。

巨头们的多边押注是理性的决策，而不是商业虚伪。

为什么会这样？因为这些协议甚至不在同一层级上。

至少到目前为止，x402和MPP更接近于付费HTTP握手层，解决了“如何确保请求能够带回支付能力”的问题。

AP2更接近于授权和可信意图，解决了"这个代理是否有权支出这笔钱？"的问题。

UCP和ACP更像是工作流层，处理发现、结账、商家关系和凭证传输等问题，这些问题更接近于"谁控制流量和交易编排。"

许多同时支持x402、MPP、AP2和UCP的公司并不是因为他们自己不清楚，而是因为最终获胜的架构可能跨越多个层次，甚至可能需要多个协议共同形成。

因此，如果我用一句话来反思我之前的判断，我现在更强烈地相信，没有互操作性，这一生态波浪根本不会出现。

现在看来，市场正在积极验证这一判断。

此外，这一判断对于B2B与零售也很重要。

因为在零售世界中，它确实可能最终被少数大型平台和几个主要工作流所吸收；但B2B世界并非如此。

企业本质上存在于一个多云、多支付方式、多工作流系统和多身份权限系统共存的现实中。

任何试图使用新协议彻底改造整个企业堆栈的人都可能首先失败。

B2B客户真正愿意支付的往往不是"唯一正确的协议"，而是使现有系统在多协议环境中工作的能力。

正是这种逻辑使得互操作性在企业场景中比在消费者场景中更为关键。

5。这不仅仅是协议竞争，而是分层堆栈竞争。

一旦你将此事理解为分层堆栈，许多原本看似混乱的现象将立即变得明了。

底层是付费访问握手。

这一层涉及HTTP请求如何表达"这里需要支付"，以及客户端在支付后如何带回支付凭证。

x402和MPP主要在这里竞争。MPP试图将402正式化为更官方的HTTP认证语义；而x402则更侧重于将402平台化，使用自定义头、促进者、链上结算抽象和生态系统集成来首先使其运行。

一个更像是标准化的语义路线，而另一个则类似于平台分发路线。

上层是支出的权利，即"谁授权了这笔钱。"

这一层是许多人尚未完全意识到的关键。

机器支付并不困难；真正的挑战在于确保机器可以被信任为有权支出资金。

AP2之所以重要，正是因为它不仅解决了“如何支付”，还涉及到强制性、可验证的凭证、真实性和问责制。

Visa和万事达卡最近加大力度的代理令牌、指令验证、通行密钥和争议信号基本上都属于这一层。

下一层是工作流和分发。

这包括发现、结账、商家关系、凭证共享和人工智能表面集成——这些问题更接近于“谁控制流量和交易编排”。

UCP和ACP更像是在争夺这一层。

对于B2B而言，这一层在短期内可能不会那么活跃，但其长期价值可能非常高。

因为如果未来越来越多的企业软件由代理进行协调、调用、采购和支付，那么掌握工作流语言的人不仅仅是在管理单一支付，而是在管理整个工作流。

一旦你将这三层分开，你会发现一个非常简单的事实：没有必要期待单一协议覆盖所有问题。

更现实的路径是这三层分别发展，然后逐渐互操作。

因此，多头下注并不是优柔寡断，而是理性。

6。x402的真正风险可能不是监管，而是并发经济。

如果我们只承认“多协议的共存”，那仍然不够深入。

x402最大的风险可能主要不是监管，而是由两步验证-结算过程带来的检查时间/使用时间经济。

简单来说，如果支付的验证和最终结算不是同一回事，那么在高并发、重试、代理层和缓存层特征的真实互联网环境中，将会出现“支付一次，多次访问”的窗口。

x402生态系统目前也在修补漏洞，例如结算缓存、幂等性扩展和支付标识符，但这恰恰表明问题并不仅仅是理论上的。

为什么这对B2B读者特别值得注意？

因为B2B世界最害怕的不是无法制作出漂亮的演示，而是边缘案例太多，一旦投入生产，就开始出现漏洞。

API货币化表面上可能看起来像是每个请求支付几美分，这似乎很轻松；但一旦您的产品按调用、结果或工作流收费，那么"一次支付获得一个"或"一次支付获得多个"不仅仅是产品细节，而是生死攸关的问题。

因此，如果x402确实能够在B2B中起飞，一个重要的前提条件不是叙述，而是这些默认安全机制必须足够简单；否则，企业将不会感到安全地引入真实流量。

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

我认为在这篇文章中还有一点值得详细阐述。

许多开放协议最终到达一个非常熟悉的地方：协议本身变得越来越便宜，甚至免费，但真正的收费站将与之并存。

x402也不例外。

标准本身当然强调开放性、中立性和内置的0费用，但这并不意味着价值捕获会消失。

如果x402成功，价值将不会主要停留在协议内，而是会迁移到促进者、钱包、密钥管理、发现、政策引擎和信任包装等相邻层面。

这对B2B尤其重要。

因为企业客户不会为了一个新协议而大规模改造他们的整个系统；他们真正愿意支付的是谁能帮助他们整理多协议环境中的编排、政策、风险、合规、审计、结算和权限边界。

换句话说，协议将越来越像底层语言，但将这些语言翻译成"企业就绪"能力的能力将更容易成为新平台和新收费站。

这也是为什么我觉得在今天看待x402时，我们不应该仅仅关注Coinbase、Cloudflare或Stripe中谁更像"主角"。

真正值得关注的是谁在这些相邻层面上拥有最佳机会。

Cloudflare在边缘和流量分配方面占有一席之地，Stripe在支付基础设施和商家关系方面占有一席之地，Visa和Mastercard在凭证、网络令牌和消费者信任方面占有一席之地，而Google在工作流和发现表面方面占有一席之地。

真正的价值捕获可能不会发生在"谁定义了402"，而是在"谁将402集成到更大的企业系统中"。

8。结论

x402基金会并没有宣布x402在所有代理商业协议中已经获胜。

它公开承认这一代代理支付从第一天起就不会是单一协议的世界。

Coinbase将x402交给Linux基金会是为了使其更像一个中性的公共层，而不是一个独占的产品。

Stripe在加入x402时推动MPP并不是犹豫不决；而是因为它知道现在不应该只押注于一个方向。

Cloudflare同时支持这两种系统是因为它最接近真实流量。

像Google、Visa、Mastercard和Adyen这样的参与者的行为也表明了同样的事情：首先，让系统互操作，然后讨论谁最终占据哪个层。

如果我们将视角从零售转移开来，这一判断变得更加清晰。

因为第一个需要这些协议的可能不是购物车，而是越来越多按调用、任务或结果收费的B2B软件和服务。

零售当然更大，但B2B往往更早暴露出真实需求，并更早定义基础设施的最终形态。

在我上一篇文章中，我将互操作性置于中心，我相信市场的答案现在相当明确：是的，甚至比我当时想的还要早。

从这个意义上说，x402基金会并不是这个故事的终点。

它只是让我们更早地看到，真正的主题从来不是“谁会赢”，而是“这个世界注定要首先互操作，谁能在互操作之后占据最有价值的层。”