Electrolux_blog
Search K

Appearance

目录

UCP 核心架构概述 ​

什么是 UCP ​

Universal Commerce Protocol (UCP) 是一个开放标准，旨在解决电商生态系统中不同实体之间的互操作性问题。它提供了一个标准化的通用语言和功能原语，使得平台（如 AI 代理和应用）、商家、支付服务提供商（PSP）和凭证提供商（CP）能够有效沟通。

核心问题 ​

问题背景 ​

在当前的电商生态中，存在以下问题：

  1. 碎片化严重：每个平台都需要为每个商家构建定制化的集成
  2. N-to-N 复杂度：平台、商家、支付提供商之间的集成呈指数级增长
  3. 缺乏标准化：不同系统使用不同的 API 和协议
  4. 安全挑战：支付凭证和用户数据的交换缺乏统一的安全标准
  5. AI 代理支持不足：现有协议难以支持 AI 代理代表用户完成购买

UCP 的解决方案 ​

UCP 通过以下方式解决这些问题：

  • 标准化交互：提供统一的交互方式，无论底层后端如何
  • 模块化商务：将商务功能分解为独立的 Capabilities（能力）和 Extensions（扩展）
  • 动态发现：商家通过标准化 Profile 声明支持的能力，平台可以自主发现和配置
  • 传输无关：支持多种传输协议（REST、MCP、A2A）
  • 安全优先：支持高级安全模式，如 AP2 mandates 和可验证凭证

架构设计 ​

四角色模型 ​

UCP 定义了四个主要参与者：

┌─────────────┐         ┌─────────────┐
│   Platform  │────────│   Business  │
│  (平台)     │         │   (商家)    │
└──────┬──────┘         └──────┬──────┘
       │                      │
       │                      │
┌──────▼──────┐         ┌──────▼──────┐
│ Credential  │         │     PSP     │
│  Provider   │────────│  (支付服务)  │
│  (凭证提供) │         │             │
└─────────────┘         └─────────────┘

1. Platform (平台) ​

职责：

  • 代表用户发现商家能力
  • 发起结账会话
  • 提供 UI 或对话界面

示例：AI 购物助手、超级应用、搜索引擎

关键特性：

  • 通过 Profile 发现商家能力
  • 执行能力协商
  • 处理支付凭证获取
  • 管理结账流程

2. Business (商家) ​

职责：

  • 作为 Merchant of Record (MoR)，保留财务责任和订单所有权
  • 暴露商务能力（库存、定价、税费计算）
  • 履行订单
  • 通过选择的 PSP 处理支付

示例：零售商、航空公司、酒店连锁、服务提供商

关键特性：

  • 在 /.well-known/ucp 发布 Profile
  • 声明支持的能力和扩展
  • 提供支付处理器配置
  • 处理结账和订单生命周期

3. Credential Provider (凭证提供商) ​

职责：

  • 安全管理和共享敏感用户数据
  • 认证用户
  • 发行支付令牌（避免原始卡数据出现在平台上）
  • 安全持有 PII 以最小化其他方的合规范围

示例：数字钱包（Google Wallet、Apple Pay）、身份提供商

关键特性：

  • 提供支付凭证令牌化
  • 支持多种支付方式
  • 确保 PCI-DSS 合规

4. Payment Service Provider (支付服务提供商) ​

职责：

  • 代表商家处理支付
  • 授权和捕获交易
  • 处理结算
  • 与卡网络通信

示例：Stripe、Adyen、PayPal、Braintree

关键特性：

  • 处理支付授权
  • 管理资金流
  • 提供支付处理器集成

核心概念 ​

1. Capabilities (能力) ​

定义：商家支持的核心功能，是协议的"动词"。

特点：

  • 独立的核心功能
  • 通过反向域名命名（如 dev.ucp.shopping.checkout）
  • 版本化管理
  • 包含 spec 和 schema 引用

标准能力：

  • dev.ucp.shopping.checkout：结账能力
  • dev.ucp.shopping.cart：购物车能力
  • dev.ucp.shopping.order：订单能力
  • dev.ucp.common.identity_linking：身份链接能力

2. Extensions (扩展) ​

定义：可选的能力模块，通过 extends 字段增强另一个能力。

特点：

  • 可选模块
  • 可以扩展单个或多个父能力
  • 使用 allOf 进行 Schema 组合
  • 支持版本依赖声明

示例：

  • dev.ucp.shopping.fulfillment 扩展 dev.ucp.shopping.checkout
  • dev.ucp.shopping.discount 扩展 checkout 和 cart
  • dev.ucp.shopping.ap2_mandate 扩展 checkout（提供加密授权）

3. Services (服务) ​

定义：定义垂直领域（如 shopping、common）的 API 表面。

特点：

  • 包含操作、事件和传输绑定
  • 使用标准格式定义（OpenAPI、OpenRPC、Agent Card）
  • 支持多种传输协议

服务定义结构：

json
{
  "version": "2026-01-23",
  "spec": "https://ucp.dev/.../specification/overview",
  "rest": {
    "schema": "https://ucp.dev/.../rest.openapi.json",
    "endpoint": "https://business.example.com/api/v2"
  },
  "mcp": {
    "schema": "https://ucp.dev/.../mcp.openrpc.json",
    "endpoint": "https://business.example.com/ucp/mcp"
  }
}

4. Profiles (配置文件) ​

定义：JSON 文档，声明参与者的身份、支持的能力和端点。

位置：

  • 商家：/.well-known/ucp
  • 平台：通过 UCP-Agent header 在请求中声明

结构：

json
{
  "ucp": {
    "version": "2026-01-23",
    "services": { ... },
    "capabilities": { ... },
    "payment_handlers": { ... }
  },
  "signing_keys": [ ... ]
}

关键字段：

  • version：协议版本
  • services：支持的服务和传输绑定
  • capabilities：支持的能力和扩展
  • payment_handlers：支付处理器配置
  • signing_keys：用于验证签名的公钥

设计原则 ​

1. 可组合架构 ​

原则：通过 Capabilities 和 Extensions 的组合实现灵活的功能扩展。

实现：

  • 基础能力定义核心功能
  • 扩展通过 extends 字段声明依赖
  • Schema 通过 allOf 组合
  • 运行时通过能力协商确定激活的扩展

优势：

  • 避免能力定义臃肿
  • 支持渐进式功能增强
  • 保持向后兼容性

2. 动态发现 ​

原则：商家通过 Profile 声明能力，平台自主发现和配置。

实现：

  • 商家在 /.well-known/ucp 发布 Profile
  • 平台在请求中声明自己的 Profile URI
  • 双方通过能力协商确定共同支持的能力

优势：

  • 无需预先注册
  • 支持无许可集成（Permissionless Onboarding）
  • 减少集成复杂度

3. 传输无关 ​

原则：协议设计独立于传输层，支持多种传输协议。

支持的传输：

  • REST：标准 HTTP RESTful API
  • MCP：Model Context Protocol（JSON-RPC）
  • A2A：Agent-to-Agent Protocol
  • Embedded：嵌入式协议（OpenRPC）

实现：

  • 传输定义只声明方法名和引用基础 Schema
  • 操作语义与传输无关
  • 统一的错误处理和签名机制

4. 基于标准 ​

原则：尽可能使用现有开放标准，而非重新发明。

使用的标准：

  • OAuth 2.0：身份链接和授权
  • RFC 9421：HTTP Message Signatures
  • RFC 8785：JSON Canonicalization Scheme (JCS)
  • RFC 7517：JSON Web Key (JWK)
  • OpenAPI 3.x：REST API 定义
  • OpenRPC：MCP 协议定义

优势：

  • 利用成熟的安全机制
  • 减少学习曲线
  • 提高互操作性

5. 安全优先 ​

原则：从设计开始就考虑安全性。

安全机制：

  • HTTP Message Signatures（RFC 9421）
  • 密钥发现和验证
  • AP2 Mandates 扩展（加密授权）
  • PCI-DSS 合规模式
  • 单向凭证流（Platform → Business）

架构优势 ​

1. 解决 N-to-N 复杂度 ​

问题：传统上，N 个平台需要与 M 个商家集成，复杂度为 O(N×M)。

UCP 方案：

  • 平台和商家都实现 UCP 标准
  • 通过能力协商自动适配
  • 复杂度降低到 O(N+M)

2. 支持无许可集成 ​

问题：传统集成需要预先注册和配置。

UCP 方案：

  • 商家通过 Profile 声明能力
  • 平台通过 HTTP Message Signatures 验证身份
  • 无需预先建立信任关系

3. 模块化和可扩展 ​

问题：单一协议难以满足所有需求。

UCP 方案：

  • 核心能力定义基础功能
  • 扩展机制支持功能增强
  • 供应商可以定义自定义能力

4. 面向 AI 代理 ​

问题：现有协议难以支持 AI 代理自主完成购买。

UCP 方案：

  • 动态能力发现
  • AP2 Mandates 扩展提供加密授权
  • 支持多种传输协议（MCP、A2A）

数据流示例 ​

典型结账流程 ​

1. Platform 发现商家
   └─> GET /.well-known/ucp
   └─> 解析 Profile，获取能力和端点

2. Platform 创建结账会话
   └─> POST /checkout-sessions
   └─> Header: UCP-Agent: profile="https://platform.example/profile.json"
   └─> Business 获取 Platform Profile，执行能力协商

3. Business 返回结账响应
   └─> 包含支付处理器配置
   └─> 包含激活的能力列表
   └─> 包含签名（如果支持 AP2）

4. Platform 获取支付凭证
   └─> 与 Credential Provider 交互
   └─> 获取支付令牌

5. Platform 完成结账
   └─> POST /checkout-sessions/{id}/complete
   └─> 包含支付凭证和授权（如果支持 AP2）

6. Business 处理支付
   └─> 使用 PSP 处理支付
   └─> 创建订单
   └─> 返回订单确认

总结 ​

UCP 的核心架构设计体现了以下关键思想：

  1. 解耦：通过能力抽象解耦平台和商家
  2. 标准化：使用开放标准而非专有协议
  3. 可组合：通过扩展机制实现功能组合
  4. 安全：从设计开始就考虑安全性
  5. 面向未来：支持 AI 代理和新兴用例

这种架构设计使得 UCP 能够：

  • 降低集成复杂度
  • 支持快速集成
  • 保持灵活性和可扩展性
  • 确保安全性和合规性

MIT License.

Copyright © 2023～present Electrolux