AI代理支付：x402 vs. MPP

一键发币： x402兼容 | Aptos | X Layer | SUI | SOL | BNB | ETH | BASE | ARB | OP | Polygon | Avalanche

直到最近，API 收费的方式几乎只有一种：Stripe 订阅、API 密钥和月度发票。当注册的是人类开发者时，这个模式运作得很好。但 AI 代理不会填表，也不会管理计费仪表盘。

两种新协议正在竞相解决这个问题：

• Coinbase 的 x402 将支付直接嵌入 HTTP 请求，无需账户，无需设置。
• Stripe 的机器支付协议（Machine Payments Protocol，MPP），于 2026 年 3 月 18 日随 Tempo 主网推出，采用了一种不同的方法：基于会话的流式支付，并内置了 Stripe 的合规体系。

如果你正在构建或商业化 MCP 工具，这就是你现在需要做的决策。本文将详细介绍这两种协议，在开发者体验、成本、安全性和生态成熟度方面进行比较，并讨论传统计费在哪些场景仍然适用。

1、为什么传统计费模式不适用于 AI 代理

AI 代理在代我们执行任务方面已经变得非常出色：调用 API、查询数据库、编排多步骤工作流。但当代理需要为一个它未被预配置使用的服务付费时，整个体验就会崩溃。

传统流程（注册账户、生成 API 密钥、配置计费、管理订阅）是为使用浏览器的人类设计的。它需要有人创建客户账户、输入信用卡信息并管理仪表盘。自主代理无法做到其中任何一项。成本结构也不匹配：Stripe 的标准信用卡处理费约为每笔交易 2.9% + $0.30，这使得低于约 $1 的按请求计费变得不经济。当你的 MCP 工具每次调用收费 $0.01 时，$0.30 的固定费用是行不通的。

传统计费仍然有其用武之地。订阅、企业合同、开票、合规：这些都不会消失。如果你面向的是需要仪表盘和收据的人类团队，Stripe 的核心平台仍然是最佳选择。我们会在本文末尾再讨论它的适用场景。

但对于代理原生用例（自主发现、按请求微支付、无人类参与），2026 年真正的选择在两个专用协议之间：x402 和 Stripe 的 MPP。

2、x402：开放、简单的选择

x402 是一个开放协议（Apache 2.0，由 Coinbase 和 Cloudflare 共同创立的 x402 基金会治理），它重新利用了长期休眠的 HTTP 402（"Payment Required"）状态码。流程极其精简：

1. 客户端请求受保护的资源。
2. 服务器响应 HTTP 402 和机器可读的支付指令（价格、代币、链、收款钱包）。
3. 客户端在链上支付（通常是 Base 或 Solana 上的 USDC），将支付证明附加到重试请求中。
4. 服务器验证结算并返回响应。

无需账户、API 密钥或订阅。支付收据就是凭证。

对于 MCP 服务器，Vercel 构建了 x402-mcp：一个将 x402 协议封装到 Vercel AI SDK 中的 npm 包。它引入了 paidTool 原语，让你可以为任何 MCP 工具声明价格并在执行前要求支付。实际使用效果如下：

import { createPaidMcpHandler } from "x402-mcp";
import z from "zod";

const handler = createPaidMcpHandler(
  (server) => {
    server.paidTool(
      "weather_lookup",
      { price: 0.001 },                          // $0.001 per call
      { location: z.string() },
      async ({ location }) => {
        // your tool logic here
        return { temperature: 72, conditions: "sunny" };
      }
    );
  },
  { recipient: process.env.WALLET_ADDRESS }
);

export { handler as GET, handler as POST };

这是一个完整的付费 MCP 工具：模式验证、定价和支付执行都在一个声明中完成。在客户端，一个简单的包装器就能实现自动支付处理：

import { experimental_createMCPClient as createMCPClient } from "ai";
import { withPayment } from "x402-mcp";

const mcpClient = await createMCPClient({
  transport: new StreamableHTTPClientTransport(url),
}).then((client) => withPayment(client, { account }));

const tools = await mcpClient.tools();  // paid tools just work

虽然 x402-mcp 是在 MCP 中使用 x402 最便捷的方式，但协议本身与框架无关，拥有适用于 Express、Hono、Next.js 等框架的中间件。

x402 不是一个完整的支付平台。它不处理订阅、开票、客户管理、税务合规或退款争议。它是一个协议级别的按请求支付原语。

3、Stripe MPP：高吞吐量、内置合规的选择

MPP 于 2026 年 3 月 18 日随 Tempo 主网一同推出，由 Stripe 和 Tempo 共同编写。x402 要求每个请求进行一次区块链交易，而 MPP 引入了会话的概念：代理预先授权一个消费限额，然后持续对该会话流式支付微付款，无需为每次调用单独进行链上交易。

这对高频场景非常重要。如果你的代理每小时查询数据源数千次，你不会希望每次都签名并广播链上交易。会话通过聚合支付并批量结算来解决这个问题。

Tempo 的链是为此专门构建的。它每秒处理数万笔交易，具有亚秒级最终性，并且没有原生 Gas 代币；费用以稳定币支付。MPP 流入 Stripe 现有的 PaymentIntents API，因此商家可以获得欺诈检测（Radar）、税务处理和报告功能。

MPP 还与 Stripe 的 共享支付令牌（Shared Payment Tokens，SPTs）协同工作，意味着通过 MPP 支付的代理可以使用 Tempo 上的 USDC 或用户关联的 Visa 卡。这种混合法币 + 加密货币的能力是该方案的独特优势。

4、x402 vs. Stripe MPP：正面比较

4.1 开发者体验

x402 在代理支付领域的入门门槛最低。使用 x402-mcp 包，你只需定义一个带有价格的 paidTool，指向一个钱包地址，就完成了。在客户端，用 withPayment() 包装 MCP 客户端即可自动处理 402 握手。

MPP 需要 Stripe 集成，这意味着更多的设置工作（SDK、仪表盘、PaymentIntents）。但如果你已经在使用 Stripe，添加 MPP 更像是配置变更而非平台迁移。会话管理在客户端增加了一些复杂性，但作为回报，Stripe 处理结算、合规和报告。

4.2 定价模型

两种协议都针对按请求和微支付定价，但执行方式不同。

x402 将每个请求结算为独立的链上支付。简单、透明，但意味着每次调用都会产生区块链开销（尽管在 Base 上这个开销很小）。

MPP 在会话内聚合支付并批量结算。这使得它在高频场景中更高效，因为在数千次调用中每次交易的开销会累积。

4.3 成本结构

x402： Base 上的交易结算费用不到一分钱。没有平台费；只有名义上的区块链网络费用。一次 $0.01 的 API 调用总费用约为 $0.011。亚美分定价变得经济可行。

MPP： Tempo 没有原生 Gas 代币；费用以稳定币支付，设计上可以忽略不计。基于会话的聚合进一步降低了每次调用的开销。由于 MPP 结算进入 Stripe，商家获得 Stripe 的处理能力，但链上环节很便宜。

两者都比传统的信用卡处理便宜几个数量级。x402 和 MPP 之间的成本差异本身很小；更大的区别在于包含什么（MPP 捆绑了合规）与你需要自己构建什么（x402 留给你自己处理）。

4.4 安全与信任

这是两种方法在决策者眼中分歧最大的地方。

• x402 安全模型： 支付经过加密签名并在链上结算，提供最终性和透明度。没有退款；一旦支付，即已结算。但反面是：如果代理多付了钱或支付给了恶意端点，没有内置的追索机制。V2 规范（2025 年 12 月）引入了动态支付路由和模块化 SDK，扩展了功能但也引入了新的攻击面。动态路由意味着服务器告诉你的代理把钱发到哪里，如果不验证地址，就可能导致收款方被篡改。模块化 SDK 通过第三方插件引入了供应链风险。生产部署需要：收款方白名单、每个会话和每个代理的预算上限、速率限制、链验证，以及异常支出的监控。像 PaySentry 这样的工具正在涌现以填补这一空白，但该领域仍不成熟。
• Stripe MPP 安全模型： 会话提供内置的消费限额。Stripe 的合规体系（Radar 欺诈检测、PCI、税务）适用于 MPP 支付。SPTs 按商家、时间和金额限定凭证范围，防止代理支出失控。权衡在于对 Stripe 和 Tempo 作为中介的依赖。你信任他们的基础设施，而不是自己构建控制措施。

4.5 生态与采用：现实检验

两种方法背后的机构动力令人印象深刻。但实际使用数据讲述了一个更为克制的故事。

• x402： Coinbase 报告其 Agentic Wallets 基础设施累计处理了超过 5000 万笔交易。然而，链上分析描绘了更微妙的画面：截至 2026 年 3 月初，日交易量约为 131,000 笔交易，价值约 $28,000，平均支付 $0.20。大约一半似乎是测试或游戏化活动，而非真实商业活动。真实的生产用户包括 Neynar（社交数据查询）、Hyperbolic（GPU 推理）和 Token Metrics（加密分析）。x402 基金会（Coinbase + Cloudflare）以及被纳入 Google 的 AP2 倡议提供了强大的机构支持。Stripe 也提供原生 x402 集成，因此商家可以通过现有 Stripe 仪表盘接受 x402 支付。
• MPP： 2026 年 3 月 18 日刚发布几天。Tempo 列出了与 Anthropic、DoorDash、Mastercard、Nubank、OpenAI、Ramp、Revolut、Shopify、Standard Chartered 和 Visa 的合作。发布时支付目录中有超过 100 个服务，包括 Alchemy、Dune Analytics 和 Merit Systems。现在还太早没有有意义的交易量数据，而发布时的"合作"可能意味着从签署意向书到实际生产流量之间的任何程度。

两者都处于早期阶段。基础设施正由严肃的参与者铺设，但大规模的代理支付交易量仍在未来而非过去。

5、混合路径：结合 x402、MPP 和传统计费

对许多团队来说，正确的答案不是单一协议。最务实的架构是针对不同受众使用不同的支付路径：

• x402 用于进行一次性或低频调用的自主代理（无许可、无设置）
• MPP 用于受益于聚合和 Stripe 合规性的高频代理会话
• Stripe 传统 用于需要订阅、发票和仪表盘的人类客户

以下是混合中间件的实际实现方式（伪代码）：

async def authenticate(request):
    # Path 1: Stripe API key (human customer with subscription)
    api_key = request.headers.get("Authorization")
    if api_key and verify_stripe_key(api_key):
        record_stripe_usage(api_key)
        return "stripe_subscription"

    # Path 2: MPP session token (high-frequency agent)
    session = request.headers.get("X-MPP-Session")
    if session and verify_mpp_session(session):
        debit_session(session, tool_price)
        return "mpp"

    # Path 3: x402 payment receipt (autonomous agent, one-off)
    receipt = request.headers.get("X-Payment-Receipt")
    if receipt and verify_onchain(receipt):
        return "x402"

    # Path 4: no credentials; return 402 with payment options
    return Response(
        status=402,
        headers={
            "X-Payment-Amount": "10000",    # 0.01 USDC
            "X-Payment-Token": "USDC",
            "X-Payment-Chain": "base",
            "X-Payment-Address": "0xYourWallet...",
        },
    )

一个中间件，多种验证路径。人类团队获得发票和仪表盘。高频代理获得会话效率。一次性代理获得无许可访问。没有受众被排除在外。

这也是 Stripe 的立场：他们通过独立的集成路径支持 x402、MPP 和传统计费，所有结算都进入同一个商家仪表盘。他们的策略是拥有抽象层，让协议在底层竞争。如果你不想押注单一协议，以 Stripe 作为结算层可以保持你的选择开放。

如果你现在正在构建 MCP 服务器，这意味着：

• x402 是最快的起步方式。 通过 x402-mcp，paidTool 抽象简洁且 MCP 原生。如果你的工具执行离散的、有界的工作（搜索、查询、转换、生成），在每次调用上放置 $0.001 到 $0.01 的价格现在是一条现实的商业化路径，代码量极小。
• 如果你预期高频代理流量，MPP 值得关注。 如果你的 MCP 工具在每个会话中被调用数百次（数据源、监控、持续查询），基于会话的聚合避免了每次调用的区块链开销。Stripe 集成意味着你无需自己构建就能获得合规和欺诈防护。
• 你需要围绕 x402 自行构建运营基础设施。 如何处理退款？监控？失控代理支出的速率限制？密钥管理？这些在 x402 中都是你的问题。MPP 将大部分工作委托给 Stripe。
• 无论哪种方式，定价模式的转变都是真实的。 从订阅转向按请求计费改变了你对产品的思考方式。你不再销售访问权限；你在为单个工作单元定价。这需要了解你每次调用的成本、每次调用的价值，以及不同价格点的需求弹性。这更像是为无服务器函数定价，而不是为 SaaS 席位定价。
• 你的用户需要加密钱包（目前而言）。 x402 需要 Base 或 Solana 上的 USDC。MPP 需要 Tempo 上的 USDC（或通过 SPTs 使用法币）。对于开发者与开发者、代理与代理的场景，这越来越正常。对于主流采用，钱包入驻仍然是一个摩擦点，尽管 Coinbase 等公司的托管钱包解决方案正在缩小差距。

6、x402 和 MPP 常见问题

x402 真的会取代 API 密钥和订阅吗？

不会全面取代，可能也不会很快。x402 在自主的、按需工具访问这一特定场景中消除了对 API 密钥的需求。但订阅的存在是有原因的：它们为提供商提供可预测的收入，为消费者提供可预测的成本。特别是企业买家，重视约定定价和开票。更有可能的是，x402 开辟了一个新的访问层级（随意的、探索性的、代理驱动的），它与现有计费并存而非取代。可以将其理解为按次付费和流媒体订阅之间的关系：不同的消费模式对应不同的模型。

开发者体验在实践中如何比较？

对于按请求 MCP 工具支付这一狭窄场景，x402（通过 x402-mcp）要简单得多。五行服务器代码、一行客户端包装器，你就在收款了。MPP 增加了会话管理，但作为回报提供了 Stripe 的完整技术栈。开发者体验的问题实际上是：你实际需要支付技术栈的多少？如果答案是"按调用收费就行，其余的我自己处理"，x402 胜出。如果答案是"按调用收费加上欺诈防护、税务合规和报告"，MPP 胜出。

自主代理支付的真正安全风险是什么？

核心风险是拥有钱包访问权限的代理可以以机器速度花钱，包括在恶意或定价过高的端点上。对于 x402：V2 的动态路由意味着服务器告诉你的代理把钱发到哪里，如果你不验证地址，就可能导致收款方被篡改。基于会话的身份可能被劫持。模块化 SDK 通过第三方插件引入供应链风险。生产部署需要收款方白名单、每个会话和每个代理的预算上限、速率限制、链验证（防止 Gas 费操纵）以及异常支出模式的监控。MPP 的会话模型通过设计缓解了其中一些问题（内置消费限额、Stripe Radar），但引入了对 Tempo 和 Stripe 作为中介的信任依赖。

监管和税务影响呢？

x402 支付以 USDC 结算，这意味着你收到的是加密货币。根据你所在的司法管辖区，这具有税务报告影响（资本利得处理、收入确认、报告阈值）。如果适用，你还需要自行负责 KYC/AML 合规。x402 目前还没有 IETF RFC，这意味着多个实现可能会碎片化。MPP 通过 Stripe 结算，后者自动处理税务、合规和报告。如果你处于受监管的行业，MPP 在没有原始 x402 合规负担的情况下为你提供了微支付能力。

x402 只适用于加密原生团队吗？

越来越不是了。协议本身与支付网络无关，设计上将在未来支持非加密支付方式。但今天，生产实现在 Base 或 Solana 上的 USDC 中结算。Coinbase 等公司的托管钱包解决方案正在降低加密知识门槛，Stripe 自己的 x402 预览意味着你可以使用熟悉的 Stripe 工具接受 x402 支付。话虽如此，如果你的团队完全没有加密经验，预计在钱包管理、密钥安全和链上监控方面会有学习曲线。MPP 可能是更容易的入门路径，因为它将加密货币包装在 Stripe 熟悉的界面中。

x402 和 MPP 之外的竞争格局如何？

Google 的 AP2（Agents Payment Protocol）使用基于授权的系统，用户以细粒度控制委派消费权限。Visa 和 Mastercard 正在开发自己的代理支付标准，并计划使其成为 AI 代理交易的强制要求。学术研究（例如 2026 年 3 月的 A402 论文）正在提出更复杂的基于通道的协议，以解决 x402 的原子性限制。该领域仍处于早期和碎片化阶段；预计会有整合，但也预计 x402 的开放性和 MPP 的 Stripe 背书将使两者保持相关性。

采用程度有多真实？我应该等待吗？

交易量仍然很小。截至 2026 年 3 月初，x402 的日链上活动约为 131,000 笔交易，价值约 $28,000，其中相当一部分是测试活动。MPP 几天前刚发布；现在还没有真实数据。但基础设施正由严肃的参与者铺设（Coinbase、Cloudflare、Stripe、Tempo、Google、Visa）。问题不在于代理支付是否会变得重要；而在于何时。从 x402 开始成本低、承诺少（几行代码、一个钱包地址）。你可以随着需求的发展叠加 MPP 或传统 Stripe。当代理到来时做好准备几乎没有坏处。

7、结束语

截至 2026 年 3 月，代理支付领域有两种专用协议在不同的优势上竞争：

• x402 是最简单、最开放、最无许可的选择。适用于：按请求微支付、自主代理访问、无供应商锁定的架构，以及愿意自行管理安全和合规的团队。
• Stripe MPP 是内置企业合规的高吞吐量选择。适用于：高频代理会话、混合法币 + 加密支付，以及希望获得 Stripe 的欺诈检测、税务处理和报告而无需自行构建的团队。

这两者并不互斥。Stripe 通过不同的集成路径支持两者（加上传统计费），结算到同一个仪表盘。最有远见的团队会像对待计算基础设施一样对待支付协议选择：为每个工作负载选择合适的工具，并设计系统以支持不止一种。

代理支付的未来不是一个协议统治一切。它是一个分层模型，最优秀的团队会像选择技术栈中的其他一切一样慎重地选择支付基础设施。

原文链接: x402 vs. Stripe MPP: How to choose payment infrastructure for AI agents and MCP tools in 2026

DefiPlot翻译整理，转载请标明出处

免责声明：本站资源仅用于学习目的，也不应被视为投资建议，读者在采取任何行动之前应自行研究并对自己的决定承担全部责任。