AI 商業的四次權威交接：從商品知識到訂單
BLOG / ai-commerce-authority-handoffs.mdx
梳理 SKU.md 到即時 Catalog、MCP 或 UCP、頁面 WebMCP 操作、Checkout 與訂單系統的四次明確交接。
一段商品解釋要成為訂單，agent 至少要跨過四次明確的權威交接。每一次都重新核驗身分、狀態、權限或使用者意圖。
SKU.md 是由商家託管的商品發現與穩定商品知識：agent 可以找到商品、理解有來源的事實，並知道去哪裡複查即時商業狀態；它不是新的結帳協議。
四次交接分別由誰負責
| 交接 | 新來源擁有 | 必須設定的護欄 |
|---|---|---|
| 1. SKU.md → 即時 Catalog | 目前 Product、Variant、價格與庫存 | 精確身分匹配與新鮮回應 |
| 2. Catalog → MCP 或 UCP 能力 | 可呼叫操作與協商後的輸入輸出 | 能力、認證、scope 與錯誤處理 |
| 3. 即時來源 → 頁面 WebMCP 操作 | 目前頁面 UI 中有意義的操作 | 可見上下文與使用者審查 |
| 4. 操作 → Checkout/訂單 | 約束性總額、支付、購買與訂單狀態 | 明確確認與權威完成結果 |
這是概念上的四次交接，不代表每個商家都使用所有技術。獨立文件連結到 UCP、MCP 或 WebMCP，不等於這些專案採用 SKU.md。
第一次：知識回到即時 Catalog
Agent 讀取穩定 Facts、Claims、Disclosures 與 Limitations，再把 Product、Variant、SKU 和存在時的 GTIN 與即時結果精確匹配。UCP Catalog明確說明 Catalog 價格與庫存反映目前請求條件，但不是交易承諾；Checkout 才擁有最終權威。
即時來源不可用或身分衝突時，交接失敗。此時應報告不確定，不能拿 offer_snapshot 或正文頂替。
第二、三次：可呼叫能力與頁面操作
MCP可以暴露工具與資源，但協議本身證明不了商家授權，也證明不了結果仍然新鮮。UCP 可以在發現和協商後，把商業能力綁定到 REST 或 MCP。
WebMCP是另一份頁面上下文草案。頁面可以暴露在目前 UI 中有意義的操作，但它不是後台 Catalog、離線發現機制或交易完成證明。可見表單或工具仍需要有界輸入、安全失敗與使用者審查。
第四次：Checkout 與訂單系統做約束性決定
UCP Checkout負責會話狀態、履約、支付處理、總額與完成。有些路徑要求買家補充資訊或複核，agent 必須原樣呈現這些狀態；只有權威系統返回確認，訂單才算存在。
- 展示精確商品與目前條件。
- 說明重要披露和未解決不確定性。
- 請求使用者確認高影響操作。
- 透過已授權系統提交。
- 如實報告結果，不把錯誤或 pending 寫成成功。
交接失敗時應該如何處理
| 失敗 | 正確回應 |
|---|---|
| Variant 不匹配 | 停止並請求消歧 |
| 即時價格不可用 | 標記未知，不使用舊正文 |
| 工具沒有授權 | 請求正確交接，不盲目重試 |
| 使用者拒絕 | 不產生副作用並結束 |
| Checkout 要求複核 | 開啟可信複核路徑 |
| 訂單結果不確定 | 報告 pending 或未知，絕不寫已完成 |
延伸閱讀
實作前先讀穩定商品知識與即時商業資料和ProductGroup、Variant、SKU 與 GTIN。