x402 和 MPP 不是竞争对手——它们在代理支付堆栈的不同层。
Source: Dev.to
Stripe 上周发布了微支付协议（MPP）。他们也是 x402 基金会的创始成员之一，基金会成员还包括 Coinbase、Google Cloud 和 Cloudflare。
“选边站队”的论调是错误的。这些协议在技术栈的不同层面解决不同的问题。
MPP 能解决什么
MPP 旨在处理 代理‑到‑商业 的流程。用户为一个受限令牌充值——可以把它想象成带有每个供应商消费上限的预付卡。代理使用该令牌代表用户付款：订阅、市场购买、用户明确授权的服务。
关键属性
- 用户出资 – 资金来自用户的钱包/账户，而不是代理。
- 受限授权 – 每个令牌仅限于特定供应商和金额。
- 支持循环支付 – 代理可以在授权范围内多次使用该令牌收费。
- 面向网页结算流程设计 – 替代购买流程中“人工输入卡号”的步骤。
这对面向消费者的代理使用场景非常有力。构建一个能够预订餐厅、购买商品、支付 SaaS 订阅的代理——MPP 正是你需要的。用户通过令牌范围保持控制，而代理则在这些约束内自主执行。
什么是 x402 解决的
x402 旨在用于 agent‑to‑infra 微支付。代理从自己的钱包为其交易提供资金；没有用户参与。
关键属性
- 代理出资 – 代理持有 USDC 并从自己的地址支付。
- 亚美分级别 – 如每次 API 调用 $0.01，每次数据获取 $0.001。
- 完全自治 – 每笔交易无需人工授权；代理根据任务逻辑决定支付。
- 原生 HTTP – 使用 402 响应码、
X-Payment头部，可在任何 HTTP 客户端中使用。
典型使用场景包括数据源、计算、监控和工具端点——任何需要人工授权每笔交易会破坏自动化价值的情况。
典型流程 (HTTP)
GET /api/v1/data
← 402 Payment Required (amount, address in headers)
← Agent signs USDC tx on Base L2
GET /api/v1/data + X-Payment-Proof header
→ 200 + data为什么它们是互补而非竞争
- MPP 的答案： 代理如何代表授权它的人花钱？
- x402 的答案： 代理如何为完成工作所需的工具和数据付费？
在电子商务网站上为用户购物的代理使用 MPP 进行购买——用户委托的商业。同一代理可能在给出购买建议之前，使用 x402 从数据端点获取当前价格数据——自主的基础设施访问。
一个构建良好的代理会同时使用这两种原语。
实际转化数据说明
我们已经运行了几个月的实时 x402‑受限市场。当前数据：
- 359 次探测 来自真实的代理流量
- 5 笔购买（全部来自代理测试和技能资产）
- **技能资产：**约 33 % 的转化率——代理以稳定的频率探测并付费
- **数据源资产：**约 0 % 的转化率——
defi-yields-live有 121 次探测，token-anomalies-live有 64 次探测，几乎没有购买
技能/数据之间的差距正在显现。技能资产价值有界且可预测——代理测试评估脚本执行固定操作，代理知道会得到什么。数据源则存在新鲜度模糊性——如果不知道数据有多陈旧，就无法自信地决定是否值得花 0.01 美元。
我们在 402 响应头中部署了 data_freshness_seconds 字段来解决此问题。现在代理在付款前可以准确看到数据的年龄。我们正在测量这是否能够缩小转化差距。
假设： 数据资产的 x402 转化率低是透明度问题，而非定价问题。如果假设成立，data_freshness_seconds 应该能将转化率从约 0 % 提升至约 10 %。如果不成立，我们将以不同的方式定价或打包数据。
MPP 并不改变上述任何内容——MPP 用于用户授权的购买，而非自主的探测后付费流程。探测我们端点的代理依据自身判断行动，资金来自各自的钱包。这属于 x402 的范畴。
实际要点
- Agent‑to‑infra，自治，子中心: 实现 x402。SDK 大约 30 行，协议已具备生产就绪能力，拥有 3500 万+ 交易。
- Agent‑to‑commerce，用户委托，循环: 关注 MPP。它是全新的，Stripe 在背后支持，解决了真实问题。
- 两者皆可: 随着你的代理产品成熟，你可能会同时需要两者。
技术栈正趋向于 infra 使用 x402，用户商务使用 MPP。选择适合你用例的方案，不要被讨论误导而延迟行动。
试用实时 x402 目录
npx skills add danielxri/clawmerchants-skills或直接在 . 浏览。探针端点免费——只有在你决定拉取数据时才收费。