UCP 与 ACP:两套代理商务协议的对比
两套协议正在竞争「AI 代理购物」的标准化:UCP 与 ACP。它们解决的问题有重叠但并不相同——而对大多数 Shopify 商家来说,正确答案是不用选。
一句话结论
UCP(Universal Commerce Protocol,规范在 ucp.dev)覆盖完整购物旅程:商品发现、购物车、结算、账号绑定与订单管理,且结算可以在代理界面内闭环。它由 Google 牵头,与包括 Shopify 在内的零售方共同制定。
ACP(Agentic Commerce Protocol)是 OpenAI 与 Stripe 推动的方案,重心偏向结算与委托支付的标准化。实践上它更接近发现与转介,成交回到商家自有结算完成。
如果你在 Shopify 上卖货,你不需要押注任何一套。协议适配是平台的事。你需要押注的只有一件:你的商品数据和结算资格,在任何一套协议下都足够好。
它们真正的区别在哪
- 覆盖范围——UCP 从发现一直管到售后的订单查询;ACP 集中在支付与结算握手。
- 钱在哪里易手——UCP 支持在代理界面内完成的协议原生结算;ACP 把更多交易环节留在商家侧。
- 谁召集的——UCP 由 Google 牵头、零售方共同署名;ACP 出自 OpenAI 与 Stripe。
- 配套标准——UCP 被设计成与代理支付、代理间通信协议互操作;ACP 在 Stripe 的代理商务工具链内演进。
- 商家要做什么——在 Shopify 上,UCP 支持由平台在你自己的域名上提供;ACP 式集成更多涉及你的支付栈。
Shopify 为什么在这件事上位置特别好
Shopify 既是 UCP 的共同制定方、在店铺上原生实现它,又通过官方 Shop skill 与连接器直接出现在 ChatGPT 等助手里。换句话说,它没有把自己绑死在某一套协议上,而是把「商家侧的供给」做成了一个可以接到任何代理上的标准件。
这是 Fall '26 在竞争层面最锋利的一刀,而且双向有效。你在 Shopify 上,协议工作基本被平台吸收;你在自建栈或别的 SaaS 上,同样的能力就变成你工程预算里的一行——这也是这个季度「要不要迁站」的讨论明显加速的具体原因之一。
与其选边,不如做这几件事
- 确认你的发现文档与工具清单解析到自有域名,而不是平台域名。
- 确认声明的支付处理器非空、永久链接指向自有域名。
- 把跨店目录真正能过滤的那些商品属性归一化——不被支持的属性名会被直接忽略。
- 发布政策与服务事实,让代理能用你的措辞回答退换货、运费与保修,而不是靠猜。
- 把成交测量重建到服务端,这样无论订单从哪套协议来,你都读得出这个渠道。
唯一值得做的那个战略判断
协议会持续变化:能力清单会漂移,草案能力会来会走。真正耐久的资产是你暴露出去的东西的质量——可被抽取的商品事实、准确的属性、已发布的政策、能用的结算。这些扛得住每一次版本跳变,所以我们把它们当成「工作」,把协议新闻当成「背景」。
如果你想把这两类分开——这个季度在你店里真正可执行的是什么、哪些还只是值得观察的草案——我们的 Agentic Commerce 与 AI 可见度(GEO/AEO)服务就是围绕这种分流构建的。把域名发给我们,我们告诉你每一项该放进哪一栏。
常见问题
最终会有一套协议赢吗?
不确定,而且对主流平台上的商家来说,它的重要性没有看起来那么高。两套都在被大玩家采用,平台也越来越倾向于同时支持多套。商家侧的资产——商品数据、政策、结算资格——无论哪套都是同一批。
要同时支持两套,我需要开发吗?
在 Shopify 上,协议层通常不需要。你可能需要工程资源做规模化的商品数据归一化、ERP 或 PIM 数据源对接,以及把分析搬到服务端。
一手资料去哪里看?
UCP 规范在 ucp.dev,Shopify 的工程说明在 shopify.engineering/ucp,面向代理的完整开发者文档在 shopify.dev/docs/agents。ACP 方面,Stripe 与 OpenAI 各自发布了自己的文档。