读懂 SKU.md v0.8 分层架构：自托管信息与平台门控交易

SKU.md v0.8 的架构图并不是把一组技术从“基础”到“高级”依次堆叠起来。 它更像一张控制权地图：AI agent 从商家域名开始，先经过公开发现和商家发布 的商品上下文，然后才进入可能依赖外部协议、平台身份、准入流程或交易后端 的能力层。

颜色把这条边界直接画了出来。青色表示商家可以在自己的域名发布或实现的 表面；珊瑚色表示实际运行仍需要协议方、平台、身份系统或交易系统参与。信息 可以公开发现，不代表执行这些信息所指向的操作也对所有调用方开放。

颜色表达的是权威边界

图中的白色方框列出文件、数据结构或运行机制，外层颜色回答的则是另一个 问题：谁有能力让这些机制真正存在并持续运行？

青色层的共同点是发布权由商家掌握。商家可以配置 robots.txt、提供 Sitemap、维护 llms.txt、发布根目录 sku.md、增加分区索引和商品文档， 也可以在自己的页面运行时提供工具。这些表面仍需正确托管、安全解析和准确 数据，但文件能否存在，不需要先由某个商务平台批准。

珊瑚色并不表示协议规范一定是封闭的，而是表示实际使用需要另一个参与方。 协议 Profile 可能涉及商家注册、身份核验、凭据、平台支持或商业审核；结账、 支付与订单完成则必然涉及用户授权，以及能够提交商业状态的外部系统。

因此，这张图首先分开了两个常被混为一谈的概念：发布一项声明，与拥有执行 该声明的权限。

治理与发现仍由商家自主控制

第一层包含 robots.txt、llms.txt 和 sitemap.xml。三者都能帮助消费方 发现或理解站点资源，但职责并不相同。

robots.txt 表达抓取规则，也可以声明 Sitemap；它不是通用的身份认证或 访问授权协议。Sitemap 用于批量发现 URL，并不能证明每个 URL 中的声明仍然 新鲜、准确或可信。llms.txt 可以为面向 AI 的消费方提供紧凑导航，但文件 发布后，不保证任何模型或 agent 会读取、接受、引用或提高其排名。

所以这一层被称为“治理与发现”，而不是“信任”。商家控制发布什么以及链接 到哪里；消费方仍需判断是否允许抓取、响应是否来自预期来源，以及这些内容 能够承担多大的证据权重。

SKU-MD 文档族让根清单保持有界

第二个青色层是 SKU-MD 文档族：

• 根目录 /sku.md Catalog Manifest；
• 面向大型或分段目录的可选分区索引；
• 商品级 *.sku.md 文档。

图中的 O(1) 指根清单的大小应在商品目录增长时保持有界，并不是说整个商品 目录都能在常数时间内完成查询。根清单不嵌入全部商品，而是链接到目录入口、 分区和商品文档发现表面，因此可以保持短小和稳定。

这种设计为 agent 提供了一个位置可预测的起点，同时不强迫小商家建设复杂 索引。规模较小的目录可以直接链接已有资源；大型目录可以按市场、语言或 业务分区逐层组织；商品文档则聚焦一个 ProductGroup 及其 Variants，使局部 商品详情更新时无需重写根文件。

这些文件都由商家托管，但文件名本身并不会自动产生权威性。可信度仍来自 域名控制、Canonical URL、一致修订、证据和正确的 HTTP 交付。

商品真相层分离稳定知识与变化状态

第三个青色层把 Product JSON-LD 与 SKU.md Knowledge 放在一起，同时并列 展示 offer_snapshot 和 live_verification。它的目的，是防止稳定事实和 易变商务状态被压进同一份不分层的记录。

Product JSON-LD 提供成熟的页面级商品语义；SKU.md Knowledge 可以组织 Facts、Claims、Disclosures、Guidance、Limitations 以及相应证据。Knowledge 适合保存值得发布和审计的陈述，不应把短期价格、库存、运费或促销固化成 长期正文。

offer_snapshot 记录某个市场、某个 Variant 在特定时间被观察到的状态。 observed_at、refresh_after 和真实存在的 offer_valid_until 帮助消费方 判断新鲜度。快照只能证明过去的观察，不是库存锁定，也不能证明同一价格和 可用性在决策时仍然成立。

live_verification 是保守的实时兜底：重新打开公开商品页，检查同一 Variant 当前显示的状态。它明确不是结构化 Catalog Lookup API，也不能直接触发购买。 如果消费方能够识别一个可用的结构化 live_lookup，可以优先使用；否则公开 页面仍是商家自主控制且可重新核实的表面。

capabilities[] 与 protocol_profiles[] 是两条不同路径

商品真相层之后，架构开始分叉。这不是“新技术”与“旧技术”的区分，而是 能力由谁运行，以及消费方在使用前还需要满足什么条件的区分。

capabilities[]：商家发布的运行时能力

当不存在外部协议的权威 Profile，或能力本身存在于页面运行时时， capabilities[] 可以描述通用 Function，例如 WebMCP 页面工具。商家可以 在店铺页面实现这些工具，并声明其 Scope、Status、Discovery 和 Access 方式。

页面运行时工具仍然受页面上下文约束：它可以要求用户在场，只暴露商品或 购物车范围，也不会因为写入清单就自动获得远程调用 URL。“自主可控”不等于 “无限制调用”；浏览器、站点策略、当前用户会话、工具 Schema 和应用代码 仍共同限定实际行为。

一条 Capability 只说明某个能力表面存在。它不能证明 agent 已经取得用户同意、支付权限或执行不可逆操作的许可。

protocol_profiles[]：指向外部信任系统

当外部协议已经定义权威发现 Profile 时，protocol_profiles[] 用于链接该 Profile，而不是把协议版本、服务、传输、端点和 Schema 全部复制进 Catalog Manifest。

图中使用 UCP 与 ACP 作为这条路径的示例。Profile 可以发布在商家域名下， 但实际参与仍可能依赖协议支持、商家注册、平台审核、凭据或商业协议。语法 正确的 Profile 无法凭空制造另一个参与方的接纳。

这正是该架构的重要特征：开放的发现文档可以如实描述一个受到门控的执行 环境，而不必假装门槛不存在。

两条路径都在交易边界汇合

最底部的珊瑚色层包含 Checkout、Payment 和 Order。无论 agent 经由页面 Capability 还是 Protocol Profile 到达这里，真正提交交易都需要能够控制 资金、库存、税费、履约、风控和用户授权的系统。

SKU.md 可以指出这些系统位于哪里，并声明某个字段应以哪个来源为权威，但 不能替代 Checkout Backend。最终金额、支付状态和订单状态必须由能够执行并 记录这些变化的系统产生。如果没有可用来源，安全结果应是 unknown，而不是 根据静态文档推断出一笔交易。

两条路径在这里汇合，也阻止了一个危险捷径：自托管页面工具不能被当作绕过 平台或协议控制的方法。它可以准备购物车或引导用户，但当商业状态即将具有 约束力时，操作仍必须进入经过授权的后端。

这套架构避免了五种类别错误

1. 发现不等于采纳。 文件可访问，不代表 agent 会消费、信任或推荐它。
2. 声明不等于准入。 写入 Capability 或 Protocol Profile，不能证明外部 系统已经启用它。
3. 快照不等于实时状态。 价格和可用性必须结合观察时间判断，并在决策 需要时重新验证。
4. 页面工具不等于支付权限。 运行时能力仍受用户在场、应用策略与结账 系统约束。
5. 开放规范不等于开放交易。 身份、凭据、同意、风险控制和商业协议仍 可能是必要条件。

小型文档也能表达诚实的边界

这套架构保持了入口的简洁，同时拒绝把所有下游依赖压缩成一句笼统的 “AI Commerce”。商家可以在自己的域名掌握发现、文档、证据和页面运行时 层；外部协议与交易系统则保留真实存在的准入与授权要求。

这正是分层设计的核心。SKU.md 不试图消除商品上下文与可执行商务之间的 边界，而是把边界表达得足够清楚：发布方知道自己控制什么，平台保留必须 运营的门控机制，消费方也能够判断自己何时从“读取证据”进入了“请求操作”。

延伸阅读

用llms.txt、agents.md 与 SKU.md 的职责矩阵比较各层当前责任。