Dify 搭建客服机器人实战：工作流 + 知识库，能答产品问题
把客服机器人跑在 Dify 上，是当下落地最快、ROI 也最清晰的 LLM 应用形态之一：你不用写后端、不用自己搭向量库，也不用操心召回链路，只要把产品 FAQ 和说明文档丢进知识库，再用 Chatflow 把”提问 → 检索 → LLM → 回答”这条主线串起来，就能得到一个能挂在官网、嵌入企微或通过 API 对接业务系统的客服机器人。
下面这篇教程，会从一台空白的 Linux / macOS 机器开始，把 Dify 部署到位，再一步步把知识库和工作流搭起来，直到发布成一个可以访问的 WebApp。所有节点命名、字段名以你当前 Dify 版本实际界面为准（Dify 迭代很快，本文给出的是通用逻辑，遇到细节对不上请参考官方文档）。
环境准备：先把 Dify 跑起来
> 即使你已经部署过 Dify，也建议顺手验证一遍版本和端口，本文的示例基于仓库 README 推荐的 Docker Compose 启动方式。
Dify 官方对自托管的最低硬件要求如下：
- CPU：≥ 2 核
- 内存：≥ 4 GiB
如果你只是本地体验，4G 内存的虚拟机也能起；如果要服务真实业务，建议至少 8G 起，并且把 PostgreSQL / Weaviate / Redis 这几个依赖单独拆出去。
需要先在机器上装好两个东西：
- Docker：参考官方文档 https://docs.docker.com/get-docker/ 安装对应平台的 Docker Desktop 或 docker-engine。
- Docker Compose：要求 v2.24.0 或更高。可以用
docker compose version检查，没装的话跟着官方文档补一下。
环境就绪后，开始部署 Dify：
# 1. 拉代码
git clone https://github.com/langgenius/dify.git
cd dify
# 2. 进入 docker 目录并复制环境配置
cd docker
cp .env.example .env
# 3. 启动全部服务（api / web / postgres / redis / weaviate / nginx 等）
docker compose up -ddocker compose up -d 会拉一组镜像并以后台方式启动。Dify 的 docker-compose 里包含核心 API、Web 前端、PostgreSQL、Redis、向量数据库（默认 Weaviate）以及 Nginx 反代等多个服务，端口以 compose 文件内声明为准，Web 入口默认对外暴露在 http://localhost（由 Nginx 反代到 80 端口）。
启动完成后，浏览器访问 http://localhost/install，按照向导设置管理员账号、登录密码和时区，进入 Dify 主界面。
## 配置模型供应商：机器人得有”脑子”
进入 Dify 主界面后，机器人能不能回答问题，完全取决于你接入了什么 LLM 和 Embedding 模型。前往 设置 → 模型供应商，把你要用的供应商加上：
- LLM（生成答案用）：常见的有 OpenAI、Anthropic、DeepSeek、通义千问、智谱、月之暗面、Ollama 自托管等。填入对应 API Key 并保存。
- Embedding（把文档变成向量用）：可以用同一厂商的 Embedding 模型，也可以单独接一家，比如 bge、text-embedding-3 系、Doubao-embedding 等。
> 不填 API Key 就去搭工作流，会在调试时直接报错；这是新手最常见的卡点之一，先把这一步做掉再继续。
准备知识库：把产品文档喂给机器人
这一步决定机器人”知不知道”产品。客服场景里，建议准备两类资料：
| 资料类型 | 建议内容 | 格式 |
|---|---|---|
| FAQ | 高频问题与标准答案，最好是”问句 + 答句”的成对形式 | Markdown / CSV / Excel |
| 产品文档 | 功能说明、参数表、版本对比、操作指南 | PDF / Markdown / Word |
| 政策类 | 退换货、售后、价格政策、合规说明 | Markdown / PDF |
创建知识库
进入 知识库 → 创建知识库，选择 “导入已有文本” 或 “同步自 Notion / Web 站点”：
- 上传你的 FAQ 和产品文档；
- 在 索引模式 处选 “高质量”（即 Embedding 索引），系统会要求你选 Embedding 模型——选刚才配置好的那一个；
- 分段设置 是最容易踩坑的地方，详见下文常见坑章节。
📷 Growtika / Unsplash License / 来源 上传完成后，Dify 会自动分块、向量化、入库。处理完后你可以在知识库详情里点 “召回测试”，输入一个问题看能召回哪些段落，调到满意为止。
搭建 Chatflow 工作流：把流程画出来
回到 工作室 → 创建应用，选择 “Chatflow” 类型（而不是直接选 “Chatbot”，因为我们要在中间插入知识检索节点）。给应用起个名字，比如”产品客服助手”。
进入画布后，按下面的顺序拼节点（**节点名称以你当前 Dify 版本界面显示为准**，遇到找不到的请参考官方文档）：
1. 开始节点
负责接收用户输入。sys.query 是默认的用户问题变量，先保持默认。
2. 知识检索节点
把上一步建好的知识库接进来：
- 知识库：选刚才创建的那个；
- 检索方式：推荐 Top K = 3~5 之间，配合相似度阈值过滤低相关结果；
- 输出变量会变成
result_list，里面是召回的若干段落（含content、metadata等字段）。
3. LLM 节点（核心）
这一步是机器人的”大脑”，把检索结果和用户问题一起塞给模型。系统提示词用来定人设和约束，用户提示词用来拼装问题与上下文。下面给一个可直接拷过去改的模板（提示词设计详见下一节）：
SYSTEM：客服人设 + “只基于知识库回答 + 不知道就转人工”USER：{{#sys.query#}}\n\n以下是知识库内容：\n{{#knowledge_retrieval.result_list#}}
knowledge_retrieval 是上一步检索节点的输出变量名，Dify 版本不同可能略有差异，记得在节点上确认。
### 4. 直接回复 / 结束节点
把 LLM 节点的 text 输出连到结束节点，用户就看到答案了。整个流程是：
开始 → 知识检索 → LLM → 直接回复（结束）提示词设计：让客服不胡说八道
很多人搭出来发现机器人“看起来答得很顺，但内容是瞎编的”，根因不在模型，而在提示词没约束。一个能用的客服提示词至少要包含四块：
- 角色定义：你是一名 XX 品牌的客服助理，名字叫 XXX。
- 信息来源约束：只能基于下方”知识库内容”回答；不要使用任何外部知识、不要编造参数、价格、版本号。
- 不知道的处理：如果知识库内容里没有答案，统一回复”这个问题我需要转给人工客服，请留下你的联系方式”，而不是猜一个答案。
- 格式约束：回答尽量简洁、分点；遇到参数类问题，强制要求附上来源段落。
一个简化的系统提示词参考：
> 你是”小 X”，XX 品牌的官方客服助理。请只根据下方”知识库内容”回答用户问题，不要使用任何训练知识，不要编造任何参数、价格、版本号或政策条款。
>
> 如果知识库内容里没有相关信息，请直接回复：”这个问题我暂时无法回答，已为你转接人工客服，请留下你的联系方式。” 不要道歉，不要解释原因，不要补一句”通常情况下……”。
>
> 回答时尽量使用中文，分点列出，关键参数请附上来源段落。
提示词里越是把”不要做什么”写死，幻觉越少。
调试与发布
在调试面板自测
Dify 的 Chatflow 自带调试面板，强烈建议先用它测 20~50 个真实问题再发布。调试面板里能看到：
- 用户问题原文；
- 每个节点的中间输出，包括 检索召回的段落 和 LLM 实际收到的 prompt；
- 最终回复。
调试时重点看三件事：
- 召回的段落是不是和问题真的相关；
- LLM 是不是在认真引用召回内容；
- 用户换种问法 / 写错别字时，机器人是否还能召回正确答案。
调满意之后，右上角 “发布”，生成一个 WebApp 链接，长这样：
https://your-dify-domain/chat/同时你也能拿到 API 接入方式（/v1/chat-messages 等），可以塞到自己的网站挂件、企业微信客服、Discord bot、Zapier 等任何能发 HTTP 请求的地方。
进阶玩法
基础流程跑通后，下面这些”加法”能让机器人更接近真实客服：
- 分类器 / 问题分类节点分流：先用分类节点判断是售前、售后、投诉还是闲聊，再走不同的分支——例如投诉直接转人工。
- 转人工触发：在 LLM 节点后挂一个条件分支，检测回复里是否包含”转人工”关键字，是的话输出”已为你转接人工，请稍等”并通过 webhook 通知值班客服。
- 多轮对话记忆：把
conversation_id一直透传，Dify 会自动维护上下文；如果想手动控制上下文长度，可以在 LLM 节点上设置历史轮数。 - 引用来源展示：在直接回复节点里，把检索节点的
metadata（文档名 + 段落定位）一起渲染成”参考资料”列表挂在答案下面，对用户更可信。
常见坑与排查思路
| 坑 | 现象 | 解法 |
|---|---|---|
| 分段太粗 | 一段 2000 字，召回时把整篇塞进去 | 把 chunk size 调到 300~800 字，重叠 50~100 |
| 提示词没约束 | 答案”看起来专业”但参数是编的 | 系统提示词里强制写”不知道就转人工” |
| 选了便宜模型 | 复杂问题答非所问 | 复杂分流用强模型，FAQ 直答用便宜模型 |
| 知识库无意义 | 召回段落和问题完全不相关 | 召回测试环节反复调阈值和 Top K |
| Embedding 没配 | 上传文档时报错或一直处理中 | 设置 → 模型供应商 里把 Embedding 补上 |
小结
用 Dify 搭一个能答产品问题的客服机器人，本质上就三件事：部署 Dify → 把文档塞进知识库 → 用 Chatflow 把检索和 LLM 串起来。剩下的所有优化——提示词工程、分段策略、分类分流、转人工——都建立在这条主线之上。
Dify 在易用性、可视化、和对中文模型的支持上都是目前最成熟的开源方案之一，值得作为团队内部第一个跑通的 LLM 应用。如果你想横向对比其他类似平台，可以看这篇评测：Dify 工具评测。
评论(0)