这四份标准里有三份回答的是同一个问题，第四份回答的是另一个——这正是为什么把它们读成互相竞争，会产出一份造不出来的路线图。ACP、UCP 与 AP2 最终都落在一件支付工具上：谁可以被扣款、最多扣多少。而 Poppy 落在一个会话上。如果你是商家，这意味着前三份会落到你的结账团队手上，第四份则落到管你登录的那个人手上——而第四份正是你还没配人的那一份。
一览
四份标准，关于「智能体究竟是什么」的四种不同假定。日期是公开公布的日期；版本在动，所以请把这里的每个数字都当作截至 2026 年 10 月下旬为准，动手之前先读规范。
| 标准 | 推动方 | 公布日期 | 它假定智能体是…… |
|---|---|---|---|
| ACP — Agentic Commerce Protocol | OpenAI、Stripe | 2025-09-29 | 平台的买方，在平台自己的界面里完成结账 |
| UCP — Universal Commerce Protocol | Google、Shopify | 2026-01-11 | 通向商家自有目录与结账的一条通路 |
| AP2 — Agent Payments Protocol | 2025 年 | 出示一份并非自己签发的可验证授权的一方 | |
| Poppy — Personal Agent Protocol | Sierra、Meta | 2026-10-06 | 某一位用户的受托人，在某一家公司以该用户身份登录 |
先说缩写问题
在智能体文档里，ACP 指三件不同的东西，而只有其中一件与商务有关。Agentic Commerce Protocol 是本文讨论的 OpenAI 与 Stripe 的标准。Agent Client Protocol 是 Zed 的编辑器到智能体协议，和支付毫无关系。Agent Communication Protocol 是一个智能体之间的 REST 标准，2025 年 7 月被贡献给 Linux 基金会，随后并入 A2A。搜索结果会把这三者随意混在一起，而一篇把 ACP 说成 A2A 替代品的对比文章，指的是那个已经不在的。本站把它们分开放在Agent Client Protocol 与 ACP：后来怎么了。
ACP：平台拥有界面，商家拿到一个令牌
ACP 于 2025 年 9 月 29 日以 Apache 2.0 发布，与 ChatGPT 里的 Instant Checkout 同时亮相，其带版本号的规范如今标着日期 2026-04-17。它的架构承诺是：买方留在平台之内——智能体在平台自己的界面里呈现商家目录并接单，商家则在后面暴露一个 agentic-checkout API。
值得细读的是 Delegated Payment Spec，因为它是这些标准最终都需要的那个模式最干净的一次表达。平台依据用户实际选择的内容，准备一次带可扣款最高金额与过期时间的一次性委派支付请求；支付服务商返回一个令牌；平台把这个令牌交给商家去完成扣款。卡片信息从不抵达智能体。OpenAI 自己的文档明确写着，只有 PSP 或 PCI DSS 一级商家才应直接集成该规范，而 Stripe 的 Shared Payment Token 被称为首个兼容实现——这就告诉你，对其他所有人来说，现实的集成路径要经过一家服务商。
一份有上限、会过期、只能用一次的授权，正是智能体支出该有的形状；而这与本站在钱包枯竭与成本攻击里主张的是同一个形状：防御是写在凭证里的一个上限，而不是写在提示词里的一句承诺。
UCP：商家守住界面，任何智能体都可以来交易
Google 与 Shopify 于 2026 年 1 月 11 日在美国全国零售联盟展会上公布 UCP，共同开发方包括 Etsy、Wayfair、Target 与 Walmart。它押的注与 ACP 相反：商家发布自己的能力，任何兼容的智能体都能发现并对其交易，而不是让交易发生在某一个平台的聊天窗口里。Shopify 商家能直接卖进 Google 搜索的 AI Mode 与 Gemini 应用，就是看得见的后果。
在支付上，UCP 向外伸手而不自己规定——AP2 的 mandate 通过一个扩展接入，于是智能体可以出示一份由商家验证的密码学授权。这是一处刻意的分层决定，而各方资料对这层耦合有多紧说法不一，这件事本身在你照它做规划之前就值得知道。实用的读法是：UCP 标准化了发现、目录与结账，把支付工具留给别人。
请注意 ACP 与 UCP 真正争的是什么，因为那不是技术。两者都能承载一个有上限的令牌。分歧在于：主要的商务界面会变成智能体的界面，还是仍然是商家的界面——这是一个带着协议外衣的分发问题。沃尔玛的 Agent Gateway 在同一根轴上画了它自己的那条线，那正是《店门开了，钱包没开》的论点。
AP2：它根本不是一个商务协议
AP2 是最常被归错类的那一个，因为它出现在每一份商务对比里，而它并不是一份商务标准。它把意图、购物车与支付建模为可验证凭证——一份关于「某个人授权了智能体去做什么」的可签名、可核验的记录——并且它位于 A2A 与 MCP 之上，而不在两者之内。它的工作单位是 mandate，不是结账。
这也让它成为四者中唯一能与其余三者干净组合的那一个：一份 mandate 是 ACP、UCP 或某个定制集成都能承载的东西。需要保持怀疑的是常与它同行的「稳定币轨道」话术，而机制在AP2 与智能体商务。把 AP2 读成审计层，这片领域里大部分混乱就自行消解了：它回答的是「证明这个人同意过」，而它对谁搭了那个店面毫不关心。
Poppy：撞上你的登录的那一个
Sierra 与 Meta 于 2026 年 10 月 6 日公布个人智能体协议，并在 10 月 9 日发布草案，设计伙伴被第三方追踪者数到约 35 家公司。它跑得很快——日期为 10 月 18 日的 SDK 发布面向草案 0.2，而已公开的示例里 protocol_version 已经写到 0.3——所以版本号不是一个值得你去对准编码的东西。一家公司在 /.well-known/poppy.json 发布一份文档，声明智能体如何开启会话、它提供哪些登录方式与权限范围，以及存在哪些通路：一个对话式端点、若干 API，或者一个由智能体驾驶的网站会话。
有三处设计选择让它成为另一种标准，而不是商务标准的另一个方言。会话开场是未登录的，登录是把一个账户挂到一个已经在跑的会话上——于是你的授权检查不能放在连接建立处，因为在连接建立的那一刻没有任何人可供授权。标准权限词汇只有两个取值，poppy:read 与 poppy:write，而 poppy: 前缀是保留的，所以你没法自造一个更细的标准 scope；更细的东西都得是你自己命名下的自定义 scope。而用户标识在一家公司内稳定、在其他每一家都不同，于是两家商家无法通过比对各自智能体递来的东西，发现它们服务的是同一个人。
支付被列为未来工作，而这处缺席是整份草案里信息量最大的一行。一个受托人没有自己的支付工具可以出示；这个协议在一个需要「谁持有支付工具」的问题边缘上，正确地停了下来。机制以及它会让你的后端付出什么，在Poppy：个人智能体协议。
横向对比：被争夺的那一层是身份，不是支付
按「谁是那个已鉴权的主体」来对比这四者，这片领域的形状就变了。在 ACP 下，主体是平台的账户——商家看到的是一个可信中介带着一个有上限的令牌来交易，而终端用户是平台认识、商家基本不认识的人。在 UCP 下，主体是商家自家登录所说的那个人，智能体只是一条通路。AP2 拒答这个问题，改为承载一份指名了主体的凭证，这也正是它能垫在两者之下的原因。而 Poppy 直接让终端用户成为主体，就在商家处，通过一个商家无法与任何其他人对接的化名。
相比之下，支付已经收敛了。三份商务侧标准全都落在同一个原语上——一份有上限、会过期、只能用一次的授权，由某个并非智能体的一方持有——它们的差别主要在于由谁签发。正因为这种收敛，支付那一列才是无聊的那列，而身份那一列才是接下来两年争论的发生地：一个有上限的令牌是已被解决的工程问题，而「由哪一方持有『化名到人』的映射」是一个市场结构问题，没有任何规范能裁定。
有一处不对称很容易被漏掉，而且它与「Poppy 是隐私胜利」这种读法相抵。按公司隔离的化名阻止的是各家商家之间互相关联同一个用户，它完全没有阻止智能体——而智能体恰恰是那个同时握着某个人全部化名、并知道它们属于谁的唯一一方。Poppy 并没有去掉这次跨商家对接，它把这次对接搬去了智能体厂商那里。这是不是一种改进，取决于你认为它该由谁握着，那是委托代理问题，不是一场技术争论。
什么情况选哪个
| 如果你是…… | 先实现 | 可以推后 | 原因 |
|---|---|---|---|
| 已有 PSP、且有来自助手界面流量的商家 | ACP 或 UCP，取决于你的销售渠道实际从哪边送来买家 | Poppy | 两者都是结账集成；令牌那部分工作由你的 PSP 扛 |
| 价值主要落在自家账户里的商家（订阅、预订、客服） | Poppy | ACP、UCP | 难的是一个陌生人的智能体以你客户身份行动，而不是付钱给你 |
| 正在搭建智能体界面的平台或市场 | ACP，然后是 AP2 mandate | UCP | 授权由你签发，所以支付工具的设计是你的事 |
| 处在需要同意记录的受监管流程里 | AP2 | 其余三者 | 它是唯一一个工作单位就是「可证明的授权」的标准 |
还有一件无论你选哪个都该做的事，因为四者推的都是同一个方向：把你的授权检查从会话挪到单个动作上，并在你暴露的最粗那个写权限底下放一道风险门。这件工作与协议无关，是四者中三者的前置条件，而且它让你在面对那些根本不用任何标准、已经在驾驶你站点的智能体时更安全。
常见问题
这四个协议是竞争关系吗？
只有其中两个是。ACP 与 UCP 争的是「主要商务界面是智能体的界面还是商家的界面」。AP2 作为一种授权格式垫在两者之下，而 Poppy 处理的完全是另一个问题——个人智能体以用户身份登录——现阶段没有支付那一块。
商家该先实现哪一个？
跟着你的买家实际从哪来走。如果助手界面已经在给你送流量，那个集成最先回本，而大部分工作由你的支付服务商扛。如果你产品里的价值是落在客户登录之后、而不是落在购物车里，那么 Poppy 才是碰到你真问题的那一个。
Poppy 处理支付吗？
不处理。草案覆盖身份、登录、会话与权限范围，并把支付列为未来工作。这与它的设计一致，而不是一处缺口：它把智能体当作用户的受托人，而一个受托人没有自己的支付工具可以出示。
为什么 ACP 指三件不同的东西？
因为三个互不相关的群体选了同一个缩写：Agentic Commerce Protocol（OpenAI 与 Stripe）、Agent Client Protocol（Zed，编辑器到智能体），以及 Agent Communication Protocol（2025 年 7 月贡献给 Linux 基金会，后并入 A2A）。在相信一篇文章的对比之前，先确认它指的是哪一个。
这些规范有多稳定？
参差不齐。ACP 有一份带日期的版本化规范，并且已在现场运行了一年。Poppy 是草案，其版本在 2026 年 10 月的九天里动了两次。请对准交易对手所提供的那份发现文档去构建，而不是对准你读过一次的某个修订号。
按公司隔离的化名算真正的隐私收益吗？
算真的，但很窄。它让跨商家关联在结构上对商家不可得，这比一份请他们别做的政策更强。而它留下的是智能体厂商握着某一个人的全部化名，所以那次对接是被搬走了，而不是被去掉了。
延伸阅读
本站内容：
- Poppy：个人智能体协议——会话模型、保留的权限范围，以及这次反转会让你的后端付出什么。
- AP2 与智能体商务——把 mandate 建模为可验证凭证，以及需要保持怀疑的稳定币话术。
- 智能体支付——这四份标准底下的那些原语。
- 购物与结账智能体——构建买方那一侧。
- 以你用户身份登录的第三方智能体——Poppy 要标准化的那个问题，在今天还没有标准时的样子。