Agent 支付基础设施全景：从 HTTP 402 到机器对机器经济

距离研究 ACP 过去 7 个月，上个月我的服务获得第一笔来自 Agent 的自动付款，本月我的 Agent 完成第一次自助支付，两件事意义重大，故写此文，系统梳理面向 Agent 的支付基础设施全景。

正在发生的金融基础设施变革

2026 年 3 月，Stripe 宣布与 Tempo 联合推出 Machine Payments Protocol（MPP），一个专为 AI Agent 设计的开放支付标准。同一时期，Coinbase 在持续推进基于 x402 协议的稳定币支付生态，Google 联合多家科技公司推出 AP2（Agent Payment Protocol），OpenAI 与 Stripe 共同设计了 ACP（Agentic Commerce Protocol）。

这些动作并非巧合，它们指向同一个方向：当前互联网的金融基础设施，完全不是为 AI Agent 设计的，而这个问题正在变得无法忽视。

互联网的商业模式从 1995 年诞生那一刻，就默认用户浏览免费。平台依靠广告变现，内容平台靠订阅维持，搜索引擎靠用户行为数据分发广告。然而，当 AI 成为互联网的主要内容消费者，它不看广告、不为品牌曝光付费、只抓取内容转化为知识------这套逻辑开始从根基动摇。

更深层的矛盾在支付侧。每当我们用支付宝或 VISA 完成支付，背后一套复杂的风控体系正在识别和对抗机器行为。然而，AI Agent 的支付行为从第一天起，就站在了现代支付系统的对立面。Agent 不会在手机上按按钮，不会等验证码，不会扫二维码------它无法进入人类支付体系的合法流程。

从风控模型的角度看，每一个 AI 的支付行为都是可疑的；从 AI 自己的角度看，每一个人类支付流程都是无法执行的。

这种结构性断裂，正在催生一套全新的支付基础设施。

HTTP 402：沉睡三十年的协议复活

要理解 Agent 支付，必须从一个极具历史感的技术细节说起：HTTP 状态码 402。

在 HTTP 协议的设计中，402 是"Payment Required"（需要付款）的状态码。它在 1991 年就写入了 HTTP/1.0 规范，原本预留给未来的收费网络服务------但在互联网以免费为基础的三十年发展中，这个状态码从未被真正启用，只是在规范文档里沉睡。

现在，它被唤醒了，成为机器支付的天然载体。

MPP 和 x402 协议的核心机制，都建立在 HTTP 402 之上：

Agent 请求付费资源：向 API、MCP 端点或任何 HTTP 地址发送请求
服务返回 402 响应：附带支付要求（金额、接受的支付方式、收款地址）
Agent 授权支付：使用预配置的支付凭证完成支付
Agent 重试请求：携带支付证明，服务验证后返回资源

整个流程是机器对机器的，无需人类干预。这正是它与现有支付流程的根本差异------没有跳转页面，没有短信验证码，没有人脸识别，只有一次标准化的 HTTP 往返。

复制代码

客户端                      服务端
  |                           |
  |------ GET /resource ----> |
  |                           |
  |<----- HTTP 402 ---------- |
  |   { "amount": "0.01",     |
  |     "currency": "usd",    |
  |     "recipient": "..." }  |
  |                           |
  |  [Agent 完成支付]          |
  |                           |
  |------ GET /resource ----> |
  |   Authorization: Bearer   |
  |   <payment-proof>         |
  |                           |
  |<----- HTTP 200 ---------- |
  |   { data: "..." }         |

这个设计的优雅之处在于，它完全兼容现有的 HTTPS 基础设施，不需要任何新的网络层协议，只需在应用层加入支付逻辑。

三大协议格局：谁在定义 Agent 支付的标准

当前 Agent 支付领域已经形成了三条主要技术路线，各有侧重，背后的推手也各不相同。

MPP：Stripe 与 Tempo 的机器支付协议

Machine Payments Protocol（MPP）由 Stripe 和 Tempo 联合设计，于 2026 年 3 月正式发布。其定位是"机器对机器支付的开放互联网原生标准"，核心使命是让 Agent 能够以编程方式支付 API 调用、工具调用或内容访问。

MPP 的技术架构支持两种支付方式的统一：

加密支付：直接链上支付，通过 Tempo 区块链上的稳定币（USDC）完成，适合低金额高频交易
法币支付：通过 Shared Payment Tokens（SPT）机制，支持信用卡、BNPL 等传统支付方式，适合需要更广泛支付方法的场景

对于 Stripe 上的商家，接入 MPP 只需几行代码：

复制代码

const paymentIntent = await stripe.paymentIntents.create({
  amount: 1,
  currency: "usd",
  payment_method_types: ["crypto"],
  payment_method_data: {
    type: "crypto",
  },
  payment_method_options: {
    crypto: {
      mode: "deposit",
      deposit_options: {
        networks: ["tempo"],
      },
    },
  },
  confirm: true,
});

MPP 已有一批早期落地案例，展示了其应用场景的多样性：

Browserbase：无头浏览器基础设施提供商，Agent 现在可以按 session 付费启动浏览器实例
PostalForm：Agent 付费打印和邮寄实体邮件
Prospect Butcher Co.：Agent 可以在纽约市任意地点下单订三明治
Parallel Web Systems：Agent 按 API 调用次数付费访问互联网，创始人 Parag Agrawal 表示："几行代码就集成了机器支付，现在 Agent 可以自主为每次 API 调用付费"
Stripe Climate：Agent 可以程序化地向气候捐款项目捐款

这些案例的共同点是：支付作为 Agent 任务执行链条中的一个原子动作，而非需要人类干预的异步步骤。

x402：Coinbase 主导的链上支付协议

x402 协议由 Coinbase 主导推进，以 Base 链和 USDC 稳定币为核心，目标是让每一次 HTTP API 调用都能承载支付行为。

x402 的生态格局可以用四方博弈来理解：

供应方（卖家） 分为两类：第一方卖家是直接出售自身数据或服务的项目（比如新闻网站要求 AI 爬虫付费访问内容）；第二方是 API 集市，整合多种 API 并提供统一支付入口，类似于早期互联网时代的 API 聚合器。

需求方（买家） 主要是 AI Agent，但真实需求仍处于早期阶段，大部分交易仍属测试性质。要点燃需求，需要两个条件：独家高价值内容（只通过 x402 提供），或足够丰富的 x402 支持 API 生态。