“电商客服+导购智能体”这个方向，我断断续续做了两版，从最早的“能聊天”到现在的“能卖货”，中间踩过的坑比写出来的功能还多。很多人一开始就把重心放在模型选型或Prompt调优上，结果上线后发现用户根本不按预设路径提问，推荐的商品点击率低得可怜。这个项目真正的难点，不在于“让机器说话”，而在于“让机器知道什么时候该客服、什么时候该导购”，以及怎么把这两件事在同一套技术框架里无缝切换。这篇内容我会尽量把一个可落地的方案拆开讲，从整体设计、核心模块，到实现细节和避坑经验，适合准备在电商场景里接智能体、但还不太确定技术选型和功能边界的团队参考。
1. 先想清楚：为什么客服和导购要放进同一个智能体里
1.1 传统客服与导购割裂带来的问题
在很多电商系统里，客服和导购是两套完全不同的工具。客服走的是工单、话术库、知识库，本质上是“用户有问题，我去查答案”；导购走的是推荐算法、优惠策略、营销活动，本质上是“用户有潜在需求，我去推商品”。两套系统各干各的，问题就出在一个用户经常在一次会话里同时触发两种需求。
举个常见的例子——用户问“这个手机支持5G吗？”，这句话表面上是客服问题。但用户接下来很可能追问“那你们现在有优惠吗？能不能便宜点？”到这里就变成导购问题了。如果系统里只有客服机器人，它可能会机械地回答“当前商品暂无优惠”，然后对话结束，用户跑了。如果系统只有导购推荐，它可能一开始就推一通手机配件，用户觉得答非所问，直接退出。
我在模拟项目X里做的一次数据分析也印证了这一点：同时涉及咨询和购买的会话，比纯咨询或纯购买的会话转化率高出将近三成。问题在于这些会话往往需要用户手动切换“咨询窗口”和“购买窗口”，流失率很高。所以把客服能力和导购能力整合进同一个智能体，不是营销上的噱头，而是真实会话场景在倒逼技术方案。
1.2 单一客服机器人的能力天花板
传统客服机器人，大多是基于“意图分类+FAQ匹配”搭起来的，有的加一点知识图谱，有的加一点简单上下文。这套方案到今天仍然有它的价值，尤其适合处理“我的快递到哪了”“怎么开发票”这类高频、固定、答案明确的咨询。
但它有个天花板：它不理解“交易”。它不知道用户当前浏览了什么商品，不知道购物车里有啥，不知道用户说的是“这个”指的是哪一件商品，更不会根据用户预算做正向推荐。遇到“我想买个三千块以内的手机，拍点风景照用”这种需求，FAQ型机器人基本就废了，因为它没有“推荐”这个动作，也没有“对比商品”的能力。
而智能体要补的，恰恰就是这个断层。所谓“客服+导购智能体”，不是说把两个机器人的接口写在一起，而是让大模型在同一个会话流里面同时承担“解答确定性事实”和“完成主动性推销”两种职责，并且在适当的时候做角色切换。
1.3 智能体介入后到底能改变什么
从我实际跑下来的结果看，一个合格的客服+导购智能体，至少能做到三件事：
- 把客服场景里积累的“确定性问题”处理得更精准，比如订单状态、退款进度、发票信息，这些问题必须给确定性答案，不能靠生成。智能体通过调用订单系统API拿到结果，再组织成语言回给用户。
- 把导购场景里需要的“推荐”变成一个可解释的推理过程，不是简单“猜你喜欢”，而是基于用户刚问的问题、当前会话里的预算范围、历史偏好，组合出推荐列表，并且能说清楚为什么推荐这款。
- 在两个角色之间做平滑切换，用户从“问问题”切到“想买”，智能体不必重新拉一个新会话，上下文里的信息全部保留。这是转化率提升最明显的一个点，也是纯规则机器人最难做到的一件事。
我对团队的要求是：这个智能体不能只是一个会说话的大模型，它必须是一个有明确工具调用能力、有状态管理能力、有业务边界的系统。后面的内容基本都是围绕这个标准展开的。
2. 整体架构怎么搭：从一个“大模型壳子”到一个“智能体系统”
2.1 模块划分与数据流向
我把整个智能体分成了几个相对独立的部分：会话入口、语义解析层、路由与规划层、工具执行层、业务数据库与知识库、以及最上层的会话记忆管理。每一层负责一件事，避免把所有逻辑都塞进Prompt里。
会话入口很简单，就是承接H5、小程序、APP等不同端点的用户消息。语义解析层做意图识别和关键信息抽取，这里我用的是大模型+少量规则兜底的方式，而不是单独训练一个小模型设意图分类。原因是电商场景里的表达太灵活了，规则和传统分类模型覆盖不全，直接让大模型做Few-shot抽取，效果反而好，维护成本也低。
路由与规划层是整个架构里最关键的一环。它决定当前这句话到底应该走“客服模式”还是“导购模式”，或者同时触发。规划层拿到解析结果后，会把它拆成一个个操作步骤，比如“查库存—算优惠—对比两款商品—推荐”。每个步骤对应一个工具调用，工具调用回来后，大模型再组织语言生成回复。
工具执行层是一堆业务API的封装，包括商品检索、订单查询、库存校验、优惠计算、运费估算、知识库检索等等。这一层必须对上层提供统一的输入输出格式，不然大模型每次对接不同接口都容易出错。我刚开始就是没做统一封装，结果模型经常把一个接口的字段抄到另一个接口的返回里，排错排到怀疑人生。
知识库和业务数据库分开存。知识库放的是售后政策、退换货规则、常见问题这类相对静态且需要语义检索的内容，用向量库+关键词混合检索。业务数据库放的是订单、商品、SKU、优惠券等强结构化数据，必须在工具调用层实时查，不能用向量检索去猜。
2.2 模型选型与部署方式
基座模型我优先选了支持Function Calling（工具调用）的中文开源模型，原因很实际：电商场景里几乎每句话都需要对应到具体工具，没有函数调用能力的模型做这个项目会特别吃力。
选开源而不是闭源，主要是从成本和定制化角度考虑。客服+导购的场景里，Prompt会频繁调整，数据也在不断累积，用开源模型我们可以做有监督微调，把“话术风格”和“工具调用习惯”固定到模型权重里，而不是每次都在推理时靠Prompt硬撑。部署上我走了CPU+GPU混合推理的老路：简单意图识别走小模型或者Prompt模式，真正需要生成回复、调用工具的复杂对话走大模型。这样能把单次会话的平均成本压下来不少。
具体到模型大小，我的经验是7B级别的模型在日常FAQ上够用，但一旦涉及多轮推荐、多条件对比、长上下文，效果就明显吃紧。最终线上跑用的是13B级别，在延迟和效果之间勉强找到了平衡点。这里没有绝对的答案，取决于你的预算、QPS和硬件条件。但我不建议一上来就追大参数，先拿中等规模模型把链路跑通，比什么都重要。
2.3 会话状态与记忆设计
多轮对话里最容易被忽略的是状态管理。电商会话是强状态型的，用户可能在第3轮提到“红色的那款”，第5轮又说“还是算了吧”，如果你没有把“红色那款”对应的商品ID保存下来，后面所有推荐都是瞎猜。
我的做法是维护一个“会话状态容器”，里面保存当前用户正在浏览的商品、候选推荐列表、已经确认的筛选条件、待处理订单号、以及用户画像标签。每轮对话开始前，先读取状态容器；对话结束后，把本轮抽取出的信息更新进去。容器本身放在Redis里，设置超时时间，比如30分钟无互动就清理，避免长期占用内存。
记忆又分成短期和长期。短期记忆就是同一会话里的上下文，长期记忆是跨会话的用户偏好，比如“这个用户之前问过两次跑步鞋，预算都在五百左右”。长期记忆我放到向量数据库里，每次新会话开始时做一次召回，把有价值的偏好信息注入系统Prompt。这个设计上线后，对推荐商品的相关性指标提升很明显，因为模型不再每次从零猜用户。
3. 核心功能模块逐个拆：意图、商品推荐、交易动作
3.1 意图识别与任务规划的正确打开方式
很多团队喜欢把意图识别做成一个“单选题”，比如把意图分成咨询、售后、购买、投诉几类，然后让模型选。实际用下来，这样分太粗了。用户一句话里经常包含多个意图，而且意图还会在对话过程中发生漂移。
我在这版智能体里，改用了一种“标签组合+置信度”的方式。模型不是只输出一个意图，而是输出一组带概率的标签，比如“查询物流: 0.7，咨询商品参数: 0.3”。路由层再根据标签组合决定后续策略。如果“查询物流”概率最高，就优先调用订单物流接口；但同时带着“咨询商品参数”，系统会在回复物流信息后，追问一句“您是想看看这款的详细参数吗”，这就把客服顺利过渡到了导购场景。
任务规划部分，我采用的是“模板规划+兜底自由规划”的双层策略。预置一批高频场景的固定步骤模板，比如“退换货流程=校验订单→判断是否在售后期→查询退款规则→生成答复”。大模型识别到“退换货”这个场景，直接执行模板里的工具调用顺序，减少不稳定的推理过程。只有当模板匹配不上时，才让模型自由发挥，把任务拆解成临时多步计划。这样既保证了稳定性，也留下了灵活空间。
3.2 商品推荐的难点不在算法，在场景对齐
推荐模块如果你把它当成一个独立的推荐系统来做，基本会跑偏。智能体里的推荐和Feed流里的推荐逻辑不一样，用户是带着一个具体问题进来的，推荐必须跟着会话上下文走，而不是根据历史行为猜测。
我的实现方式是，先把用户本轮对话里抽出的商品筛选条件（预算、品牌、功能、颜色）转成结构化的查询参数，然后调商品检索API拿回候选集。拿到候选集之后，再做一次“可解释排序”，排序因子包括匹配度、销量、好评率、佣金比例和当前是否有活动价，每一项都有权重。大模型在生成推荐回复时，必须引用排序因子说明推荐理由，比如“这款价格在您预算内，而且最近一周销量前3”，而不是干巴巴说“为您推荐这款”。
这里有一个很容易踩的坑：不要直接在系统Prompt里让模型“自由推荐”。大模型没有实时库存和价格数据，它凭空生成的推荐往往是幻觉。必须让模型先调工具，再基于工具返回的真实数据生成推荐话术。我甚至把这条做成了硬约束，在Prompt里明确写了“所有涉及商品价格、库存、优惠的信息必须来自工具返回结果，不得自己编造。”
3.3 订单、售后等强交易动作怎么处理
强交易动作必须走“用户确认+工具执行”的双重保险。比如退款，用户说“我要退款”，智能体绝对不能直接调退款接口。它要做的事情是：
- 校验用户身份、订单归属、退款资格。
- 把退款金额、预计到账时间等信息算清楚。
- 以文本形式向用户确认“是否确认退款XXX元到原支付账户”。
- 用户明确回复确认后，再执行退款调用。
我会在技术上把这类操作标记为“高风险动作”，调用前必须重新提取用户最近一条消息里的确认意图，只有出现“确认”“好的”“可以”“是的”这类词，才放行。否则一律不执行，并提示用户再次确认。
订单查询这类低风险动作则可以自动执行，但输出时要做好数据脱敏，比如收件人手机号只显示后四位、地址只显示到街道。我在初期版本里踩过一个教训，就是把完整地址直接拼进回复文本，后来被安全评审打回来。所以做这类功能的时候，数据展示规则最好在工具层就处理好，不要在生成层再去做截断，那样不可控。
4. 关键实现细节：Prompt设计、工具协议和边界兜底
4.1 一套能同时管住客服和导购角色的Prompt长什么样
Prompt我分成了四层：系统角色层、工具描述层、业务规则层、示例层。每一层解决不同的问题。
系统角色层定义它是什么：“你是电商平台的客服与导购智能体，负责解答用户售前售后问题，并在合适时机推荐相关商品。”注意，这里必须同时写明“你不是万能的，不确定的信息必须查工具”。
工具描述层要写明每个工具的作用、输入参数、输出结构，最好给一个示例JSON。模型看到清晰的工具描述，才能正确填参数。我见过太多的Agent工具调用失败，都是因为工具描述里参数名称不统一，比如一个地方叫product_id，另一个地方叫skuId，模型就懵了。
业务规则层放的是硬性规则，比如“不同时推荐竞品”“用户未询问优惠时，不要主动发送大额优惠券”“已售后完成的订单不能二次退款”。这些规则如果只靠模型自觉，迟早出事故，必须写死并加测试。
示例层放3到5组完整对话，覆盖客服转导购、多轮砍价、售后拒绝等典型场景。示例不需要多，但要覆盖边界情况。示例的作用是给模型一个“照着做”的参照系，比抽象描述准确得多。
4.2 工具调用协议：统一输入输出是稳定性的基石
我刚才提到了统一封装工具，这里详细说一下。智能体涉及的工具五花八门，有查询类的、有写操作类的、有计算类的。如果每个工具的返回格式都不同，模型很容易在生成回复时搞错字段。
我给所有工具定义的统一包装结构是：
{ "code": 0, "data": { }, "message": "ok", "trace_id": "xxxx" }数据库字段统一用下划线命名，比如order_id、sku_id、goods_name、sale_price。嵌套层级不超过两层，避免返回太深的对象让模型“迷路”。而且每个工具返回里必须带上字段的中文说明，比如“sale_price: 商品销售价（元）”，这样模型在生成自然语言时能准确描述。
另外一个小的经验：不要让模型直接拼接SQL或拼接口地址。所有数据库查询都预编译成参数化查询，API地址也从配置文件读取，模型的职责是“填参数”，不是“生成查询语句”，这样能防止注入和乱调用。
4.3 兜底与降级策略：智能体不会的地方必须认怂
没有哪个智能体是万能的，关键是“不会的时候怎么办”。我的兜底策略分三级：
第一级，模型对某一类问题不确定，但知识库里有相似内容，就检索之后告知用户“根据现有资料，可能是这样”，并提示自行核实。
第二级，模型完全不知道，也不涉及交易和推荐，就明确回复“这个问题我暂时无法确认，已为您转接人工客服”，然后触发转人工流程，把会话ID和上下文一起传过去。这比硬编一个答案好得多，用户不会因为一句假话产生售后纠纷。
第三级，涉及退款、改地址、开发票等敏感操作，模型推理置信度不够时，主动选择“只解释流程，不实际执行”。也就是说，它告诉用户“退款的路径如下”，但不会真的去调退款接口，除非用户后续强烈表达执行意愿。
这里要特别强调：在客服+导购智能体里，“主动认怂”不是失败，而是一种成本控制。你用一个幻觉的回答换来的可能是投诉和赔偿，远比转人工的成本高。
5. 评测体系与上线指标：别被“答对率”骗了
5.1 离线评测集的构造思路
我见过很多团队做智能体，评测指标就一个“答对率”，结果模型答得都对，但用户就是不买账。原因很简单，电商对话的“对”是分场景的。客服语境下的“对”是准确、完整；导购语境下的“对”是相关性、购买引导、话术自然。
我搭了一个三元组的离线评测集，每条数据标记为“用户输入、期望动作、期望话术要点”。期望动作包含该调用哪个工具、返回值是什么、有没有高风险操作；期望话术要点包含必须出现的商品信息、推荐理由、语气要求。这样评测的不只是“最终文本像不像标准答案”，而是“工具调用对不对、数据引用准不准、推荐逻辑顺不顺”。
离线评测集至少覆盖这些正负样本边界：用户故意说错商品型号、用户问服务范围内不存在的活动、用户要求推荐明显超出预算层次的商品、用户对话中夹带情绪。这些边界样本往往最能暴露系统短板。
5.2 线上A/B指标怎么取舍
线上看指标，我分为三个层级，从底层到高层排：
第一层是链路健康指标，包括工具调用成功率、接口超时率、转人工率。这些指标任何一个出问题，后面都白搭。尤其是工具调用成功率，智能体不具备某个工具却硬编了一个回复，这在线上就是事故。
第二层是会话体验指标，包括平均回复时长、用户追问率、会话长度、单会话消息轮数。如果平均回复时长超过4秒，用户基本会流失，这种场景下就要考虑模型降级或流式输出优化。
第三层是业务效果指标，包括咨询转购买率、推荐点击率、推荐成交转化率、客单价变化。这一层才是老板最关心的。我做过一轮优化，把“推荐话术里加入限时优惠提示”之后，推荐点击率提升了将近20%，但这里有个前提是优惠信息必须真实可查，不能为了效果乱说。
做个A/B实验的时候，我建议把用户随机分流到两个版本，而不是按时间分片，因为电商的转化受大促、季节、流量来源影响极大，时间分片容易被外部因素干扰，导致误判。
5.3 数据回流与持续优化
智能体跑起来之后，数据回流就是持续迭代的燃料。我每天会做三件事：
第一，把当天答错的用户问题聚类，按语义相似度聚合，看哪些高频问题模型总答不对，优先补知识库和工具。
第二，把用户不满意的会话抽出来做人工标注，标记“模型哪里让人不满意”，是不该推荐时乱推荐、还是推荐理由太生硬、还是语气不自然。这些标注数据攒到一个量级后做微调。
第三，分析转人工会话，看转人工前模型做了什么，是不是某一步把用户惹毛了。有时候用户连续问三次同一个问题，模型还在给不同答案，这就是上下文中断导致的，我会针对这类问题优化记忆刷新逻辑。
有一说一，数据回流是脏活累活，但它的ROI比不停调Prompt高得多。Prompt上限很快就能摸到，继续往上走靠的就是数据。
6. 常见问题与排查经验：实测中遇到的典型坑
6.1 幻觉商品信息与价格飘忽
这是新手智能体最常见的翻车现场：用户问“这个有白色吗”，模型没有调库存工具，直接回到“有的”，实际上白色SKU早就下架了。还有更严重的，用户在砍价场景里问“最低多少钱”，模型为了促成转化直接编了一个低于成本的价格。
排查方法是在日志里把模型生成话术和工具返回数据做比对，凡是出现价格、库存、促销词的位置，必须能在工具返回字段里找到对应值。我在代码里加了一个校验钩子，生成回复的末尾会附带引用source，线上审计的时候跑脚本扫一遍，看每条回复里的关键数据是否都有出处。没有出处的，一律当幻觉处理。
解决的根本办法还是反复强调工具优先原则：所有具体数据必须先调工具再生成，Prompt里写清楚“没有工具返回就承认不知道”。实在不行，可以是做一个受限生成槽位：价格、库存、优惠比例这些槽位值必须在工具返回的数据字典里取，模型不能自由生成。
6.2 多轮对话里的“指代消解”与推荐漂移
用户说“这款红色的呢”“那白色的呢”时，模型如果不知道“这款”指的是什么，推荐就会漂移。我遇到的情况是，上一轮推荐了A品牌手机，用户接着问“那这个牌子的耳机呢”，系统直接去搜“耳机”而没锁定品牌，结果推荐了一堆杂牌。
我的排查思路是给会话状态容器里增加一个“当前候选锚点”字段，每次推荐后把“用户可见的推荐列表”和“每个商品的简要属性”结构化存起来。下一轮里凡是出现“这个”“那款”“你刚说的”，先到候选锚点里找，而不是重新跑搜索。
另外，推荐漂移还容易出现在用户同时问两个品类的场景，比如“跑步鞋和篮球鞋哪个适合我”。这时候如果模型只记住最后一个品类，推荐范围就窄了。我建议在状态容器里支持多个“候选集合”，按用户提及顺序排优先级，而不是每次都只保留一个。
6.3 人工接管时状态怎么传
转人工不是简单把一个按钮给用户，而是要把智能体记录的会话状态完整同步给人工客服工作台。我踩过的坑是，转人工之后，人工客服看不到用户前面问的推荐候选、筛选条件和对话摘要，用户需要从头复述，体验极其糟糕。
后来我做了转人工事件钩子：触发转人工之前，系统自动把“会话摘要、当前用户画像、最后候选推荐集合、用户情绪标签、是否涉及退款”打包成一个结构化卡片，随同会话ID一起推到人工客服队列。客服打开工作台，第一眼就能看到完整背景，不用再从头翻聊天记录。
还有一个细节：转人工前的最后一条智能体回复里，要明确告诉用户“已为您整理好前面的问题”，让用户感觉系统是主动交接，而不是“不会了就把你踢给人工”。
6.4 并发峰值下的链路熔断
电商场景的流量峰谷差异很大，大促期间并发可能是平时的几十倍。如果智能体链路不做限流和降级，大模型推理服务很容易被打挂。
我的做法是给整条链路加了两层保护。第一层是在网关层按用户维度做限流，同一个用户每分钟最多30次请求，超出直接返回兜底话术。第二层是在工具调用层做熔断，如果订单查询接口响应时间超过500毫秒，智能体立即放弃实时调用，改为从缓存读取近似数据，并在回复里注明“数据可能有延迟，请以订单详情页为准”。这种灰度降级保住了服务的可用性，不然大促刚开始，客服系统先崩了，后面全白搭。
6.5 安全与合规审查清单
最后提醒一句，客服+导购智能体涉及的合规话题比一般内容生成多得多。对用户隐私数据（姓名、手机号、地址、订单内容）的输出要脱敏；对涉及营销话术的宣传要不夸大、不虚假；对退款、赔付等承诺性内容不能由模型自由发挥。我在每次发版前都会过一个静态检查清单，重点扫三样：日志里是否打印了完整的手机号和地址、回复文本里是否有绝对化的价格承诺、工具返回里是否有未脱敏的支付信息。这几样只要跑一次，就能避免绝大多数实际风险。
这个项目做下来，我最大的感觉是——客服+导购智能体不是“做一个比机器人更聪明的机器人”，而是把一个电商业务线里已经被拆开很久的“服务”和“销售”重新缝起来，用一套技术方案同时解决确定性问题和非确定性推荐。如果你正在做类似的事，先从最小的垂直场景切入，把工具调用跑稳，把状态管理做好，再谈大模型的花活。这样也许不会一夜爆出惊艳Demo，但至少能稳稳落地，不至于上线当天就被用户投诉淹没。
