摘要：重构数字经济的交互层
2026年1月，Google 在全美零售联合会 (NRF) 大会上正式发布的通用商业协议 (Universal Commerce Protocol, UCP)，标志着全球数字贸易从“搜索与浏览”时代向“代理式商务 (Agentic Commerce)”时代的决定性转折 。在过去的二十年里，电子商务主要依赖于一种以人类为集成中枢的模式：用户作为连接“发现引擎”（搜索引擎、社交媒体）与“履行引擎”（商家网站、结账页面）的中间件，手动跨越信息孤岛，通过点击、滚动和重复输入支付信息来完成交易。UCP 的推出，旨在通过建立一套标准化的“通用语言”，消除这种摩擦，使人工智能 (AI) 代理能够代表用户自主发现产品、协商条款并执行购买 。
UCP 由 Google 与 Shopify 联合开发，并获得了 Walmart、Target、Wayfair 和 Etsy 等零售巨头的强力支持。它不仅仅是一组新的 API，而是一个旨在解决“N x N 集成瓶颈”的开放标准——即每一个 AI 代理需要为每一个商家构建定制集成的指数级复杂性难题 。通过标准化商业信息的交换格式，UCP 意图成为“商业领域的 HTTP”，为下一代 AI 驱动的数字经济铺设不可见的底层基础设施 。
本报告将对 UCP 框架、其技术架构、配套的代理支付协议 (Agent Payments Protocol, AP2)、以及它对全球零售商、开发者和资本市场引发的深远经济变革进行详尽的深度剖析。
第一部分：战略必要性与市场背景
1.1 传统搜索的危机与“行动引擎”的崛起
UCP 的推出，本质上是 Google 面对传统搜索引擎及其广告商业模式潜在生存危机的一次战略反击。随着以 Gemini、ChatGPT 和 Perplexity 为代表的生成式 AI (Generative AI) 的兴起，用户获取信息的方式正在发生根本性转变：从寻找“十个蓝色链接”的列表，转向寻求直接的答案和任务的完成 。在这种新范式下，用户期望的是结果的交付，而非导航的中转。
然而，在 UCP 问世之前，大语言模型 (LLM) 与互联网的交易层之间存在着根本性的断裂。AI 可以根据参数记忆撰写关于咖啡机的诗歌，或者对比两款相机的技术规格，但它无法可靠地检查并确认用户家附近实体店的实时库存，无法应用特定的忠诚度折扣，更无法在不产生幻觉或不跳转页面的情况下执行购买 。这种“执行鸿沟 (Execution Gap)”将 AI 限制在了被动顾问的角色，而非真正的主动代理。
Google 通过 UCP 实施的战略机动，旨在跨越这一鸿沟，将其搜索界面从“推荐引擎”转型为“交易引擎”。通过在 Google 搜索和 Gemini 的 AI 模式 (AI Mode) 中启用“原生结账 (Native Checkout)”，Google 试图捕获那些高意图的商业时刻——这些时刻以往可能会流失到 Amazon 这样的封闭生态系统或垂直领域的应用程序中 。这种转变既是防御性的（保护 Google 在商业搜索领域的主导地位），也是进攻性的（试图将商业的接口层商品化，同时确立底层数据交换的新标准）。
1.2 “反亚马逊联盟”：零售商为何结盟
UCP 的首发合作伙伴阵容——Shopify, Walmart, Target, Etsy, Wayfair——揭示了一个清晰的战略意图：针对商业权力中心化（主要以 Amazon 为代表）的联合防御 。多年来，零售商面临着两难的囚徒困境：要么依赖 Amazon 巨大的流量但牺牲数据所有权和利润率，要么维持独立的品牌网站但在流量获取和转化摩擦中苦苦挣扎。
UCP 提供了一条“第三条道路”：联邦式商业模式 (Federated Commerce Model)。通过采用 UCP，像 Shopify 和 Walmart 这样的零售商可以将其产品目录和结账能力暴露给数以百万计的 AI 代理（首先是 Google 的），同时不放弃“记录商家 (Merchant of Record)”的地位 。至关重要的是，UCP 的设计理念确保了商家保留客户关系、交易数据和业务逻辑。协议负责“协商”交易，但最终由商家“执行”交易。
对于 Shopify 而言，UCP 充当了一个巨大的分发乘数。它允许其平台上的数百万商家瞬间变得“代理就绪 (Agent-Ready)”，有效地将每一个 Shopify 店铺转化为一个可以被 AI 买家访问的无头 (Headless) 节点 。这与 Shopify “无处不在的商业 (Commerce Everywhere)” 战略高度契合，将其触角从传统的在线商店延伸到了社交媒体、游戏，以及现在的 AI 代理中。
1.3 破解“N x N”集成瓶颈
要理解 UCP 的必要性，必须分析标准化之前代理式商务面临的技术壁垒。在没有统一协议的情况下，任何希望启用购物功能的 AI 代理开发商，都需要为 Shopify、Magento、Salesforce Commerce Cloud、WooCommerce 以及成千上万个定制的企业技术栈编写特定的 API 连接器。每一个连接都意味着独立的维护成本、独特的身份验证流程和差异化的错误处理机制。
这就造成了一个经典的“N x N”复杂性问题： 个 AI 代理乘以 个商家 。这种复杂性仅有利于那些拥有无限工程资源的巨头，而将中小企业和新兴的 AI 初创公司拒之门外。UCP 将这种复杂性坍缩为 模型。一个代理只需要“会说” UCP 语言；任何“会说” UCP 语言的商家就都变得可访问。这种标准化类似于 SMTP 协议如何允许不同服务商之间互发电子邮件，或者 HTML 如何允许浏览器渲染来自任何服务器的网页 。
第二部分：UCP 技术架构深度剖析
UCP 技术架构
2.1 核心设计哲学：基于能力的协商 (Capability-Based Negotiation)
UCP 的核心不仅仅是数据传输，它是关于发现与协商的协议。与要求严格遵守静态模式的刚性 API 不同，UCP 承认商业现实的混乱性——不同商家的折扣规则、运输选项和税收计算逻辑千差万别 。该架构模仿了人类商务中的“握手”机制，代理和商家服务器交换各自的“能力 (Capabilities)”以确定交易的参数。
系统采用分层架构以确保可扩展性和稳定性 ：
- 购物服务层 (Shopping Service Layer)： 定义交易的不可变原语——结账会话 (Checkout Session)、行项目 (Line Items)、总计 (Totals)、消息 (Messages) 和状态 (Status)。这确保了每一次 UCP 交互都共享相同的基本 DNA。
- 能力层 (Capabilities Layer)： 代表主要的功能区域（例如：结账、订单追踪、目录发现）。这些能力是独立版本化的，允许商家在不破坏其目录浏览能力的情况下升级其结账能力。
- 扩展层 (Extensions Layer)： 这是最灵活的一层，允许领域特定的模式。例如，家具零售商可以使用“预约配送”扩展，而数字商品卖家则使用“即时下载”扩展。
2.2 发现机制：.well-known/ucp
任何 UCP 交互的入口点都是发现阶段。模仿现有的 Web 标准，兼容 UCP 的商家会在一个标准化的端点发布 JSON 清单 (Manifest)：/.well-known/ucp 。
当一个 AI 代理（例如 Gemini 或第三方购物机器人）访问商家的域名时，它首先查询此端点。响应内容充当了服务的“菜单”，声明如下信息：
- 支持的能力： “我支持 Checkout v1.0 和 Order Tracking v2.0。”
- 支持的支付处理程序： “我接受 Google Pay, Shop Pay, 和 Apple Pay。”
- 支持的扩展： “我支持‘忠诚度积分’扩展和‘店内取货’扩展。”
- 身份验证要求： “我需要 OAuth 2.0 进行用户识别。”
这种机制将代理与商家的后端实现解耦。代理不需要知道商家运行的是 Shopify 还是定制的 Python 服务器；它只需要能够读取 UCP 清单 。
2.3 动态协商逻辑
一旦代理读取了清单，“协商”过程即刻开始。这是对代理能做什么与商家需要什么之间交集的实时计算 。
-
场景示例： 用户要求代理“买这双跑鞋，并使用我的退伍军人折扣。”
-
协商过程： 代理检查商家的 UCP 配置文件。
-
商家侧： “我支持
dev.ucp.shopping.discount扩展。” -
代理侧： “我也支持
dev.ucp.shopping.discount。我将传输折扣代码。” -
结果： 折扣代码输入字段会在交易载荷中暴露出来。
反之，如果商家不支持折扣扩展，代理会先验地知道不应向用户提供该选项，从而防止了“功能幻觉”带来的挫败感。这种动态协商发生在每一次请求中，类似于 HTTP 内容协商，确保了交易的高保真度 。
2.4 传输与绑定 (Transports and Bindings)
UCP 是传输无关的 (Transport-Agnostic)，这意味着它不绑定于单一的数据传输方式。规范定义了多种传输协议的绑定，以确保最大的兼容性 ：
| 传输协议 | 适用场景 | 优势 |
|---|---|---|
| HTTP/REST | 基于 Web 的标准交互 | 易于与现有的电子商务微服务集成，通用性最强。 |
| JSON-RPC | 有状态、双向通信 | 适用于需要快速交换多条消息的场景（例如：用户添加商品时实时更新购物车）。 |
| Agent2Agent (A2A) | 代理间直接通信 | 允许“购物者代理”与“商家代理”在无人干预的情况下进行对话与协作。 |
| Model Context Protocol (MCP) | LLM 数据连接标准 | UCP 包含 MCP 绑定，实际上允许任何兼容 MCP 的 LLM（如 Claude 或 ChatGPT）立即“插入”UCP 商业轨道 。 |
2.5 结账流程：原生 vs. 嵌入式
UCP 支持两种主要的结账模式，以适应不同程度的信任和复杂性需求 。
2.5.1 原生结账 (Native Checkout - The "Headless" Path)
在此流程中，交易完全在 AI 界面（例如 Gemini 聊天窗口）内发生。商家的 API 提供数据，AI 负责渲染 UI 组件（产品卡片、运输选择器、“购买”按钮）。
- 优势： 无缝的用户体验；零上下文切换；由于摩擦减少，转化率通常更高。
- 劣势： 商家对视觉品牌的控制力较弱。
- 机制： 代理调用
checkout_session端点，创建会话 ID。它通过 API 调用更新行项目。当用户确认时，代理通过 AP2 提交支付令牌至complete端点。
2.5.2 嵌入式结账 (Embedded Checkout - The "Handoff" Path)
对于复杂的购买（例如：定制配置的笔记本电脑、需要处方的药品），原生流程可能不足以应对。UCP 支持嵌入式能力。
- 机制： 商家在结账会话载荷中提供一个
continue_url。 - 流程： 代理将用户导航至商家托管的安全 Web 视图或 iframe，以完成特定细节（如上传处方或选择布料样本）。
- 交接 (Handoff)： 至关重要的是，UCP 保持了状态。代理将会话上下文传递给 Web 视图，因此用户无需重新输入信息。一旦特定任务完成，Web 视图可以通过 JSON-RPC 消息将控制权交还给代理 。
2.6 身份与安全：OAuth 2.0 与账户链接
商业交易需要知道谁在购买。UCP 利用行业标准的 OAuth 2.0 协议进行身份链接 。
- 流程： 当用户想要购买时，代理检查是否拥有该商家的令牌。如果没有，它会提示用户“链接账户”。
- 授权： 用户被短暂重定向到商家的登录页面（或使用保存的 Passkey），授予代理
ucp:scopes:checkout_session权限。 - 令牌： 代理接收刷新令牌，允许其在未来进行购买时无需每次都重新验证用户（受安全策略限制）。
- 访客结账： UCP 也支持标准化的访客结账流程，代理提供运输/账单信息而无需建立永久账户链接 。
2.7 开发者实施指南：无 Shopify 场景下的手动集成
对于不使用 Shopify 的开发者或定制平台（如 Magento, WooCommerce），实施 UCP 需要以下技术步骤 ：
- 环境搭建： 使用 Python SDK (UCP 官方提供)。
mkdir sdk
git clone https://github.com/Universal-Commerce-Protocol/python-sdk.git sdk/python
uv sync # 使用 uv 进行依赖管理
- 业务服务器配置： 开发者需要设置一个服务器来托管业务 API，并指向产品数据库。
uv run server.py --products_db_path=/tmp/ucp_test/products.db --port=8182
- 端点实现： 必须实现三个核心 REST 端点：
POST /checkout_sessions: 创建会话。PATCH /checkout_sessions/{id}: 更新购物车（添加商品、应用折扣）。POST /checkout_sessions/{id}:complete: 提交支付并完成订单。
- 清单发布： 在服务器的
/.well-known/ucp路径下托管 JSON 文件，声明支持的能力和支付处理程序。
第三部分：信任层框架 —— 代理支付协议 (AP2)
如果说 UCP 处理的是商业的物流（买什么），那么 代理支付协议 (AP2) 处理的则是风险（怎么付）。与 UCP 同步发布的 AP2 解决了代理式商务最关键的障碍：信任。用户如何信任 AI 花他们的钱？银行如何信任一个由机器人发起的交易是经过人类授权的？
AP2 代理支付协议
3.1 确定性意图 (Deterministic Intent) 的哲学
当前的大语言模型是概率性的——它们预测下一个字。然而，支付必须是确定性的。银行不能处理一笔“大概可能是”50 美元的交易。AP2 通过引入 Mandates（授权指令） 来弥合这一差距：这是一种防篡改、经过加密签名的数字合同，作为用户意图的可验证证明 。
3.2 Mandate 结构与类型
AP2 定义了不同类型的 Mandate，以覆盖不同的交互模型：
表 1：AP2 Mandate 类型解析
| Mandate 类型 | 用户在场状态 | 使用场景 | 安全机制 |
|---|---|---|---|
| 购物车指令 (Cart Mandate) | 人类在场 (Human-Present) | 用户盯着屏幕，批准特定的商品和价格。 | 商家对购物车载荷签名（保证价格/库存）；用户用私钥对该载荷进行“反签 (Countersign)”。 |
| 意图指令 (Intent Mandate) | 人类不在场 (Human-Not-Present) | “价格下跌时帮我买。”（委托授权） | 用户预先签署一套逻辑规则（价格 < X, 商品 = Y）。代理持有此凭证，并在条件满足时出示。 |
- 技术细节： 意图指令实际上是一种受限的预授权。它不像传统的信用卡预授权那样锁定资金，而是锁定“购买条件”。如果代理试图在价格高于 X 时执行购买，或者购买商品 Z 而非 Y，加密签名验证将失败，支付网关会拒绝交易 。
3.3 可验证凭证与支付处理程序
AP2 利用了 W3C 可验证凭证 (Verifiable Credentials, VC) 标准。当一笔支付被提交时，它不仅仅是一个信用卡号；它是一个包含以下内容的捆绑包：
- 支付令牌 (Payment Token)： 代币化的卡信息。
- 签名指令 (Signed Mandate)： 用户意图的证明。
- 加密证明 (Cryptographic Proofs)： 验证代理和商家的身份。
这种结构允许支付处理商（如 Stripe, Adyen, PayPal）区分“用户点击购买”和“代理执行预批准订单”，从而实现复杂的风险建模和欺诈检测 。主要金融机构（Visa, Mastercard, Amex）的参与表明，AP2 指令可能很快成为处理代理发起交易的强制性要求，从而将责任从消费者身上转移开 。
第四部分：生态系统集成与比较分析
4.1 UCP vs. ONDC (印度)
印度的开放数字商务网络 (ONDC) 经常被引用为 UCP 的前身或平行物。虽然两者都共享“解绑”商业和打破平台垄断的理念，但它们在技术堆栈中的层级不同 。
表 2：UCP 与 ONDC (Beckn Protocol) 的架构对比
| 特性 | ONDC (基于 Beckn 协议) | 通用商业协议 (UCP) |
|---|---|---|
| 主要目标 | 民主化电子商务接入；解绑物流、买家应用和卖家应用。 | 标准化代理式 (Agentic) 交互；解决 AI 的技术集成瓶颈。 |
| 架构基础 | 去中心化网络节点注册表；Beckn 协议。 | 标准化 API 模式 & 发现机制；基于 HTTP/JSON。 |
| 核心关注点 | 基础设施（物流配送、超本地化服务）。 | 交互（发现、协商、结账）。 |
| 地理范围 | 主要在印度（政府支持）。 | 全球（Google & Shopify 主导）。 |
| 互操作性 | 关注不同服务提供商（如物流与电商）的互联。 | 关注 AI 代理与商家目录的“对话”。 |
| 关系 | Beckn 是网络的“铁轨”。 | UCP 是代理的“语言”。UCP 可以作为抽象层运行在 ONDC 之上 。 |
值得注意的是，UCP 与 Beckn 的原则是兼容的。事实上，一些分析师将 UCP 描述为一种“通用抽象层”，理论上可以置于 ONDC 网络之上，将 ONDC 特定的物流流程转化为通用全球 AI 代理可以理解的语言 。
4.2 UCP vs. OpenAI 代理商务协议
有迹象表明，OpenAI 正在与 Stripe 合作开发自己的“代理商务协议” 。虽然细节较少，但竞争将非常激烈。
- UCP 的优势： 采取“联盟”策略——拥有 Shopify 和 Walmart 的运营能力，赋予了它即时的库存深度。
- OpenAI 的路径： 可能更依赖 Stripe 的支付轨道。
- 未来格局： UCP 的开源性质以及与 MCP（OpenAI 也受其影响）的兼容性表明，未来可能出现融合，或者类似于 Blu-ray 与 HD DVD 的“格式之战”，商家最终可能被迫支持多个清单文件（如
.well-known/ucp和.well-known/openai-cp）。
4.3 融入“代理堆栈” (Integration with the Agent Stack)
UCP 并非孤立存在，它是 AI 时代“协议堆栈”的一部分 ：
- 通信层 (A2A - Agent2Agent)： 允许不同代理交谈。一个“旅行代理”机器人（使用 A2A）可以与“预订代理”机器人交谈。
- 上下文层 (MCP - Model Context Protocol)： 允许 LLM 理解数据（读取 PDF、查询数据库）。
- 商业层 (UCP)： 允许代理进行交易（协商价格、结账）。
- 信任层 (AP2)： 确保资金安全流动。
这种模块化设计意味着开发者无需重新造轮子。构建“个人造型师”代理的开发者无需构建支付网关；他们只需实施 UCP/AP2，让底层轨道处理金融复杂性。
第五部分：运营 UCP —— 商家与开发者体验
5.1 实施 UCP：从零到一的流程
对于商家而言，成为 UCP 兼容者的过程因平台而异 。
Shopify 商家： 集成基本上是原生的。Shopify 已更新其后端，为其数百万商家自动生成 UCP 清单。管理面板中的一个开关（“启用代理店面”）即可立即将目录暴露给 Google 的 AI 表面 。这赋予了 Shopify 巨大的“先发优势”，瞬间用数百万个 SKU 填充了 UCP 生态系统。
审批与门槛： 目前，Google 对 UCP 的“原生结账”功能实施了严格的准入控制。商家需要通过“候补名单 (Waitlist)”申请，且初期仅限于在美国境内履约并拥有美国银行账户的商家 。这表明在协议早期阶段，Google 极度重视信任和质量控制，宁愿牺牲速度也要防止不良商家利用 AI 渠道进行欺诈。
5.2 新的 SEO：代理优化 (Agent Optimization, AO)
UCP 引入了一门新学科：代理优化 (AO)，作为搜索引擎优化 (SEO) 的继任者 。
- 旧世界 (SEO)： 优化关键词、反向链接和页面加载速度，以在蓝色链接中排名靠前。
- 新世界 (AO)： 优化能力和数据的结构化程度。
- 准确性 (Accuracy)： 代理会严厉惩罚幻觉。如果商家的 UCP 源显示“有货”但结账失败，代理会在内部降低该商家的“可靠性评分”。
- 协商能力 (Negotiation Power)： 暴露细粒度能力的商家（例如：在 UCP 模式中结构化地声明“接受 90 天退货”）将比政策不透明的商家更受代理青睐。
- 风险信号 (Risk Signals)： Google 会将“风险信号”（设备数据、会话数据）回传给商家，允许商家接受/拒绝交易。优化这些阈值对于转化至关重要 。
5.3 风险与挑战：商家的达摩克利斯之剑
尽管 UCP 承诺了覆盖范围，但也给商家带来了重大风险 ：
- 商品化 (Commoditization)： 如果 AI 控制了界面，商家的品牌资产（字体、颜色、氛围）将被剥离。商家变成了单纯的产品管道。
- 利润挤压 (Margin Pressure)： AI 代理是无情的优化器。一个被编程为寻找最低价格的“购物代理”可以瞬间比较 50 个 UCP 兼容卖家并选择最便宜的，这将比人类比价购物更快地侵蚀利润率。
- 数据依赖： 虽然商家保留“记录商家”的身份，但交互数据（用户问了什么，犹豫了多久）主要留在代理（Google）手中，而非商家。UCP 试图通过共享部分信号来缓解这一问题，但主要上下文仍由 AI 掌握。
第六部分：未来展望与经济影响 (2026-2030)
6.1 经济转移：从基于广告到基于交易
UCP 的广泛采用威胁到了价值 2000 亿美元的搜索广告市场 。如果用户停止点击搜索广告，转而通过代理直接购买，“每次点击成本” (CPC) 模式将走向消亡。UCP 暗示了向“每次行动成本” (CPA) 或“每次交易成本”模式的转型。Google 的“直接优惠 (Direct Offers)”功能——商家竞价在 AI 结账流程中直接放置折扣——正是这种新广告模式的雏形 。
摩根士丹利 (Morgan Stanley) 预测，到 2030 年，代理式购物者可能占据美国电子商务支出的 10-20%，代表着 3850 亿美元 的市场转移 。这不仅仅是新钱；这是从“浏览”渠道转移到“代理”渠道的钱。
6.2 “个人参谋长”的崛起
有了 UCP 和 AP2，“个人 AI”的愿景在技术上变得可行。我们很可能会看到专业化“生活代理”的出现：
-
食品储藏室代理： 监控消费习惯，并通过 UCP 自动购买杂货，在用户无需打开应用程序的情况下，跨 Walmart 和 Target 协商批量折扣 。
-
旅行代理： 编排航班、酒店和餐厅预订，持有“意图指令”以便在航班取消时立即重新预订。
6.3 对中小企业 (SME) 的影响
矛盾的是，UCP 可能会为中小企业创造公平的竞争环境。在浏览器时代，小商店无法与 Amazon 的 UI/UX 和物流速度竞争。在 UCP 时代，如果一家小店拥有独特的商品并使用 Shopify（处理 UCP 技术），AI 代理发现它的难易程度与发现 Walmart 一样 。 “发现”将基于产品的相关性，而非营销预算或域名权重。然而，这完全取决于 AI 代理算法的中立性——这将是未来监管的主要战场。
6.4 全球推广与监管摩擦
尽管 UCP 在美国率先推出，但在全球范围面临复杂的道路。欧盟的《数字市场法案》(DMA) 将审查 Google 的“原生结账”是否偏袒其自家的支付轨道 (Google Pay) 或 UCP 合作伙伴。目前的“候补名单”审批流程 已经暗示了一个有门槛的生态系统，这可能会招致反垄断关注。此外，不同地区可能采用不同的协议（如印度的 ONDC），迫使全球代理必须会说多种商业“方言”。
结论
通用商业协议 (UCP) 不仅仅是一份技术规范；它是互联网下一个时代的宣言。它承认 Web 的复杂性已经超出了人类的耐心，必须引入一层 AI 中介来处理繁琐的发现和交易任务。
对于 Google 而言，UCP 是抵御传统搜索相关性下降的护城河。对于 Shopify 和零售商，这是在后 Web 世界中争取分发权的赌注。对于开发者，这是一个新的原语——编写代码来花钱的能力。
正如任何协议一样，成功取决于采用率。凭借全球最大搜索引擎、全球最大电商平台软件 (Shopify) 和全球最大零售商 (Walmart) 的支持，UCP 在第一天就已达到了“逃逸速度”。“商业的 HTTP”已经到来；现在的问题不是代理是否会为我们购物，而是我们多快能信任它们来掌管我们的钱包。
