大促刚结束客服后台的消息列表红点一直跳运营同事在群里发了一句客服真的不够用了。那段时间我一直在想如果把大模型接进来做电商客服能不能顶一阵子但真去试了才发现直接丢一个通用模型当客服大概率会被用户怼回来甚至把店铺投诉量拉高。我们后来花了大约两个月时间把一个电商客服导购智能体完整做了出来这篇文章准备把整个设计思路和落地过程摊开来讲包括怎么拆架构、怎么建知识库、怎么定义意图和工具、上线后怎么评测、踩了哪些坑。如果你也在考虑用大模型做类似的客服、导购或私域助手这篇文章应该能帮你少走不少弯路。1. 为什么客服智能体不能直接拿通用大模型顶上1.1 客服表面是对话本质是“业务操作体验承诺”刚立项那天我们几个人的想法很简单接一个大模型给一段系统提示词再丢一堆商品说明它不就能回消息了吗结果第一次内测就翻车了。有用户问“我的订单到哪了”模型回了一长段“您的订单正在运输中请耐心等待”问题是那笔订单在系统里压根没有付款记录。这不能怪大模型它在聊天里表现得像一个“客服”但它没有权限查订单也没有接入业务系统所有回答都只能靠猜。电商客服和普通闲聊机器人最大的区别在于客服的大多数动作不只是说话而是要落到业务系统里。用户说“我要改地址”你得真的去订单系统里调出这笔订单确认收货地址能不能修改再执行修改用户说“我要退货”你得查商品是否在可退周期内、有没有运费补贴然后生成售后单。这些动作只要有一个环节出错就不是“回复质量不高”的问题而是实实在在的客诉和资损。所以第一步想清楚的事是智能体不能只做一个会聊天的语言模型它必须是一个能编排工具、能查数据、能按照规则办事的系统。语言生成只是最外层的壳真正的核心是业务动作。1.2 客服和导购是两套人设、两套目标别混在一个prompt里再往深看一层电商场景里的“客服”和“导购”其实是两种能力甚至可以说两种人格。客服的核心目标是“不出错”准确解释规则、如实告知物流、不轻易承诺赔偿、不跟用户起冲突。它的语气是克制的、被动的用户问什么答什么绝不画蛇添足。导购就不一样了。导购的目标是“多卖货”用户说“随便看看”你得从对话里挖出送人还是自用、预算多少、偏好什么颜色然后主动推荐商品把“随便看看”聊成“我想买这个”。它的姿态是主动的、热情的需要会用利益点打动用户。把这两个目标塞到同一个提示词里模型很容易“人格分裂”。比如用户说“这个外套多少钱”客服线应该直接报价格导购线想的是“要不要顺便告诉他搭配裤装更划算”。第一次上线测试时我们就观察到智能体有时候过度热情用户明明是在问退货流程它却在推荐“如果不喜欢可以换季新品”用户直接说“你是机器人吧”。后面我们把架构改成了“一个入口、两条工作流”——先用意图识别把用户分流到客服线或导购线每条线用自己的提示词、工具和知识库。这个拆法的好处是客服线可以严格卡规则导购线可以放开话术客服线出错了能追踪到规则哪里不严导购线效果不好也能单独调参不会互相污染。1.3 现实约束时延、成本、红线一个都不能放松抛开原理讲现实。我们上线前排了一组硬性约束全部来自业务侧的反馈首屏响应时间不能超过3秒。用户可没有耐心等一个“正在思考”的转圈动画超过3秒就会连续追问或者直接关掉窗口。单人单轮对话成本要压到可控范围。一通咨询往往要来回七八轮如果每一轮都调用一次高配大模型大促当天账单会非常难看。平台上有一批“红线词”属于绝对不能乱说的比如“保证赔付”“无条件免单”“绝对正品”这类确定性承诺模型一旦自由发挥说出了口店铺就要背锅。我把这些约束写在项目第一页文档里时刻提醒自己这是一个工程系统不是一次大模型调用。约束项指标要求原因首屏响应≤3秒用户耐心有限超时会重复提问单次交互成本控制在可控范围大促并发时成本会指数级上涨红线词命中后强制走人工模型不能做出任何决定性承诺夜间弱算力降级为模板小模型保证系统不挂、不胡言乱语2. 整体设计一个入口分发两条工作流各干各的2.1 入口层先决定“该聊商品还是该办业务”整个智能体最前面是一个轻量入口层它不直接跟大模型对话而是先把用户消息分门别类。这个入口我们同时用了规则和模型规则负责处理确定性信号——用户消息里出现“退”“换”“投诉”“人工”等词基本可以直接判断为售后或客诉模型负责处理模糊信号——用户说“你们家有没有适合送妈妈的包”这类话没有售后词但明显是导购需求。入口层把用户请求打成四类标签售前咨询、售后服务、导购推荐、其他对话包括闲聊和脏话等。前两类走客服工作流第三类走导购工作流最后一类直接用固定话术处理不占用大模型推理资源。为什么要单独做这层分发因为如果不做分流让一个模型同时处理售后、销售、闲聊最后每个任务都做不精还会出现“用户问退货模型推荐新品”这种尴尬情况。入口层把复杂问题先拆开每条下游链路只需要面对自己那类问题提示词可以写得更窄、更准、更容易维护。2.2 客服工作流查得准、答得稳、不越权客服线内部是一条标准的“感知-决策-执行”链路拆成四步意图识别和槽位抽取识别用户要查物流、查订单、申请退款还是开发票顺带抽取出订单号、商品名、退款原因这些关键信息。工具调用根据意图去调用订单查询、物流查询等接口拿到真实数据。知识检索从售后规则库里召回对应的政策片段比如退款时效、运费承担方、发票开具流程。回复生成和安全校验把工具数据和规则片段拼进提示词让模型生成一段人话生成后再过一道敏感词校验确认没有越过红线。伪代码大概是这样的def handle_service(user_msg, session): intent, slots parse_intent(user_msg, session) if intent logistics_query: trace call_logistics_api(slots[order_id]) policy retrieve_policy(logistics_status, trace[status]) reply generate_reply(intent, trace, policy) reply safety_check(reply) return reply elif intent refund_request: # 退款这种破坏性动作先确认不直接执行 return ask_confirm(slots)每个环节都做成独立接口而不是让大模型一把抓。这样做的最大好处是可观测哪里出问题直接定位到具体环节不用猜模型到底“理解错了什么”。2.3 导购工作流把“随便看看”聊成“我要买这个”导购线和客服线完全不同它不查订单不做售后它只做一件事从用户的模糊语句里挖需求然后给出有说服力的商品推荐。用户的原话往往非常短比如“想给爸爸买个保温杯不要太贵的”。这句话信息量很少但我们能抽取出的槽位有使用场景是礼物、目标人群是中年男性、价格意向是“不要太贵”。有了这些槽位之后导购线开始干活召回候选商品从商品库里按品类、价格带、标签召回8到10个候选。生成对比信息把每个候选的参数整理成几句话比如容量、材质、保温时长、重量。生成推荐话术根据用户的场景选择最重要的一到两个卖点而不是把所有参数都堆给用户。我们当时给导购线定了一条原则推荐必须有依据任何结论都要落到具体参数上。同一款保温杯对“送爸爸”的用户理由可以落在“500ml大容量适合喝水多的人”对“送女朋友”的用户落在“轻量设计携带方便”。模型不能只会说“这款很棒”要能解释清楚棒在哪里。2.4 两条工作流怎么切换逻辑要钉死系统里经常出现的情况是用户本来在问商品聊着聊着突然说“那我先退了你们这个也不便宜”。这时候智能体必须立刻从导购线切回客服线不能再补一句“那您可以看看另一款更实惠的”那只会火上浇油。我们定义了几条切换规则全部写死在入口层触发场景切换动作用户提到退换货、投诉、人工直接进客服线用户情绪强烈连续多个感叹号、表意明确生气直接进客服线且优先转人工导购流程中连续两次推荐被否停止推荐改问用户具体需求售后处理完成用户语气缓和可尝试一句温和的交叉销售不复推切换规则是血的教训总结出来的。一开始我们没有做强制切换结果模型在用户生气的时候还在推商品体验非常差。把逻辑钉死、用规则兜底之后哪怕模型再傻也不会在错误时间干错误的事。3. 冷启动知识库把卖点和售后规则变成可检索的上下文3.1 冷启动数据从哪来翻聊天记录、啃商品详情页、逼运营交底知识库是整个智能体的记忆。没有知识库模型就像一个口才很好但什么都不懂的新员工。我们冷启动的时候没有花哨的办法就是老老实实做了两周的“知识整理”第一翻历史聊天记录。把所有能导出的客服会话导出来筛出高频问题。常见的是“什么时候发货”“运费怎么算”“尺码偏不偏”“有没有赠品”这些直接整理成一对一的QA条目。第二啃商品详情页。每个商品页的规格参数、卖点文案、常见疑问我们抽成了结构化字段。比如一款杯子参数表里有“容量500ml”卖点文案里有“食品级不锈钢”常见疑问里有“能不能放微波炉”。这些内容分开存类型不同后面检索策略也不一样。第三逼运营团队把售后规则以书面形式写出来。退换货周期、运费补贴上限、发票开具流程、赠品缺失的处理方式……这些规则过去散落在各个人脑子里不写出来模型根本无从学起。我们用了一周时间让运营一条一条填表这一步虽然枯燥却是后面所有准确性的地基。3.2 分库售前、售后、话术各管各的一开始我们把所有知识都塞进一个向量库里结果发现一个严重问题用户问“退货运费谁出”向量检索经常会召回一堆商品介绍比如“运费说明偏远地区不包邮”跟售后政策混在一条上下文里模型生成回复时就容易张冠李戴。后来我们把知识库拆成了三个子库知识库内容更新频率检索方式售前商品库规格参数、卖点、商品QA每周一次向量召回关键词精确售后规则库退款、物流、发票、赔付规则规则变动即更新规则匹配向量召回话术风格库不同场景的开场白、安抚语、转人工话术每月一次按场景分类直接调用分库的价值是避免“上下文污染”。售前库管商品、售后库管政策各自独立检索、独立过滤。模型生成回复时只拼接对应库的内容规则就清晰多了。特别是售后规则这种强逻辑内容更适合用规则匹配去精确命中而不是靠向量相似度去“猜”。3.3 混合检索而不是只靠向量召回只做向量检索的另一个坑是对数字和型号不敏感。我们实测过向量检索对语义相近的句子召回效果好但到了精确数值就时常漂移用户问“500ml的保温杯有吗”向量检索可能召回“550ml”的产品因为语义相似度太高了。所以后来我们做的是混合检索关键词精确匹配管型号、规格、数字类查询比如“500ml”“316不锈钢”“订单号”。向量召回管口语化表达比如“这衣服掉色吗”对应到洗涤说明。规则匹配管政策类问题比如“退货地址是多少”直接从售后规则库精确拉取。三类结果会合并排序取分数最高的前几段作为上下文。排序时有个小技巧关键词精确命中的结果权重最高因为数值和型号类的错误是不能容忍的向量召回的结果降一档因为它更多是扩展语义不是精确事实。3.4 可刷新的“事实池”防止参数过期知识库还有一个绕不开的问题商品数据会变。价格会变、库存会变、上下架状态会变。如果这些动态数据写进长期知识库里模型拿到的永远是旧数据。我们曾经出过一个事故智能体推荐了一款已经下架的连衣裙用户高高兴兴地点进去发现链接404转头就是一个投诉。后来我们把知识库分成两层静态知识和动态事实池。动态事实池专门存状态变化频繁的字段——商品当前是否在售、实时库存、当前价格、优惠活动标识。这些数据不放进长期知识库而是定时从商品系统同步到内存表中。生成回复前先查事实池拿到最新状态再结合知识库里的静态卖点描述最后才让模型开口说话。这个改动之后“商品已下架但还在被推荐”的坑基本被填平了。事实池刷新频率不用太高我们设置的是五分钟同步一次大促期间会缩短到一分钟一次够用且不至于压垮商品接口。4. 意图识别与状态机决定智能体“什么时候该闭嘴”4.1 意图标签体系不是拍脑袋是从真实会话里长出来的意图识别是智能体的大脑它必须知道用户这段话说的是“想买东西”还是“想退东西”之后所有动作都建立在这个判断上。我们最初照着网上常见的对话系统标签表套了一版结果发现根本不好用因为电商场景的意图颗粒度太细。后来我们老老实实把历史会话按频次做了个统计最后沉淀出十几个高频意图比如意图用户常见说法对应动作是否需要工具price_query这个多少钱 / 现在有优惠吗返回价格和优惠信息需要查事实池logistics_query发货了没 / 快递到哪了调用物流接口需要refund_request我要退 / 怎么退货生成退货指引或创建售后单需要recommendation_request送女朋友适合什么走导购召回和话术生成不需要工具但要商品库complaint你们太慢了 / 我要投诉直接转人工需要有了这版标签之后我们再去让模型做意图分类准确率明显提升因为标签本身更贴合真实业务。这个梳理过程很耗时但是必须做。标签体系是后面所有评价指标的地基如果标签本身混乱再准的分类器也没有意义。4.2 多轮状态机追问到槽位齐了再执行别让用户重复填客服场景里用户的第一句话往往信息不全。比如用户说“我要退货”缺了订单号这就要靠多轮对话把缺的槽位问出来。我们把这类流程做成状态机每个意图对应一组必填槽位当前缺哪个就问哪个一次只问一个不打扰用户。举个例子“退货申请”这个流程的状态序列是用户说“我要退货”系统发现缺订单号。系统问“方便提供一下订单号吗”用户发来订单号系统查单确认商品信息。系统继续问退款原因用户选择“尺码不合适”。所有槽位齐了生成退货指引包括地址、退回要求、注意事项。状态机里最重要的一条经验是该闭嘴的时候必须闭嘴。槽位齐了、该落地执行了就不要再追问“还有其他需要帮忙的吗”——这句话在真人客服嘴里叫服务周到在智能体嘴里就是机器人味拉满。用户体验的一大来源就是节奏感系统知道什么时候该问、什么时候该停。4.3 一个让我印象深刻的误判把“催发货”听成了“要退货”这个坑必须放在前面说因为它太典型了。有一次内测用户发来一句“你们到底什么时候发货啊再不发我就退了。”意图识别模型把它识别成了“退货申请”于是智能体回复“好的您是想要申请退货吗”用户当场炸了我不是要退我是在催发货我们复盘原因发现两个问题叠加在一起第一这句话里同时出现“发货”和“退”模型对“退”字的敏感度过高直接归到了退款类第二我们没有做“破坏性动作确认”退货这种高影响操作系统直接就准备接单了。修正方案是双管齐下在意图识别层增加一个“催发货-潜在退货”的边界意图用模板去匹配“再不发我就退了”这类句式在动作层规定所有退款、索赔、投诉类动作必须先发一句确认句——“您是希望申请退货还是查询发货时间呢”一句话确认成本极低却能避免最严重的用户情绪恶化。5. 工具调用与系统联动让智能体真正能“办事”5.1 需要定义的几类核心工具查询、修改、创建一个都不能少智能体要“办事”就必须能把自然语言翻译成对系统的调用。我们把工具分成几类每一类都采用统一的函数描述查询类查询订单详情、查询物流轨迹、查询优惠券。操作类修改收货地址、申请退货、重新发起配送。计算类计算预计退货金额、计算满减差价。每个工具的定义我都会写成统一格式方便模型理解参数和约束{ name: query_logistics, description: 根据订单号查询包裹物流轨迹, parameters: { type: object, properties: { order_id: { type: string, description: 用户提供的订单号 } }, required: [order_id] } }这里有个容易被忽视的点工具描述要写得足够具体尤其要说清楚“什么时候用、什么时候不用”。比如查询物流的工具描述如果只写“查询物流”模型很容易在用户问“发货了吗”时顺手调用实际上这个动作完全可以等一版再说减少一次接口调用就降低一次出错概率。描述越精确模型越不容易误调用。5.2 从工具返回数据到“人话”的翻译别把JSON丢给用户工具返回的数据是机器语言不能直接拼到回复里。我们内部定了一个规矩系统返回的数据永远先经过一层“话术模板”把状态码翻译成用户能看懂的表达。物流状态码原始含义话术模板shipped包裹已由仓库发出您的订单已经打包完成快递员正在揽收预计1-2天内会有更新in_transit运输中您的包裹正在运输途中最新位置是XX请耐心等待delivered已签收您的包裹已被签收如果没找到可以查看一下快递柜或前台exception运输异常您的包裹在途中遇到延误我们会尽快核实请您先别着急光有模板还不够还要加一层校验逻辑。工具返回的数据如果显示订单不存在就绝不能生成“您的订单正在运输中”哪怕模型再想顺嘴编校验层也会把它拦下来。这种“生成前校验”是减少错误承诺的核心手段。5.3 转人工兜底别让用户陷在死循环里不管智能体做得再好总会有它搞不定的事。我们把“转人工”当成系统的安全阀而不是失败。触发转人工的条件我们设置了四条用户主动要求人工客服。进入投诉、赔付、高阶纠纷场景。连续两轮意图确认失败模型始终不确定用户要干什么。命中红线词系统判定不能继续对话。转人工时系统会把完整会话记录、识别到的槽位、当前走到哪个状态、工具调用结果全部打包给坐席后台。人工客服接过来时已经能看到用户的完整上下文不需要用户再复述一遍。刚开始我们没做上下文传递转人工之后用户要重新解释半天体验比没有智能体还差。补上之后这个环节才算真正闭环。转人工的另一个小细节如果用户情绪已经非常激动智能体转人工之后就不要再多话了直接发“我帮您安排人工客服请稍等”。不要在结尾画蛇添足加一句“祝您生活愉快”那只会让用户更冒火。6. 上线后的评测与踩坑从“能用”到“好用”不是一回事6.1 客服线看什么数据准确率只是底线红线违规才是高压线智能体上线之后评测不能只看“回答得像不像人话”。我们客服线的指标体系分三层指标计算方式目标值意图准确率从历史会话中抽样标注比对模型判断与人工标注95%以上一次解决率用户是否在同一个会话里再次提出同类问题85%以上红线违规率回复中是否出现错误承诺、漏报规则等低于0.5%转人工率转人工会话数 / 总会话数30%以下动态调整准确率、一次解决率都只能说明系统“大多数时候好用”。真正要盯死的是红线违规率因为这是一个“一次事故就可能抹掉一百次好评”的领域。我们每周会抽100条会话人工复核凡是红线违规样本会立刻回溯到提示词、知识库、校验层定位是哪个环节漏的。还有一类指标不能只看平均数夜间与大促期间的响应情况。白天流量小高配模型慢慢推理也没关系夜间凌晨流量几乎为零但恰恰是用户最容易急躁的时候。我们后来专门为夜间启用了降级策略模板能答的问题绝不让大模型回答保证弱算力环境下也不会“卡死”。6.2 导购线看什么数据盯着转化率但不做“硬推荐”导购线的评测和客服线完全不同它关心的不是“有没有犯错”而是“有没有卖出东西”。我们看的主要指标是商品卡片点击率智能体推荐的商品用户有没有点进详情页。推荐咨询转购率聊完推荐后用户有没有真正下单。平均客单价导购对话带来的成交金额是否高于自然流量。不过这里有一个反直觉的提醒导购线最怕的不是推荐效果差而是“硬推荐”。用户明明没有购买意向智能体还在反复推商品这会让用户产生强烈抵触甚至演变成投诉。所以我们同时监控一个反向指标——推荐引发的投诉率只要这个指标上升立刻收紧推荐触发条件。导购线的调优我们还发现把主推商品和活动信息在话术里“软性植入”比直接说“现在买可以减30元”效果更好。比如推荐一款保温杯时顺带说“这款正好参与店铺满减活动”用户会觉得自己在做选择而不是被推销。6.3 踩坑记录参数过期、提示注入、串单、回复过长上线这几个月我们踩了不少坑很多都很有共性整理成了一张表坑现象根因现在的解法商品参数过期推荐了已下架商品用户点击404商品池没有实时同步事实池五分钟同步一次提示注入用户输入“忽略之前的指令”后模型开始说奇怪的话没有对用户输入做风险过滤输入侧加风险词和注入模式过滤多轮记忆串单A订单的物流贴到了B订单会话状态中实体没有隔离工具调用时必须传订单号作为主键回复过长用户已读不回模型一次性输出太多信息限制回复长度长内容用列表归纳情绪误判用户正常问一句模型以为在投诉情绪识别阈值调得太低只有在明确攻击性措辞时才触发安抚流程这里最值得展开的是“提示注入”。我们第一次做智能体时完全没想过这个点直到有一天某用户在对话框里输入了一串奇怪指令模型开始用一本正经的语气承认“我是AI助手不是店铺客服”运营当时冷汗就下来了。后来我们把所有用户输入先过一遍风险词过滤发现类似“ignore previous instructions”的模式直接替换成普通客服模板。这类安全机制不用做得特别聪明能挡住大多数试探就够了。6.4 成本控制模型分级与模板兜底最后说一个所有做智能体的人都躲不开的话题成本。我们的做法是模型分级不同任务用不同规格的模型而不是所有对话都走最强配置。场景使用模型级别原因快捷回复、价格查询、物流查询小型模型有工具和模板不需要复杂推理多轮导购、复杂售后推理高配模型需要综合多个商品参数和规则做判断最终话术润色中等模型主要做表达规范不需要强推理实测下来80%的会话用“小模型工具模板”就能解决高配模型只用在真正需要推理的场景。这个比例带来的成本收益非常明显大促期间服务器负载也没有失控。模板兜底是最后一道防线如果大模型接口超时、返回失败或者识别结果置信度过低系统直接走预设模板回复。模板内容宁可保守也绝不胡编。用户最反感的是“客服消失”和“客服乱说”模板兜底至少保证了两个都不会发生。回头看整个项目我最大的感受是做一个电商客服导购智能体模型能力只是地基真正决定上限的是数据新鲜度、工具调用严谨度和转人工兜底的完整性。这三样任何一样掉了链子模型跑得再快也白搭。如果让我重新做一遍我一定把商品事实池的定时刷新放在第一天去做而不是上线两周后才补上我也一定会在第一天就让“确认后执行”成为所有破坏性动作的默认规则而不是等误判事故发生了再改。这些细节不是大模型能教你的是用户一条一条消息把你教会的东西。