Shopify 与 UCP 正在把“交易能力”变成机器可调用的协议
文 / Shopify AI研究院
当多数品牌还在研究“怎么被 AI 搜到”，一批更早的商家已经在进入下一阶段：怎么让 AI 真正完成交易。
我们最近关注到，Shopify网站都有一个 /.well-known/ucp的链接。
比如：https://www.getcasely.com/.well-known/ucp
表面看，这只是一个 JSON 文件；但从协议意义上看，它更像是一张写给 AI Agent 的“商业能力名片”：它告诉外部平台，这家商家支持什么协议版本、提供哪些购物服务、开放哪些交易能力、以及能接受哪些支付处理方式。
这件事的意义在于，AI 电商的竞争，正在从“内容可见性”升级到“交易可执行性”。过去，品牌要解决的是搜索引擎能不能看见我；接下来，品牌还要解决的是：AI 能不能理解我、协商我、调用我，并最终在我的商业规则内完成一笔交易。
一、什么是 UCP：它不是一个新接口，而是一种新的交易语言
Universal Commerce Protocol（简称 UCP）是一个面向 AI 商业场景的开放协议标准。按照官方定义，UCP 的目标，是统一平台、商家与支付提供方之间的交互方式，使 AI 界面——例如 Google AI Mode、Gemini 等——不仅能推荐商品，还能直接推动购买流程，减少跳转、流失和结账摩擦。Google 将其定位为把 AI 交互转化为即时成交的开放标准，而 Shopify 则将其描述为让 AI Agent 可以与任意商家连接、协商并完成交易的一套通用协议。
从更底层的视角看，UCP 试图解决的是未来商业网络中的 N 对 N 集成复杂度。如果没有统一协议，每一个 AI 平台都要和每一个商家、每一种支付方式做定制对接，复杂度会迅速失控。UCP 的思路，是把服务发现、版本协商、能力协商、支付处理和扩展机制全部协议化，让不同参与方在统一框架下建立连接。UCP 官方将其概括为一种解耦式商业架构，用标准化能力、支付处理器和扩展机制，提升安全性、可扩展性与生态兼容性。
UCP 的高层支付流程
图：UCP 官方给出的高层支付流程图，展示平台、商家与支付链路之间如何协同。
而 /.well-known/ucp之所以重要，是因为它正是 UCP 的标准发现入口。平台先读取这里，了解商家支持什么版本、哪些服务、哪些能力与支付处理器，再进入后续协商流程。Google 官方文档明确要求商家将 UCP profile 发布在这一固定路径上，以便平台进行能力发现与协商。换句话说，这不是给消费者看的页面，而是给未来 AI 商业生态读取的基础设施。
UCP 的发现与协商机制
图：UCP 官方给出的发现与协商流程，说明为什么 /.well-known/ucp会成为 AI Agent 的第一跳。
二、为什么 Casely 这个案例值得重视
Casely 这个案例的价值，不在于它公开了一份 JSON，而在于它代表着品牌开始把自己的交易能力，从传统网站页面和后端系统中“抽出来”，变成标准化、机器可读、可协商的协议对象。
如果说过去十年品牌数字化的重点，是把商品、库存、订单、支付这些能力在线化；那么未来两三年，品牌 AI 化的重点，很可能是把这些能力进一步协议化。也就是说，未来真正重要的，不只是“你的网站好不好看”，而是“你的商业能力能否被 AI 高效读取并安全调用”。在这个意义上，/.well-known/ucp很可能会成为继商品 Feed、Schema Markup、Merchant Center 之后，品牌在 AI 电商时代新的标准入口。
Casely 这份 profile 最有代表性的地方在于，它不是只让外部 AI 知道“我卖手机壳”，而是在告诉外部 AI：“我支持哪些购物能力、配送规则能复杂到什么程度、哪些优惠逻辑可协商、哪些支付处理方式可用，以及在什么时候你需要把流程交回给用户继续完成。”这已经不是内容表达，而是交易表达。
三、拆解 Casely 的 UCP Profile：它到底声明了什么
从结构上看，Casely 的 profile 可以分成五个部分：协议版本、支持版本、服务、能力、支付处理器。这与 Google 官方给出的 UCP business profile 示例结构高度一致，属于一个标准的商家能力声明。
首先是版本信息。Casely 当前声明的主版本为 2026-01-23，并保留了 draft与正式版本入口。这说明 UCP 已经进入清晰的日期版本化治理模式，支持平台与商家在明确版本边界下完成兼容与演进，而不是停留在“概念标准”的阶段。对商业生态来说，版本化意味着这个协议具备持续迭代与长期商用的基础。
其次是服务声明。Casely 在 services中声明了 dev.ucp.shopping，并同时开放了两种 transport：一种是 mcp，对应可访问的 endpoint；另一种是 embedded，对应嵌入式相关 schema。这一点很关键，因为它意味着 Casely 不是只准备了一条“纯接口式”的交易路径，而是同时准备了 AI 直连推进与嵌入式 handoff 两种机制：前者适合自动化程度高的场景，后者适合需要用户继续补充信息、确认或完成支付的复杂场景。
再次是能力声明。Casely 当前公开的能力包括 checkout、fulfillment、discount和 order。这四类能力已经构成一个相对完整的交易闭环：AI 可以发起结账、读取履约方式、应用折扣能力，并在成功后获取订单结果。更重要的是，其中 fulfillment 与 discount 都以 extends的方式建立在 checkout 之上，这与 Shopify 对 UCP 的解释一致——UCP 并不是一个包罗万象的大接口，而是一套分层、可组合、可扩展的商业协议体系。
还有一个很值得注意的细节，是 Casely 的 fulfillment 配置明确写明：当前 shipping不支持 multi-destination，多种方法组合也仅限于 shipping。换句话说，UCP 不只是抽象地表达“支持履约”，而是能把商家的真实运营边界表达成机器可理解的规则。未来 AI Agent 不是只知道“这家店可买”，而是知道“这家店当前能不能多地址配送、能不能做复杂履约组合、自己是否能在不中断用户的情况下把交易跑完”。
四、Shopify 为什么强调“能力分层”：AI 交易不能靠一个大接口解决
在 Shopify 的技术解读中，UCP 最重要的思想之一，是把商业复杂性拆解成“服务—能力—扩展”的分层结构。Shopify 认为，真实商业世界远比“加入购物车—付款”复杂：支付路由、区域差异、折扣叠加、履约组合、税费逻辑、会员权益等因素交织在一起，决定了一笔交易能否真正完成。因此，协议必须允许核心能力稳定存在，同时支持扩展能力持续演进。
Shopify 对 UCP 的分层能力解释
图：Shopify 对 UCP 的分层设计示意，核心能力稳定，扩展能力按需叠加。
这恰恰解释了为什么 Casely 的 profile 会出现 checkout、fulfillment、discount、order 这样的结构。它们不是散乱的功能列表，而是在同一套协议语言下，被拆解为可协商、可组合、可独立演进的能力模块。对于 AI Agent 来说，这种设计很重要，因为它不必一次性理解所有商家特例，而可以先理解核心能力，再按需加载和协商扩展。
五、这份文件里最有含金量的部分，其实是支付
Casely 的 profile 中声明了两个支付处理器：com.google.pay与 dev.shopify.card。从 UCP 的角度看，payment handler 不是简单的“支持哪些支付方式”，而是一种标准化的支付处理规范：它告诉平台，商家接受哪些支付工具、应如何初始化、如何返回 token、如何映射为 UCP 中的 payment instrument，以及商家将如何处理这些支付对象。UCP 官方专门将 payment handler 定义为提升平台、商家与支付提供方互操作性的关键机制。
先看 com.google.pay。Google 官方文档说明，这个 handler 的核心是 headless integration model：商家提供自己的 Google Pay 配置，包括 merchant identity、可接受的卡网络、tokenization 方式等；平台负责拉起前端 Google Pay 交互，获取安全 token，再按 UCP 的 instrument schema 回传给商家完成支付。Casely 当前公开配置中的 merchant name、merchant id、merchant origin、allowed card networks，以及基于 Shopify gateway 的 tokenization 参数，都说明它已经具备被兼容平台调起 Google Pay 交易的条件。
再看 dev.shopify.card。Shopify 的卡支付 handler schema 表明，商家通过这一 handler 对外声明自己接受的卡品牌。Casely 当前列出的包括 Visa、Mastercard、American Express、Discover 与 Diners Club。这意味着过去隐藏在 PSP 配置和前端结账页面中的支付可用性，如今正在提前成为 AI 可发现、可协商的协议能力。对于 Agentic Commerce 来说，这一步非常关键：AI 在交易前就能知道哪些支付路径可行，而不是走到最后一步才发现“不支持该支付方式”。
如果只用一句话概括这一层变化，那就是：支付正在从页面元素，变成协议对象。
六、Shopify 在 UCP 中真正做的，不只是“接入 AI”，而是“重写 checkout 的底层表达”
Shopify 对 UCP 的解读里，有一个非常重要的判断：并不是所有交易都能由 AI 一步自动完成。真实世界中的商业流程，经常会遇到缺失信息、合规限制、支付确认、特殊履约规则等问题。因此，UCP 被设计成一种既支持自动化，又支持人机协作接力的协议系统。
Shopify 明确将 checkout 的推进过程表达为一套状态机：例如 incomplete、requires_escalation、ready_for_complete。这意味着，当 AI 能完成的部分，它就继续完成；当 AI 无法继续时，协议会通过 continue_url或 embedded checkout 机制，把流程平滑地交还给用户。也就是说，UCP 的目标不是“100% 无人化电商”，而是“最大化自动化、最小化断裂感的人机协同交易”。
Shopify 展示的 Checkout 完成状态图
图：Shopify 对 UCP checkout 状态推进的说明，强调自动化与人工接力并存。
从这个角度再回看 Casely 同时支持 mcp与 embedded，就会发现这不是冗余设计，而恰恰说明它的实现逻辑与 Shopify 所倡导的人机协同交易模型高度一致：能自动完成的，由 AI 继续推进；不能自动完成的，平滑切回用户接手。这比“全自动购买”的想象更现实，也更接近真实商业的大规模落地路径。
因此，对 Shopify 而言，UCP 的战略意义并不是“增加了一个 AI 流量入口”，而是把自身过去沉淀最深的能力——checkout、支付、履约、规则编排、嵌入式协作——标准化、协议化，并输出为未来 AI 交易网络可以调用的底层基础设施。
七、从行业演进看，/.well-known/ucp很可能会成为品牌新的标准入口
Google 已经明确将 UCP 与 AI Mode、Gemini 等购物场景直接关联起来，并强调商家接入后，可以在 Google 的 AI 界面中承接更直接的购买行为。与此同时，UCP 路线图也显示，协议未来还将继续向多商品购物车、会员权益、账户关联、售后与生命周期管理、跨市场本地化等方向拓展。今天我们看到的 Casely 案例，很可能只是一个起点。
当协议从单品 checkout 延伸到购物全旅程时，品牌面临的竞争也会发生变化。过去，品牌争夺的是“搜索结果里的位置”；未来，品牌还要争夺“AI 交易网络中的可调用优先级”。而决定这一点的，不再只是页面文案，而是你是否具备足够结构化、稳定、可协商的交易能力输出。谁能把商品、履约、优惠、支付、订单与会员体系表达成清晰的机器协议，谁就更容易进入 AI 时代的新分发体系。
也正因此，我们的判断是：/.well-known/ucp这类链接，未来很可能会像 SEO 时代的 sitemap、schema markup，或平台时代的 product feed 一样，成为品牌的“标准设施”。它未必被消费者看见，但它会决定品牌能否被 AI 交易系统真正理解。
结语：AI 电商的下一场竞争，不在页面，而在协议
如果要用一句话概括 Casely 这份文件的价值，那就是：
AI 电商正在从“流量入口竞争”，走向“交易协议竞争”。
当用户越来越多地在 AI 界面里完成商品发现、比较、选择与购买时，品牌和平台之间的接口形态一定会变化。网页不会消失，App 也不会消失，但它们不再是唯一入口。越来越多的交易前置动作，会转移到 AI Agent 与商家系统之间的协议协商层。
在这个新阶段，真正决定品牌 AI 竞争力的，不只是内容写得好不好，而是商业能力能不能被稳定调用；不只是能不能被看见，而是能不能被执行；不只是有没有支付方式，而是支付方式能不能被标准化协商。Casely 这份 UCP profile 的价值，正在于它把这种变化提前展示了出来。
从更长期看，Shopify 与 Google 共同推动 UCP，可能会成为 AI 电商基础设施演进中的一个关键节点。它标志着一个新趋势的到来：未来的品牌，不只是一个网站、一个店铺、一个前端界面，更是一组可以被 AI 安全调用的交易能力。
未来电商的核心竞争力，不只是“被 AI 看见”，而是“被 AI 交易”。
/.well-known/ucp不是一个隐藏链接，而是品牌写给 AI 世界的交易能力说明书。
Shopify 正在做的，不是为 AI 增加一个入口，而是把 checkout 本身变成 AI 时代的标准基础设施。