x402、MPP、AP2、ACP、UCP 和 Visa TAP：它们在竞争什么？

如果你想让 Agent 帮你买一份数据或一件商品，很快就会看到一串缩写：x402、MPP、AP2、ACP、UCP、TAP。它们都与 Agent 交易有关，却不能简单放进同一个排行榜。

先问具体问题：你在购买的是一次 API 访问，还是一件需要配送的商品？你需要的是付款交互、购物车管理、授权证明，还是识别访问网站的 Agent？问题不同，协议的作用也不同。

本文依据公开资料比较协议关注点，不代表任何组合已经实际部署或互通。资料查阅日期：2026 年 10 月 28 日。协议和产品会变化，项目接入前应重新核对版本。

六个名字，各自主要解决什么？

名称	主要关注	典型问题	不应直接推断
x402	付费资源请求与支付交互	API 如何返回付款要求并处理支付凭证？	自带用户预算与完整售后
MPP	机器支付交互及计费模式	一次请求、会话或订阅如何协调付款？	与所有 x402 客户端天然互通
AP2	Agent 购买及支付的可验证授权	参与方如何验证用户授权与交易约束？	它本身是钱包或资金网络
ACP	Agent 与商家的商业和结账流程	如何同步购物车、订单和支付信息？	实施后自动进入所有 AI 平台
UCP	商业能力发现、协商与交易生命周期	平台如何发现并调用商家支持的能力？	所有 UCP 交易都可无人确认
Visa TAP	可验证的 Agent 识别及相关信息	商家如何判断访问请求的来源和意图？	识别 Agent 等同于批准付款

这个表概括的是侧重点，并非严格的分层标准。协议范围有重叠，也可能扩展；评估具体系统时要看对应版本及实际接入。

放进两种交易，看差别

场景一：Agent 支付一次 API 请求

flowchart LR U[用户设定预算] --> A[Agent 请求数据] A --> P[x402 或 MPP 协调付费请求] P --> W[兼容的钱包或支付方法] W --> S[服务方按条件交付]

这里最直接的问题是资源访问和付款交互，x402 和 MPP 都可能成为候选，存在应用场景的重叠。选择时比较实际 SDK、支付方法、网络、计费方式、费用和支持方。共同使用 HTTP 402 并不保证实现互通。MPP 的 mppx SDK 宣布支持兼容的 x402 exact 流程，是具体兼容实现的例子，仍需核对配置和范围。MPP 对 x402 的支持预算与密钥控制需要额外设计。x402 HTTP 规范、MPP 会话

场景二：Agent 购买需要配送的背包

flowchart LR A[用户表达需求] --> B[Agent 与商家协商商品和结账] B --> C[用户确认或验证可用授权] C --> D[提交支付并创建订单] D --> E[配送与订单状态]

在这个场景中，ACP 或 UCP 可能承担商业交互；AP2 可能提供可验证授权；商家也可能使用 TAP 类机制识别访问的 Agent。这只是按功能说明可能的组合，不表示这些具体协议一定被同一家平台同时使用。 UCP 官方明确提供 AP2 Mandates 扩展，是有文档依据的组合例子。UCP 与 AP2

有重叠，也有互补

x402 与 MPP 都处理机器对付费资源的访问，存在直接比较空间。需要对比的是具体支持的支付方法、计费模型和接入体验，而不是仅按名称判断谁更先进。

ACP 与 UCP 都覆盖 Agent 商业和结账流程，也存在商家与平台的接入选择。需要具体核对平台覆盖、商家系统、版本、功能与支付处理方。一个实现支持其中之一，不自动意味着支持另一个。ACP 规范、UCP 核心概念

AP2 与商业协议 更容易体现互补：AP2 记录和验证授权，商业协议管理结账交互。但授权凭证是否可用，依赖商家、平台和支付方共同实现并建立信任。AP2 规范

TAP 与结账协议 可能共同使用：前者帮助识别和验证请求，后者处理商品与订单交互。签名验证成功，不代表购买内容、预算和银行卡交易都已获批准。Visa TAP 规范

一张实际选型清单

先定任务：是一次付费 API 调用、持续计量服务，还是包含运费的商品结账？
再定参与方：谁提供 Agent、钱包、商家服务、支付处理和用户确认界面？
核对兼容：双方支持哪些协议版本、扩展、资产、网络与支付方法？
核对控制：预算由谁执行？谁持有签名密钥？授权如何到期或撤销？
验证失败：超时、拒付、付款后未交付、重复请求如何查询与处理？
算完整成本：除协议集成外，考虑处理费用、网络费、退款、人力和运营。

协议能减少双方沟通成本，但只有在双方实际支持、权限得到执行、交易和交付结果可追踪时，才形成可用产品。