x402、AP2、MPP、TAP：四种代理支付标准及你的技术栈实际需要哪一个

如果你在 2026 年试图理解代理支付，你会遇到一堆缩写词。Coinbase 的 x402。Google 的 AP2。Stripe 和 Tempo 的 MPP。Visa 的 TAP。每个发布声明都暗示这是一场赢家通吃的竞赛，而每篇对比文章读起来都像你必须押注其中一个。

这种框架是错误的，它会引导你构建错误的东西。这四个标准并非同一个问题的四个答案。它们位于代理支付栈的不同层级。一个证明代理是谁。一个证明用户允许了什么。两个则以不同方式实际转移资金。如果你把它们当作竞争对手来挑选，要么你会拼凑一些不需要的东西，要么你会错过一个必要的层级。

这是面向构建者的版本。我们将用通俗易懂的语言定义每个标准，展示代表性代码片段，使差异具体化，将它们并排比较，逐一分析安全陷阱，最后根据你实际构建的内容给出一个简单的决策指南。

这四个标准是竞争对手还是不同层级？

它们是不同层级，而非竞争对手。TAP 回答“这是一个代表真实用户的合法代理吗”。AP2 回答“用户实际授权了什么”。x402 和 MPP 回答“资金如何流动”，其中 x402 处理按请求的稳定币支付，MPP 处理更广泛的模式如订阅和多代理结算。一个真实的消费者商务栈通常同时使用多个标准。正确的问题不是哪个会赢，而是你在解决哪个层级的问题。

记住这张图，困惑就会消散。

想象一个代理为用户购买东西。必须满足四个独立的条件。商家必须相信代理是真实的，而不是爬虫。系统必须证明用户同意此次购买。支付必须实际结算。而对于持续的关系，计费必须安全地重复进行。

每个标准负责其中一项工作。它们被设计为可组合的，主要参与者已公开承诺可以实现互操作。因此，决策取决于你的工作负载，而非对某个供应商的忠诚。

什么是 x402，何时需要它？

x402 是一种按请求支付的结算协议。它使用 HTTP 402 状态码，使代理无需账户或银行卡即可用稳定币支付单个 API 调用或资源。代理发出请求，收到附带条件的 402 响应，签署稳定币转账，然后重试。它在几秒内完成结算，成本不到一分钱。当软件为许多小东西（如 API 调用、数据或计算）向软件付费时，你需要 x402。

x402 是机器对机器的微支付轨道。它在银行卡失效的场景下大放异彩：双方之间数千笔低于一分钱的支付，且双方之前没有关系。

一个最小的付费端点只需几行代码。处理程序仅在支付清算后运行。

import express from "express";
import { paymentMiddleware } from "@x402/express";
const app = express();
app.use(paymentMiddleware(
  { "GET /data": { accepts: [{ scheme: "exact", price: "$0.001",\
    network: "eip155:8453", payTo: "0xYourAddress" }] } },
  server
));
app.get("/data", (req, res) => res.json({ result: "paid content" }));

当你的客户是另一个软件、单价极小且账户只会碍事时，选择 x402。

什么是 AP2，何时需要它？

AP2，Google 的代理支付协议，是授权层。它不移动资金。它生成一个加密签名的授权书，捕获用户授权的内容：意图、购物车和消费条件。它与支付方式无关，因此同一授权书可以通过 x402 扩展在银行卡、银行轨道或稳定币上结算。当你必须证明人类确实同意了代理的行为时，你需要 AP2。

AP2 回答了使代理支付合理化的同意问题。授权书由用户提前签名，并随行动一起传递。

授权书是一个描述授权的签名对象。

const mandate = {
  principal: "user:8842",
  agent: "agent:shopper",
  intent: { category: "appliances", maxPriceUsd: 100 },
  constraints: { perTxUsd: 100, dailyUsd: 300, expiresAt: "2026-07-31T00:00:00Z" },
};
const signed = await user.sign(mandate); // 随购买请求一起传递，作为同意证明

当你需要一份可验证的记录来证明是用户（而非模型）授权了支出，尤其是在跨多种支付方式结算时，选择 AP2。

什么是 MPP，何时需要它？

MPP，Stripe 和 Tempo 提出的机器支付协议，也是一种结算标准，但它涵盖比 x402 更广泛的支付模式。x402 围绕单次按请求支付构建，而 MPP 处理定期计费、订阅、按用量计费以及跨多个代理的协调结算。当关系是持续性的而非一次性时，例如代理订阅的按用量服务或需要共同结算的多代理工作流，你需要 MPP。

MPP 和 x402 是互补的，而非竞争对手。一个是单次点击；另一个是长期关系。

将 MPP 安排视为带有规则的重复授权，而非一次性支付。

const subscription = {
  payer: "agent:research-bot",
  payee: "service:market-data",
  plan: { model: "metered", unit: "query", priceUsd: 0.002 },
  caps: { monthlyUsd: 50, autoRenew: true, revocable: true },
};

当支付重复、按量计费或跨越多个需要集体结算的代理时，选择 MPP，因为单次按请求支付无法体现这种关系。

什么是 TAP，何时需要它？

TAP，Visa 的可信代理协议，是身份与信任层。它也不移动资金。它将代理的身份加密签名到 HTTP 请求头中，使商家能够实时验证该代理是代表真实用户的合法注册参与者，而非爬虫。它使用签名后的 HTTP 消息，并与 Visa 运营的目录进行校验，同时在银行卡轨道上提供欺诈和拒付保护。当代理在商家网站购物且必须在入口处获得信任时，你需要 TAP。

记住我以便更快登录

TAP 解决了商家最关心的一个问题：将真正的购物代理与机器人区分开来，因为合法代理在老式防御系统看来就像机器人。

在实践中，TAP 将签名头附加到代理的请求中。签名绑定到商家域和具体操作，有时效限制，且无法重放。

Signature-Agent: "https://agent-operator.example/keys"
Signature-Input: sig1=(...); keyid="agent-123"; tag="agent-payer-auth"; created=...; expires=...
Signature: sig1=:Ed25519signatureOverCanonicalRequest:

在请求被信任之前，商家或其边缘服务提供商会根据目录验证该签名。当你的代理在传统银行卡轨道上进行交易，且商家需要欢迎它而不将其标记为欺诈时，选择 TAP。

这四个标准一目了然如何对比？

一目了然：TAP 是身份，AP2 是授权，x402 和 MPP 是结算。TAP 和 AP2 在资金转移前证明身份和授权；x402 结算单次稳定币支付，而 MPP 处理重复和多代理结算。TAP 和 AP2 是与支付方式无关的信任层，x402 原生支持稳定币，MPP 覆盖多种模式。大多数严肃的栈会组合一个信任层、一个授权层以及一到两个结算轨道，而不是选择单一标准。

表格让要点一目了然。其中两个建立信任和授权，两个移动资金，并且它们被设计为可叠加。

这些标准有哪些安全考量？

核心风险是混淆层级。已验证的身份并非授权，授权也非结算。必须独立验证每一项。对于 TAP 和 AP2，陷阱是重放、过于宽泛的授权书以及信任中心化目录。对于 x402 和 MPP，陷阱是没有原生退款、长期重复授权、促进者信任以及密钥作用域。将所有签名凭证视为有时限、窄范围且可撤销的，切勿让一个层级的检查替代另一个层级。

最常见的错误是将某个层级通过的检查视为另一个层级的许可。

TAP 签名证明代理的身份属实。它并不证明用户批准了此次具体购买——那是 AP2 的工作。两者都不证明资金到位，那是结算的工作。在行动之前，分别验证所有三个。

在信任层，严格限定范围并尊重过期时间。签名凭证应绑定到特定操作和域、有时限且无法重放——这些标准都支持，但你的实现必须实际执行。另外，请记住，供应商运营的代理密钥目录既是一种便利，也是一个控制点，因此要为未来的联邦化做打算，并监控你所依赖的内容。

在结算层，尖锐的边角是熟悉的。x402 没有协议层面的退款，因此要使处理程序幂等，并通过交易哈希记录每笔结算。MPP 的重复授权功能强大但也危险，因此要设置上限、使其可撤销，并在异常漂移时发出警报。在这两者中，代理的密钥应该限定作用域、保持低余额、定期轮换，且绝不提交到仓库，因为泄露的代理凭证仍然是资金损失的主要原因。

你的栈实际需要哪个标准？

将标准与你的工作负载匹配。如果软件为小型 API 或数据调用向软件付费，你需要 x402。如果这些支付重复或按量计费，添加 MPP。如果代理在商家网站使用银行卡轨道购物，你需要 TAP 用于身份，AP2 用于授权。如果你必须跨任意支付方式证明用户授权，你需要 AP2。大多数消费者商务构建最终是组合一个信任层、一个授权层和一个结算轨道，而非选择其中一个。

使用以下作为快速决策指南：

• 你正在构建机器对机器的 API 或数据货币化，单价低于一分钱？从 x402 开始，如果支付重复或按量计费，添加 MPP。
• 你的代理在商家网站使用银行卡支付购物？你需要 TAP 使商家信任代理，再加上 AP2 以便用户同意可证明。
• 你跨多种支付方式结算，并需要一份适用于所有方式的统一授权记录？AP2 是你的授权层，结算轨道按方法选择。
• 你的工作负载是持续服务、订阅或多代理结算？MPP 适合单个 x402 调用无法覆盖的场景。
• 你正在构建一个严肃的消费者商务代理？假设你将组合三个层级：身份、授权和结算。从一开始就做好规划。

如果你能将你的用例放在上述列表中，你就已经知道了答案，通常是一个小组合而非单一选择。

停止挑选赢家。选择你需要的层级。

2026 年的代理支付标准看起来像一场竞争，因为它们确实以竞争方式推出——竞品新闻稿和重叠的合作伙伴名单。但在营销表面之下，它们是合作性的。TAP 证明身份，AP2 证明授权，x402 和 MPP 转移资金，并且生态系统已刻意将它们设计为可互操作。

对于构建者来说，这令人解放。你不是在押注哪个标识会赢。你是在审视自己的工作负载，识别它触及哪些层级，并组合最小的一套标准来覆盖它们。机器对机器的 API 几乎只需要 x402。消费者购物代理则需要完整的信任、授权和结算栈。

将你的用例映射到各层级，独立验证每一项，你将构建一个既在当下正确、又为未来哪个标准成为主流做好准备的代理支付系统。赢家和输家会自行分化。你的架构不应依赖于结果。

选择并连接这些层级的正确组合，并将身份、授权和结算作为独立检查进行验证，正是决定代理支付栈是安全还是脆弱的集成工作。这就是我们做的工作。

• 原文链接： medium.com/@ancilartech/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～