讀懂 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 的職責矩陣比較各層目前責任。