基于Dify的可视化LLM工作流编排实战：从部署到多租户

简介面向企业开发者与流程自动化实施人员这份资料围绕Dify平台的可视化编排、模型调用与API集成三大核心能力整理出多场景下的工作流实操案例覆盖文本分析、图像识别、自然语言处理等智能业务也适合具备一定基础、希望将Dify落地到具体项目的学习者参考。资源共107个文件、约78.99MB包括35个Python脚本、29个YAML配置、8个XML及Markdown笔记等分别承担流程逻辑、DSL定义、接口配置与使用说明目录结构便于按模块检索。已有199人学习下载。通过案例能掌握可视化拖拽构建流程、接入第三方服务与预训练模型的方法并了解财务审计、供应链优化、客户服务等场景下自动化流程的拆解与实现要点可直接对照环境配置与脚本修改进行复现和二次开发。 我们组最早是拿 Python 脚本直接串 LLM 调用的一开始只有两三个步骤还好后来越加越多先查知识库、再判断意图、然后调工具、最后还要拼接多个模型输出……prompt 改一版要翻半天代码日志又散在各个调用栈里排错全靠猜。后来换到 Dify 这类 LLM 应用开发平台把整个流程搬到可视化工作流里情况才真正好转。这篇就基于 Dify 平台把我从部署、搭节点到排错、上多租户的实操过程完整梳理一遍包括我在工作流里踩过的坑和绕过的弯路。适合正在做 AI 应用但不想重复造轮子的人也适合团队里负责内部工具、知识库问答、内容生成这类场景的开发者参考。1. 为什么我放弃了手写 LLM 编排脚本转到 Dify 平台1.1 手写脚本的维护成本比你想象的高得多我最早做的工作流原型其实很简单用户输入 - 拼 prompt - 调 OpenAI - 返回结果。用个 FastAPI 包一下就能跑。但真实业务很快就开始“膨胀”——要做知识库检索要接公司内部系统要根据用户问题决定走哪个分支甚至还要在多个模型之间做判断。这时候你会发现所谓“工作流”本质上不是几个 API 调用排队而是一套状态机。状态维护、分支判断、上下文传递、失败重试、日志追踪全部得自己写。写完之后 prompt 一改整段逻辑又要跟着调。更难受的是业务同事想要看“这个结果是怎么一步步算出来的”你对着代码很难讲清楚。Dify 的价值就在这里它把“编排 LLM 应用”这件事做成了可视化画布节点就是块连线就是数据流动每一步的输入输出都能直接点开看相当于给 AI 应用加了一层可观测的流水线。1.2 Dify 工作流到底是什么Dify 工作流的核心是把一次完整的 AI 任务拆解成多个节点每个节点负责一个子任务。节点之间靠变量传递数据上游节点的输出可以作为下游节点的输入。和代码里的函数调用不同工作流天然适合做“需要人看得明白”的业务逻辑比如客服对话、内容生产流水线、数据清洗加生成。一个典型 Dify 工作流里有这些角色开始节点定义用户输入参数比如问题文本、日期范围、文件链接。LLM 节点调用大模型完成生成任务可以指定模型、温度、max_tokens。知识检索节点从知识库里召回相关片段是老 Dify 用户最常用的能力。条件分支节点根据上游输出走不同路径类似编程里的 if/else。代码节点执行 Python/JS适合做数据清洗、格式转换、计算。HTTP 请求节点调用外部 API把工作流和业务系统打通。模板转换节点用模板字符串组织 prompt比直接拼字符串友好得多。结束节点决定工作流最终输出什么。打个比方工作流就像一条流水线每个节点是一个工位节点之间的连线就是传送带。你在“传送带”上放一个变量下一道工序就能拿到它加工加工完再往下传。Dify 帮你把传送带和工位管理好了你要做的是设计工序本身。2. 本地部署的第一道坎Docker Compose 与升级2.1 用 Docker Compose 拉起整套服务Dify 官方推荐的方式是 Docker Compose 部署这个方案我在 Windows 和 Linux 上都跑过。核心步骤很简单下载项目代码复制环境变量模板然后一条命令拉起所有容器。git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d这套编排里包含了好几个服务API 服务、Worker 服务异步任务、Sandbox 服务代码节点沙箱、PostgreSQL、Redis、Weaviate 或 Qdrant向量数据库以及 Nginx 和 Web 前端。首次启动会拉不少镜像耗时取决于网络。启动完成后浏览器访问http://localhost:8080就能看到控制台。这里有个很关键的细节一定要先配置.env再启动。默认模板里的很多配置是占位符尤其是密钥、向量存储类型、端口这些直接拉起虽然能跑但后期改起来要重启一堆容器。我习惯先把.env里的EXPOSE_NGINX_PORT改好避免和本机其他服务端口冲突。2.2 Windows 部署和在线升级的实操细节Windows 上跑 Docker 需要先装 Docker Desktop并且把镜像目录放到空间充足的盘Dify 全家桶镜像加起来体积不小。另外我实测在 Windows 下如果用的是 PowerShell执行docker compose命令没问题但遇到运行cp .env.example .env这类命令时要留意文件是否被占用。升级这件事Dify 社区版迭代很快官方升级思路是拉取最新代码然后重新构建镜像。cd dify git pull cd docker docker compose down docker compose pull docker compose up -d升级前务必备份数据库。Dify 的元数据都存在 PostgreSQL 里向量数据存在单独存储里。我同事有一次在线升级后遇到知识库索引异常就是因为升级过程中向量库连接配置变了旧索引没重建。稳妥的做法是升级前用docker compose exec db pg_dump导出一份 SQL升级后再验证核心流程。2.3 前端二开部署改界面不只是换个 logo如果你需要改 Dify 前端界面比如统一登录页、改文案、接自己的 CSS日常开发可以直接跑前端源码但生产环境最好重新打一个前端镜像。Dify 的 web 目录是独立前端工程基于 Next.js。cd dify/web npm install npm run build构建产物需要放到 Nginx 容器中Dify 官方镜像里已经有打包好的前端二开时你可以改 Dockerfile 里的 web 镜像构建阶段把自己的构建产物打进去或者用 Nginx 反向代理指向自己的静态目录。我试过最简单的做法是用自己的 Nginx 容器挂载构建好的out目录然后反向代理到后端的 API 地址省去改官方镜像的麻烦。3. 工作流节点拆解串流程、做判断、查知识库3.1 节点之间靠变量传递别被花哨的连线搞晕在 Dify 工作流画布上拖节点第一眼会觉得连线很复杂但本质上就是“变量名”的传递。每个节点输出一组结构化数据你可以在下游节点里用{{#节点ID.字段#}}的方式引用。举个例子开始节点接收了一个参数query那么 LLM 节点的 prompt 里可以直接写用户的问题是{{#start.query#}}如果前面挂了一个知识检索节点它的输出里包含result数组那么你可以把检索结果拼进 prompt请根据以下参考资料回答问题 {{#knowledge_retrieval.result#}} 用户问题{{#start.query#}}这套变量引用机制是整个工作流的地基。我见过不少人搭工作流报错十有八九是变量路径写错了——节点 ID 变了没同步或者嵌套字段名不对。Dify 的节点配置面板里会动态显示可用的变量列表直接点选比手敲靠谱。3.2 知识检索节点搭建自己的知识库问答流水线Dify 的知识库是独立模块把文档切分、向量化、存储都封装好了。你的工作流里只需要拖一个“知识检索节点”选择要检索的知识库设置检索方式和 TopK就能拿到相关片段。知识库问答工作流是我用得最多的场景。节点顺序一般是开始节点 - 知识检索节点 - LLM 节点 - 结束节点。检索节点负责“找资料”LLM 节点负责“根据资料写答案”两个职责分开互不干扰。好处是调 prompt 时不用动检索逻辑调检索策略时也不会影响生成。有一个细节容易忽略知识检索召回结果有时候排序不理想Dify 的重排序能力在多个知识库混合检索时特别有用。混合检索加 Rerank 之后答案质量提升非常明显。我习惯把 Rerank 模型单独配好检索节点里打开“启用重排序”阈值设 0.3 左右太低会混入不相关片段太高又会把可能相关的片段全部丢掉。3.3 条件分支让工作流会“判断”很多业务场景不是一路走到黑而是要根据中间结果走不同分支。Dify 里的条件分支节点支持多种判断规则比如“包含”“等于”“大于”“为空”。我做过一个简历筛选工作流先用 LLM 节点解析简历文本提取技能列表和年限然后走条件分支如果满足硬性条件就进“通过”路径否则进“淘汰”路径最后再让 LLM 生成一段筛选意见。条件分支最怕的是条件和实际数据类型对不上。LLM 节点输出的是字符串你拿“包含”判断没问题但要判断数字大小就得先经过代码节点转成整数或者让 LLM 按固定 JSON 格式输出再解析。Dify 里的变量类型是结构化的加个代码节点做数据转换能省掉后面一堆麻烦。4. 能直接抄的案例周报生成工作流搭建过程4.1 场景和整体设计我搭过一个周报生成工作流需求很简单团队成员每天在内部系统登记任务到了周五要自动汇总生成周报。如果手写我得写一个脚本拉数据、拼 prompt、调模型、再输出文档用 Dify 工作流只需要把每个环节变成一个节点。整体流程开始节点接收两个输入一个是用户姓名一个是日期范围。HTTP 请求节点从内部任务系统拉取该用户在日期范围内的任务列表。代码节点把任务列表整理成文本过滤掉空字段按优先级排序。模板转换节点把整理后的任务文本拼进周报 prompt。LLM 节点生成周报正文。结束节点返回最终周报文本。这样设计的原因很简单数据获取、数据预处理、文本生成三者解耦。后续如果任务系统接口变了只改 HTTP 请求节点如果领导要求换 prompt 风格只改模板节点和 LLM 节点其他环节不用动。4.2 各节点关键配置和踩坑点HTTP 请求节点里我配置了请求 URL、Header、Body返回结果用 JSONPath 提取任务数组。这里有个坑Dify 的 HTTP 节点返回的是字符串要传给代码节点得在代码节点里用json.loads()解析一遍。代码节点用 Python 写了个极简处理逻辑import json def main(task_json: str) - dict: tasks json.loads(task_json) lines [f- {t.get(title)}{t.get(status)} for t in tasks if t.get(title)] return {task_text: \n.join(lines)}模板转换节点里拼接 prompt你是团队助理请根据以下任务记录生成一份简洁的周报按“本周完成”和“待推进”分类 {{#code.task_text#}}LLM 节点我用的模型是gpt-4o-mini温度设 0.3避免周报内容太发散。实测这个工作流跑一遍不到 20 秒成本极低。上线之后最常改的是 HTTP 请求节点的接口字段因为内部系统文档更新不及时字段名经常对不上这种情况在 Dify 的调试面板里一跑就能发现逐步排查也算友好。4.3 智能体工作流测试验证别跳过单步调试Dify 工作流右上角的“运行”按钮会走完整流程但遇到错误时我习惯用单步调试模式一节点一节点看输入输出。某个节点红了直接点开查看它是哪一步报错是参数缺失还是上游输出格式不对。测试验证阶段我建议至少覆盖三种情况正常输入、边界输入空字符串、超长文本、异常输入接口超时、字段缺失。工作流节点之间是有依赖关系的异常输入最容易暴露出“某个节点返回了空值导致下游直接崩掉”的问题。在关键节点之间加个代码节点做默认值兜底能明显减少后期线上报错。5. 调试排错缺包报错和变量污染这类高频问题5.1 “请安装缺失的包以使用此工作流”是导入工作流最常见的坑搜索热词里有一条很能说明问题“请安装缺失的包以使用此工作流。要安装缺失的节点请先在你的 python 环境中运行”。这个报错我遇到太多次了尤其是从别人那里导入一个工作流时。原因很直接Dify 工作流里的代码节点支持 Python/JS但代码节点运行在 Sandbox 服务中沙箱环境只预装了一些基础库。如果你在工作流里写了import requests或import pandas而当前沙箱环境没有这个包导入工作流后运行代码节点就会报这个错。解决办法有两种。第一种是在 Sandbox 容器里安装依赖docker exec -it docker-sandbox-1 bash pip install requests但这样装完重启容器就丢了还是得改 Dockerfile 或依赖文件把包固化进去。另一种更省事的办法尽量用 HTTP 请求节点替代需要第三方库的代码逻辑。Dify 的 HTTP 请求节点自带系统代理和请求能力你不需要在代码节点里import requests直接把外部 API 的调用放到 HTTP 节点里再把结果交给代码节点做纯逻辑处理就能绕开大半缺包问题。5.2 变量污染与迭代节点看着简单跑起来才发现不对我搭过一条批量生成工作流逻辑是已知一组用户 ID对每个 ID 调一次 API再让 LLM 生成个性化文案。第一版我用“迭代节点”把用户列表传进去循环处理。结果跑了一段时间发现连续运行多次后结果偶尔会串——A 用户的结果里出现了 B 用户的字段。排查后发现问题出在变量命名上。迭代节点内部使用了外部同名的输出变量在循环体里赋值时把外部变量覆盖了。Dify 的变量作用域在画布上不容易一眼看出但实际运行时会互相影响。我的经验是迭代节点内部的变量名加上“item_”“loop_”这样的前缀强制和外部变量区分开。不要图省事用默认命名。5.3 调试面板看不到日志时怎么办Dify 的调试信息在大多数情况下够用但遇到 HTTP 节点返回了非 200 状态码、但响应体被截断的情况我一般直接去 API 容器里看日志。docker logs docker-api-1 --tail 200日志里会打出每次工作流运行的节点执行记录包括 HTTP 请求的 URL、状态码、耗时。有些错误在画布上看不到完整堆栈但在容器日志里能找到 Python traceback。生产环境我把 Dify 的日志接入到了本地的 Loki方便后续检索历史运行记录。6. 从单机自用到团队协作Agent 策略、插件与多租户6.1 Agent 策略工作流之外的第二条腿Dify 里除了普通工作流还有一种叫 Agent 的玩法。它不是在画布上预设流程而是把工具交给 LLM 自己决定调用顺序。你给它一堆工具搜索、知识库、内部 API模型根据自己的推理一步步调用。Dify 的 Agent 节点支持多种策略比如 ReAct 和 Function Calling。我的判断是业务路径固定时优先用工作流路径开放、需要模型自主决策时用 Agent。比如“简历筛选”这种流程固定的场景用工作流“帮我查一下最近项目状态并写个总结”这种需要决定先查什么、再查什么的场景Agent 更合适。Dify 的 Agent 策略插件可以在插件市场里安装装完后在 Agent 节点里选择对应策略即可。6.2 插件安装先把“联网搜索”这类高频工具配好Dify 的插件体系把很多常用能力做成了独立包安装方式有两种插件页面搜索安装或者下载插件包手动上传。我这里最常用的是联网搜索插件和网页抓取插件。给 LLM 接上这些工具工作流就能获取实时信息不再只靠训练数据。插件安装有个注意点安装后要到“工具”列表里给插件配置 API Key比如搜索服务商、Google 搜索 API 等。不配置 Key 直接调用工具会返回鉴权失败。这在测试 Agent 流程时是一个很容易被忽略的坑。6.3 社区版 1.10 的多租户从个人项目到团队平台Dify 社区版 1.10 开始支持多租户这对团队内部共享平台很重要。在.env里开启多租户模式后管理员可以创建多个工作空间不同团队的数据、知识库、工作流互相隔离。我搭的内部平台就是用一个实例服务多个业务团队每个团队各自维护自己的知识库和工作流互不干扰。多租户模式下权限控制更敏感了。我给每个团队分配空间后还要注意工作流的“发布”权限和 API 访问密钥的管理。团队成员可以调试自己的流但发布到生产环境最好只有管理员能操作。Dify 这块在社区版里没有特别细的权限粒度我目前是靠“只给负责人管理员角色、其他人普通成员”来控制。6.4 最后说一句关于工作流复杂度的话我个人踩过不少坑之后的体会是工作流不是节点越多越好而是越清晰越好。一个能塞进一个 LLM 节点完成的事不要拆成三个一个能用 HTTP 节点解决的调用不要为了“看起来高级”去装一堆插件。Dify 的价值是让你把复杂的业务逻辑理清楚而不是把简单的事变复杂。画布上每多一个节点就意味着多一个调试点、多一处可能出错的位置。先画流程草图再动手拖节点是我现在搭任何工作流之前必做的一步——这个习惯帮我少踩了很多坑。本文还有配套的精品资源点击获取