核心要点（TL;DR）

• 通用商务协议(UCP) 是一个开放标准，实现AI平台、企业、支付提供商和凭证提供商之间的无缝互操作性，无需定制集成
• 通用商务协议 通过提供标准化的结账、订单管理、身份关联和支付处理API，解决了碎片化的商务流程问题
• 基于行业标准(REST、JSON-RPC、MCP、A2A)构建，内置对AP2协议和A2A协议的支持，通用商务协议 实现了真正的智能商务
• 由Google、Shopify、Etsy、Wayfair、Target和Walmart等行业领导者共同开发，并获得60+组织的认可，包括Adyen、Mastercard、PayPal、Stripe和Visa

目录

1. 什么是通用商务协议(UCP)？
2. 为什么通用商务协议很重要
3. 通用商务协议架构
4. 通用商务协议核心能力
5. 通用商务协议扩展
6. 通用商务协议与支付架构
7. 通用商务协议传输层
8. 通用商务协议与AP2和A2A的集成
9. 通用商务协议入门
10. 通用商务协议路线图
11. 关于通用商务协议的常见问题

什么是通用商务协议(UCP)？

通用商务协议(UCP) 是一个开放标准，旨在促进不同商务实体之间的通信和互操作性。在消费者界面/平台、企业、支付提供商和身份提供商运行在不同系统上的碎片化环境中，通用商务协议 提供了标准化的通用语言和功能原语。

通用商务协议 定义了智能商务的构建块——从发现和购买到购买后体验——允许生态系统通过一个标准进行互操作，无需自定义构建。通用商务协议 作为平台、智能体和企业的通用语言，实现整个商务生命周期的无缝协作。

通用商务协议的关键目标

通用商务协议 围绕四个基本目标构建：

目标	描述
互操作性	弥合消费者界面、企业和支付生态系统之间的差距
发现	允许消费者界面动态发现企业支持的功能（例如，"他们支持访客结账吗？"、"他们有忠诚度计划吗？"）
安全性	促进基于标准的(OAuth 2.0、PCI-DSS合规模式)敏感用户和支付数据的安全交换
智能商务	使AI智能体能够代表用户完成复杂任务，如"找到低于100美元的耳机并购买"

专业见解

通用商务协议 旨在解决商务中的"N对N"复杂度问题。UCP不需要每个平台和每个企业之间都进行自定义集成，而是提供了一个所有各方都可以实施的单一标准，大幅降低了集成成本和上市时间。

为什么通用商务协议很重要

传统商务系统假设人类直接与受信任的界面交互。AI智能体的兴起打破了这一基本假设，创造了 通用商务协议 解决的三个关键挑战：

1. 碎片化的商务流程

没有标准化，每个平台都必须为每个企业构建自定义集成，导致：

• 由于集成失败而导致的购物车放弃
• 购物者体验不一致的挫败感
• 支持多个平台的企业开发成本高昂

通用商务协议 通过提供适用于所有平台和企业的单一标准来消除这种碎片化。

2. 智能商务需求

AI智能体需要：

• 动态发现企业能力
• 安全协商支付方式
• 以编程方式处理复杂的结账流程
• 管理购买后体验

通用商务协议 提供了真正的智能商务所需的基本要素，使AI智能体能够自主完成购买，同时保持安全性和用户控制。

3. 支付互操作性

支付生态系统涉及多个参与方：

• 平台（AI智能体、应用、网站）
• 企业（零售商、服务提供商）
• 支付凭证提供商（数字钱包、银行）
• 支付服务提供商（Stripe、Adyen、PayPal）

通用商务协议 将支付工具与支付处理器解耦，在保持安全性和合规性的同时，实现提供商之间的开放互操作性。

通用商务协议架构

通用商务协议 采用基于角色的架构，有四个主要参与者：

角色与参与者

角色	职责	示例
平台	代表用户面向消费者的界面。发现企业、启动结账、呈现UI。	AI购物助手、超级应用、搜索引擎
企业	销售商品/服务的实体。作为记录商户(MoR)，保留财务责任。	零售商、航空公司、酒店连锁、服务提供商
凭证提供商	安全管理支付工具和用户数据的受信任实体。	数字钱包(Google Wallet、Apple Pay)、身份提供商
支付服务提供商	处理支付、授权、结算的金融基础设施。	Stripe、Adyen、PayPal、Braintree、Chase Paymentech

核心概念

通用商务协议 围绕三个基本构造展开：

1. 能力(Capabilities)

能力是企业支持的独立核心功能。这些是协议的"动词"。

核心能力：

• com.ucp.shopping.checkout - 促进结账会话创建和管理
• com.ucp.shopping.order - 启用订单生命周期管理和webhook
• com.ucp.common.identity_linking - 基于OAuth 2.0的账户关联

2. 扩展(Extensions)

扩展是通过extends字段增强另一个能力的可选能力。扩展与核心能力一起出现在ucp.capabilities[]中。

官方扩展：

• com.ucp.shopping.fulfillment - 扩展结账功能，添加配送/取货选项
• com.ucp.shopping.discount - 扩展结账功能，添加折扣代码支持
• com.ucp.shopping.buyer_consent - 扩展结账功能，添加隐私同意字段
• com.ucp.shopping.ap2_mandate - 扩展结账功能，添加AP2协议加密授权

3. 服务(Services)

服务定义用于交换数据的底层通信层。通用商务协议与传输无关，但定义了特定的绑定以实现互操作性。

支持的传输：

• REST API - 使用OpenAPI 3.x的主要传输
• MCP (Model Context Protocol) - 用于LLM集成的JSON-RPC绑定
• A2A (Agent2Agent Protocol) - 用于智能体间通信的智能体卡片规范
• 嵌入式协议 - 用于嵌入式结账体验的JSON-RPC

发现与协商

通用商务协议 使用服务器选择架构，其中：

1. 企业在/.well-known/ucp发布其配置文件，声明支持的能力
2. 平台在每个请求中宣传其配置文件URI
3. 企业计算能力交集（双方都支持的内容）
4. 没有父能力的扩展会自动被修剪

这种协商在正常的请求/响应流中自动发生，无需单独的协商阶段即可实现高效的能力发现。

通用商务协议核心能力

结账能力

结账能力（com.ucp.shopping.checkout）是 通用商务协议 的基础。它使平台能够促进具有复杂购物车逻辑、动态定价、税费计算和支付处理的结账会话。

关键特性：

• 多商品购物车支持
• 动态定价和税费计算
• 支付处理器协商
• 具有严重性级别的错误处理
• 用于买家交接的继续URL

结账状态生命周期：

incomplete ↔ requires_escalation
     ↓              ↓
ready_for_complete → complete_in_progress → completed
     ↓
  canceled (can occur from any state)

状态值：

• incomplete - 缺少必需信息，平台应通过更新结账来解决
• requires_escalation - 需要通过continue_url进行买家输入
• ready_for_complete - 已收集所有信息，平台可以完成
• complete_in_progress - 企业正在处理完成
• completed - 订单已成功下单
• canceled - 会话无效或已过期

订单能力

订单能力（com.ucp.shopping.order）使企业能够推送关于订单生命周期事件的异步更新，包括配送、交付、退货和退款。

关键组件：

1. 订单项 - 购买的内容，带有数量跟踪（总数、已履行）
2. 履行 - 交付期望和事件（已发货、运输中、已交付）
3. 调整 - 订单后事件（退款、退货、信用、争议）

事件机制： 企业通过webhook向平台提供的URL发送订单更新。Webhook使用JWT (RFC 7797)进行签名以进行验证。

身份关联能力

身份关联能力（com.ucp.common.identity_linking）使平台能够获得OAuth 2.0授权，以代表用户执行操作。

关键特性：

• 标准OAuth 2.0授权代码流程
• 通过/.well-known/oauth-authorization-server进行RFC 8414发现
• UCP特定作用域（例如，ucp:scopes:checkout_session）
• 令牌撤销支持（RFC 7009）
• 通过OpenID RISC Profile 1.0进行跨账户保护

通用商务协议扩展

履行扩展

履行扩展（com.ucp.shopping.fulfillment）为结账会话添加配送和取货选项。

关键特性：

• 多种履行方式（配送、取货等）
• 目的地管理（地址、商店位置）
• 带定价的配送选项组
• 替代履行方式的可用方法
• 方法无关的渲染（平台无需理解特定类型）

示例结构：

{
  "fulfillment": {
    "methods": [{
      "type": "shipping",
      "line_item_ids": ["shirt", "pants"],
      "destinations": [...],
      "groups": [{
        "options": [
          {"id": "standard", "title": "Standard Shipping", "totals": [...]},
          {"id": "express", "title": "Express Shipping", "totals": [...]}
        ]
      }]
    }]
  }
}

折扣扩展

折扣扩展（com.ucp.shopping.discount）支持折扣代码提交和自动折扣应用。

关键特性：

• 提交一个或多个折扣代码
• 接收带有可读标题的已应用折扣
• 通过messages[]数组传达被拒绝的代码
• 自动折扣与基于代码的折扣一起显示
• 显示折扣如何分配的分配明细

分配方法：

• each - 独立应用于每个符合条件的商品
• across - 按价值比例分配

买家同意扩展

买家同意扩展（com.ucp.shopping.buyer_consent）使平台能够传输买家关于数据使用和通信偏好的同意选择。

同意类别：

• analytics - 用于分析的数据使用
• preferences - 个性化偏好
• marketing - 营销通信
• sale_of_data - 数据销售同意

此扩展帮助企业遵守CCPA和GDPR等隐私法规。

AP2授权扩展

AP2授权扩展（com.ucp.shopping.ap2_mandate）将 通用商务协议 与AP2协议集成，用于用户授权的加密证明。

关键特性：

• 企业对结账条款提供加密签名
• 平台提供加密签名的授权，证明用户授权
• 不可否认的交易证据
• 支持可验证数字凭证(VDC)
• SD-JWT与密钥绑定格式

安全绑定： 一旦协商此扩展，会话将被安全锁定。任何一方都不能恢复到标准（未受保护）的结账流程。

通用商务协议与支付架构

通用商务协议 采用解耦的支付架构，解决了平台、企业和支付凭证提供商之间的"N对N"复杂度。

支付处理器模型

支付处理器是规范（而非实体），定义如何处理支付工具。它们分离：

• 支付工具 - 接受的内容（卡、钱包等）
• 支付处理器 - 如何处理工具（令牌化规范）

信任三角：

1. 企业 ↔ 支付凭证提供商 - 预先存在的法律/技术关系
2. 平台 ↔ 支付凭证提供商 - 平台对数据进行令牌化但不拥有资金
3. 平台 ↔ 企业 - 平台将令牌/授权传递给企业以完成

支付生命周期

支付过程遵循3步生命周期：

1. 协商 - 企业宣传可用的处理器及其配置
2. 获取 - 平台与支付凭证提供商执行处理器逻辑
3. 完成 - 平台向企业提交不透明的凭证

安全原则：

• 凭证仅从平台流向企业（单向）
• 平台处理令牌，而非原始PAN（PCI-DSS范围最小化）
• 处理器ID路由确保正确的密钥使用（防止密钥混淆攻击）

PCI-DSS范围管理

平台范围最小化：

• 使用提供不透明凭证的处理器
• 绝不访问或存储原始支付数据
• 转发凭证但无法直接使用

企业范围最小化：

• 使用提供商托管的令牌化
• 使用具有加密凭证的钱包提供商
• 绝不记录原始凭证
• 委托给PCI认证的提供商

通用商务协议架构架构

通用商务协议 使用JSON Schema进行数据验证和自描述能力。理解架构架构对于正确实施 通用商务协议 至关重要。

架构类别

通用商务协议 定义了四种架构类别：

类别	目的	必需字段
能力架构	定义协商的能力	$schema, $id, title, description, name, version
组件架构	能力内的数据结构	$schema, $id, title, description
类型架构	可重用的类型定义	$schema, $id, title, description
元架构	协议结构定义	$schema, $id, title, description

自描述架构

通用商务协议 中的能力架构必须是自描述的。当平台获取架构时，它应该准确确定它代表什么能力和版本，而无需交叉引用其他文档。

为什么自描述？

• 独立版本控制 - 能力可以独立版本化
• 验证 - 验证器可以交叉检查能力声明
• 开发者体验 - 立即明确架构目的
• 紧凑命名空间 - 反向域名标识符（例如，com.ucp.shopping.checkout）

架构组合

通用商务协议 中的扩展使用allOf组合来扩展基础架构：

{
  "$defs": {
    "checkout": {
      "allOf": [
        {"$ref": "checkout.json"},
        {
          "type": "object",
          "properties": {
            "discounts": {"$ref": "#/$defs/discounts_object"}
          }
        }
      ]
    }
  }
}

这种组合模型允许 通用商务协议 维护干净的基础架构，同时支持灵活的扩展。

通用商务协议传输层

通用商务协议 支持多种传输协议，使平台和企业能够选择最适合其用例的方案。

REST传输（主要）

主要传输使用HTTP/1.1+和RESTful模式：

• Content-Type: application/json
• 标准HTTP动词（POST、GET、PATCH）
• 标准HTTP状态代码
• OpenAPI 3.x规范

Model Context Protocol (MCP)

UCP能力与MCP工具1:1映射。企业可以公开一个包装其UCP实现的MCP服务器，允许LLM直接调用create_checkout等工具。

Agent-to-Agent Protocol (A2A)

企业可以将支持UCP的A2A智能体公开为A2A扩展，使平台能够通过结构化的UCP数据类型进行集成。通用商务协议与A2A协议无缝集成，用于智能体间通信。

嵌入式协议（EP）

企业可以嵌入结账界面，在用户交互时接收事件，委托关键用户操作。启动通过企业返回的continue_url进行。

通用商务协议与AP2和A2A的集成

通用商务协议与AP2协议

通用商务协议与AP2协议完全兼容。AP2作为智能体主导交易的信任层，要求安全、可验证的意图和授权交换。

关键优势：

• 绑定证明 - 提供和同意内容的加密证据
• 欺诈减少 - 支付授权范围限定为结账哈希，防止令牌重放
• 智能体就绪 - 允许自主AI智能体在可验证边界内进行交易

协议流程：

1. 发现 - 企业声明AP2支持
2. 会话激活 - 平台发出AP2激活信号
3. 签名（企业） - 企业提供checkoutSignature（分离的JWT）
4. 授权 - 平台生成CheckoutMandate和PaymentMandate
5. 完成 - 平台向/complete端点提交授权
6. 验证 - 企业和PSP验证授权
7. 确认 - 支付已处理，订单已确认

通用商务协议与A2A协议

通用商务协议与A2A协议集成，用于智能体间通信。A2A使智能体能够以其自然模式协作，而UCP提供商务特定的原语。

互补角色：

• A2A协议 - 用于智能体协作的应用层协议
• 通用商务协议 - 商务特定的能力和数据模型

它们共同使AI智能体能够发现企业、协商结账条款并自主完成购买。

通用商务协议入门

对于开发者

通用商务协议为开发者提供全面的资源：

1. 技术规范 - 在ucp.dev的完整协议文档
2. GitHub仓库 - 在github.com/Universal-Commerce-Protocol/ucp的开源实现和示例
3. 代码示例 - 多种语言的参考实现
4. Playground - 在ucp.dev/playground的交互式演示

对于企业

企业可以集成 通用商务协议 以：

• 在任何地方满足客户（AI助手、购物智能体、嵌入式体验）
• 保持记录商户身份，完全拥有客户关系
• 保留对业务规则和逻辑的控制
• 避免为每个平台重建结账

集成步骤：

1. 在/.well-known/ucp实现UCP配置文件
2. 支持核心能力（结账、订单）
3. 根据需要添加扩展（履行、折扣）
4. 配置支付处理器
5. 为订单事件设置webhook端点

对于AI平台

AI平台可以使用 通用商务协议 来：

• 通过标准化API简化企业入驻
• 提供集成的购物体验
• 支持多种传输协议（REST、MCP、A2A）
• 通过AP2集成启用自主智能体商务

对于支付提供商

支付提供商可以：

• 定义支付处理器规范
• 发布处理器架构和配置
• 支持多种支付工具
• 与AP2集成以进行加密授权

通用商务协议路线图

通用商务协议遵循分阶段开发方法，即将到来的优先事项包括：

对完整消费者旅程的更深支持

扩展到支持孤立交易之外的内容：

• 产品发现 - 促进整个购物旅程
• 购物车和篮子构建 - 具有复杂规则的多商品结账
• 忠诚度和会员福利 - 账户关联和个性化优惠
• 原生交叉销售和追加销售 - 个性化推荐

对全球市场的支持

分阶段推出到包括以下市场：

• 印度
• 印度尼西亚
• 拉丁美洲
• 其他区域市场

调整 通用商务协议 以支持更广泛的区域用例和本地化支付互操作性。

社区驱动的演进

通用商务协议由行业构建，为行业服务。路线图反映了战略优先事项，但根据社区反馈和业务需求保持灵活。

关于通用商务协议的常见问题

Q: 通用商务协议与其他商务API有何不同？

A: 通用商务协议专门为智能商务和互操作性而设计。与专有API不同，UCP提供：

• 标准化能力发现和协商
• 多种传输协议支持（REST、MCP、A2A）
• 内置安全性，集成AP2
• 用于灵活功能添加的扩展模型
• 具有行业广泛采用的开放标准

Q: 通用商务协议如何确保安全性？

A: 通用商务协议实施多层安全：

• OAuth 2.0用于身份关联
• PCI-DSS合规的支付模式
• AP2协议集成用于加密授权
• 基于JWT的webhook签名
• 单向凭证流（仅从平台到企业）

Q: 通用商务协议能否与现有支付系统配合使用？

A: 是的。通用商务协议设计为与现有支付基础设施配合使用：

• 支持所有主要支付方式（卡、钱包、银行转账、加密货币）
• 与现有PSP集成（Stripe、Adyen、PayPal等）
• 不需要更改现有风险/欺诈系统
• 为更好的风险评估提供额外信号

Q: 通用商务协议、AP2和A2A之间的关系是什么？

A: 这些协议是互补的：

• 通用商务协议 - 商务特定的能力和数据模型
• AP2协议 - 用于智能体支付的信任层，具有加密授权
• A2A协议 - 智能体间通信协议

UCP集成AP2以进行安全支付，并可以使用A2A作为传输层。

Q: 企业如何开始使用通用商务协议？

A: 企业可以通过以下方式开始：

1. 在ucp.dev查看技术规范
2. 实现UCP配置文件端点（/.well-known/ucp）
3. 支持核心能力（结账、订单）
4. 使用UCP Playground进行测试
5. 与支持 通用商务协议 的平台集成

Q: 通用商务协议支持哪些编程语言？

A: 通用商务协议与语言无关。它使用：

• JSON进行数据交换
• 标准HTTP用于REST传输
• JSON-RPC用于MCP/A2A传输
• OpenAPI/OpenRPC规范

参考实现可在Python和TypeScript中使用，社区贡献了其他语言的实现。

Q: 通用商务协议如何处理架构版本控制？

A: 通用商务协议使用基于日期的版本控制（YYYY-MM-DD格式）进行架构：

• 每个能力架构在version字段中声明其版本
• 架构是自描述的，带有name和version字段
• 平台验证架构URL是否匹配命名空间授权
• 独立版本控制允许能力以不同速度演进

Q: 通用商务协议中的命名空间治理模型是什么？

A: 通用商务协议使用反向域名命名：

• UCP能力：com.ucp.*命名空间（由UCP机构管理）
• 供应商能力：com.{vendor}.*命名空间（供应商控制）
• 不需要中央注册表 - 基于DNS的命名空间治理
• 规范URL必须匹配命名空间授权来源

Q: 通用商务协议如何处理版本控制？

A: 通用商务协议使用基于日期的版本控制（YYYY-MM-DD格式）：

• 协议与能力独立版本化
• 每个能力独立版本化
• 强大的向后兼容性保证
• 明确的破坏性变更策略

Q: 供应商可以扩展通用商务协议吗？

A: 是的。通用商务协议支持供应商能力：

• 供应商使用反向域名命名空间（例如，com.shopify.loyalty）
• 供应商能力独立版本化
• 相同的自描述架构要求
• 不需要中央注册表

Q: 通用商务协议中能力和扩展的区别是什么？

A: 在 通用商务协议 中：

• 能力 - 独立的核心功能（结账、订单、身份关联）
• 扩展 - 增强能力的可选功能（履行扩展结账）

扩展使用extends字段声明其父能力，如果父能力不在能力交集中，则自动被修剪。

Q: 通用商务协议如何支持AI智能体？

A: 通用商务协议通过以下方式启用AI智能体：

• 能力发现用于动态业务功能检测
• 具有错误处理的程序化结账流程
• AP2集成用于具有加密证明的自主交易
• 多种传输选项（REST、MCP、A2A）适用于不同的智能体框架
• 针对智能体处理优化的结构化数据模型

总结与下一步

通用商务协议(UCP) 代表了向标准化、可互操作商务的根本转变。通过为平台、企业和支付提供商提供通用语言，通用商务协议 消除了对自定义集成的需求，同时实现了真正的智能商务。

通用商务协议的关键优势

优势	影响
互操作性	单一标准适用于所有平台和企业
安全性	内置对OAuth 2.0、PCI-DSS模式和AP2加密授权的支持
灵活性	多种传输协议和用于自定义功能的扩展模型
行业支持	由Google、Shopify、Etsy、Wayfair、Target、Walmart共同开发，并获得60+组织的认可

推荐的下一步

1. 探索规范 - 在ucp.dev/specification查看完整技术文档
2. 尝试Playground - 在ucp.dev/playground体验交互式演示
3. 查看代码示例 - 在github.com/Universal-Commerce-Protocol/samples查看参考实现
4. 加入社区 - 在github.com/Universal-Commerce-Protocol/ucp贡献反馈和代码

通用商务协议正在社区输入的基础上积极演进。无论您是构建下一代商务体验的开发者、希望在任何地方触达客户的企业，还是启用安全交易的支付提供商，通用商务协议都为可互操作的智能商务提供了基础。

相关资源：

• AP2协议文档 - 智能经济的安全支付
• A2A协议文档 - 智能体间通信标准
• 通用商务协议GitHub - 开源实现
• 通用商务协议规范 - 完整技术文档
• 通用商务协议指南 - 通用商务协议综合指南