UCP 概览：模型、对象与协商

UCP 的“最小心智模型”

在 UCP 里，你可以把一次商务交互拆成三层：

• Service（服务/垂直领域）：定义一个垂直领域的 API 面（例如 shopping/common）。
• Capability（能力）：服务里的“功能单元”（例如 checkout / order / identity_linking）。
• Extension（扩展）：可选能力，用 extends 绑定到父能力，给基础能力补充字段与行为（例如 discount / fulfillment / ap2_mandate）。

这套拆分的价值在于：平台与商家不必为了每个组合做定制集成，而是通过发现与协商决定“本次会话激活哪些能力与扩展”。

发现与协商：为什么 profile 是关键

UCP 依赖双方 profile 来完成“可发现 + 可协商”：

• 商家 profile：发布在 /.well-known/ucp，声明版本、服务端点、能力集合等。
• 平台 profile：平台在每次请求中声明自己的 profile 地址，商家据此计算交集。

官方规范给出了交集算法要点：

• 先按 name 求交集
• 再剪枝：任何扩展如果父能力不在交集中，必须移除（并重复直到稳定）

参考（权威来源）

• 官方规范概览：https://ucp.dev/specification/overview