Dify 高级实验03智能客服——如何让 AI 自动应答并把疑难问题转人工Dify 实验系列 · 高级 03/10 | 实验编号DIFY-103-03基于 Dify 1.16.1 实测2026-081. 业务场景先讲一个我们实际遇到的场景。一家电商公司每天要接几千条客服咨询其中一大半是重复问题「这个手机多少钱」「我的订单到哪了」「怎么退货」。客服团队 30 个人三班倒还是经常排队高峰期用户等十几分钟才被接起。公司想过用 AI 全自动应答但又不敢全放开——真遇到投诉、纠纷AI 答不好反而火上浇油。于是客服主管的诉求很明确能自动处理的自动处理处理不了的带着完整上下文转人工别让用户重复描述第二遍。我们第一次接这类需求时第一反应也是「全自动 AI 客服嘛套个知识库就完事了」。真正动手才发现——知识库只能覆盖「商品咨询」这一路订单查询要对接系统、退换货要按规则判定、转人工要生成工单自动应答和转人工兜底是两套工程少了哪一套这个客服系统都立不住。这不是个例。任何「客服量大的企业」都是这个模式银行网点问答、运营商话费查询、SaaS 厂商工单支持——常见问题重复回答是常态但完全用 AI 替代人工又不放心难点从来不是「要不要用 AI」而是「AI 接得住多少、接不住时怎么优雅地交给人工」。2. 场景痛点这个流程的痛点在客服团队身上体现得最直接重复咨询吃掉人力一半以上的会话是同类问题客服每天把同样的答案说几十遍——人力成本高回答质量还随状态波动累了就敷衍。高峰期排队流失用户大促、活动期间咨询量翻倍用户排队等几分钟就关页面走人可能直接去竞品下单——每一次排队都是一次流失风险。转人工要用户重复描述AI 答不了转人工时用户得把问题从头再说一遍体验极差客服还要重新理解上下文——「我已经说过了」是客服场景最常见的抱怨。疑难问题无兜底投诉、纠纷这类问题没有可靠的升级通道AI 硬答容易激化矛盾漏接则直接变成客诉事件。本质上客服的困境不是「AI 能不能替代人」而是「常见问题自动化 疑难问题兜底」这套分工体系没搭起来——该自动的没自动该转的没转好。3. 方案为什么是这套智能客服架构Dify 的Chatflow对话型应用里用「问题分类 → 多分支路由 → 自动应答 → 转人工兜底」的架构正好把「自动 兜底」两件事同时解决。选它的理由我们实际对比过问题分类器原生路由不用手写意图识别配置好商品咨询/订单查询/退换货/转人工四类示例LLM 自动把用户问题分到对应分支确定性问题不用 LLM订单查询用正则提取订单号、退换货按规则判断代码节点搞定——确定性规则交给代码省 token 且结果稳定转人工带上下文对话变量conversation_history自动累积转人工时取最近 3 条随工单带走人工接手不用用户重新描述。这篇文章我们就用它搭一个「电商智能客服」商品咨询走知识库、订单查询走模拟 API、退换货按规则自动判定用户说「转人工」则生成工单并通知客服。4. 整体架构productorderreturncase_autocase_humanhuman开始用户输入 sys.query问题分类器 qc_mainproduct / order / return / human知识库 kb_productsingle 检索 TopK3LLM lm_product回复 ans_product代码 cd_order正则提取订单号 模拟订单 APILLM lm_order回复 ans_order代码 cd_return退换货规则判断条件分支 cond_returnLLM lm_return回复 ans_return代码 cd_ticket生成工单代码 cd_notify通知客服回复 ans_human链路很清晰入口收用户消息 → 分类路由 → 各分支自动应答 → 疑难问题转人工。分类器是这个架构的枢纽——分错类后面所有分支的努力都白费所以分类器必须写清示例、并强制「用户明确要求人工时一定归入转人工」。5. 模块设计5.1 问题分类器 qc_main单标签分类四类指令必须写清示例并强制兜底转人工class_list:-商品咨询 product:商品信息、规格、库存、价格例这个手机多少钱-订单查询 order:订单状态、物流、配送例我的订单到哪了-退换货 return:退货、换货、退款例我要退货-转人工 human:用户主动要求找人工客服例转人工、找客服instruction:用户明确要求人工时一定要归入转人工避免漏接。5.2 商品咨询分支知识库 LLMkb_product用retrieval_mode: single单路检索、top_k: 3、score_threshold: 0.0必须绑定真实知识库dataset_ids填实际库 IDquery_variable_selector绑用户查询lm_product用context 模式引用检索结果context: {enabled: true, variable_selector: [kb_product, result]}prompt 里用{{#context#}}占位符——由平台把检索结果注入上下文引用溯源/上下文管理交给平台而不是手动把{{#kb_product.result#}}拼进提示词。系统提示词要求仅依据检索结果回答、不编造规格价格你是电商客服助手小 D负责商品咨询。请根据知识库检索到的商品信息回答用户问题。 用户问题{{#sys.query#}} 商品资料 {{#context#}} 要求 1. 仅根据检索到的商品资料回答不要编造规格、价格和库存 2. 如果检索结果为空或不足以回答诚实说明并建议用户转人工客服 3. 回答简洁友好5.3 订单查询分支正则提取订单号用户句子是「我的订单 OD202607002 到哪了」不能整句查表必须先正则提取OD开头的订单号defmain(order_id):importre mre.search(rOD\d{6,},order_idor)oidm.group(0)ifmelsemock_orders{OD202607002:{status:配送中,logistics:中通 ZT9876543210,eta:2026-07-23},OD202607003:{status:已签收,logistics:圆通 YT5555555555,eta:2026-07-20},}ordermock_orders.get(oid,{status:未找到,logistics:,eta:})return{found:trueifoidinmock_orderselsefalse,order_id:oid,status:order[status],logistics:order[logistics],eta:order[eta]}5.4 退换货分支规则判断 条件分支确定性规则用代码节点不用 LLMboolean 展平为字符串cond_return的 case_auto 用 OR 组合cd_return 输出:can_return / can_exchange 均为 true|false 字符串case_auto:cd_return.can_return is true OR cd_return.can_exchange is truecase_human:cd_return.can_return is false AND cd_return.can_exchange is false5.5 转人工分支工单 通知 上下文cd_ticket生成工单号、按是否含「投诉」定优先级并带上对话变量conversation_history最近 3 条作为上下文让人工客服不用用户重复描述defmain(user_query,conversation_history):importtime historyconversation_historyifisinstance(conversation_history,list)else[]ticket_idTK-{}.format(int(time.time()))priorityhighif投诉in(user_queryor)elsenormalctx.join(history[-3:])ifhistoryelse无历史记录return{ticket_id:ticket_id,priority:priority,context:ctx,message:已为您转接人工客服工单号{}。客服将在 5 分钟内联系您。.format(ticket_id)}6. 运行验证输入期望行为实测「这个手机多少钱」分类为 product知识库检索后回答商品信息与预期一致「我的订单 OD202607002 到哪了」正则提取订单号返回「配送中 物流单号」与预期一致「我要退货刚收到 3 天」规则判定可退货走 case_auto 自动回复与预期一致「投诉你们物流太慢了转人工」分类 human工单优先级 high通知客服与预期一致工单上下文含历史记录7. 实战坑坑现象修复分类器漏「转人工」兜底用户说「找客服」被分到商品咨询AI 答非所问且无法转人工指令明确「用户明确要求人工时一定要归入转人工」 给示例dify103_03 实测订单号整句查表「我的订单 OD202607002 到哪了」查不到含多余文字代码节点先re.search(rOD\d{6,})提取订单号再查dify103_03 实测代码节点返回 booleancan_return在 if-else 变量选择器不可见分支配不上boolean 展平为true/false字符串条件用is比较知识库分段不自包含single 检索单段命中LLM 拿到的片段缺上下文答不全入库分段时保证每段自含答案自包含分段检索 TopK 才有效转人工不带上下文人工客服看不到用户之前说了什么用户重复描述工单代码引用conversation_history最近 3 条拼进 contextdify103_03 实测8. 实验文档及源码获取实验文档完整操作步骤DIFY-103-03智能客服系统.md源码可直接导入dify103_03_智能客服系统.yml文章聚焦核心配置与采坑点实验的完整分步操作节点搭建/参数表/调试指引见实验文档原文。下一篇Dify 高级实验04RAG 增强问答——如何让知识库问答更准还能多轮追问 你在这个实验的场景里踩过什么坑欢迎评论区分享你的实战经验。
