【保姆级教程】Dify+RAGFlow+LangBot搭建本地企业级智能客服系统，零代码也能轻松上手，建议收藏！

1. 为什么要在本地把 Dify、RAGFlow、LangBot 串起来如果你正在找一套能跑在自己服务器上、数据不出内网、还能同时接微信/飞书/钉钉的企业智能客服方案那 Dify RAGFlow LangBot 这个组合值得认真看一遍。Dify 负责对话流编排和智能体逻辑RAGFlow 负责知识库的 Embedding、召回与重排LangBot 则把各个聊天平台的事件协议翻译成 Dify 的 HTTP 调用再把回答原路推回去。三者跑在同一个 Docker 网络里不需要依赖任何外部 SaaS日志和文档全部留在本地硬盘。这套方案适合谁一是中小团队的技术负责人想给内部或客户做一套可控的问答系统二是独立开发者手里有文档资产但不想把数据交给第三方平台三是运维或后端同学被要求“搭一个能接多个渠道的客服机器人”但不想从零写适配层。零代码指的是业务编排层面不需要写代码Docker 命令和配置项还是要照着敲一遍的。我试过把这三件套跑通中间踩了几个网络不通、变量名对不上的坑下面按实际操作的顺序把每一步拆开讲。整个流程分六块先讲清楚问题场景和整体架构再把 TaoToken 的 Key/API 通道配好然后给出可复制的 docker-compose 和 config 骨架接着做三步验证再列常见报错最后给一个统一入口的 CTA。2. TaoToken 前置统一 Key 与 API 通道配置在开始编排之前先把模型调用的通道准备好。Dify 里无论是智能体还是工作流最终都要调大模型如果你有多个模型供应商Key 管理会很散。TaoToken 的作用是提供一个统一的 API 入口你只需要在 Dify 的模型供应商配置里填一个 Base URL 和一个 Key就能调用多个模型。先到官网注册并拿到 Keyhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 登录后在控制台的 API Keys 页面创建一个新 Key复制保存。API 的基础地址是 https://taotoken.net/api 注意这个地址后面不加 UTM 参数直接用在代码和配置里。在 Dify 里的操作路径是右上角头像 → 设置 → 模型供应商 → 选择 OpenAI 兼容类型或自定义把 API Base 填成 https://taotoken.net/api API Key 填你刚创建的那串。保存后可以在模型列表里拉取可用模型选一个对话模型和一个 Embedding 模型分别用于生成和向量化。如果你后面要用 Coding Plan 做长期编码或 Agent 任务可以在控制台里单独开一个计划Key 是独立的不要和客服系统的 Key 混用。模型对话的调试入口在 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API Keys 管理在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。这一步做完Dify 里就有了可用的模型通道RAGFlow 的 Embedding 也可以指向同一个 Base URL省去分别配置的麻烦。3. 可复制配置docker-compose 与各服务骨架3.1 整体网络规划三个服务要互通关键是网络。Dify 默认会创建一个名为dify_default的网络如果你用官方 compose 且项目名是 difyRAGFlow 和 LangBot 都要挂到这个网络上。RAGFlow 的容器名假设为ragflow-serverLangBot 的容器名为langbotDify 的 nginx 容器名为dify-nginx-1。后面所有内部调用都用容器名不用 localhost。先确认 Dify 的网络名docker network ls | grep dify如果输出里有dify_default说明网络已存在。如果没有检查你的 Dify compose 项目名把下面命令里的网络名替换成实际的。3.2 RAGFlow 的 compose 骨架RAGFlow 官方提供了 docker-compose这里给一个精简后的关键片段重点是网络和端口version: 3.8 services: ragflow-server: image: infiniflow/ragflow:latest container_name: ragflow-server ports: - 9380:9380 - 80:80 environment: - SVR_HTTP_PORT9380 - MYSQL_PASSWORDragflow123 - MINIO_PASSWORDminio123 - REDIS_PASSWORDredis123 volumes: - ./ragflow/data:/ragflow/data networks: - dify_default networks: dify_default: external: true启动命令docker compose -p ragflow -f docker-compose-ragflow.yaml up -d启动后访问http://localhost:80进入 RAGFlow 界面注册账号创建一个知识库上传你的文档PDF/Word/Markdown 都行选择 Embedding 模型时把 Base URL 指向 TaoToken 的 API 地址Key 填同一个。RAGFlow 会自动做分块、向量化和索引。3.3 LangBot 的 compose 与网络接入LangBot 的官方仓库在 GitHub 上下载后进入目录用自带的 compose 启动docker compose -p langbot -f docker-compose.yaml up -d启动后访问http://localhost:5300/register注册登录。接下来是最关键的一步把 LangBot 挂到 Dify 的网络里。docker network connect dify_default langbot验证网络是否通docker exec langbot curl -i http://dify-nginx-1/v1/如果提示 curl 没安装用下面命令装兼容 apt 和 apk 两种基础镜像docker exec -u 0 langbot sh -c apt-get update -qq apt-get install -y curl || apk add --no-cache curl装好后重新执行验证命令看到 HTTP 响应头就说明网络通了。3.4 Dify 侧的应用配置在 Dify 里创建一个应用类型选“工作流”或“智能体”。如果选工作流输出变量名一定要设为summaryLangBot 默认读这个字段。如果自己加了输入变量不要勾选“必填”否则 LangBot 传参时会报错。然后在应用的 API 页面创建一个 API Key复制保存。这个 Key 要填到 LangBot 的流水线配置里。3.5 LangBot 流水线配置进入 LangBot 后台创建流水线运行器选 Dify 服务基础 URL 填http://dify-nginx-1/v1/应用类型按你在 Dify 里创建的类型选API 密钥填上一步复制的 Key。保存后进入对话调试先关掉流式传输这样报错能更快看到。如果连接失败用下面命令看日志docker logs --tail 50 -f langbot把报错信息贴给 AI 分析通常问题集中在网络不通、Key 不对、变量名不匹配这三类。4. 三步验证召回测试、多轮联调、渠道回环4.1 知识库召回测试在 RAGFlow 的知识库页面找到“召回测试”功能输入一个你文档里明确有答案的问题比如“公司的报销流程是什么”。看返回的片段是否命中正确段落相似度分数是否合理。如果召回为空检查文档是否解析成功、Embedding 模型是否配置正确。这一步单独验证 RAGFlow不涉及 Dify 和 LangBot。4.2 多轮问答联调回到 Dify 的应用编排页面在对话框里连续问三个相关问题比如“报销流程是什么”→“需要哪些材料”→“审批要多久”。观察智能体是否能记住上下文工具节点是否能正确调用。如果第二轮就丢失上下文检查 Dify 的会话变量配置和记忆节点是否接上。4.3 渠道消息回环确认以钉钉为例。进入钉钉开放后台创建应用添加机器人消息接收模式选 Stream记下 RobotCode、Client ID、Client Secret。如果需要流式输出还要在卡片平台创建一个 AI 卡片模板记下模板 ID并在应用里开通卡片权限。回到 LangBot创建机器人填入上面四个值加模板 ID选择之前配好的流水线并启用。然后在钉钉里搜索机器人名字私聊发一条消息看是否收到回复。如果工作流类型一直没响应把流式输出关掉再试。改完配置后群聊里要把原机器人删除重新添加才生效私聊可以直接生效。三步都通过说明整条链路从知识库到渠道已经打通。5. 本篇常见错排查网络不通最常见的是 LangBot 没挂到dify_default网络。用docker network inspect dify_default看容器列表里有没有 langbot。如果没有重新执行docker network connect。curl 未安装LangBot 的基础镜像可能是 alpine没有 curl。用前面给的 apt/apk 兼容命令装一下。Dify 返回 401API Key 不对或没填。检查 LangBot 流水线里的 Key 是否和 Dify 应用 API 页面里的一致。工作流无响应输出变量名不是summary或者输入变量勾了必填。改成summary取消必填。钉钉群聊不生效改完 LangBot 配置后群里的机器人需要删除重新添加。私聊可以直接生效。RAGFlow 召回为空文档没解析完或者 Embedding 模型没配。等解析状态变成“已完成”再测试。流式输出卡住工作流类型关闭流式输出智能体类型可以开。端口冲突RAGFlow 默认占 80如果本机已有服务占用改 compose 里的端口映射。6. 统一入口与后续扩展整套系统跑起来后你得到的是一个本地企业客服中心知识侧往 RAGFlow 扔文档即可秒级生效业务侧在 Dify 画布拖节点就能查订单、调 API、写数据库渠道侧 LangBot 把同一套大脑挂到钉钉、飞书、企业微信、Discord 等多个平台对话日志全部留在本地。模型通道统一走 TaoTokenKey 和 Base URL 在 Dify 和 RAGFlow 里各配一次就行。后续如果要加渠道只需要在 LangBot 里新建机器人不用动 Dify 和 RAGFlow。如果要换模型在 TaoToken 控制台切换即可业务侧无感知。接入文档和 API Keys 管理入口接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI Keyshttps://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content模型对话调试https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentCoding Plan长期编码/Agenthttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content最后提醒一句Dify 工作流类型在钉钉群里一定要关流式输出这个坑我踩过关了之后响应就正常了。改完 LangBot 配置记得在群里删掉机器人重新加私聊不用。