项目背景
DTC 商家在售前咨询、订单查询、优惠券使用和售后政策解释上会遇到大量重复问题。传统 FAQ 能覆盖简单问题，但很难处理上下文、订单信息、多轮追问和高风险售后场景。
我把它做成一个可演示的客服与导购原型：它服务于一个 mock 护肤品牌 GlowCare。重点不是让回复更像真人，而是让它知道什么时候该查数据、什么时候该停下来。
产品目标
- 消费者侧：用聊天方式完成商品推荐、订单查询、政策问答、优惠券触发和投诉升级。
- 商家侧：保留意图分布、升级率、优惠券触发、热门问题和推荐商品等运营指标。
- 风险侧：对隐私、退款承诺、医疗功效、缺货推荐和低置信度回答设置 guardrails。
- Demo 侧：用 mock 商家数据和可交互页面把范围跑一遍，而不是只画概念图。
Agent 架构
流程被拆成 Intent Router、Context Retrieval、Tool Execution、Guardrail Layer 和 Analytics Log。模型先判断用户意图，再根据场景调用商品、订单、政策、优惠券或升级工具，最后由风险规则检查输出边界。
这个拆分让 AI 不直接“决定业务动作”：订单查询需要订单号和邮箱双重验证，优惠券只作为转化辅助，退款和身体反应类问题必须进入人工复核，低置信度问题也不会强行生成确定答案。
关键交互
- 商品推荐：把肤质、预算、香精偏好、库存和评分作为推荐约束，输出推荐理由和置信度。
- 订单查询：没有邮箱时只提示补充信息；验证通过后展示状态、物流和预计送达时间。
- 优惠券触发：在用户表达价格犹豫时返回可用券，并避免承诺退款或价格保证。
- 投诉升级：对不适反应、强退款诉求等高风险问题，明确不做医疗判断，转交人工支持。
- 商家看板：展示意图分布、升级率、优惠券次数、热门问题和推荐商品。
复盘
这个项目最有价值的地方是让我看到：客服 Agent 不是一个更聪明的聊天框。真正要设计的是它什么时候查订单、什么时候推荐商品、什么时候不能继续说，以及怎么把问题交给人工。
下一步可以继续补真实商家后台权限、A/B 评估、客服质检样本和更细的 handoff 策略，让它更接近真实客服场景。