谷歌 UCP 在每次结账请求上挂了四个标头，其中三个是为日后的争议准备的
Universal Commerce Protocol 于 2026 年 1 月 11 日发布，谷歌与 Shopify 联合开发，Etsy、Wayfair、Target、Walmart 等 20 多家伙伴背书。但读完规范会发现，购物是其中最无聊的部分：/.well-known/ucp 发现机制、RFC 9421 消息签名、强制 Webhook 签名，以及一个唯一目的就是让智能体的购买无法抵赖的 AP2 授权书扩展。本文细读 UCP 真正标准化了什么，以及其中与买东西毫无关系的那一项。
2026 年 1 月 11 日，谷歌发布了 Universal Commerce Protocol——一个让 AI 智能体替人下单的开源标准，与 Shopify 联合开发，并获得 Etsy、Wayfair、Target、Walmart、Adyen、American Express、Mastercard、Stripe、Visa、Zalando 等 20 多家伙伴的背书。
随后的报道谈的全是购物。替你逛街的智能体、替你结账的智能体、购物车的终结，诸如此类。
然后你去读规范，会发现购物恰恰是里面最不有趣的部分。UCP 以罕见的细致标准化的，并不是这笔购买，而是这笔购买确实按双方所说发生过的证据。
要点速览：
- 每一个会改变状态的 UCP 请求都带四个标头，其中三个——
request-signature、idempotency-key、request-id——对交易本身毫无贡献。它们存在，是为了日后有人能证明请求了什么、只请求过一次、以及还能把这条记录重新找出来。- 抗抵赖是一项有名字的功能。 可选的 AP2 授权书扩展（
dev.ucp.shopping.ap2_mandate）要求商家对结账条款做密码学签名，同时由平台提供证明用户已授权这些条款的密码学授权书。规范自陈的目的是"大幅降低篡改与争议的风险"。- 背书数不等于接入数。 "20 多家全球伙伴"是谷歌公布的措辞，指的是背书。截至撰稿时，我们没有找到任何给出 UCP 实际上线商家数量的一手资料。
标头组合取自谷歌发布当日的实操教程。出处见文末。
去掉形容词之后，UCP 还剩下什么
在展开论点之前，先列出你能自行核对的事实。以下来自 ucp.dev 上公开的规范和谷歌开发者博客，两者均于 2026 年 9 月 5 日取得。
| Universal Commerce Protocol | |
|---|---|
| 发布日期 | 2026 年 1 月 11 日 |
| 取得时的规范版本 | 2026-04-08（YYYY-MM-DD 日期式版本号） |
| 治理方式 | 开源，github.com/Universal-Commerce-Protocol/ucp |
| 联合开发 | 谷歌与 Shopify |
| 点名的合作方 | Shopify、Etsy、Wayfair、Target、Walmart |
| 背书伙伴 | 20 家以上，含 Adyen、American Express、Best Buy、Flipkart、Macy's Inc、Mastercard、Stripe、The Home Depot、Visa、Zalando |
| 发现端点 | /.well-known/ucp |
| 传输方式 | REST（OpenAPI 3.x）、MCP（OpenRPC）、A2A（Agent Card）、嵌入式（OpenRPC） |
| 标准能力 | Cart、Checkout、Identity Linking、Order |
| 支付 | 兼容 AP2，模块化支付处理器 |
| 认证 | API 密钥、OAuth 2.0、mTLS、HTTP 消息签名（RFC 9421） |
表里有两处值得停一下，因为大多数介绍文章两处都跳过了。
第一处是传输那一行。UCP 不是一个 MCP 方案，也不是一个 REST 方案。同一份声明数据同时通过 REST、MCP、A2A 和嵌入式绑定提供，用哪一种由商家自己挑。这是一次刻意的拒绝：不去赌哪套智能体管道会赢。
第二处是日期式版本号。2026-04-08 不是语义化版本，而是一个日子。规范给出的理由是时间顺序清晰、比较无歧义，但实际效果在别处：每一次协商完成的会话，都同时记下了它所遵循的规则是哪一天的。这是一个披着版本决策外衣的存档决策，也提前定下了整份文档的性格。
它要干掉的那个 N×N 瓶颈
谷歌的说法是 N×N 问题。想出现在对话式界面里的商家，必须为每一个界面各做一套定制对接；每一个界面又要为每一家商家单独走一遍接入；最后谁也没上线。
同一天发布的 Shopify 工程博客从底下切入同一个问题。作者、杰出工程师 Ilya Grigorik 说，在 20 多年、数十亿笔交易、数百万商家之后，得到的教训是商业拒绝被归一化：「支付选项和规则会随购物车、买家和市场的属性而变；折扣的叠加与组合规则复杂到堪比税法；履约选项则以失控的排列组合爆炸式增长。」接着是那句值得留下的话：「这种复杂性不是缺陷，而是多样化零售商身上涌现出来的性质。」
这一行解释了整个架构。如果你承认商家之间存在不可化约的差异，你就无法标准化他们的行为，只能标准化商家如何声明自己的行为，以及智能体如何弄清自己刚刚同意了什么。
商家发布在 /.well-known/ucp 的结构。来源：UCP 规范 2026-04-08，Overview。
对话是在发现结束之后才开始的
以下是规范和谷歌教程描述的流程。顺序本身就是论点，值得逐字跟一遍。
- 商家在
/.well-known/ucp发布一份档案。 其中声明协议版本、一个或多个服务（dev.ucp.shopping）、服务内的能力、传输方式与端点、可用的支付处理器，以及后面会派上大用场的公钥signing_keys。 - 智能体在每一次请求里报出自己的档案。 通过使用 RFC 8941 字典语法的
UCP-Agent标头，形如UCP-Agent: profile="https://agent.example/profiles/shopping-agent.json"。在 MCP 传输上，同样的信息装在meta对象里。 - 商家计算交集。 在自己支持的能力里，保留平台也声明了的；对每一个幸存者，选出同时存在于双方数组中的最高版本；如果没有共同版本，这项能力整个被剔除。
- 孤立的扩展被剪掉。 声明了
extends: "dev.ucp.shopping.checkout"的扩展，若 checkout 没能留下，就随之消失。这一步反复执行直到没有东西可剪，因此能处理链式依赖。 - 由商家做选择。 UCP 采用服务端选择的架构：决定本次会话有哪些能力生效的是商家而不是智能体，并把生效的能力注册表回写在响应里。
命名不是惯例问题，而是被治理的对象。每一项能力都是 {反向域名}.{服务}.{能力} 的格式：标准能力是 dev.ucp.shopping.checkout，商家自有能力则形如 com.example.payments.installments。零售商可以不经任何人许可、也不与任何人冲突地发明一项别人没有的能力，因为反向域名本身就是权威。
失败也有自己的分类体系，而这个切分很说明问题。规范把发现失败（传输错误：invalid_profile_url 返回 400、profile_unreachable 返回 424、profile_malformed 返回 422）和协商失败分开。协商失败属于业务结果，因此以一个正常的 200 带着 capabilities_incompatible 返回。"我够不着你"和"我们之间没有交集"是两件事，UCP 拒绝把它们糊成同一个 400。
每个变更请求上都挂着四个标头
现在看一次真实调用。这是谷歌发布当日示例里，对一家样例花店创建结账会话的请求：
POST /checkout-sessions
UCP-Agent: profile="https://agent.example/profile"
request-signature: test
idempotency-key: 0b50cc6b-19b2-42cd-afee-6a98e71eea87
request-id: 6d08ae4b-e7ea-44f4-846f-d7381919d4f2
Content-Type: application/json
四个标头。逐个去问它们各自为何存在，一个模式就浮出来了。
| 标头 | 调用过程中的作用 | 调用结束后留下的东西 |
|---|---|---|
UCP-Agent | 定位平台档案，以便协商能力并找到签名密钥 | 单独看什么也不留。只有这一个真正是为对话服务的 |
request-signature | 用调用方自己档案中公开的密钥，按 RFC 9421 对请求签名 | 密码学证据：是这个智能体、而非任何别的智能体，发出了这份确切的请求体 |
idempotency-key | 让商家把重试识别为重试 | 一个意图恰好产生了一次扣款的证据 |
request-id | 在双方日志中对上同一次调用 | 这一步在其余全部事件顺序中的位置 |
四个里有三个不是为交易服务的，而是为围绕这笔交易的争议服务的。
这不是 API 卫生习惯的偶然产物。幂等键和请求 ID 确实是支付领域常见的良好实践，但规范走得远得多，而且走得越远，意图就越清楚。
抗抵赖是设计目标，不是合规的收尾工作
UCP 列出商家可以接受的四种认证方式：API 密钥、OAuth 2.0、mTLS，以及基于 RFC 9421 的 HTTP 消息签名。前三种平平无奇，第四种在做一件特别的事。
在消息签名下，双方都把公钥登在声明能力的那同一份档案文件的 signing_keys 数组里。验证方从 Signature-Input 标头取出 keyid，与签名方公布的密钥集合中的 kid 匹配，然后校验签名。不需要共享密钥，不需要事先注册，不需要账号。规范把这个结果称为无许可接入：「任何拥有可被发现档案的平台，都可以在没有事先注册的情况下与任何商家交互。」
明显的漏洞由身份绑定堵上。无论用哪种机制，验证方都必须确认被认证的主体确实有权代表 UCP-Agent 中所声明的档案行事，两者冲突时必须拒绝请求。你不能以自己的身份完成认证，然后声称自己是别人的智能体。
而从商家发往平台的 Webhook 必须签名。不是应该，是必须。关于发货、送达和退货的订单生命周期更新，是整个协议中这项要求唯一绝对化的地方——因为它们是在钱已经动完之后才到达、而且没有人在实时盯着的消息。
来源：UCP 规范 2026-04-08，Identity & Authentication 与 Transaction Integrity 两节。
然后是梯子的顶端。针对自主智能体和大额交易，UCP 定义了一项可选扩展 dev.ucp.shopping.ap2_mandate。当双方协商启用它时：
- 商家提供对结账条款的密码学签名，并且
- 平台提供证明用户已授权这些条款的密码学授权书。
智能体是在一个非智能体的界面上，用用户的私钥对授权书对象签名。也就是说，人是在自己掌控的屏幕上授权的，而不是在那个马上要花他钱的智能体循环里面。规范自陈的目的值得原样引用，因为它不是一句安全套话：这套机制「就交易细节与参与方同意提供了强有力的端到端密码学保证，大幅降低了篡改与争议的风险」。
要点在这里。一个只想让智能体去购物的协议，这些一样都不需要。商家侧的签名条款和用户侧的签名授权书不是"买"的功能，而是六周之后，在一个必须判断谁有理的人面前，"为这笔买卖吵架"的功能。
叙述跑到证据前面的地方
关于 UCP 反复被转述、但一手资料并不按此支持的说法有三条。
"20 多家"是背书数。 谷歌的原话是 UCP 由「20 多家伙伴共同开发并背书」。背书是一种公开的支持表态，不是已经上线的对接，更不是正在运营的商家。我们找过给出 UCP 上实际交易商家数量的一手资料，没有找到。
"开放标准"和"谷歌的标准"两句都成立，其间的张力是真实的。 规范是开源的，GitHub 仓库接受 pull request，命名规则也刻意让任何人都能主张自己的命名空间。同时，第一个参考实现是谷歌做的，而要参与那个实现，商家需要一个拥有可结账商品的有效 Google Merchant Center 账号。中立的协议，带门槛的首发场地。
UCP 并没有把商家拿掉。 这一点被误传得够多，值得直说：在 UCP 之下，商家保有自己的业务逻辑，并继续担任 Merchant of Record。Shopify 的 Embedded Checkout Protocol 从另一个方向作出同样的承诺——当流程需要人介入时，智能体加载 continue_url，商家真实的结账页通过 JSON-RPC 2.0 通道渲染在智能体的界面内，最终完成交易的仍是商家。智能体是一个界面，不是一个替代品。
四件我们无法核实的事，如实标注
取得时 ucp.dev 上公开的规范是 2026-04-08 版，其标准能力清单为 Cart、Checkout、Identity Linking、Order，这与 1 月 11 日的教程不同：那边的示例跑在 2026-01-11 版上，展示的是 checkout、discount 和 fulfillment。两个日期之间显然新增了东西。我们没有找到能指明时间点的一手变更日志，也没有找到中间版本的带日期发布说明，因此我们只报告这个差异，而不报告一次"发布事件"。
我们没有在谷歌、Shopify 或任何背书伙伴处找到公布 UCP 上线商家数量的资料。没有数字并不等于数字很小，但这正是我们不写任何数字的原因。
谷歌称自己构建了第一个参考实现，为搜索中的 AI Mode 和 Gemini 应用内的购买提供支撑。我们没有独立核实该上线的可用范围、地区和规模。
UCP 会不会成为智能体商务的那个标准，在撰稿时无从得知，任何告诉你答案的文章都是在猜。诚实的读法要窄得多：规范存在，它是公开的，它在"证明"这件事上罕见地细致，并且有好几家极大的公司在发布中署了名。
没有签名的那一半
从商务本身退一步看，有意思的部分是可以推广的。
UCP 描绘的世界里，机器替你行动，而这个行动的每一步都留下点什么：谁提出的，有签名；条款是什么，有签名；发生了几次，有幂等键；顺序如何，有关联 ID。六周后这笔扣款被质疑时，那里有一件实物。没有人需要去回忆。
现在想想这些行动的授权究竟来自哪里。智能体买 400 件，是因为有人做了采购决定。合同续签，是因为有人同意了某个条款。范围变了，是因为两个人在周四聊过，其中一个说了行。
那些对话就是同一条工作流里没有签名的那一半。机器那一半正建立在密码学收据之上，建立在一份把争议当作一等场景来对待的规范之上。人的那一半，在大多数组织里，是某人的记忆、另一个人不一样的记忆，以及从这两者里写出来的一份摘要。
这个不对称在变好之前会先变得更糟，因为机器那一半按规范的节奏改进，而人的那一半根本没有在改进。而且失败的形态很具体：问题不是人会说谎，而是派生物——摘要、纪要、待办清单——会在它所派生自的原件消失的那一刻起，被当成记录本身。摘要在构造上就是有损的，这正是它有用的原因，也正是它不适合当一手材料的原因。原件被丢掉之后，没有任何办法把有损的摘要和准确的摘要区分开。
UCP 的设计者在协议层理解了这一点并把它写了下来：保留签过名的原件，从它派生出你想要的任何东西，并确保这份派生随时能与一个没有移动过的对象核对。这是一种纪律而不是一种技术，它适用于 POST /checkout-sessions 的程度，和适用于一小时的人类谈话完全一样。
结论：智能体商务是一套穿着购物外衣的凭证标准
Universal Commerce Protocol 通常被描述成让 AI 智能体买东西的办法。整篇读完之后，更准确的描述是：它试图回答一个"智能体化的一切"即将不断遭遇的问题——当机器替我行动之后，关于我到底同意了什么，究竟有什么是能被证明的？
UCP 给出的答案是个好答案：把能力公开声明出来，给条款签名，给同意签名，给重试上键，把调用关联起来，并给那个事后汇报结果的 Webhook 也签上名。这个协议会不会赢，确实是开放的；但它围绕的那个问题，无论谁赢都不会消失。
于是留下一个值得慢慢想的问题。你的智能体很快就会对"自己同意了什么"拥有比你对"自己同意了什么"更好的记录。这条路通向哪里？
Telli.sh 的位置：我们做的正是那没有签名的一半。Telli.sh 录下对话、区分说话人、以 15 种语言实时翻译，并在它生成的每一份摘要旁边保留原始录音和完整转写——这样派生物就永远不会成为唯一的存留物。Telli.sh 并未实现 UCP，也不作此声称；我们处理的是同一个问题的另一端：授权智能体行为的那些决定，通常是口头做出的，而且哪里都没有留下。
来源
- Universal Commerce Protocol 规范，Overview，版本 2026-04-08 — 服务、能力与扩展模型，命名规则，日期式版本号，能力交集算法，协商与签名错误码，标准能力（Cart、Checkout、Identity Linking、Order），传输方式，
UCP-Agent标头与 RFC 8941 语法，认证机制与无许可接入，通过signing_keys的密钥发现，身份绑定，强制 Webhook 签名，以及 Transaction Integrity and Non-Repudiation 一节；2026 年 9 月 5 日取得 - Google Developers Blog，《Under the Hood: Universal Commerce Protocol (UCP)》，2026 年 1 月 11 日 — 伙伴名单与 20 家以上的背书数字，AP2/A2A/MCP 兼容性，N×N 论述，
/.well-known/ucp清单，五步教程与POST /checkout-sessions的标头组合，Merchant of Record 与嵌入式选项，AI Mode 和 Gemini 中的谷歌参考实现，以及 Merchant Center 要求；2026 年 9 月 5 日取得 - Shopify Engineering，Ilya Grigorik，《Building the Universal Commerce Protocol》，2026 年 1 月 11 日 — 20 多年、数十亿笔交易、数百万商家的背景，「不是缺陷而是涌现性质」的论点，四条设计原则，以及经由
continue_url的 JSON-RPC 2.0 嵌入式结账协议交接；2026 年 9 月 5 日取得 - Agent Payments Protocol (AP2) — UCP 声明兼容的支付协议
- GitHub 上的 Universal Commerce Protocol — 两份公告都点名的开源仓库
- 我们对 GPT-6 Astra 的解读，以及采集层仍在决定什么 — 从模型一侧看同一个论点：推理质量的上限，早在产生那份记录的环节就已经定下了