BLOG / ai-commerce-authority-handoffs.mdx
AI 商业的四次权威交接：从商品知识到订单
梳理 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。