电商客服+导购智能体：从多智能体架构到工程落地实践

1. 先聊聊这个项目到底要解决什么问题

1.1 从客服的痛点说起

做电商的朋友应该都深有体会，客服这块的活儿看着简单，实际特别吃人力。一个成熟的店铺，尤其是SKU数量几百上千的那种，客服每天要处理的重复咨询量非常大：尺码怎么选、发什么快递、能不能开发票、订单什么时候发货、退款多久到账，再加上售后的催单、物流查询、退换货流程，这些问题翻来覆去就是那么几十个模板答案，但你不配够人，高峰期真的回复不过来。

更麻烦的是，客服和导购在传统模式里是割裂的。用户问“这件T恤有蓝色的吗”的时候，如果客服只回答“有”或者“没有”，这个销售机会就浪费了。好的导购应该知道关联推荐：如果没蓝色了，要不要看看灰色的？这单是大码用户，是不是顺便看看配套的裤装？这种“服务+销售”一体的能力，普通培训出来的客服很难完全兼顾，何况是人力成本越来越高的今天。

所以当时我们团队立项做这个“电商客服+导购智能体”，核心目标就两条：第一，把重复性咨询自动化，至少消化掉70%以上的常见问题；第二，在对话里植入导购能力，让智能体不只是被动回答问题，而是在合适的时机主动做推荐，把客单价拉上去。这个项目上线之后，我们实际测下来的数据我后面会详细说，整体效果是超出预期的。

1.2 为什么是“客服+导购”而不是单纯客服

立项的时候，其实有一波争论。一部分同事觉得，先把手头客服机器人做好就行，导购这种偏营销的功能容易翻车，万一推荐得不对，客户体验反而下降。但这个观点我不同意。原因很简单：电商场景里，用户来咨询本身就带着购买意图，这时候是转化率最高、最自然的销售窗口。

就拿一个真人场景举例。用户问“这条裙子是均码吗？我155穿会不会太长”，如果你是纯客服，回复“均码，裙长85cm”就算结束了。但一个导购型客服会接着问“亲亲，这款还有同系列的短款，裙长72cm，小个子穿更利落，需要帮您看看吗”。前者和后者产生的GMV差距，做过电商的都懂。

所以“客服+导购”不是两个功能的简单叠加，而是把服务台变成了销售前线。这也就决定了我们的智能体不能只做一个FAQ问答机器人，它必须有能力理解用户需求、判断推荐时机、选择合适的商品进行推荐，并且推荐完还要能无缝接住用户的进一步询问。这几点放在一起，就是我们做这个项目的核心边界。

1.3 整体架构与方案选型

明确了目标之后，接下来的问题就是用什么方案搭。我们当时在几个主流的智能体平台和自研路线之间做了对比。市面上的dify、coze这类平台，优势是上手快，工作流可视化，适合快速验证想法；劣势是深度定制空间有限，尤其是涉及到和ERP/OMS深度对接、复杂的库存判断、多渠道数据同步的时候，平台自带的能力往往不够。

我们最终的选择是：核心对话与工作流用开源的智能体框架自建，同时参考dify的工作流设计思路来组织节点，而不是直接套用平台。原因很实在，我们的业务有一些特殊逻辑，比如不同店铺分组要接不同的知识库、不同会员等级要展示不同的优惠策略，这些在通用平台上做起来非常别扭。

技术栈方面，对话引擎用的是主流的大模型API，配合自建的向量知识库做RAG检索；工作流编排用的是一个支持多智能体协作的框架，后端服务用Python写，主要解决工具调用和状态管理；前端后台管理界面用了React，方便运营配置知识库和推荐策略。这块我们后面会逐步拆开讲。

2. 整体设计思路拆解：从对话流程到多智能体协作

2.1 对话主流程设计

智能体的对话流程，说复杂也复杂，说简单也简单。抽象到底就是三个环节：听懂用户在说什么，决定接下来应该做什么，把做出来的结果组织成人话回复给用户。具体到这个项目里，我们把它拆成了五个节点。

第一个节点是入口分流。用户发来消息后，先做一次快速的意图预判，判断是闲聊、售前咨询、售后问题还是中差评投诉，把高危对话优先路由给人工客服。第二个节点是信息抽取，把订单号、商品名、尺码、颜色这类实体捞出来。第三个节点是任务分发，根据意图把请求交给对应的子智能体，比如导购智能体、订单查询智能体、售后处理智能体。第四个节点是结果组装，把子智能体返回的数据和话术模板拼装成完整回复。第五个节点是兜底判断，如果智能体连续两次无法解决用户问题，自动触发人工转接。

这套流程的起点是“意图识别”的准确率。我们一开始图省事，直接用大模型提示词让模型判断意图，结果在真实对话里经常翻车。后来改成“分类模型预筛+大模型精判”的两级方案，先用轻量模型把明显的问题快速分好类，拿不准的再交给大模型做深度判断。准确率和响应速度都提上来了，这块细节我会在开发实录里细说。

2.2 多智能体的主从模式：subagent就是“另类的tool”

这个项目开发过程中，我对多智能体架构最深的体会是：没必要追求花里胡哨的对等协商模式，现实中跑得好、可控性强的还是主从模式。所谓主从模式，就是有一个主智能体负责理解全局、分配任务、汇总结果，下面的子智能体各自负责一个独立能力域，做完了把结果交回给主智能体。

这里有个非常关键的设计心法：把subagent看作一种“另类的tool”去调用。什么意思呢？传统工具调用是“模型决定调用哪个函数，函数返回结构化数据”；子智能体调用则是“模型决定把任务交给哪个子智能体，子智能体返回一段处理结果”。两者在调用逻辑上是同构的，区别只是子智能体能处理更模糊、更复杂的任务。

实际落地的时候，我们就是把每个子智能体封装成了带有描述信息的工具接口，主智能体看到描述后决定调不调用。比如“查询订单信息”这个子智能体，它的工具描述是“当用户询问订单状态、物流进度、发货时间时使用”，主智能体在对话中一旦识别到这类需求，就自动发起调用。这种做法最大的好处是扩展性好，新增一个能力域只需要新增一个子智能体，并在描述里写清楚触发条件，主智能体不用改逻辑。

2.3 工作流搭建与状态管理

多智能体协作的项目里，状态管理是最容易被低估的坑。用户和智能体对话不是一问一答就结束的，经常是连续好几轮都在讲同一件事。比如“我昨天买的那个蓝色卫衣发货了吗”这句话，如果用户没有提供订单号，智能体必须记得“这个用户可能有一个昨天购买的蓝色卫衣订单”这个上下文，才能去对应的订单列表里找，而不是直接回复“请提供订单号”把用户晾在那。

我们参考了dify这类平台工作流的设计思路，把每个对话会话的状态分成三个层次：第一层是会话级状态，记录用户ID、会话ID、当前所在节点，这些是全局都要用的；第二层是业务级状态，记录订单信息、商品信息、查询结果，这些是用户在本轮对话里临时产生的业务数据；第三层是临时变量，比如一次工具调用的中间返回结果。

状态存储上我们最开始用内存缓存，后来流量上来之后换成了Redis，key用会话ID做前缀，设置了三十分钟的过期时间，超时未活跃的会话自动清理。这里有一个很实用的经验：每次大模型返回结果之后，一定要做一次状态同步，把模型抽取出的实体更新到业务级状态里，而不是等到下一次用户发消息才去更新，否则很容易出现上下文错位。

3. 核心模块开发实录

3.1 提示词设计：让模型“说人话”也“办人事”

智能体项目里提示词设计占了开发量的很大比例，这个项目让我彻底理解了为什么业内会说“提示词就是新型代码”。我们所有的主智能体和子智能体提示词加起来，前前后后改了二十多版，才达到比较满意的效果。

先聊一下主智能体系统提示词的设计思路。我把它分成四个区块：角色定义、能力边界、工作流说明、输出规范。角色定义不是简单说“你是电商客服”，而是把店铺定位、目标用户群体、说话风格都说清楚，比如“你是某潮牌旗舰店的客服，用户主要是18-28岁的年轻人，说话可以活泼一点但不要轻浮”。能力边界这一块特别重要，要明确告诉模型哪些事能做、哪些事不能做，比如不能承诺赔付、不能编造库存信息。工作流说明则要告诉模型在什么情况下调用哪个子智能体。输出规范是约束回复格式的，比如需要包含商品链接时用规定的markdown格式。

子智能体的提示词和主智能体是配合用的。我们给每个子智能体都写了详细的工具描述，这部分不是给人看的，是给模型看的。工具描述写得好不好，直接决定模型能不能在正确的时候触发正确的调用。我们第一版写得特别简略，比如“查询订单”，后来模型老是乱触发，用户在问退换货政策的时候也去查订单。后来我们把描述改成“当用户询问具体订单的状态、物流轨迹、预计送达时间时使用，必须包含订单号或能唯一锁定订单的信息”，准确率马上就上来了。

3.2 知识库与商品数据对接

客服智能体的另一半核心是知识库。常见问题、退换货政策、尺码对照、快递说明这些内容都必须放到知识库里。我们用的是RAG方案，先把文档切分成段落，做向量化之后存到向量数据库里，用户提问时先做语义检索，把最相关的几条上下文拼到提示词里喂给模型。

这里有几个细节值得说说。第一个是文档切分的策略，我们一开始用固定长度切分，比如512个字符一刀切，结果经常把半句话切断，导致检索到的是残缺的上下文。后来改成按段落切分，段落太长的再按句子边界二次切分，检索质量明显提升。第二个是知识库的更新机制，店铺的促销活动、运费政策经常变，不可能每次变动都重新跑全量向量化，我们做了一个定时增量更新的任务，每天凌晨跑一次，只处理有变更的文档。

第三个是商品数据的对接。这一块比较麻烦，因为商品信息是结构化数据，SKU、库存、价格、图片、详情页链接都是字段化存储的，不能直接塞进向量库。我们的做法是给商品数据单独开一个检索接口，模型的工具调用可以直接走这个接口查询商品信息，不走RAG。如果涉及商品的语义匹配，比如“有没有显瘦的牛仔裤”，这个才走向量检索，匹配到对应的商品标签之后再把商品详情调出来。

3.3 订单/物流/售后工具链开发

客服场景里大量咨询跟订单有关，所以订单和物流的查询能力必须做成稳定可靠的工具。这块技术上不复杂，核心就是对接内部订单系统和第三方物流接口。我们封装了三个核心工具：订单查询、物流追踪、售后进度查询。

订单查询的入参是订单号或者用户ID加商品信息。这里有一个并发问题必须考虑，同一个用户可能会在很短的时间内反复查询同一个订单，如果每次都直接打到订单系统上，高峰期会给核心系统造成压力。我们的方案是加了一层缓存，同一用户的同一个订单号在五分钟内的查询直接走缓存，超过五分钟或者订单状态有变更才重新拉取。

物流追踪相对复杂一点，因为不同快递公司接口格式不一致，有的是XML，有的是JSON，有的回调还有延迟。我们做了统一的物流信息抽象层，把所有快递公司的返回格式都转成统一的结构体，包含物流状态、物流轨迹列表、预计送达时间。这样下游无论是智能体生成话术还是后台页面展示，都不用关心具体是哪个快递公司。

售后的进度查询比较敏感，因为涉及退款金额、售后状态这类信息。我们的处理原则是：能查到的信息如实回答，但涉及“建议”“多久到账”这类预测性内容，必须走预设话术模板，不允许模型自由发挥。比如“退款什么时候到账”这个问题，模型只能回复“一般1-3个工作日原路退回”，不能自己编一个“大概两小时”。

3.4 导购推荐逻辑：从“答非所问”到“精准推荐”

导购是这个小项目的重头戏，也是我们花时间最多的地方。一开始我们天真地认为，只要在系统提示词里写一句“在合适的时机向用户推荐商品”，模型就会自动推荐。结果实测下来，要么推荐得很生硬，用户问了一个问题它就开始硬推；要么推荐的时机不对，用户在问售后问题它也去推新品，体验非常差。

后来我们总结了导购推荐的三个触发时机：第一，用户明确表达对某类商品的兴趣，比如“有没有适合夏天穿的T恤”；第二，用户对某个商品表现出犹豫，比如“这个颜色会不会太暗了”，这时候适合推荐同款的其他颜色或者相近款；第三，用户在完成购买决策后、确认下单前，适合做关联推荐，比如买了连衣裙推荐腰带或者配套的饰品。

推荐话术的生成也做了严格的约束。我们给导购子智能体定了几个硬性规则：每次推荐的商品数量不超过三款，必须说明推荐理由，“这款短裤和您刚看的卫衣是同一系列，面料是一样的”；不允许使用“我推荐”“我觉得”这类主观表达，要用“这款商品/很多用户反馈”来弱化推荐感。实测下来，用户对后者的接受度要高不少。

还有一个比较细节的实践是建立用户画像标签，把用户历史对话中提到的偏好记录下来，比如“喜欢宽松版型”“关注纯棉材质”“偏向深色系”，在后续推荐时优先匹配这些标签。这些标签我们只是存在会话级状态里做一些短期画像，不做跨会话的长期追踪，避免涉及用户隐私的合规风险。

4. 工程化落地中的关键细节与避坑

4.1 API幂等性设计：防止一条订单被查三次

做智能体开发，很多人把精力都放在模型和提示词上，工程层面的问题容易被忽略。但真实线上跑起来之后，工程设计和模型能力同等重要。我们在第一期就吃过亏：有一次订单系统的数据没有同步过来，用户在客户端看到“您的订单已发货”的状态一直不对，于是反复询问，智能体每次收到询问都去订单系统拉一次数据，结果把一个本来压力就不小的接口打崩了。

这个案例暴露出来的核心问题就是幂等性。我们做工具调用必须保证：同样的请求，重复执行多少次，结果都是一致的，并且不能对下游系统造成额外负担。对订单查询来说，方案就是在工具调用层加请求指纹，用用户ID、订单号、查询类型三个字段生成一个哈希值，五分钟内相同的哈希值直接返回缓存结果，不再真正发起调用。

幂等性还体现在更危险的地方：涉及状态变更的操作。比如售后申请、优惠券发放，如果因为网络超时导致同一个请求被发送了两次，就可能给用户发两张优惠券、提交两条售后工单。我们的做法是给这类写操作生成全局唯一的请求ID，服务端记录已经处理过的请求ID，重复的请求直接拒绝。

4.2 多轮对话的上下文管理与记忆清理

大模型的上下文窗口是有限的，就算现在的模型支持长上下文，塞太多历史消息进去既浪费token也会让模型注意力分散。我们在实际运行中发现，多轮对话超过一定轮数之后，模型的回复质量会明显下降，尤其是它会把早期的不相关内容“记错”到当前问题上。

我们的上下文管理策略是分层处理：最近五轮的对话完整保留，更早的对话做摘要压缩。具体做法是每一轮回复结束后，都会触发一个轻量的摘要任务，把已经过去的对话内容提炼成一句话摘要存起来。下一次请求时，系统提示词里放压缩摘要，会话变量里放最近五轮的完整消息，这样既保证了上下文连贯性，又不会让提示词长度爆炸。

上下文清理还有一层是隐私和合规。用户对话里经常会出现姓名、电话、地址等敏感信息，这些信息不应该被长期保留。我们的策略是会话结束之后立即清理临时状态，所有包含敏感信息的消息只保留在日志系统里并且做脱敏处理，业务状态里只保留必要的脱敏后的信息。这块虽然不起眼，但真要出问题就是大问题，建议做类似项目的朋友不要省。

4.3 性能优化与成本控制

智能体项目跑起来之后，最大的成本项就是大模型的API调用。一个用户问一个简单问题，背后可能触发三次以上的模型调用：意图识别一次、主智能体生成回复一次、说不定导购子智能体还要再调一次。如果每次都调最大最快的模型，成本会非常吓人。

我们的成本控制策略是模型分级。简单意图识别和实体抽取这类结构化任务，用便宜的小模型就够了，响应速度快还省钱；主智能体的对话生成用能力强的模型，这是核心质量保障；导购推荐这种需要一定创造力的任务，也用主模型。另外，凡是可以模板化的话术，就不要让模型生成，比如“亲，您的订单已经发货，物流单号为XXX”，这种直接用模板拼接，不经过大模型。

性能优化方面，主要瓶颈在检索和生成两个环节。检索环节我们做了向量数据库索引优化，把几个高频查询的集合结果做了缓存，命中率大约有40%左右。生成环节因为模型调用是同步的，用户体验直接受影响，我们用了流式输出，让用户先看到第一个token出现，而不是干等两三秒，用户体感上快了很多。

4.4 灰度与人工兜底

智能体上线这种事，最怕的不是bug，而是模型在真实场景里说出让人无法预料的话。所以我们在上线策略上非常保守，走了一套灰度+兜底的双保险机制。

灰度分三层：第一层是渠道灰度，先放开一个流量较小的店铺渠道试运行；第二层是会话灰度，在同一个渠道里只放部分比例的用户流量给智能体，其余仍由人工客服服务；第三层是意图灰度，只放开安全级别高的意图类型给智能体处理，比如查快递、查尺码，涉及售后的退款操作必须转人工。

兜底方案有两个：一是服务降级，如果检测到大模型API的响应超时或者质量异常，智能体会自动切换为预置的FAQ问答模式，只回复知识库里能直接查到的内容，不再进行复杂的推理；二是人工接管，当智能体连续两次回复不确定或者用户明确表达不满情绪时，自动把会话转接给人工客服，并且把智能体已经掌握的信息整理成接管摘要给人工客服参考，避免用户重复描述问题。

5. 常见问题排查与调优实录

5.1 高频问题速查表

这个项目从开发到上线，我们踩过不少坑，整理了一个高频问题速查表，分享出来给做类似项目的朋友参考：

这个表里的每一条，背后都对应一次线上事故或者一次用户投诉。建议大家遇到问题不要只盯着模型输出本身，先排查工程链路，往往问题出在数据没传对、上下文没传递好，而不是模型本身不够聪明。

5.2 排查方法与日志设计

智能体项目的排查难度比传统后端高很多，因为同一个问题可能是模型抽风、提示词词不达意、检索结果不准确、工具返回异常等多层原因叠加导致的。我们最大的教训是：日志设计一定要在项目初期就做好，不然后期排查起来是灾难。

我们的日志体系分了三层。第一层是请求链路日志，记录用户每一条消息在智能体内部完整的处理链路：意图识别结果、命中了哪个子智能体、调用了哪个工具、工具返回了什么、最终生成的回复是什么。第二层是质量监控日志，定期抽取一部分会话做人工标注，看回复是否准确、是否符合预期。第三层是业务效果日志，记录每个会话是否产生了订单、是否点击了推荐商品、是否有转人工的情况。

排查问题的键思路是“逐层拆解”。比如用户反馈智能体推荐了错误的商品，先看链路日志里用户到底说了什么、意图识别输出是什么、商品检索返回了什么、模型生成了什么，通常问题就出在中间某个环节。我们把每个环节的输入输出都记录下来，定位问题的时间比以前快了好几倍。

5.3 效果评估与迭代

项目上线不是终点，持续迭代才是常态。我们对这个智能体的效果评估主要看四个维度的指标。

第一个是解决问题的成功率，我们定义为一个会话里用户的问题被解决且没有转人工，这个指标从第一版的52%慢慢调到了现在的78%左右。第二个是人工转接率，也就是智能体搞不定转给人工客服的比例，最开始高达30%，现在稳定在15%以内。第三个是导购转化率，也就是用户在和智能体对话过程中产生点击商品链接或者下单的比例，这个做到大概8%，比纯人工客服基线的5%要高。第四个是用户满意度，主要通过会话结束后的评价来统计，目前是4.6分左右。

迭代的方向主要来自三个地方：一是人工客服的接管日志，每次转人工都是一次提升智能体的机会，我们会去分析为什么没接住，是没理解意图还是知识库没覆盖；二是用户侧的真实吐槽，比如“你回的根本不是我问的”，这类反馈是最直接的；三是业务指标的变化，如果导购转化率下降，就要去看是不是推荐策略过于激进。

这里分享一个挺实用的迭代技巧：把热门问题的对话样本固化成测试集，每改一版提示词或者知识库，都先跑一遍测试集看有没有回归。这个测试集不用很大，一百到两百条有代表性的对话就够，但能有效防止“改好了这个问题却把那个问题改坏了”的情况。

写在最后：几个让我印象深刻的体会

这个项目做完，我最大的感触是：智能体开发本质上是“转译问题”的艺术，好的智能体不是靠一个聪明的模型就能跑通的，而是靠对业务的深刻理解、对提示词的精细打磨、对工程细节的严苛把控，三者缺一不可。

第二点体会是，不要迷信“全自动”。我们最开始试图做一个几乎不需要人工干预的智能体，但实际跑下来发现，它在复杂场景里注定会翻车。后来我们调整思路，把目标改成“智能体搞定80%的常规问题，让人类客服把精力集中在20%的高价值和高难度对话上”，这才是最健康的人机协作模式。人工兜底和转接机制不是智能体的“遮羞布”，而是整个系统安全感和体验感的重要来源。

最后给准备做类似项目的朋友一个建议：第一期上线的时候，千万不要追求功能大而全，先围绕最高频的几类咨询场景做到极致，跑通之后再慢慢加导购推荐、售后处理这些高阶能力。我们第一版就做了售前咨询、订单查询、物流查询、导购推荐四个能力，上线效果其实不错，后面迭代再加售后和退换货处理，每一步都走得很稳，也避免了“什么都想做，什么都做得一般”的陷阱。