电商客服与导购智能体合并设计：意图识别、工具调用与知识库实践

做客服类智能体这几年，我的电脑里存过三版方案。第一版是规则加菜单按钮，用户点两下就烦了；第二版是纯大模型问答，什么都能聊，但一问到订单和售后就露馅；第三版才是真正跑通业务价值的——把电商客服+导购智能体合并成一件事，一次对话里既能查单、退款，也能顺着用户的话题把合适的商品推到他面前。

这篇文章就是把这一版的完整设计思路、实现细节和踩坑记录整理出来。适合正在做电商客服系统、想引入大模型智能体但不知道从哪下手的团队，也适合那些已经上了大模型问答但发现转化率没什么变化的朋友。我会尽量把每个环节的"为什么"讲清楚，而不是只给结论。

1. 为什么把客服和导购塞进同一个智能体，比拆成两个更划算

1.1 拆开的后果：用户要的是"一条龙"，不是转两次手

很多平台现在的标配是"售前机器人"和"售后机器人"分开部署，甚至售后还分订单组、退换货组。听起来很专业，但站在用户视角，他的诉求其实非常简单：我进来不是来分类的，我是来解决问题的，顺带看看有没有更合适的商品。

举个我实际遇到过的场景。有人在店铺里看中一台便携榨汁杯，问客服"这个杯子能打冰块吗"。如果系统把它判定成售前问题，导购机器人回答完就结束了；但用户下一句往往是"我去年买的那个型号底座坏了，能修吗"。这时候如果售后机器人接不住上文，用户就得退出重新进，把已经说过一遍的背景再说一次。用户没有这个耐心，流失往往就发生在这两步之间。

我在模拟项目里做过一次统计，零售品类中超过30%的会话会同时涉及售前和售后内容，而且这个比例在活动大促期间会更高。你说这是服务问题，其实是销售问题——一个在售后环节把用户服务妥帖的店铺，复购率远高于不操心售后的店铺。这个数据说服了当初坚持拆分的人。

1.2 合体之后，对话才真正"懂你"

把客服和导购塞进同一个智能体，最重要的不是省一个机器人部署位，而是共享上下文。用户前一句话在抱怨"上次发的货外包装是破的"，后一句话问"你们有没有同系列的礼盒装"，这中间的逻辑关系只有同一个会话上下文才能捕捉到。

从技术上说，这意味着记忆模块必须在多轮对话中持续维护一个"用户状态"，里面至少包含三类信息：

• 用户身份：登录ID、历史订单数、会员等级、常用收货地址所在区域
• 会话目标：当前这一轮到底是售后服务优先，还是选品比较优先
• 商品意愿池：用户提到过、点开过、加入过暂存的商品ID列表

这个状态不用大模型刻意去整理，更靠谱的方式是用结构化的槽位填充，在每个关键节点由意图识别模块更新。大模型只负责读状态、做决策，不负责凭空记忆。我把这个设计叫做"状态放在系统里，语言交给模型"，后面会详细说。

1.3 边界画在哪：不越界的导购才是好导购

合并之后最容易出的问题，是智能体过于热情。用户只是想查个快递，结果被连着推荐了三轮商品，这种体验比查不到快递更让人生气。

所以我给智能体定了一条操作原则：服务请求优先，导购推荐靠后。如果用户当前的意图是售后类，智能体必须在完成售后处理后，才允许在回复末尾附带一个不超过两句的推荐语；如果用户明确表达"现在不需要"，推荐动作直接取消，并且在接下来三个轮次内不再主动发起推荐。这个阈值是上线后用用户投诉数据反推出来的，一开始设的是两个轮次，被投诉"太烦了"之后改成了三个。

边界感还需要落到话术设计上。同样是一句话，好的说法是"如果后面想看看其他款式，我可以帮你对比，不着急"，而不是"这款颜色卖得很好，要不要一起带走"。前者把主动权还给用户，后者是典型的推销腔。别小看这个差异，差评原因里"机器人一直烦我"的占比一度排到前五。

2. 主链路设计：意图识别、状态管理和工具调用的分层方案

2.1 三层骨架：交互层、决策层、执行层

整个智能体的技术骨架我分成三层，从下往上分别是：

• 执行层：各种外部系统接口的封装，订单查询、退款申请、库存校验、价格查询、优惠券核销，全部以工具函数的形式暴露
• 决策层：负责理解用户请求、判断意图、决定下一步调用哪个工具，核心是一个大模型加一套决策提示词
• 交互层：负责多轮对话的组装、话术模板、异步消息的发送

这样分层的核心原因是一个大模型没办法也不应该直接操作数据库和订单系统。让模型通过工具调用的方式去访问，权限可控、日志可查、出问题了可以单点回滚。我给每个工具都定义了严格的入参和出参schema，并且规定大模型一次决策最多调用两个工具——限制工具数量可以显著降低模型在复杂场景下的幻觉概率。

2.2 意图识别两步走：轻量分类器兜底，大模型做二次确认

意图识别是整个智能体的方向盘。常见做法是直接让大模型判断意图，但在真实场景里，尤其是晚高峰高并发时，把每一轮对话都丢给大模型做意图分类，成本和延迟都很难看。

我的做法是两步走。第一步用一个小型分类模型在本地做意图粗分类，类别只设六个：售前咨询、售后服务、订单查询、退换货、商品推荐、闲聊。这个模型的参数量不大，几秒钟就能出结果，负责拦截掉明显不需要大模型处理的简单请求。第二步才是大模型介入，在粗分类为"售前咨询""商品推荐"这类需要理解力和表达力的场景里，模型结合状态做细粒度判断。

这里有个经验：粗分类无法确定时不要硬分，交给大模型做兜底判断，然后让人工在离线抽样里看分类错误率。上线第一周我们分类准确率只有88%，后来发现大部分错误集中在"退换货"和"订单查询"这两个类别上，原因是用户口语太多："那个东西我不想要了"这种话，分类器很容易当成订单查询。最后靠加了一批规则模板才压到96%以上。

2.3 工具调用的实现：订单查询、库存校验、价格保护怎么接

工具调用是智能体真正"办实事"的关键。我举订单查询这个例子：

用户在对话里说"帮我查一下我那个咖啡机的物流"。决策层需要从这句话里抽取两个关键参数：订单号和查询类型。订单号往往不是用户主动提供的，需要通过用户身份ID去订单系统反查最近的订单列表，再结合用户提到的商品关键词（咖啡机）做匹配。这个匹配逻辑我建议放在工具函数内部，而不是让大模型猜。

工具函数返回的数据要经过一次"裁剪"，只把用户真正需要的信息拼装进回复。订单流水有几十个字段，但是给用户看的永远是那几个：当前状态、物流单号、预计到达时间、异常原因。裁剪的好处是减少大模型的输入token成本，同时降低模型被无关字段干扰的概率。

退换货接口更要注意幂等性。用户提交一次退货，如果因为网络超时被重复提交了两次，订单系统会出现重复工单，这是真实发生过的事故。解决办法是在工具层维护一个请求ID，同一对话同一请求只允许处理一次，重复请求直接返回上一次的结果。这个细节花了我一天时间，但上线后再也没出过重复工单。

3. 知识库、提示词与索引：决定智能体贴不贴业务的地基

3.1 知识库的本质是把"老师傅的经验"结构化

很多团队做智能体，第一反应是"把文档丢进去，让模型读"。丢进去之后发现效果很差，因为文档是给人看的，不是给模型用的。客服场景的知识库要想有效，必须改造成原子化的问答对。

比如"你们的物流一般几天到"这个问题，文档里可能写在"配送说明"的第三段，模型能读到但要花不少力气，而且不同地区答案不一样，模型很容易挑错。我在项目里做的改造是：把每条知识切成"问题+答案+适用条件+失效日期"四个字段的结构化条目，涉及到分地区、分时效的信息，就拆成多条记录。这样检索命中时直接返回答案，可靠性高很多。

这个结构化过程一开始没有捷径，只能靠业务侧提供原始文档，产品经理带着标注团队逐条拆解。一个小家电品类，几千条知识条目大概花了两周。但后面迭代的效率会指数级提升，因为每一次用户反馈的错误都能精准定位到某一条知识上，改一条比改一个大文档快得多。

3.2 提示词里的三件事：人设、边界、兜底话术

提示词是智能体的"性格"，也是它的"紧箍咒"。我的提示词模板分为三块：

第一块是人设，说明这个智能体的身份是店铺官方客服，语气友好、专业、不过度热情，称呼用户用"您"。第二块是边界，严格规定哪些可以做、哪些必须拒绝、哪些需要转人工，例如涉及赔偿金额超过一定额度、用户表达强烈不满、用户要求联系真人客服，都必须触发转人工。第三块是兜底话术，当模型拿不准时应该怎么回应，核心原则是"不确定就不编造"。

我写过一个可以直接复用的兜底话术框架：

如果用户的问题超出了知识库和工具能处理的范围，不要尝试编造答案，可以这样回复：
"抱歉，这个问题我需要再核实一下，已经为您转接人工客服，预计今天之内会联系您。您也可以直接拨打热线电话。"
这个话术看起来很普通，但它是上线初期防止幻觉投诉的关键闸门。

提示词里还有一个容易忽略的点：不要让模型每次都把完整人设复述一遍。有些模型会自动在回复前加一句"作为AI助手，我……"，这句话在客服场景里等于向用户宣示"我是机器人"，信任感立刻减半。所以我在提示词里加了一条"永远不要提及自己是AI助手，直接回答问题"的约束。

3.3 检索增强不是万能药：召回结果要过一道"安检"

知识库再结构化，也避免不了检索系统偶尔召回错误内容。尤其是那些"看起来很像但实际不适用"的问题，比如"这个杯子能不能进洗碗机"和"这个杯子能不能进微波炉"，某些场景下检索模型会给同一个答案。

我的做法是在检索层和大模型之间加一个"置信度安检"。检索结果返回时，附带上每一个结果的相似度分数和知识条目的适用条件。决策层在拿到这些信息后，如果最高分的相似度低于阈值，就判断为"未命中"，不会强行用低质量结果去回答；如果命中但适用条件明确不匹配（比如地区不是发货范围），也会直接放弃。

阈值怎么定？我建议用一批真实历史对话做标注测试，跑一遍不同阈值的精确率和召回率曲线，选一个"宁可不答也不答错"的点位。我们项目里最终把阈值定在0.72，在这个值下召回的漏答率只增加了5%，但错误回答的比例下降了大约40%。

4. 导购能力落地：从被动应答到主动推荐的实现路径

4.1 商品知识怎么喂给智能体：向量化与属性过滤

导购部分的核心问题只有一个：用户说"我想要一个不粘的、能进烤箱的锅"，系统怎么找到最合适的那一口？

我采用的方案是"向量召回+属性过滤"双通道。向量召回负责语义相似，把用户的模糊描述（"不粘""进烤箱""容量大一点"）转化成向量，在商品知识库中找出语义上相近的商品；属性过滤负责硬性约束，把用户明确提出的参数（材质、容量、价格区间、是否包邮）做成结构化过滤条件，先筛掉一批明显不符合的。

双通道结果取交集，再按综合分排序。这个综合分不是简单的向量相似度，而是把销量、好评率、与用户偏好的匹配度做加权。我的经验是向量相似度只占40%，其他占60%，因为用户真的下单，看的是综合体验而不是语义像不像。

4.2 推荐排序：优先回复问题，再夹带推荐

导购智能体和传统推荐系统的最大区别在于：用户是先提问再被推荐，而不是先进推荐流。一个用户问"这个吹风机噪音大吗"，如果你的回复直接变成三款吹风机的参数对比，他没得到想要的答案，自然也不会点你的推荐。

所以我的推荐动作分为两步。第一步是回答用户当前的问题，这个回答要精确、直接、带来源。第二步才是在用户回答满意之后，附上推荐内容，推荐内容必须跟当前讨论的商品同品类或者强关联，几乎不支持跨品类推荐。比如用户在问吹风机，你推一款空气炸锅，哪怕数据上好，实际点击率也低得可怜。

推荐语的长度控制在三句话以内，包含商品名、核心卖点、为什么适合他。超过三句用户根本不看。我们做过A/B测试，三句话版本的商品点击率比五句话版本高32%，转化率高18%。别觉得话多是把信息都给足了，对话场景里的耐心比网页端低得多。

4.3 动态数据兜底：价格、库存、促销必须走实时接口

导购推荐最怕"推荐了一个无货或者已涨价的商品"。静态知识库里的价格信息在活动期间往往几小时就过时，所以凡是涉及价格、库存、促销状态的商品信息，一律需要在推荐时通过工具实时拉取，不允许直接读知识库里的静态字段。

这条规则让我吃过一次亏。某次大促前我把一批商品的价格预更新到了知识库，结果凌晨价格临时又调了一版，智能体推出去的价格全部是错的，客服电话被打爆。从那以后我把知识库里的商品价格字段全部声明为"只读参考"，模型在任何推荐场景下都必须先掉实时接口取数，取不到的宁可不再推销，也不要报错数字。

实时接口的压力也不小，我做了一层简单的缓存：同一个商品在30秒内的价格和库存复用缓存，超过30秒重新拉取。大促场景下这层缓存能把接口压力降一半左右，而价格误差几乎感知不到。缓存时间可以根据活动强度动态调整。

5. 转人工策略、效果指标和对话数据的迭代闭环

5.1 转人工的四个触发条件

再聪明的智能体也不能覆盖全部场景。人工转接不是失败，而是系统设计的一部分。我总结出四个必须转人工的触发条件：

这个列表里，情绪识别往往被放在最后，但它其实是准确率最差、最容易误报的一个。我因此做了一层"确认机制"：情绪模型报高负面时不直接转，而是由大模型结合上下文判断一次，两个信号都高才转。误转率从将近20%降到了5%以下。

5.2 指标怎么定：解决率、满意度、转化率一起看

客服智能体的指标不能只看一个。我日常盯四类：消息解决率（用户在智能体会话内问题是否得到解决）、用户满意度（会话结束后的打分）、意图转人工率、下单转化率。这四类要放一起看才有意义。

举个例子：某次版本迭代后人工转接率从12%降到7%，看起来很好，但满意度也从4.2掉到了3.8。深挖发现，是因为一部分用户没送到人工，问题没解决但也不想投诉，直接走了。所以单独追求降转接率是危险的目标——它丢失的是服务质量。正确的指标组合是"转接率下降的同时，满意度不下跌、解决率不下跌"，这才是真的优化。

我还会额外看一个"关联购买转化率"，统计在智能体推荐后有多少用户产生了加购或下单。这个指标直接衡量导购能力，也是区分客服机器人和导购智能体的分水岭。项目中期我们把这个指标从1.2%提升到了4.6%，靠的主要是推荐时机和推荐话术的调整，而不是推荐商品的变化。

5.3 数据回流：每一轮失败对话都是下一次迭代的养料

智能体上线不是结束，只是迭代的开始。我建立了一个每天凌晨跑的数据回流任务，把前一天所有会话按标签分类：解决成功的、转人工的、差评的、超时的。其中转人工和差评的会话是重点分析对象。

分析方法很朴素：抽样100条人工介入的会话，看用户最后说了什么让模型决定转人工，这个"临门一脚"往往就是模型能力的缺口。比如我们曾经发现大量会话集中在"改地址"这个话题，用户已经下单了想修改收货地址，而工具层没有提供这个接口。补齐接口之后，这一类会话的转人工率直接从65%降到了12%。

数据回流还有个容易被忽略的价值——发现知识库的盲区。用户问的很多问题，业务方根本不知道会有人问，比如"你们这个产品孕妇能不能用"。这种问题模型答不了，但业务方其实能给出答案。每周从差评会话里提取一批"未覆盖问题"，交给业务方补充知识条目，这是知识库持续变厚最有效的方式。

6. 上线半年踩过的坑：幻觉、延迟和成本的三笔账

6.1 幻觉的三道防线

大模型客服最怕的就是一本正经地胡说八道，我在这上面吃了不止一次亏。第一道防线是"检索命中才回答"原则：凡是知识类问题，必须从知识库召回高置信度内容才能答，召回不到就按规则走兜底。这条原则把知识类幻觉几乎清干净了。

第二道防线是"工具结果为准"原则：凡是涉及订单、价格、库存等动态数据，一律以工具实时返回的结果为准，模型不得凭记忆推断，也不得引用知识库里的静态价格。第三道防线是"回复前自检"：在模型生成回复后，用一次轻量的校验，检查回复中是否有具体数字、具体日期这类"高风险陈述"，如果有则必须能在工具返回或知识条目里找到对应信息，否则整句删除。

三道防线听着繁重，实践中就是几个if判断加一个校验提示词。但效果非常明显：上线第一个月，有明确事实错误的回复占比是4.7%，加完三道防线后的第二个月降到了0.3%以内。

6.2 模型分级：把贵的调用用在刀刃上

全链路所有对话都走同一个大模型，是个成本灾难。我上线第一个月的账单差点让我没睡着。后来做了模型分级：

分级的直接效果是单次会话的模型成本下降了约60%，同时整体延迟从平均2.3秒降到了1.4秒。有一条经验：不要因为省成本把复杂的决策场景也降级，省下的那点钱会在差评和转人工里加倍还回来。我在一次灰度中试过把商品对比场景降级成中等模型，结果用户满意度直接跌了0.3个点，马上回滚了。

6.3 灰度上线的几个细节

智能体上线最忌一步到位。我的做法是先在10%的流量上灰度一个星期，重点盯两个数字：投诉量是否上升、关键时刻转人工是否正常。灰度期间每天拉一次会话日志，人工过一遍模型回答，发现明显错误立即回滚到上一个稳定版本。

版本回滚也要提前做好准备。我把提示词和知识库配置全部纳入版本管理，每次改动都能一键回退。这个看起来是工程规范，但真正救过我两次：一次是新提示词里把人设约束写错，导致智能体自称"AI"，灰度三小时就被发现回滚；另一次是知识库里一条退换货规则的失效日期配错，差点让一批不符合条件的退货单通过审核。没有版本管理的话，这两次事故的影响面会大得多。

智能体的维护是一场持久战，不存在"上线即完成"的状态。尤其在你把客服和导购合并之后，系统的复杂度加倍，但是带来的业务价值也会加倍。把上面这套骨架搭起来之后，后面的优化就变成了持续打磨知识、调阈值、看数据的过程，天花板远远高于传统的规则机器人。