手搓一个企业智能客服问答智能体：基于 Dify 的工作流实战
用一套「意图分流 + 多知识库检索 + 大模型生成」的工作流，把散落在几十份产品文档里的客服知识，变成 7×24 小时在线的智能客服。
引言：客服的痛点，不只是"人多"
做过企业客服的都清楚，最难的不是"回答问题"，而是这三件事：
- 知识散：产品手册、售后话术、常见故障文档、各产品线资料，散落在不同人手里、不同文件夹里
- 新人慢：一个客服要熟记几百条问答，培训周期长，离职率高
- 在线时间有限：客户不分工作日与节假日地提问，客服却要上下班
传统做法是"整理一份 FAQ 文档 → 客服照着答"，本质还是人肉检索。而用 Dify 搭一个智能客服智能体，核心就是把"检索 + 组织答案"这两步交给大模型完成，客服只需要处理那些真正需要人判断的事。
这篇文章完整记录我"手搓"这个映美云打印平台智能客服工作流的过程——从整体架构到每个节点的设计取舍，以及踩过的坑。
一、整体架构：五个节点，两条分支
这个智能客服工作流不长，但结构非常清晰。整体链路如下：
┌──────────────────┐
用户提问 ──▶ ┌────────┐ │ 直接回复(人工) │
│ 开始 │─▶│ 客服热线话术 │
└───┬────┘ └──────────────────┘
│ ▲
▼ │ IF: query 含"转人工"/"人工"
┌──────────┐ │
│ 条件判断 │─────────┤
└────┬─────┘ │
│ │
│ ELSE │
▼ │
┌──────────┐ │
│ 知识检索 │ │
│ (6个知识库)│ │
└────┬─────┘ │
▼ │
┌──────────┐ │
│ LLM │ │
│ DeepSeek │ │
└────┬─────┘ │
▼ │
┌──────────┐ │
│ 直接回复 2│◀────────┘
│ (生成答案)│
└──────────┘
核心思路只有一句话：先用一组确定性的关键词规则把"要转人工"的请求挑出来，剩下的全部走"知识库检索 + 大模型生成"。
这样做的好处是——把"最贵的"和"最便宜的"分开处理：
| 分支 | 触发条件 | 处理方式 | 成本 |
|---|---|---|---|
| 人工分支 | 用户明确要"转人工" | 直接回复固定话术 | 几乎为零（不调模型、不检索） |
| 问答分支 | 其余所有问题 | 检索知识库 → LLM 生成 | 一次检索 + 一次 LLM 调用 |
二、逐节点拆解
2.1 开始节点：接住用户的原始问题
工作流的入口，只接收一个变量就够了：
sys.query（String）——用户的原始提问
不额外设计复杂变量，原因是这是个纯问答型客服，输入信息已经足够。保持入口简洁，后面所有节点都基于 sys.query 做文章。
2.2 条件判断：一句话决定"转人工"还是"问知识库"
这是整个工作流最前面、也是最关键的"分流阀"。
条件设置（IF / ELSE 结构）：
IF query 包含 "转人工" → 走人工分支
IF query 包含 "人工" → 走人工分支
ELSE → 走知识检索分支
为什么用关键词匹配，而不是让大模型去分类？
这是我在设计时反复权衡后定下的方案，理由有三个：
- 快：条件判断是毫秒级的，而一次 LLM 意图分类要几百毫秒到几秒
- 省：转人工这部分请求根本不消耗 token
- 准：像"转人工""人工客服"这种诉求，表达高度固定，关键词匹配的准确率不比大模型差
踩过的坑：关键词一定要列全。
一开始我只写了"转人工"，结果用户输入"我要找人工""人工客服在吗""转接人工"就全部漏判、被丢进知识库去检索，答非所问。后来把关键词补成"人工"这种更宽泛的词，覆盖度立刻上来了。
一句话经验：关键词覆盖宁可宽一点，因为"误转人工"的代价只是给个电话，而"漏转人工"的代价是客户被机器反复答非所问。
如果以后关键词越来越多、规则越来越绕，可以在这个节点后面再加一个 LLM 意图分类节点做兜底——但一开始真没必要，别过度设计。
2.3 直接回复（人工分支）：一个干净利落的兜底
人工分支不玩花的，直接给出客服热线：
请问您是希望联系人工客服吗？
请拨打映美客服热线联系我们：
📞 400-930-8899 或 0750-6391888
感谢您的耐心等待，祝您使用愉快！
这个节点看似简单，但它是整个客服体系的"安全阀"。
一个智能客服无论做得多好，都一定会遇到答不上来、或者客户就是想要人的情况。预留一个"随时可转人工"的出口，比把知识库做得更全更重要——它决定了客户在最坏情况下的体验下限。
2.4 知识检索：一个节点挂六个知识库
进入问答分支后，第一个节点就是知识检索（Knowledge Retrieval）。
查询变量：sys.query，直接拿用户的原始提问去检索。
知识库配置——这里是这个工作流的核心资产。我没有把公司所有文档塞进一个大库，而是按产品线 / 用途拆成了多个知识库，一次检索时联合挂载：
| 知识库 | 内容 |
|---|---|
| 彩色标签打印机问题与解答文档 | 主打产品线的 FAQ |
| 云打印开放平台 | 开放平台对接文档 |
| 映美售后质保常用语 | 售后话术标准化 |
| 数码产品知识库 | 数码产品资料 |
| 拉式仓库知识库 | 仓储/物流相关知识 |
| 映美美的产品 | 合作/关联产品资料 |
为什么要拆成多个库，而不是合成一个？
这是我在实践中总结的经验：
- 维护隔离：某个产品线文档更新，只动它自己的库，不影响其他库
- 检索精度：分库后可以针对不同库设置不同的检索参数和切片策略
- 权限清晰：不同部门管理各自的库，职责明确
- 可扩展：新上一个产品线，加一个库就行，不用重构整个库
检索参数建议：
- TopK：先设 3～5，观察召回情况再调。设太大容易把无关内容带进上下文，反而干扰大模型
- Score 阈值：建议开启，过滤掉相关度过低的片段。宁可不答，也别拿低质内容硬答
- Rerank：如果知识库多了、召回噪音大，加一个重排序模型能明显提升命中率
2.5 LLM 节点：让模型"看着资料回答"
检索到的知识片段，连同用户问题一起，喂给大模型生成答案。
模型选择：DeepSeek-R1-Distill-Qwen
这里我选的是 DeepSeek 的蒸馏版本，而不是满血版大模型，理由是：
- 客服问答是有资料可依的任务，不需要模型有超强推理能力，够用即可
- 蒸馏模型延迟更低、成本更低，客服场景对响应速度敏感
- 免费/低价额度充足，适合高频调用
提示词（Prompt）设计要点：
你是映美公司的专业智能客服，负责解答用户关于产品、售后、技术对接的问题。
请遵循以下规则：
1. 优先基于「知识库上下文」回答，不要凭空编造
2. 如果知识库上下文里找不到答案，不要硬答，请引导用户转人工客服
3. 回答要专业、简洁、有条理，涉及步骤时分点说明
4. 涉及价格、承诺类问题，请谨慎，引导联系人工确认
5. 语气礼貌，符合企业客服形象
【知识库上下文】
{{context}}
【用户问题】
{{sys.query}}
这段 Prompt 里最关键的一条是第 2 条：明确告诉模型"找不到就说不知道，引导转人工"。这是防止大模型幻觉的第一道防线——比起让它自信地胡编一个答案，宁可让它坦率地说"这个我帮您转人工"。
2.6 直接回复 2：把答案还给用户
最后一个节点，输出 LLM 节点的返回文本 {x: text}。
到这里，一条完整的客服问答链路就跑通了。
三、知识库这口"井"，要提前挖好
智能客服的效果，70% 取决于知识库的质量，模型和编排只占 30%。这部分虽不在工作流画布上，但必须单独讲。
1. 文档清洗
原始文档里往往有页眉页脚、目录、水印、无关的修订记录。这些噪音进到切片里，会污染检索结果。先把"给人看的文档"处理成"给机器看的文档"，再上传。
2. 切片策略
不是所有文档都适合一个切片大小：
- FAQ / 问答类：按"一问一答"切，一个切片就是一条完整问答
- 操作手册类：按"步骤/小节"切，保证一个切片内的逻辑自洽
- 长文档：适当重叠切片（overlap），避免答案正好被切断
3. 命名与元数据
知识库名称要能自解释（比如"映美售后质保常用语"就比"常用语2"好得多）。有条件的话，给文档打上产品线、版本等元数据标签，后续可以做更精细的检索路由。
4. 持续更新
客服知识是活的。建议建立一个固定节奏：每月复盘一次"大模型答不上来的问题"，把新问题补充进知识库。这个闭环，才是智能客服越来越聪明的真正原因。
四、几个关键设计决策复盘
① 分流放在最前面，而不是让模型判断一切
很多人的第一反应是"让大模型判断用户要不要转人工"。我把它放到了工作流最前端，用确定性的条件判断先做粗筛——能用规则解决的，就别交给模型。省时、省钱、还更稳。
② 兜底比完备更重要
不管是"转人工"的分流，还是 Prompt 里"找不到就引导人工"的约束，本质都是在设计失败路径。一个没有兜底的智能客服，遇到知识盲区就会胡说八道；而一个兜底做好的智能客服，最差也只是"礼貌地让你打电话"，体验下限是有保障的。
③ 拆库，别贪大
知识库不是越大越好。精准、干净、分区明确的小库，效果远好于一个什么都往里塞的大库。
五、踩过的坑
| 坑 | 现象 | 解决 |
|---|---|---|
| 关键词漏判 | "找人工""转接人工"没被识别，被丢去检索 | 放宽关键词，覆盖所有"人工"相关表达 |
| 检索到无关内容 | 大模型拿着不相关的片段硬答 | 开启 Score 阈值，调小 TopK，必要时加 Rerank |
| 幻觉 | 知识库没有的问题，模型自己编答案 | Prompt 里强约束"找不到就转人工" |
| 文档噪音 | 页眉页脚进了切片，稀释了有效信息 | 上传前清洗文档 |
| 知识库过时 | 答的是旧产品的旧参数 | 建立月度知识库更新机制 |
六、下一步可以怎么扩展
这套工作流跑通后，扩展空间很大：
- 转人工接工单：人工分支不只是给电话，还可以自动创建工单/发飞书通知，把"转人工"变成"留痕的任务"
- 多轮澄清：用户问题太模糊（如"打不出来"）时，先反问"请问是哪款机型？"，再检索
- 工具调用（Agent 化）：接入订单查询、物流查询等 API，让客服能查实时数据，而不只是答文档
- 数据回流：把用户问题和命中情况记录下来，形成"高频未解决问题"看板，反哺知识库建设
- 图文并茂：产品类问题常常"一张图胜千言"，可以让模型在回答里带示意图、截图（这也是我这个客服版本正在做的方向）
七、总结
回头看，这个企业智能客服工作流的精髓，其实就三句话：
- 规则归规则，模型归模型——确定性的事用条件判断解决，开放性的答案用大模型生成
- 知识库是根，工作流是干——把知识库这口井挖好，整棵树才长得好
- 永远留一条转人工的路——兜底做扎实，体验才有下限
整个工作流只有五个节点，一天之内就能搭出第一版。真正的功夫，不在画布上的连线，而在画布外的那些产品文档里。
先用最少的节点跑通闭环，再一点点把它养聪明——这就是"手搓"一个企业智能客服的全部方法论。
本文工作流基于 Dify Chatflow 搭建，模型使用 DeepSeek-R1-Distill-Qwen，知识检索挂载多个产品线知识库。
下期预告
下期我将介绍如何多轮澄清客户问题，引导客户正确描述问题，以及 Dify 知识库的详细建立过程。
