电商客服+导购智能体设计：从意图识别到工具调用全解析

晚上十一点半，一个用户在某家电旗舰店停留了二十分钟，连续问了三个问题：“这款冰箱和隔壁那款十字对开的区别在哪”“你们占地小一点的有没有”“如果明天送到能赶上我搬家吗”。传统客服机器人能回答第一个问题，最多再甩一个商品链接，然后眼睁睁看着用户对比完离开。而一个设计得当的电商客服+导购智能体，应该能顺着这三个问题一路往前推：先讲清参数差异，再给出小尺寸替代款，最后联动库存和物流信息给确定性承诺，把一次咨询变成一单成交。

这篇文章就是围绕这类智能体的设计与开发来写的。我要讲的不是学术层面的Agent理论，而是从工程视角拆解一个能真实上线的系统：如何把客服的“答得准”和导购的“卖得动”揉进同一个智能体里，意图识别、知识检索、推荐决策三条链路怎么搭，工具调用和提示词怎么设计才不会翻车，以及上线之后用什么指标和机制让它越跑越好。适合正在做电商AI应用的产品、研发、算法同学参考，也适合想搞清楚智能体到底怎么落地的业务方读一读。

1. 客服和导购为什么必须合并成一个智能体

1.1 拆解一条真实购物路径上的能力需求

用户从进店到下单，中间会经历好几个心理阶段，每个阶段对系统能力的要求完全不同。我把一条典型的购物路径拆开看：

• 售前咨询：用户在商品详情页看了半天，想确认“这个能不能放进我家的餐边柜”“两种颜色哪个耐脏”。这个阶段的核心是货品知识要准，要能基于规格参数做具体判断，而不是复读商品详情页。
• 参数对比：用户同时在两三个SKU之间纠结，需要系统帮他做差异分析。这里要求的是结构化提取和对照表达能力。
• 疑虑消除：“七天无理由退换到底怎么算”“这台机器用久了会不会漏胶”。这需要售后服务条款、真实用户评价等非结构化信息的支撑。
• 需求引导：用户说“我想要个通勤用的双肩包，能装15寸电脑，最好侧面有水杯袋”。这是典型的导购需求，系统要能把他模糊的表达映射成具体的商品筛选条件，再给出推荐。
• 成交与售后：确认库存、运费、发货时间，以及下单后的物流查询、退换指引。

传统方案里，这些环节被拆成客服机器人、推荐系统、搜索、人工客服好几套系统。问题在于：用户不会按系统的分工来提问。他可能上一句还在问参数，下一句就问“那你觉得哪款更适合我”。一旦系统切换，上下文就断了，用户就要重新描述自己的需求——这一步足以劝退一大半人。

客服+导购智能体本质上就是用一个统一的对话大脑，把这些离散的能力串成一条完整的服务链路。这也是标题里“智能体”这三个字的分量所在：不再是“问答机器人”，而是一个能感知状态、调用工具、做出决策、完成任务的体。

1.2 一个智能体 vs 两个智能体的取舍

我见过不少团队一开始坚持做拆分：一个售后客服机器人，一个导购推荐机器人。理由也合理——售后的知识库和推荐的话术库完全是两套东西，拆开各管一摊，界限清晰。但在实际业务里，这个界限几乎撑不过一个月的线上考验。

先说技术上的理由。用户进入会话后，智能体要持续维护一份上下文记忆，里面包含他当前看的商品、问过的需求、被拒过的推荐理由。如果客服和导购是两个系统，这份记忆就得在系统间同步，同步就意味着延迟、丢失和权限问题。而同一个智能体天然共享对话上下文，用户从“这里能便宜点吗”切换到“那把赠品一起算上呢”，系统不需要任何额外机制就能自然衔接。

第二个原因是知识资产的复用。售后知识库里的退换货政策、保修细则，导购推荐时同样要用——用户在犹豫时问一句“如果买回来不合适能退吗”，这往往是临门一脚的决策因素。两个系统各维护一份同样的知识，迟早会出现政策更新不同步的问题。合并成一个智能体后，知识库只有一份，谁来调用都从中读，维护成本直接减半。

当然，合并也有代价。最明显的是权限边界：同一个模型既要能调商品推荐接口，也要能操作售后工单，任何一个环节的权限校验没做好，都可能出安全事故。这个问题我的处理方式是在工具层做强校验，而不是在模型层做区分——模型只负责决定“我要查售后政策”，至于它有没有权限查，在工具调用时统一拦截。后面第3章会细讲。

2. 整体架构：意图识别、知识检索、推荐决策三条链路

2.1 意图识别：从“用户问什么”到“系统该做什么”

一个电商智能体的第一道关卡是理解用户到底想干什么。这里我强烈建议采用三级意图架构，不要指望一个大模型Prompt就把所有判断做对。

第一级是类目意图，解决“这句话属于售前、售后、闲聊、多轮决策中的哪一类”。这个层级决定后续整个处理流程——售后类问题要走工单系统，多轮决策类问题要进入导购链路。第二级是对话意图，细化到具体动作，比如比价、参数咨询、催发货、申请退款、表达不满。第三级是槽位提取，把对话里的关键实体结构化抽出来，比如商品类目、预算范围、使用场景、偏好参数。

我实际项目里的意图分类表长这样：

这里有个工程经验：类目意图这种粗粒度分类，用一个小模型甚至规则就能做得很好，成本低、延迟小，没必要让大模型做。真正需要大模型发挥的是对话意图和槽位提取这类细粒度、语义复杂的任务。另外一定要给“闲聊”留一个类别，用户进来说句“你好呀”不能直接触发导购链路，那是很糟糕的体验。

2.2 知识检索：不是所有知识都该塞进向量库

很多团队做智能体第一个动作就是“把所有文档丢进向量库”。做过RAG的人都知道，这个做法在电商场景基本行不通。电商知识有个显著特点：大量关键信息是强结构化的，而且实时变化。商品库存从昨天到今天是两个数字，促销政策在活动开始后分秒不同，这些数据丢进向量库，召回的时候全凭语义相似度，根本没法保证准确。

我采用的方式是把知识分成三类来处理：

• 结构化业务数据：商品SKU、规格参数、实时库存、价格、运费模板。这类数据以订单式和API方式管理，智能体通过工具调用去查，绝不进向量库。
• 稳定政策文档：退换货规则、保修政策、客服话术规范。这类数据相对稳定，适合切分后做语义召回，也就是常说的RAG链路。
• 用户生成内容：真实评价、买家秀里的口碑信息、常见问题FAQ。这类数据文本形态自由、数量巨大，适合向量化召回，但必须做时效和情感过滤。

三类知识在检索链路里并行跑，最后合流：结构化查询结果、文档片段召回结果、评价口碑召回结果共同进一个rerank模块，由模型综合排序后组织回答。这个设计保证了回答的事实基础来自结构化数据，而文档和口碑数据用来补充细节和说服力。

我踩过最狠的一个坑是：初期把商品规格参数也塞进了向量库，结果线上出现“用户问颜色，模型从文档里翻出容量参数来回答”的尴尬场面。后来把所有结构化数据全部切走，只留给API查询，准确率上了不止一个台阶。

2.3 导购推荐：Rule+LLM+个性化三层结构

导购推荐链路是整个智能体里最容易“看着智能、实则失控”的部分。如果让大模型从零自由生成推荐，它可能会自信满满地推荐一个当前无货、用户根本买不到的SKU。所以我把推荐链路设计成三层结构。

最底层是规则层：负向清单强制过滤掉差评率过高的商品、无货商品、超预算商品，这部分是硬约束，一票否决。中间层是LLM分析层：理解用户对话中表达的真实需求，转成结构化的筛选条件。最上层是个性化层：结合用户历史订单、浏览记录、画像标签进行候选排序。

候选池有三条来源：当前会话涉及的商品类目下的热销款、用户历史浏览和加购过的相似款、客服侧主推的活动款。三条来源并集之后，先过规则层过滤，再进个性化层排序，最后交回LLM组织推荐话术。

一个推荐输出会同时包含：推荐商品的名称、推荐理由、与用户需求条件的匹配点、实时的价格和库存状态。这样设计的原因很简单——导购的本质是给用户一个“现在就买”的理由，而这个理由必须建立在真实、准确、可验证的事实之上。

3. 开发落地：从选模型到调工具单的实操细节

3.1 模型选型和工具调用的边界设计

模型选型这件事，我的判断标准很简单：优先选支持函数调用（Function Calling）且函数调用稳定性好的模型，性能分数是其次，因为电商场景里可控性永远比聪明重要。一个模型即使聊天能力再强，如果该触发查库存工具的时候说嗨了没触发，那就是灾难。

工具单的设计要围绕电商业务最小闭环来，不需要多，但要精准。我在第一个版本里只设计了五个工具：

工具调用在工程上比想象中复杂的地方在于：返回结果往往不会干净地匹配模型需要。比如查库存接口返回的字段里既有可售库存，也有“锁定库存”和“虚拟库存”，它们混在一个JSON里，模型直接读很可能会误解。我的做法是在工具函数内部做一层结果清洗和整形，只把最终面向用户的结论性字段暴露给模型，少给它自由发挥的空间。

3.2 提示词工程：客服智能体和通用Agent写法完全不同

很多人把通用Agent的提示词直接拿到电商场景用，这是个大坑。通用Agent强调“自由探索、拆解任务”，而客服+导购智能体必须强调约束和边界。电商智能体的提示词要明确告诉模型四件事：角色和职责边界、工作流程的固定顺序、硬性禁区、以及少样本示例。

我实际使用的提示词框架大概长这样：

code复制你是某电商平台的客服与导购智能体。你的职责是解答用户关于商品、订单、售后的问题，
并在用户有购买意向时主动推荐合适的商品。

工作流程：
1. 判断用户的类目意图（售前/售后/多轮决策/闲聊）。
2. 涉及价格、库存、优惠的信息，必须调用工具查询，禁止凭记忆回答。
3. 推荐商品时必须说明推荐理由与用户需求条件的对应关系。
4. 用户情绪激动或表达投诉时，先共情安抚，再处理问题，必要时转人工。

硬性禁区：
- 禁止编造任何价格、库存、发货时间、促销政策信息。
- 禁止替用户做最终购买决定，比如"这款最适合你，直接下单吧"。
- 禁止评价平台内外其他商家的商品。
- 禁止输出与电商服务无关的任何内容。

少样本示例：
用户：这个手机拍照怎么样？
助手：[调用查询商品详情工具，提取相机参数后回答]

这里有三个容易被忽略的细节。第一个是**“禁止替用户做最终购买决定”，客服智能体可以给建议、给对比、给理由，但决定权必须留在用户手里，这个边界没守住会引发客诉。第二个是少样本示例一定要给完整的工具调用链条**，让模型看到“用户的提问 → 触发了哪个工具 → 拿到结果后才回答”这个完整过程，而不只是给问答对。第三个是转人工的条件要前置且明确，不要指望模型自己判断“这个情况该不该转人工”，要在提示词里把条件写死。

3.3 知识库建设：清洗、切分、向量化的实践经验

说回知识库。虽然结构化数据已经让API管了，但政策文档和FAQ这批数据依然是智能体回答质量的关键。这里我积累了几条实战经验。

第一，清洗比向量化更重要。电商文档里充满了营销话术和限时活动信息，比如“限时抢购，低至五折”这种句子。如果原样切进知识库，活动结束三个月后模型还会煞有介事地告诉用户有五折优惠。清洗时要把时效性表述单独剥离，用元数据标注有效期，过期后直接不参与召回。

第二，切分按语义块而不是固定窗口长度。一条FAQ就是一个完整的咨询对，把它切成三块是灾难。我采用的方法是先按自然段落分块，再按语义相关性合并短块，保证每个切面都能完整表达一个意思。对于客服话术模板，我会在切分前先把变量位置替换成占位符，避免向量化被具体变量干扰。

第三，知识条目要带商品ID关联。电商知识库里很多内容本质上是“某商品的补充信息”，比如“这款咖啡机的萃取头可以拆卸清洗”。这类知识如果只按文本存，召回时很难定位到具体商品。我的做法是为每条知识维护一个关联主键，字段可能是SKU、类目ID或政策编号。检索时先用商品走结构化查询，再用查询结果限制知识库检索范围，缩小召回空间后准确率提升明显。

4. 灰度、评估、数据回流：上线之后才是真正的开始

4.1 先建立评测集再谈上线

智能体这种系统有个特点：开发时觉得哪里都对，一上线就原形毕露。所以我在项目启动的第一周就干了一件事——从历史客服会话里抽了500条真实对话，人工标注成评测集。这里面包含300条售前咨询、100条售后问题、50条投诉场景、50条闲聊和非业务问题。

评测指标分三层来看：

评测方法上，我建议人工标注和LLM as Judge双跑，两个结论交叉验证。LLM as Judge跑批量回归很快，但它对事实性错误的敏感度不够。比如模型一本正经地把“次日达”说成“当日达”，LLM评判员因为不知道真实Details，往往觉得回答得很流畅就给过了，人工一看就发现毛利很高。所以事实性相关的硬指标每周至少做一次人工抽检，不能偷懒。

4.2 实际运营中容易翻车的地方

上线三个月，我遇到的高频故障集中在三个场景，每一个都值得展开讲。

第一个是价格幻觉。电商的价格体系远比想象中复杂：基础价、促销价、会员价、优惠券叠加、地区差异价。最初版本里模型偶尔会在回答里自己推算出价格，“这个应该大概是在3000左右”——这种话一出来就是客诉。我的教训是：提示词里强调一百遍“别编价格”，不如在工具调用链路里做一个硬校验——所有涉及价格的话术必须由价格工具输出的事实数据拼接生成，模型不允许自己造句描述价格。

第二个是活动商品下架但推荐没跟上。智能体推荐了一款主推商品，但用户点进去发现已售罄，体验极其糟糕。排查下来发现是推荐候选池构建时读的是离线缓存的商品列表，实时上下架状态没有同步进候选池。后来我加了同步校验：候选池里的每个商品在进入推荐排序前必须做一次实时状态检查，下架的直接从池子里剔除。

第三个是知识冲突的优先级没界定清楚。促销文档里写了“全场满300减50”，但用户问的具体商品恰好不参与满减。模型从文档里召回的是全场规则，就给了错误回答。这个问题本质上是检索召回和事实校验的冲突。我后来加了知识优先级规则：具体商品、具体品类的业务数据 > 平台级通用政策 > 第三方内容。一旦来源之间出现矛盾，按优先级取高者，同时模型要能识别出“这条政策可能不适用于该商品”，主动触发复核工具而不是硬答。

4.3 数据回流：让每一次对话变成下一次更好的知识

智能体和传统客服系统的另一个根本区别在于，它有持续进化的能力。我把数据回流设计成一个闭环：对话日志、工具调用结果、用户反馈和转人工记录全量进数据管线，每周做一次数据复盘，生成新的知识条目和优化清单。

具体做法是：第一步，从转人工会话里提炼高频问题——如果某类问题反复出现且原智能体没答好，说明知识库有缺口，人工客服的回复片段就是现成的知识种子。第二步，对用户负反馈做归因，比如用户点过回答里的“没帮助”，或者对推荐商品点击停留时间极短，这些信号会回流到检索重排模块，降低类似内容的权重。第三步，每周用新数据扩充评测集，把本周出现的新问题追加进去，再跑全量回归。

这个回路跑起来之后，智能体不是交付即终点，而是一个每两周可见明显进步的系统。

我在这一段结尾想多说一句个人体会：做客服+导购智能体最容易踩的坑不是技术选型不对，而是团队对“智能”的期待值错了位。用户对它的期待是“解决问题”，不是“秀操作”。所有设计的落点都应该回到那个深夜买冰箱的用户身上——他需要的是一个真正帮他降低决策门槛、加速购买决策的助手，而不是一个会聊天但什么都承诺不了的机器。把真实性、可控性和业务转化放在一切指标之前的系统，才配叫一个能扛住真实流量的电商智能体。