x402、UCP、ACP 与 MPP 经常被一起归入“agent commerce”，但它们解决的并不是同一个问题。
有的负责零售结账，有的让软件为一次 API 请求付款；有的覆盖完整商业生命周期，有的聚焦机器原生支付。如果把它们当成可互换标签，会造成错误架构；如果只发布空壳元数据，还会制造虚假的能力信号。
第一个问题不是选择哪个缩写，而是：你的网站是否真的有一笔应该允许外部 agent 完成的交易？
快速对比
| 协议 | 主要任务 | 最适合的交易 | 发现或接口 | 不能替代 |
|---|---|---|---|---|
| x402 | 为 HTTP 资源收费 | 付费 API、工具调用、数据或内容请求 | HTTP 402 Payment Required 与支付 headers | 商品目录或零售结账 |
| MPP | 协调机器到机器支付 | API、MCP 工具、周期性或按次服务 | HTTP 支付 challenge 与 authorization | 商品发现或商家运营 |
| ACP | 执行 agent 辅助卖家结账 | 购物车、配送、税费、凭证与完成交易 | 商家 checkout API 与 extensions | 搜索可见性或商品数据质量 |
| UCP | 连接更广泛的商业生命周期 | Catalog、cart、identity、checkout 与 order | /.well-known/ucp、能力协商、REST/MCP/A2A/embedded | 已部署的商业后端 |
| AP2 | 证明用户意图与支付授权 | 有人或无人值守的授权购买 | 签名 mandates 与 verifiable credentials | 结账、支付处理或商品数据 |
P3 的主比较是 x402、UCP、ACP 与 MPP；这里加入 AP2，是因为它经常作为相邻的授权层出现。
x402：为一个 HTTP 资源付款
官方 x402 文档 定义了面向 API 和内容的 HTTP 原生支付流程：客户端请求资源，服务端返回带支付指令的 402 Payment Required，客户端授权并重试，服务端验证或结算后交付资源。
当售卖单位本身就是 HTTP 请求时，x402 比较匹配：
- 一次 API 调用
- 一次数据查询
- 一次模型或工具调用
- 一次付费内容响应
- 按量计费的机器服务
当前 x402 文档描述的是 crypto-native payment，V2 使用 PAYMENT-REQUIRED、PAYMENT-SIGNATURE 和 PAYMENT-RESPONSE 等 headers。这与包含库存、配送、税费、退货和客服的常规零售结账不同。
不要为了显得“agent ready”而发布假的 402 响应。真实实现需要价格、资产与网络、幂等、结算验证、收据、退款、rate limit 和滥用控制。
MPP：面向 HTTP 服务的机器支付
MPP 是 Tempo 与 Stripe 共同设计的 Machine Payments Protocol，目标是在 HTTP 交互中为 API request、tool call 或内容完成机器到机器支付。Stripe 的 MPP 公告 还说明了微支付和周期支付，以及通过现有 PaymentIntents 接入多种支付方式的实现路径。
MPP 与 x402 有重叠，因为两者都能把 HTTP 可访问资源放在支付之后，但 wire format、认证模型、支付方式和基础设施选择并不相同。不要只看 logo 做决定。
应该评估：
- 买方或 agent 平台实际支持什么
- 所需支付方式与币种
- 结算、退款与争议要求
- 周期收费还是单请求收费
- 现有支付处理器集成
- SDK 成熟度、可观测性与失败恢复
没有付费 API 或可调用工具的免费内容站，不需要立即采用 MPP。
ACP：Agent 平台里的程序化结账
Agentic Commerce Protocol 定义买家、AI agent 与卖家完成购买时的程序化交换。它的 checkout 接口处理 session 状态、购物车变化、配送选项、支付与卖家权威 totals。
当商家希望 ChatGPT 等 agent 界面执行确定性结账，而不是使用浏览器自动化时，ACP 才相关。卖家仍然负责库存、价格、税费、配送、订单状态与支付处理。
所以 ACP readiness 从商业后端开始，不是一个 SEO meta tag。接入前需要：
- 权威商品 ID 与实时库存
- 确定性的价格与税费计算
- 清晰的配送与退货规则
- 经过认证与签名的 API 流量
- 幂等的 checkout completion
- Webhook、对账与客服流程
ACP 不会让质量差的商品页获得排名，也不能替代 Product structured data。
UCP：更广泛的商业能力层
Universal Commerce Protocol 覆盖从发现、catalog lookup 到 cart、identity linking、checkout 与 order management 的构件。官方规范要求企业在 /.well-known/ucp 发布 profile，让平台发现带版本的 services 与 capabilities。
UCP 支持 REST、MCP、A2A 和 embedded 等 transport bindings。企业与平台协商双方能力的交集，而不是假设所有集成行为相同。
因此 UCP 不只是支付方式。只有当 profile 中的 endpoints、schemas、能力版本和业务行为真实存在时，发现文件才有价值。如果它声明支持 checkout，但后端不能稳定计算库存、总价、配送和错误，元数据就是误导。
UCP 更适合构建互操作 agent commerce 旅程的商家或平台。没有交易 API 的博客、展示站或出版商不应发布它。
AP2：授权是独立一层
Agent Payments Protocol 聚焦可验证用户意图、授权和责任。它用签名 mandates 把用户约束或批准绑定到 checkout 与 payment 详情，可覆盖有人和无人值守流程。
需要区分：
- Commerce protocol 描述买什么以及交易如何推进。
- Payment protocol 协调价值如何授权和转移。
- Authorization protocol 证明用户允许 agent 做什么。
生产系统可以组合这些层。例如 UCP 可以用 AP2 做自主支付授权；AP2 示例也可以用 x402 作为支付通道。但任何组合都不能省略反欺诈、法律复核、consent、审计日志和人工升级。
实施前先做适配评分
每项计 0 或 1 分：
| 条件 | 0 分 | 1 分 |
|---|---|---|
| 真实 agent 交易 | 不需要外部 agent 交易 | 已有支持的 agent 场景 |
| 权威后端 | 数据或 totals 需要人工修复 | API 能可靠返回状态与错误 |
| 买家 / 平台需求 | 没有确认的使用方 | 已有明确集成要求 |
| 支付运营 | 退款、争议或对账未定义 | 负责人和控制已记录 |
| 安全与授权 | Authorization 边界不清晰 | Scope、审计与升级已测试 |
| 维护能力 | 没有版本或事故负责人 | 有人监控规范和线上行为 |
评分解释：
- 0–2 分： 不实施，先修复普通网站与商业基础。
- 3–4 分： 做范围受控的技术 PoC，不公开宣称能力。
- 5–6 分： 根据真实交易选择协议，并完成安全复核。
这是实施门槛，不是成熟度徽章。高分也不代表四个协议都需要。
按交易选择，不按趋势选择
| 实际产品 | 优先评估 | 原因 |
|---|---|---|
| 纯内容站 | 无 | 可抓取性、有用内容和内部链接才是当前任务 |
| 改善 agent 发现的商店 | 暂时无 | 先修商品数据、schema、feed、政策和结账可靠性 |
| 接入 agent checkout 的商家 | ACP 或 UCP | 由目标平台与所需生命周期决定 |
| 付费 API 或计量工具 | x402 或 MPP | 售卖单位是 HTTP request 或 tool call |
| 具有委托权限的自主购买 | AP2 加 commerce/payment 层 | 必须明确用户意图与支付授权 |
支持协议不是 SEO 排名信号。它可以让真实服务与兼容客户端互操作，但不保证发现、流量、引用或收入。
基础清单永远在前面
Agent commerce 之前先验证：
- 公共页面返回正确 status、canonical 和渲染内容。
- 页面、schema、feed 与 API 的商品名、ID、价格、库存一致。
- 配送、退货、订阅与取消政策清楚。
- API 文档和 schemas 符合生产行为。
- 认证、授权与 consent 有明确负责人。
- Checkout 动作幂等且可观测。
- 失败能安全升级给人工处理。
先用 Agent SEO Audit 检查公开表面，再通过 Bot Simulator 和常规 技术 SEO 验证渲染。如果产品暴露 API，从 API Catalog 指南 与 OAuth metadata 流程 开始。只有真实 A2A 服务存在时，才增加 A2A Agent Card。
结论
x402、UCP、ACP 与 MPP 不是同一种“AI commerce tag”的四个版本。
- x402 与 MPP 聚焦 HTTP 可访问资源的机器支付。
- ACP 聚焦 agent 辅助的卖家结账。
- UCP 覆盖更广的商业发现、能力协商和生命周期操作。
- AP2 补充可验证意图与支付授权。
只实施真实交易和已确认买方所需的层。对多数内容站以及许多商店来说，当前价值最高的动作仍然是准确商品数据、可靠 API、安全授权，以及在 agent 到来之前就能正常工作的结账。
参考来源
- x402 官方文档
- Universal Commerce Protocol
- UCP 官方规范
- Agentic Commerce Protocol 文档
- Machine Payments Protocol
- Stripe：Introducing MPP
- Agent Payments Protocol
问答
每个电商或内容网站都需要 x402、UCP、ACP 或 MPP 吗？
不需要。纯内容站不需要 agent 支付协议。多数商店应该先确保商品数据、价格、库存、政策、认证和结账行为可靠，再评估特定协议集成。
UCP 与 ACP 的主要区别是什么？
两者都支持 agent 辅助商业，但 UCP 描述更广泛的商业生命周期与能力发现模型；ACP 更聚焦买家、agent 与卖家之间的程序化结账。应根据业务实际支持的平台与规范实施。
x402 和 MPP 是 SEO 排名信号吗？
不是。它们是面向付费资源、API、工具或内容的机器支付协议。发布或支持这些协议不会保证抓取、索引、排名、AI 引用或 agent 采用。
