手搭一个客服智能体，踩坑实录

为什么想到做智能体

上个月我们团队接手了一个小项目——给一个电商小程序做自动客服。

需求本身不复杂：用户咨询商品信息、查物流、退换货流程，这些占了客服工作量的70%以上，完全可以自动化处理。

老板给的期限是一周出原型。我一想，这不正好拿 AI Agent 试试手吗？

选型与技术栈

调研了一圈，最终选择的技术栈：

架构设计

整个智能体的工作流我画成了这样：

用户消息
    ↓
意图识别（分类器）
    ├── 商品咨询 → 检索商品知识库 → 生成回答
    ├── 订单查询 → 调用订单 API → 返回实时状态
    ├── 退换货 → 走退换货流程（多轮对话）
    └── 人工客服 → 转接 + 同步上下文

核心思路就一条：能查 API 的就不靠模型猜，能检索知识库的就不靠模型编。

踩坑记录

坑1：意图识别的边界模糊

最早我用一个 prompt 让大模型做意图分类："根据用户消息判断属于以下哪一类：商品咨询、订单查询、退换货、转人工。"

结果发现用户的问题往往一句里包含多个意图。比如"我昨天买的手机到了但是屏幕有一条划痕，能换吗"——既有订单确认（追踪昨天买的手机），又有退换货诉求，还涉及商品质量描述。

解决方案：改成多标签分类，每条消息允许同时命中多个意图，然后走分支合并的逻辑。

坑2：知识库检索命中率低

商品知识库我存了3000多条商品信息（规格、参数、价格、库存），但用户问法千奇百怪。

比如用户问："那个两千左右、拍照好的手机还有吗？" 知识库里的字段是：价格: 1999、特色: 5000万像素主摄

问题是 Embedding 检索对"两千左右"和"1999"的匹配并不好，对"拍照好"和"5000万像素"也有语义差异。

解决方案：两路召回——一路用向量检索原问题，另一路先用小模型做关键词提取（"价格区间:2000左右、需求:拍照好、品类:手机"），然后用结构化查询去精确匹配价格范围和标签。

坑3：多轮对话的状态管理

退换货流程大概有5步：确认订单 → 选择原因 → 上传凭证 → 选择方式（换货/退款）→ 确认提交。

最初的实现是每一步都用 LLM 判断当前状态，结果经常出现 LLM"跳步"——用户还没传图，它就已经跳到确认步骤了。

解决方案：放弃让 LLM 管理状态，改用有限状态机。**LLM 只负责解析用户输入中的信息，状态流转由代码控制。**这样安全多了。

State: AWAITING_ORDER_CONFIRM → (用户确认订单) → State: AWAITING_REASON
State: AWAITING_REASON → (用户选择原因) → State: AWAITING_EVIDENCE
...

坑4：转人工时的上下文丢失

当 AI 解决不了需要转人工时，最让用户崩溃的是——"您好，请重新描述您的问题，我来帮您处理。"

这种体验用户直接给差评。但问题是之前的对话上下文可能已经很长了，传给人工客服需要做摘要。

解决方案：转人工时自动生成一段对话摘要，格式固定：

【用户信息】用户ID: xxx
【问题类别】退换货
【已完成步骤】已确认订单、已选择退货原因
【待处理】需要人工审核退款金额
【对话摘要】用户表示收到的商品有瑕疵，已上传照片，要求全额退款

然后通过客服系统传递给人工坐席，让用户不需要重复描述。

上线后的效果

上线跑了一个月，数据如下：

自动处理率 71.6% 不算特别高，但已经帮客服团队每天省下了至少 3 个人力。而且随着我们持续优化知识库和流程，这个数字还在往上走。

一些反思

如果现在重新做一个客服智能体，我会：

1. 先用规则兜底：很多高频问题（查物流、退换货政策）其实不需要 LLM，写死规则更快更准
2. 加一个"不知道"的兜底：AI 不确认的就直接转人工，不要硬答。硬答是满意度杀手
3. 人机协作比全自动更实际：AI 先处理，处理不了的转人工，比追求100%自动化的方案更稳健

做智能体这件事，我的最大感受是：不要高估大模型的能力，也不要低估工程落地的细节。 模型选得再好，状态管理和容错设计不到位，产品体验一样崩。