Electrolux_blog
Search K

Appearance

目录

常见问题 ​

基础概念 ​

1. 什么是 UCP？它的核心目标是什么？ ​

答案：

UCP (Universal Commerce Protocol) 是一个开放标准，旨在解决电商生态系统中不同实体之间的互操作性问题。

核心目标：

  1. 标准化交互：提供统一的交互方式，无论底层后端如何
  2. 模块化商务：将商务功能分解为独立的 Capabilities 和 Extensions
  3. 动态发现：商家通过 Profile 声明能力，平台自主发现和配置
  4. 传输无关：支持多种传输协议（REST、MCP、A2A）
  5. 面向 AI 代理：支持 AI 代理代表用户完成购买

解决的问题：

  • N-to-N 集成复杂度（从 O(N×M) 降低到 O(N+M)）
  • 碎片化的电商生态系统
  • 缺乏标准化的支付和身份交换
  • AI 代理支持不足

2. UCP 的四角色模型是什么？ ​

答案：

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

  1. Platform (平台)：

    • 代表用户的消费面（AI 代理、移动应用、网站）
    • 发现商家能力，发起结账会话
    • 示例：AI 购物助手、超级应用、搜索引擎

  2. Business (商家)：

    • 销售商品或服务的实体
    • 作为 Merchant of Record (MoR)，保留财务责任
    • 暴露商务能力，处理支付，履行订单
    • 示例：零售商、航空公司、酒店连锁

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

    • 安全管理和共享敏感用户数据
    • 发行支付令牌，避免原始卡数据出现在平台上
    • 示例：数字钱包（Google Wallet、Apple Pay）

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

    • 代表商家处理支付
    • 授权和捕获交易，处理结算
    • 示例：Stripe、Adyen、PayPal

3. Capabilities、Extensions 和 Services 的区别是什么？ ​

答案：

  1. Capabilities (能力)：

    • 商家支持的核心功能，是协议的"动词"
    • 独立的核心功能（如 dev.ucp.shopping.checkout）
    • 通过反向域名命名
    • 版本化管理

  2. Extensions (扩展)：

    • 可选的能力模块，通过 extends 字段增强另一个能力
    • 可以扩展单个或多个父能力
    • 使用 allOf 进行 Schema 组合
    • 示例：dev.ucp.shopping.fulfillment 扩展 checkout

  3. Services (服务)：

    • 定义垂直领域（如 shopping、common）的 API 表面
    • 包含操作、事件和传输绑定
    • 使用标准格式定义（OpenAPI、OpenRPC）
    • 支持多种传输协议

能力发现与协商 ​

4. UCP 的能力协商算法是如何工作的？ ​

答案：

能力协商遵循 server-selects 架构，商家决定激活的能力集合。

算法步骤：

  1. 计算交集：

    • 对于商家的每个能力，如果平台也声明了同名能力，则包含在结果中

  2. 版本选择：

    • 对于交集中的每个能力，计算双方都支持的版本集合
    • 选择最高版本（最新日期）
    • 如果没有共同版本，排除该能力

  3. 修剪孤立扩展：

    • 移除任何 extends 字段存在但父能力不在交集中的扩展
    • 单父扩展：父能力必须在交集中
    • 多父扩展：至少一个父能力必须在交集中

  4. 重复修剪：

    • 重复步骤 3，直到没有更多能力被移除（处理传递性扩展链）

示例：

python
# 商家支持：checkout, fulfillment, discount
# 平台支持：checkout, cart, discount
# 交集：checkout, discount
# fulfillment 被排除（因为 checkout 不在平台支持中）

5. 为什么使用反向域名命名空间？ ​

答案：

原因：

  1. 无需中央注册表：通过域名所有权自然建立治理关系
  2. 避免命名冲突：反向域名确保全局唯一性
  3. 清晰的治理模型：从名称即可知道谁负责该能力
  4. 支持供应商扩展：供应商可以使用自己的命名空间

格式：{reverse-domain}.{service}.{capability}

示例：

  • dev.ucp.shopping.checkout：UCP 官方能力
  • com.example.payments.installments：供应商自定义能力

治理模型：

  • dev.ucp.*：UCP 治理机构
  • com.{vendor}.*：供应商组织
  • org.{org}.*：组织

支付架构 ​

6. UCP 的支付架构如何解决 N-to-N 复杂度问题？ ​

答案：

传统问题：

  • N 个平台需要与 M 个商家集成
  • 每个商家可能支持多个支付提供商
  • 复杂度：O(N × M × P)

UCP 解决方案： 通过 Payment Handler 抽象：

  • 平台和商家都实现 UCP 标准
  • 支付提供商定义 Handler 规范
  • 复杂度降低到：O(N + M + P)

支付处理器生命周期：

  1. Negotiation：商家在 Profile 中广告支付处理器
  2. Acquisition：平台执行处理器逻辑，获取支付凭证
  3. Completion：平台提交凭证给商家，商家处理支付

7. 支付凭证流为什么是单向的？ ​

答案：

决策：支付凭证只从平台流向商家，商家不得在响应中回显凭证。

原因：

  1. 最小化 PCI 范围：减少接触支付凭证的系统
  2. 安全最佳实践：避免凭证在响应中暴露
  3. 防止重放攻击：单向流减少攻击面
  4. 合规性：符合 PCI-DSS 要求

实现：

  • 平台处理令牌（网络令牌）、加密 payload 或授权
  • 商家接收不透明的凭证
  • 通过 handler_id 路由到正确的支付提供商

Schema 组合 ​

8. UCP 的 Schema 组合机制是如何工作的？ ​

答案：

设计原则：

  1. 自描述 Schema：扩展 Schema 必须声明它引入的类型
  2. 客户端解析：平台必须在客户端获取和组合 Schema
  3. 确定性解析：$defs 键必须使用完整的父能力名称

组合流程：

  1. 确定根能力：从操作确定根能力（如 dev.ucp.shopping.checkout）
  2. 获取 Schema：获取基础 Schema 和所有激活的扩展 Schema
  3. 版本兼容性：验证扩展 Schema 的 requires 约束
  4. 组合：通过 allOf 链合并 Schema
  5. 验证：根据组合后的 Schema 验证请求和响应

示例：

json
{
  "allOf": [
    { "$ref": "checkout.json" },
    { "$ref": "discount.json#/$defs/dev.ucp.shopping.checkout" },
    { "$ref": "fulfillment.json#/$defs/dev.ucp.shopping.checkout" }
  ]
}

9. 为什么扩展 Schema 的 $defs 键必须匹配父能力名称？ ​

答案：

原因：

  1. 自文档化：Schema 明确声明它扩展了哪些父能力
  2. 确定性解析：extends 值直接映射到 $defs 键
  3. 可验证：构建时检查可以确认每个 extends 条目都有匹配的 $defs 键
  4. 避免错误：防止扩展引用错误的能力

要求：

  • extends: "dev.ucp.shopping.checkout" → $defs["dev.ucp.shopping.checkout"]
  • extends: ["checkout", "cart"] → $defs["dev.ucp.shopping.checkout"] 和 $defs["dev.ucp.shopping.cart"]

安全与认证 ​

10. UCP 支持哪些身份认证机制？ ​

答案：

UCP 兼容多种身份认证机制：

  1. API Keys：预共享密钥，通过带外交换
  2. OAuth 2.0：客户端凭证或其他 OAuth 流程
  3. mTLS：相互 TLS，使用客户端证书
  4. HTTP Message Signatures：基于 RFC 9421 的加密签名（推荐）

HTTP Message Signatures 的优势：

  • 支持无许可集成
  • 无需预先建立信任关系
  • 基于标准（RFC 9421）
  • 提供不可否认性

11. HTTP Message Signatures 的签名流程是什么？ ​

答案：

签名组件：

  1. @method：HTTP 方法
  2. @target-uri：请求目标 URI
  3. @authority：请求的权威（主机）
  4. content-digest：请求体的摘要（RFC 9530）
  5. @signature-params：签名参数（包括 created、expires、keyid）

签名流程：

  1. 构造签名输入：组合所有签名组件
  2. 计算签名：使用私钥对签名输入进行签名
  3. 编码签名：Base64url 编码签名
  4. 添加 Header：在 Signature-Input 和 Signature header 中添加签名

验证流程：

  1. 解析 Header：从 Signature-Input 提取 keyid
  2. 获取公钥：从 Profile 的 signing_keys 中获取公钥
  3. 重构签名输入：根据 Header 重构签名输入
  4. 验证签名：使用公钥验证签名

版本管理 ​

12. 为什么使用日期格式版本控制？ ​

答案：

决策：使用日期格式（YYYY-MM-DD）而非语义版本（如 1.2.3）。

原因：

  1. 清晰的顺序：日期格式提供明确的 chronological ordering
  2. 避免歧义：语义版本号可能产生歧义
  3. 易于理解：日期格式直观易懂
  4. 独立组件版本化：支持协议和能力独立版本化

示例：

  • 2026-01-11：2026年1月11日版本
  • 2026-01-23：2026年1月23日版本

版本比较：基于日期比较，选择最高版本（最新日期）。

13. 协议版本和能力版本如何独立管理？ ​

答案：

协议版本：

  • 管理核心协议机制（发现、协商、传输绑定、签名要求）
  • 在 Profile 的 ucp.version 中声明
  • 通过 supported_versions 支持多个版本

能力版本：

  • 每个能力独立版本化
  • 在能力数组中声明多个版本
  • 通过能力交集算法选择兼容版本

独立版本化的优势：

  • 能力可以独立演进
  • 不需要等待协议版本发布
  • 支持渐进式迁移

传输层 ​

14. UCP 为什么支持多种传输协议？ ​

答案：

原因：

  1. 适应不同基础设施：不同商家和平台有不同的技术栈
  2. 支持多种用例：AI 代理偏好 MCP，Web 应用偏好 REST
  3. 未来扩展性：可以添加新的传输协议而不影响核心协议
  4. 统一操作语义：无论使用哪种传输，操作行为一致

支持的传输：

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

统一机制：

  • 相同的签名机制（HTTP Message Signatures）
  • 统一的错误处理
  • 相同的能力协商算法

设计决策 ​

15. 为什么采用服务器选择（Server-Selects）架构？ ​

答案：

决策：能力协商采用服务器选择架构，商家决定激活的能力集合。

原因：

  1. 商家控制：商家对自己的能力有最终决定权
  2. 简化客户端：平台不需要复杂的协商逻辑
  3. 安全性：商家可以基于安全策略选择能力
  4. 性能：协商在服务器端完成，可以利用缓存

权衡：

  • 优势：商家控制、简化客户端、安全性
  • 挑战：平台需要信任商家、协商结果可能不符合平台期望

16. 为什么要求 Profile 支持公共缓存？ ​

答案：

决策：要求 Profile 支持公共缓存，最小 TTL 60 秒，不允许 private、no-store 或 no-cache。

原因：

  1. 性能优化：减少 Profile 获取开销
  2. 稳定性：Profile 代表稳定的身份和能力
  3. 防止滥用：防止恶意请求导致大量 Profile 获取
  4. 支持 CDN：允许使用 CDN 缓存 Profile

实现：

  • Profile 响应必须包含 Cache-Control: public, max-age=60
  • 不允许 private、no-store 或 no-cache
  • 支持 stale-while-revalidate

实际应用 ​

17. 如何实现一个支持 UCP 的商家？ ​

答案：

步骤：

  1. 发布 Profile：

    • 在 /.well-known/ucp 端点发布 Profile
    • 声明支持的服务、能力和支付处理器
    • 提供签名密钥

  2. 实现能力：

    • 实现支持的能力（如 checkout、cart）
    • 实现能力协商逻辑
    • 处理能力交集计算

  3. 实现传输绑定：

    • 实现 REST API（OpenAPI）
    • 可选：实现 MCP、A2A 或其他传输

  4. 实现支付处理：

    • 集成支付处理器
    • 实现支付凭证验证
    • 处理支付完成

  5. 实现安全机制：

    • 实现 HTTP Message Signatures
    • 验证平台签名
    • 管理签名密钥

18. 如何实现一个支持 UCP 的平台？ ​

答案：

步骤：

  1. 创建 Profile：

    • 创建平台 Profile，声明支持的能力
    • 提供签名密钥
    • 托管 Profile 在可访问的 URL

  2. 实现发现：

    • 获取商家 Profile（/.well-known/ucp）
    • 解析能力和服务
    • 缓存 Profile

  3. 实现协商：

    • 在请求中声明 Profile URI
    • 处理能力交集
    • 选择兼容版本

  4. 实现 Schema 解析：

    • 获取基础 Schema
    • 获取扩展 Schema
    • 组合 Schema
    • 验证请求和响应

  5. 实现支付流程：

    • 发现支付处理器
    • 执行支付凭证获取
    • 提交支付凭证

  6. 实现安全机制：

    • 实现 HTTP Message Signatures
    • 签名所有请求
    • 管理签名密钥

高级话题 ​

19. AP2 Mandates 扩展的作用是什么？ ​

答案：

AP2 Mandates 扩展（dev.ucp.shopping.ap2_mandate）为需要加密授权证明的场景提供支持。

特点：

  1. 商家授权：商家在结账响应中嵌入加密签名
  2. 结账授权：平台提供加密签名的授权证明
  3. 不可否认性：提供强加密保证，证明交易详情和参与者同意

使用场景：

  • 自主 AI 代理
  • 高价值交易
  • 需要不可否认证据的场景

安全绑定：

  • 一旦协商了 AP2 扩展，会话被"安全锁定"
  • 双方都不能回退到标准（未保护）结账流程

20. UCP 如何处理错误和降级？ ​

答案：

错误类型：

  1. 发现失败：

    • invalid_profile_url：Profile URL 格式错误
    • profile_unreachable：无法获取 Profile
    • profile_malformed：Profile 格式错误

  2. 协商失败：

    • version_unsupported：协议版本不支持
    • capabilities_incompatible：没有兼容的能力

  3. 协议错误：

    • 认证失败（401）
    • 权限不足（403）
    • 速率限制（429）
    • 服务器错误（500）

降级机制：

  1. continue_url：

    • 当协商失败时，提供 continue_url
    • 允许用户通过标准 Web 界面完成任务
    • 实现优雅降级

  2. 版本降级：

    • 如果新版本不可用，尝试旧版本
    • 通过 supported_versions 支持多版本

  3. 传输降级：

    • 如果首选传输失败，尝试其他传输
    • 支持多种传输协议

总结 ​

以下内容涵盖了 UCP 的核心概念、设计决策和实际应用。系统学习时，应该：

  1. 理解核心概念：Capabilities、Extensions、Profiles
  2. 掌握关键算法：能力协商、Schema 组合
  3. 理解设计决策：为什么这样设计，权衡是什么
  4. 了解实际应用：如何实现商家和平台
  5. 熟悉安全机制：HTTP Message Signatures、密钥管理

通过深入理解这些内容，可以全面掌握 UCP 的设计和实现。

MIT License.

Copyright © 2023～present Electrolux