瑶瑶宝1. 先聊聊这个项目到底要解决什么问题
1.1 从客服的痛点说起
做电商的朋友应该都深有体会，客服这块的活儿看着简单，实际特别吃人力。一个成熟的店铺，尤其是SKU数量几百上千的那种，客服每天要处理的重复咨询量非常大：尺码怎么选、发什么快递、能不能开发票、订单什么时候发货、退款多久到账，再加上售后的催单、物流查询、退换货流程，这些问题翻来覆去就是那么几十个模板答案，但你不配够人，高峰期真的回复不过来。
更麻烦的是，客服和导购在传统模式里是割裂的。用户问“这件T恤有蓝色的吗”的时候，如果客服只回答“有”或者“没有”，这个销售机会就浪费了。好的导购应该知道关联推荐：如果没蓝色了，要不要看看灰色的？这单是大码用户，是不是顺便看看配套的裤装？这种“服务+销售”一体的能力，普通培训出来的客服很难完全兼顾，何况是人力成本越来越高的今天。
所以当时我们团队立项做这个“电商客服+导购智能体”，核心目标就两条：第一，把重复性咨询自动化，至少消化掉70%以上的常见问题；第二，在对话里植入导购能力，让智能体不只是被动回答问题，而是在合适的时机主动做推荐，把客单价拉上去。这个项目上线之后，我们实际测下来的数据我后面会详细说，整体效果是超出预期的。
1.2 为什么是“客服+导购”而不是单纯客服
立项的时候，其实有一波争论。一部分同事觉得，先把手头客服机器人做好就行，导购这种偏营销的功能容易翻车，万一推荐得不对，客户体验反而下降。但这个观点我不同意。原因很简单：电商场景里，用户来咨询本身就带着购买意图，这时候是转化率最高、最自然的销售窗口。
就拿一个真人场景举例。用户问“这条裙子是均码吗？我155穿会不会太长”，如果你是纯客服，回复“均码，裙长85cm”就算结束了。但一个导购型客服会接着问“亲亲，这款还有同系列的短款，裙长72cm，小个子穿更利落，需要帮您看看吗”。前者和后者产生的GMV差距，做过电商的都懂。
所以“客服+导购”不是两个功能的简单叠加，而是把服务台变成了销售前线。这也就决定了我们的智能体不能只做一个FAQ问答机器人，它必须有能力理解用户需求、判断推荐时机、选择合适的商品进行推荐，并且推荐完还要能无缝接住用户的进一步询问。这几点放在一起，就是我们做这个项目的核心边界。
1.3 整体架构与方案选型
明确了目标之后，接下来的问题就是用什么方案搭。我们当时在几个主流的智能体平台和自研路线之间做了对比。市面上的dify、coze这类平台，优势是上手快，工作流可视化，适合快速验证想法；劣势是深度定制空间有限，尤其是涉及到和ERP/OMS深度对接、复杂的库存判断、多渠道数据同步的时候，平台自带的能力往往不够。
我们最终的选择是：核心对话与工作流用开源的智能体框架自建，同时参考dify的工作流设计思路来组织节点，而不是直接套用平台。原因很实在，我们的业务有一些特殊逻辑，比如不同店铺分组要接不同的知识库、不同会员等级要展示不同的优惠策略，这些在通用平台上做起来非常别扭。
技术栈方面，对话引擎用的是主流的大模型API，配合自建的向量知识库做RAG检索；工作流编排用的是一个支持多智能体协作的框架，后端服务用Python写，主要解决工具调用和状态管理；前端后台管理界面用了React，方便运营配置知识库和推荐策略。这块我们后面会逐步拆开讲。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 整体设计思路拆解：从对话流程到多智能体协作
2.1 对话主流程设计
智能体的对话流程，说复杂也复杂，说简单也简单。抽象到底就是三个环节：听懂用户在说什么，决定接下来应该做什么，把做出来的结果组织成人话回复给用户。具体到这个项目里，我们把它拆成了五个节点。
第一个节点是入口分流。用户发来消息后，先做一次快速的意图预判，判断是闲聊、售前咨询、售后问题还是中差评投诉，把高危对话优先路由给人工客服。第二个节点是信息抽取，把订单号、商品名、尺码、颜色这类实体捞出来。第三个节点是任务分发，根据意图把请求交给对应的子智能体，比如导购智能体、订单查询智能体、售后处理智能体。第四个节点是结果组装，把子智能体返回的数据和话术模板拼装成完整回复。第五个节点是兜底判断，如果智能体连续两次无法解决用户问题，自动触发人工转接。
这套流程的起点是“意图识别”的准确率。我们一开始图省事，直接用大模型提示词让模型判断意