Google 给 Agentic Commerce 铺的那条公路

购物正在长出一个新的「用户」：不是人，是 Agent。它替你比价、加购、下单、退货。问题是——每一个 Agent 要接每一个商家，都得写一套定制连接。

Google 把这叫 「N×N 集成瓶颈」：Gemini 要接 1 万家店，ChatGPT 也要接 1 万家店，每家店还要为每个 Agent 单独适配——连接数随双边数量相乘爆炸。这正是 2010 年代「每个 App 都要为每家银行写一个接口」的翻版。

Shopify 的工程团队在复盘文章里说得更直白：商业的复杂度是真实存在的——支付方式、折扣规则、履约组合，会随购物车内容、买家地区、市场行情不断变化。「单体协议最终都会在复杂度下崩塌：太僵硬，进化太慢。」

UCP 的答案是把这条公路标准化但不锁死：定义一套通用语言和功能原语，让集成从 N×N 塌缩成 N+N——商家实现一次，所有合规 Agent 都能开上来。2026 年 1 月 11 日的 NRF 大会上，Sundar Pichai 把它作为开源标准公布，联合开发方是 Shopify、Etsy、Wayfair、Target 和 Walmart。

UCP 把商业能力拆成三层，每层职责清晰、可独立演化——这是它和「单体购物 API」最本质的区别。

这套分层不是偶然。Shopify 在复盘里直接对标 TCP/IP 的成功：底层稳定、上层可插拔，才能在不破坏存量的前提下长出新垂类。这也是 UCP 敢说自己能扩到酒店、外卖的底气。

发现 = 拉清单 + 求交集

商家在 /.well-known/ucp 发布一份 JSON 清单：声明自己支持哪些 services、capabilities、payment handlers、REST 端点和 OpenAPI schema。Agent 也带着自己的能力 profile 过来。

然后求交集：双方都支持的能力才启用，都理解的扩展才生效。遇到能力缺口，走 checkout 状态机优雅降级——incomplete → requires_escalation → ready_for_complete。其中 escalation 这一步，Shopify 贡献了从自家 Checkout Kit 蒸馏出的嵌入式结账协议 ECP（基于 JSON-RPC 2.0），用于把状态和凭证安全地交回人工或商家自有结账页。

传输层：四选一

UCP 刻意不绑定单一传输。同一份能力清单可以声明多种调用方式，Agent 任选其一发起 tool call：

所以正确的心智模型是：
用 UCP 发现这家店、协商能力，用 MCP（或 A2A）去执行那些 tool call。

Agent 替你花钱，最危险的环节是授权。UCP 把这件事拆成两半。

第一半在 UCP 内部：支付被建模成双向动态协商。商家清单声明接受哪些 payment handlers（Shop Pay、Google Pay 等支付服务方），Agent 清单声明手里有哪些 payment instruments（卡、钱包）。可用的 handler 随交易变化——换购物车、换买家地区、换任意变量，可用的支付方式都可能漂移。关键是：Agent 全程不接触原始支付和身份数据，凭证由 credential provider 代币化。

第二半交给 AP2（Agent Payments Protocol）——UCP 的信任与授权层。官方文档给的分工很干脆：UCP 管「你买什么、向谁买」，AP2 管「谁批准了这笔购买」并提供审计轨迹。AP2 作为扩展插进 UCP 的结账流程。

这套设计的潜台词是：自主 Agent 可以在预设的、可验证的边界内替用户花钱——边界、授权、审计三件事都用可验证凭证钉死，而不是靠「信任这个 Agent 很乖」。

很多人把 UCP、MCP、A2A、AP2 当成互相竞争的标准——这是最大的误读。Google 在 3 月 18 日的开发者指南里把它们摆成互补的分层，每层解决一个不同问题：

一个 B2B 采购的完整链路就是这么串起来的：MCP 连供应商数据库取库存 → A2A 把报价任务委托给另一个 Agent → UCP 管整个下单流 → AP2 授权付款。Google 给的建议也很克制：「按需加协议，大多数 Agent 从 MCP 开始就够了。」

数据印证了这一点：截至 2026 年 4 月 13 日的 3,643+ 家验证商家中，几乎 100% 把 MCP 声明为传输层。UCP 负责「发现这家店」，MCP 负责「执行 tool call」——两者是搭档，不是对手。

Agentic commerce 标准之争，本质是两种治理哲学的对撞。对面是 OpenAI + Stripe 的 ACP（Agentic Commerce Protocol）。

行业观察给的结论很务实：别二选一，两个都接——就像零售商既上 Google Shopping 又上 Amazon。而且有趣的是，两套协议正在互相趋同：ACP 在 1 月 30 日的更新里引入了「能力协商」和「支付 handler 框架」，几乎照搬 UCP 的设计模式。

UCP 这半年的扩张节奏

协议发布只是起点。到 5 月 20 日，Google 已经把 UCP 的能力和变现一起往前推：

• →Universal Cart：跨零售商存商品、统一用 Google Pay 或商家结账结清。
• →先买后付：Affirm 和 Klarna 直接嵌进 Google Pay。
• →YouTube 可购物广告 + Demand Gen 商品 feed，把内容流量直接转成结账。
• →垂类扩张：酒店预订、外卖配送——验证了「三层架构能长出新垂类」的承诺。
• →新品牌入场：Nike、Sephora、Target、Walmart、Wayfair，及 Fenty、Steve Madden 等 Shopify 商家。先美国，再加拿大、澳洲、英国。

背书名单本身就是版图：除联合开发方外，Adyen、American Express、Best Buy、Flipkart、Macy's、Mastercard、Stripe、The Home Depot、Visa、Zalando 悉数在列——支付网络、卡组织、大型零售商三方齐全。

UCP 对商家的诱惑是真实的：省掉 N×N 的集成成本。但天下没有免费的公路——商家交出的，是渠道控制权。

eMarketer 的 Jeremy Goldman 说得直接：「当交易发生在 Google 的环境里，品牌就失去了对 UX、商品陈列和售后互动的控制」——商品从「品牌体验」退化成「被排序的商品」。

具体的代价有三层：

• 01最后一触点消失：结账跳进 Gemini，商家丢掉了「再加一件」的交叉销售窗口——而这部分往往占追加销售的 33%–76%。
• 02Google 依赖症：评论者直接类比当年出版商依赖 Google 搜索——一旦 Google 改算法，承担后果的是零售商，且无力反抗。
• 03数据与关系流失：Impression 的 Aaron Dicks 指出，品牌有理由抗拒「让顾客在自有阵地之外完成交易」的技术——交易数据、推荐、客户互动都被中间平台截走。

这正是 UCP 「开源 + 免费」策略最精妙也最危险的地方：协议免费，是为了让标准无法被拒绝；而真正的收费站，设在标准之上的流量入口。这是安卓的剧本，不是 Linux 的。