附录 B：零售业案例研究

架构三层

┌─────────────────────────────────────────┐
│  客户触点层                              │
│  (网站聊天、移动 App、店内 kiosk、语音)  │
├─────────────────────────────────────────┤
│  Agent Runtime + Skills 库              │
│  - 通用运行时 (ADK、Claude SDK 等)      │
│  - 零售特定的 Skills 库                 │
├─────────────────────────────────────────┤
│  数据和工具层                            │
│  - 产品目录 (百万 SKU)                  │
│  - 实时库存                             │
│  - 客户画像                             │
│  - 向量搜索 (评论、手册)                │
└─────────────────────────────────────────┘

代表性 Skill 库

Skill 功能 所有者 级别
project-guidance 将模糊查询转化为步骤计划 行业知识团队 Read-Only
materials-list 生成材料清单 Pro 商品团队 Draft-Only
review-summarize 浓缩长评论 个性化团队 Read-Only
delivery-window 计算配送选项 履约团队 Read-Only
return-policy 编码退货规则 客服团队 Read-Only

查询路由示例

客户问：“我想改造孩子的浴室，需要什么？”

  1. Runtime 加载所有 Skill 的 L1 描述 (~30-80 tokens 每个，总计 ~2KB)
  2. 识别 project-guidance 匹配，加载其正文
  3. 生成翻新步骤大纲
  4. 如果客户跟进配送问题，加载 delivery-window
  5. 如果询问退货，加载 return-policy

没有发生的是什么：没有单体的 “装修助手” Agent 训练了每个可能的场景。每块专业知识只在对话需要时加载。

所有权模型

最关键的管理决策：谁拥有每个 Skill？

原则：将所有权分配给已经拥有底层专业知识的团队：

  • project-guidance → 行业知识/品类管理
  • materials-list → Pro 商品团队
  • delivery-window → 门店运营/履约
  • review-summarize → 个性化/数据科学

为什么比自定义 Agent 更难竞争

如果竞争对手和你的零售商都运行相同的通用 Agent 运行时（运行时已经商品化），匹配运行时是微不足道的。

Skills 库编码了公司积累的模式。投资于自定义 Agent 但忽视 Skills 库的零售商，是在投资竞争对手将免费获得的部分。投资于 Skills 的零售商，即使在通用运行时上，也在构建捕获公司实际知识的持久资产。

冷启动：从哪里真正开始

有用的练习：把团队最有经验的从业者拉过来一小时，让他们叙述三个定期做的工作流，录下来。转录稿几乎就是三个 Skills 的初稿。