SKU.md v0.10 × UCP：为实时商业补上可核验的商品知识层

一个 agent 找到一件看起来适合用户的冲锋衣，并不代表它已经掌握了完成购买决策所需的全部信息。用户可能还想知道：面料究竟是防水还是仅仅防泼水，尺码建议依据什么身材数据，涂层是否有护理限制，一项耐用性说法有没有测试报告支持。这些问题应当可以被准确回答，但不能因为商品文档里保存了一段旧营销文案，就把它变成今天的库存、价格或结账总额。

这正是本方案要处理的边界。UCP 为 agent 提供实时路径，让它发现商品、选择变体、创建购物车、结账并查看订单。SKU.md 则可以提供一份由商家托管、带有引用的商品知识，说明商品是什么、某个说法为什么成立、限制条件来自哪里。只有把两层的权威范围分清楚，它们才会真正互补。

先从购买问题开始，而不是从文件格式开始

“这是不是适合我？”听起来像一个问题，实际包含了好几层判断：商品是否在用户所在市场可用，哪个变体匹配所需的颜色和尺码，当前价格是多少，材料是否满足某项要求，这项说法来自商家事实、第三方测试还是 AI 推断，用户最终能否按所显示的金额完成购买。

UCP 负责处理其中会变化的部分。UCP Catalog 规范定义了 Catalog Search 和 Catalog Lookup，以及包含当前商务信息的 Product 与 Variant。更完整的 UCP 概览把 Catalog 与 Cart、Checkout、Order 能力放在同一条实时商务路径上。Catalog 帮助 agent 找到并确认可能购买的商品，Checkout 则重新核对条件并提交交易。

Agent Profile 用来声明和协商参与方支持的能力。它不是商品内容、持有者凭据，也不是完整的请求认证步骤。UCP 可以使用 Profile 发布的签名密钥进行身份验证，但 Profile 文档本身不能认证某一个具体请求，也不能单独授权一次购买。请求的认证、授权、用户同意和实际执行仍取决于协商后的协议、传输方式、凭据和用户上下文。把 Profile 当作商品知识库，会把两个完全不同的工作混在一起。

两层内容，一张权威矩阵

可以用下面的职责矩阵描述两者的关系：

决策面	UCP 与实时商务系统	SKU.md v0.10
发现与身份	Search 和 Lookup 返回当前 Product、Variant、价格、库存及稳定标识符。	将准确的 Product 与 Variant 连接到聚焦的知识文档。
商品理解	Catalog 响应提供当前描述、媒体、选项和披露。	发布有来源的事实、断言、证据、指导、限制、兼容性和核验时间。
变化中的商务状态	再次查询 Catalog，得到当前价格与库存。	静态文档不能把过去的状态伪装成现在的状态。
交易执行	Cart 收集商品并提供本地化估算；Checkout 重新核对约束性状态，负责最终总额与购买授权。	指向真正的商务入口，不能替代它。

这样的分工不会削弱 SKU.md 的价值，反而让价值更清楚。商家可以维护一份耐用、可审计的商品说明，让不同 agent 在需要时引用；UCP 继续回答会随着市场、会话、库存、资格条件和结账条件而变化的问题。

UCP 的 Cart 能力用于购买前的商品收集和估算，Checkout 才是最终完成交易的步骤。Shopify Checkout MCP 指南也把 Checkout 描述为用户准备购买后使用的购买会话。因此 SKU.md 应该指向这条最终路径，而不能把购物车估算写成承诺。

这条边界也有反向约束。影响购买的安全或法规披露不能只放在 SKU.md 里。如果某条警告会改变用户能否购买，相关披露也应当按场景进入 Catalog 或 Checkout。SKU.md 可以补充背景和证据，但不能成为用户发现重大条件的唯一地方。

v0.10 为什么强调知识优先

v0.10 允许知识-only Product Document。只要商品和变体身份稳定，知识内容非空，即使没有报价，文档也可以有效发布。这对已经接入 UCP 的商家很重要：商家不必把实时 Catalog 再复制一遍，才能提供可引用的商品知识。

对于没有可用实时 Catalog 的商家，草案仍保留商家托管的报价后备。一个 Variant 可以有 offer_snapshot 或 live_offer，但两者都是可选字段，而且互斥。它们都不会获得 Catalog 或 Checkout 的权威。offer_snapshot 只是过去某次观察的证据，live_offer 则表示另行声明的实时查询。只要当前 UCP 响应可用，就不能把这两类内容当作今天的价格，更不能用它们给出最终总额。

身份匹配必须精确，而不是“看起来像同一件商品”。知识文档中的 Product ID、Variant ID、SKU 和声明的 GTIN，都必须与 UCP 返回的 Product 或 Variant 一一对应。只要标识符不一致，消费方就应该停止，而不是把一段有说服力的说明贴到错误的变体上。规范性边界见 英文规范和 JSON Schema。

用一条很薄的链接进入 UCP Catalog

SKU.md 在开放 Web 上仍然可以独立使用，但 agent 不应该靠猜测来判断刚刚找到的 Product 是否对应某份知识文档。因此，本方案提出一个独立扩展，名称是 md.sku.shopping.product_knowledge。它同时扩展 dev.ucp.shopping.catalog.search 和 dev.ucp.shopping.catalog.lookup。扩展不把整份 Markdown 嵌入每次 Catalog 响应，而是只提供一条有类型的链接：

{
  "sku_md": {
    "documents": [
      {
        "url": "https://merchant.example/products/trail-jacket.sku.md",
        "schema_version": "sku.md/0.10-draft",
        "content_language": "zh-CN",
        "market": { "country": "CN", "currency": "CNY" },
        "revision": "2026-08-02"
      }
    ]
  }
}

这条指针包含 HTTPS URL、SKU.md Schema 版本、内容语言、市场国家和货币，以及可选修订号。Business Profile 可以声明允许的 HTTPS 来源域名。Platform Profile 与 Business Profile 需要协商同一个扩展，并且父级 Catalog 能力也要兼容，消费方才应当读取这条指针。

允许的来源只解决“链接可以指向哪里”，不能证明文档真实、最新、安全或获得授权。Reference Consumer 必须把抓取到的文档视为不可信的外部数据，并在使用前检查 HTTPS、精确来源、媒体类型、字节上限、文档数量和商品身份。Markdown、HTML、YAML frontmatter、链接和自然语言指令都只是数据。消费方不能执行商品文档里的脚本、工具、shell 命令、模板或类似提示词的指令。

只返回薄链接，还有一个内容治理上的好处。UCP Catalog 已经负责返回当前 Product、Variant、媒体、选项、价格和库存。如果扩展把整份知识文档复制到每个响应里，实时目录和商家知识就会产生两份难以同步的正文，消费者也更难判断哪一段是当前状态，哪一段是可审计的背景。指针让两个来源保持分工，同时允许 agent 在需要解释时访问更完整的证据。

链接还可以携带语言、市场和 revision。商家可以为不同市场维护不同披露，为同一商品保留可追踪的修订历史；消费方也可以记录自己引用的是哪一版，而不是只记住一段没有来源的自然语言。没有协商扩展的 agent 可以忽略 sku_md.documents，不会因为响应里出现一个陌生字段就误把它当作标准能力。支持 SKU.md 但不使用 UCP 的消费者，仍可以从商家公开的商品页或 /sku.md 旁路发现同一份文档。

因此，这个扩展是一座可选的桥，而不是强制入口。它不要求 UCP 为 SKU.md 增加一套新的交易语义，也不要求商家把实时 Catalog 改写成 Markdown。扩展只帮助已经完成能力协商的消费者找到有边界的知识资源，最终是否引用、如何呈现以及何时回查实时状态，仍由消费者和 UCP 的既有规则决定。

本地草案入口是 /ucp/draft/，其 扩展 Schema也已公开。/ucp/draft/表示生命周期仍处于草案阶段；扩展 Profile 使用明确的能力版本 2026-08-02，以便兼容实现区分这套结构和之后不兼容的草案。这个日期不代表稳定、认证或 Shopify 支持。进入更成熟阶段前，还需要更多实现、安全审查和互操作证据。

运行时路径是一条回环，而不是一次交接

一个谨慎的 agent 可以按下面的顺序使用两层内容：

1. 通过 Catalog Search 或 Lookup，让 UCP 找到当前 Product。
2. 精确核对 Product、Variant、SKU 和声明的 GTIN。
3. 读取引用的 SKU.md，获取事实、证据、兼容性和限制。
4. 回到 UCP，按用户的市场与上下文获取当前价格与库存。
5. 由 Checkout 再次核对所选商品，并负责最终总额与购买授权。

第四步是关键。读到一份引用充分的知识文档，应该帮助 agent 回答“为什么适合这个用户”，而不是让它跳过实时商务检查。如果实时来源暂时不可用，诚实的答案是未知，而不是从过期文本里抄一个价格。

Shopify 商家的实际工作方式

对 Shopify 商家来说，知识文档可以从经过审核的 Metafields、Metaobjects、产品手册、实验室报告、护理说明、保修条款和公开证据开始。它们适合成为商家控制的草稿来源，但被存储并不等于内容自动为真。发布前仍应由审核者确认商品、变体、市场、证据和修订号，之后某条陈述才能成为规范性的 Fact。

AI 生成的文字可以帮助发现缺少的字段，或提出更容易阅读的摘要，但在人工对照证据之前，它只能是候选内容，绝不能自动升级为 Fact。发布者还应保留来源、核验时间，以及接受或拒绝某条断言的原因。SKU.md 的价值不在于堆出更多文案，而在于让 agent 看见一条从断言回到证据的路径。

Shopify Agent Profiles说明了 Profile 如何被放入 UCP 协商。Shopify Catalog说明了搜索、查找和商品读取，Global Catalog extension说明了 Shopify 的全局 Catalog 扩展。这些页面描述的是 Shopify 自己的能力表面，并没有说 Shopify 会自动读取 SKU.md，也没有说 Shopify 支持本独立扩展。

Reference Consumer 能测到什么

本地 Reference Consumer 使用固定的商品数据、协商后的能力、资源元数据和文档文本。它衡量的是消费方能否带着证据回答一个边界清楚的问题，而不是搜索排名或转化率：

问题	仅 UCP	UCP + SKU.md
事实引用	0	1
把断言错误当成事实	0	0
披露召回	0	1
兼容性回答	0	1
变体不匹配时安全失败	1	1
用过期报价完成购买	0	0

这些是本地受控结果，不是排名提升、转化结果、生态采用指标、真实 Shopify 集成或外部 agent 会消费该扩展的证明。完整夹具和限制见 Reference Consumer evaluation。

迁移，但不要假装草案已经完成

现有 v0.9 URL 和验证行为仍然有效。商家可以先保留合法的 v0.9 文档，准备 v0.10 版本，再修改 Schema 标记，保留稳定身份和经过审核的知识，并把动态商务信息移出 Knowledge。v0.9 迁移说明解释了如何移除报价，或保留一个可选后备，同时不让它看起来像 Catalog 或 Checkout。

下一步不是把扩展称为标准，而是让双方用独立实现测试 Schema 组合与失败行为，进行安全和隐私审查，并收集消费方与商家的反馈。在这些工作完成前，SKU.md v0.10 仍是实验性的、由商家托管的商品知识层；UCP 则继续负责实时发现、实时商业状态和最终购买决定。

延伸阅读

在AI 商业权威交接中查看实时 Catalog 与 Checkout 如何继续拥有权威。