UCP 核心概念：Service / Capability / Extension 与 Profile 协商

先给一个“最小心智模型”

UCP 把一次商务交互拆成三层（官方称为核心构件）：

• Service：定义一个垂直领域的 API 面与传输绑定（例如 shopping、common）。
• Capability：服务里的独立功能单元（例如 Checkout / Identity Linking / Order）。
• Extension：通过 extends 增强某个能力的可选模块（例如折扣、履约、AP2 Mandates）。

这套拆分的工程价值在于：平台与商家可以在每次会话里通过“交集协商”选出本次激活的能力组合，而不是为每个组合开发定制集成。

Profile：发现与协商的载体

官方规范里，商家会在 /.well-known/ucp 发布 Business Profile，平台则在请求里声明自己的 Profile URI，商家据此计算交集并返回本次会话的激活能力列表。

下面这段示例来自官方规范（展示了 services/capabilities 的基本结构）：

{
  "ucp": {
    "version": "2026-01-11",
    "services": {
      "dev.ucp.shopping": {
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specification/overview",
        "rest": {
          "schema": "https://ucp.dev/services/shopping/rest.openapi.json",
          "endpoint": "https://business.example.com/ucp/v1"
        }
      }
    },
    "capabilities": [
      {
        "name": "dev.ucp.shopping.checkout",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specification/checkout",
        "schema": "https://ucp.dev/schemas/shopping/checkout.json"
      }
    ]
  }
}

你实现时要特别盯住的两个点

• 命名空间与 spec URL 绑定：官方要求 capability 的 spec/schema URL 的 origin 必须与命名空间权威域一致（例如 dev.ucp.* 必须是 https://ucp.dev/...）。平台侧应校验并在不匹配时拒绝。
• 扩展剪枝：扩展依赖父能力。如果父能力不在交集中，扩展必须被移除，并且要重复剪枝直到稳定。

继续阅读

• specification/overview：命名空间治理、服务定义、profile、交集算法与 schema 组合（官方规范）
• documentation/core-concepts：四类角色与三层模型（官方文档）
• 站内：从 核心概念 与 规范总览 开始

权威来源

• 官方 Core Concepts：https://ucp.dev/documentation/core-concepts
• 官方 Specification Overview：https://ucp.dev/specification/overview