我不止一次在社群里看到有人问Dify 里同时有 Chatflow 和 Workflow打开新建应用的时候两个按钮摆在一起到底该点哪个还有人说 Workflow 能做的东西Chatflow 好像也能做那为什么要分两种这个问题的迷惑程度几乎和RAG 和微调到底选谁一样高。我把这个事掰开揉碎讲一遍。Dify 作为一个开源的 LLM 应用开发平台它的核心价值就是让开发者用可视化画布把大模型能力编排起来而 Chatflow 和 Workflow 是它最基础、最常用的两种应用编排形态。简单讲Chatflow 是做对话应用的Workflow 是做自动化流程的。但光知道这句话还不够你得知道为什么这样设计、两者到底差在哪、实际项目里怎么选、每种流程里的节点怎么配才能真正跑起来。这篇文章我打算直接用做项目的思路来讲先拆概念再对比功能最后分别带你把一个 Chatflow 应用和一个 Workflow 应用从零搭出来再补充我在真实部署和调试过程中踩过的坑。不管你之前是已经用过 Dify 但还是不太分得清还是刚准备入门照着往下走基本都能跑通。1. 先搞清楚两件事Chatflow 和 Workflow 到底各管什么1.1 一个管聊一个管干Chatflow我把它理解成一个长了逻辑链的对话框。它保留了聊天的骨架应用启动后会先有一个聊天输入框用户发一句话进来这句话会被送入你在画布里编排好的流程流程处理完再通过聊天输出节点把结果返回给用户。整个过程是多轮、有状态、可中断的你可以随时追问、修正上下文会被记忆和引用。Workflow 就不一样了它不关心对话只关心任务。它的起点是一个 Start 节点终点是一个 End 节点中间是完整的数据加工链路。你给它一批输入参数它跑一遍输出一个结果这次运行结束。没有会话、没有上下文、没有追问它是一次性的流水线。如果想要批量处理靠的是外部系统反复触发或者在流程里加迭代循环而不是靠用户和机器一来一回地聊。所以最直白的判断标准是如果你的应用场景是用户在前面提问AI 在后面回答用 Chatflow如果你的场景是某条数据进来需要被清洗、分类、生成、汇总然后输出用 Workflow。1.2 为什么 Dify 要分两套而不是统一一套有人会问Chatflow 里也有 LLM 节点Workflow 里也有 LLM 节点节点能力基本重叠弄两套是不是重复答案是区分设计并非多余而是底层逻辑完全不同。Chatflow 的生命周期是多轮会话。它天然需要维护一个会话 ID需要把每一轮用户的消息和 AI 的回复都存起来下一轮提问时按需引用。为了做好这件事Dify 为 Chatflow 准备了专门的上下文管理机制、会话变量、对话历史变量、对话结束节点等能力。这些能力在 Workflow 里是没必要的——自动化流程不需要记住上一次运行发生了什么每次调用都是独立的一次。反过来看Workflow 的生命周期是一次性事务。它更关注完整业务逻辑的封装能不能被外部 API 稳定调用能不能作为批处理任务稳定执行能不能准确返回结构化的结果。所以 Workflow 设计了对外的 API 接口、系统运维能力更完善的独立运行窗口还可以直接被事件触发做成一个子流程供 Chatflow 或者其他流程来调用。这种刻意区分的架构本质上和你在代码里会拆命令模式和查询模式是一个道理状态化交互和无状态计算的需求边界不同强行合在一起反而会让流程复杂到没法维护。2. 其实像但细节差的真不少核心节点与能力对照2.1 起止方式不同后面所有逻辑都不一样你新建 Chatflow 应用的时候画布上默认会自带两个节点开始聊天输入和聊天输出。用户的每一个问题都会先被转成一个输入参数进入流程处理最后把结果写回聊天输出返回给前端。Workflow 新建的时候画布上默认带的是Start开始和End结束。Start 节点里可以自定义输入字段比如文件名、文档类型、用户 ID 之类的参数。End 节点负责把处理后的结果输出也可以选择输出结构化的 JSON方便对接下游系统。这里有一个很重要的差异点Chatflow 的输入是一段自由文本哪怕你在前面加了意图识别、问题分类这个思路也绕不开用户在输入框随便打字。Workflow 的输入则可以设计成严格的结构化字段更好约束业务边界。举个例子做一个朋友圈文案生成工作流入参可以设计成产品名称、卖点描述、目标人群三个字段系统拿到这三个字段后开始干活它不关心用户在某个聊天框里是怎么问的。这个差异会直接决定你搭流程的思维方式。用 Chatflow你会更偏向判断用户意图、动态路由、多轮澄清用 Workflow你会更偏向参数校验、任务分解、结果汇聚。2.2 功能节点的重合与分工两边都具备的核心处理能力是通用的比如LLM 节点调用大模型做生成、理解、推理支持提示词编排和变量引用。知识库检索节点连接知识库做向量检索或全文检索把命中的片段传给 LLM。条件分支IF/ELSE按条件把流程引向不同子路径。代码节点支持 Python 和 JavaScript处理复杂逻辑、数据清洗、格式转换。HTTP 请求节点调用外部接口把第三方系统拉进流程。变量赋值器用于修改上下文中的变量值控制分支走向。模板转换把数据拼成大模板文本适合准备提示词或生成格式化报告。迭代节点对列表数据逐个处理适合批量场景。问题分类器这个是 Chatflow 的专属增强节点可以让模型根据配置的分类器列表识别用户意图做路由分配。你不能说两边谁功能更全只能说针对各自的业务模型Dify 都给了足够的积木。选择哪套更关键是看你怎么组合这些积木。3. 动手做一个 Chatflow知识库问答助手全流程实录3.1 先明确需求我拿我自己做过的一个内部知识库问答机器人举例。需求其实不复杂公司内部有一个产品手册知识库员工在网页端输入问题机器人基于知识库内容回答回答不了就返回人工兜底提示。这种需求天然适合 Chatflow因为它的入口就是对话出口也是对话中间需要做检索、判断、多轮澄清。3.2 画布编排与节点配置第一步新建应用后选择 Chatflow。进入画布后我做的第一个节点是问题分类器。我把问题分成三类产品功能咨询、故障排查、其他问题。这个分类的意义在于下游处理策略不一样产品功能咨询走知识库检索加 LLM 生成故障排查先看知识库里有没有对应排查文档没有的话转人工其他问题直接走兜底回复。第二步接知识库检索节点。这里要注意检索节点不仅要选知识库还要配检索策略和 rerank 模型。我自己的经验是向量检索 TopK 召回只是第一步如果不做 rerank召回结果的准确率会低得让人头疼。Dify 里可以配置 rerank 模型服务把召回结果按相关性重排再截断到更合适的长度送进 LLM。第三步接条件分支。判断知识库检索结果的相关性得分是否超过阈值超过就进入 LLM 节点直接基于检索片段回答没超过就转去兜底回复。这个相关性阈值很关键阈值太高会导致很多问题明明知识库有答案却不回答阈值太低又会出现答非所问。我一般先设为 0.5然后拿真实问题跑一轮根据失败样本对应调整。第四步配置LLM 节点。模型我优先选性价比高的模型提示词里把知识库检索到的上下文内容作为一个变量注入并明确指示模型只能基于以下资料回答资料中没有明确信息时直接说明不知道不要编造。这一步是控制幻觉的关键很多新手忽略这个约束知识库问答的准确率自然上不去。第五步把结果接到聊天输出保存并发布。发布后还会有一个调试预览窗口右侧有一个带对话功能的调试环境可以直接在里面测试多轮对话效果。3.3 多轮上下文真正要用好必须配置会话变量这是 Chatflow 区别于 Workflow 最强的一点也是很多新手没用好的一点。在 Dify 的 Chatflow 里除了临时变量以外还有一类变量叫会话变量。会话变量在整个会话周期里有效跨多轮保留。举个例子用户在第一轮说我设备连不上网你通过问题分类器判定是故障排查这时候可以把用户设备类型这个值写入会话变量。第二轮用户说重试了还是不行你就能读取会话变量拿到设备类型直接进行更精确的检索和回答而不用再问一次用户设备型号。要做到这一步中间需要加一个变量赋值器节点把提取出的关键信息写进会话变量。第一次做的时候很容易掉进一个坑在 LLM 节点里明明看到了提取结果但下一步节点拿不到这个值就是因为只做了输出变量没有写入会话变量。两件事要同时做LLM 节点负责从自然语言里抽取结构化字段变量赋值器负责把抽取结果写入会话变量之后的所有节点才能跨轮读取。这里还要提醒一句如果会话变量配置了但没设置好默认值某些分支路径会因变量为空而报错。稳妥的做法是在画布里从入口接到第一个节点时先把所有可能用到的会话变量都赋一个默认空值后面再按需覆盖。3.4 调试与发布Dify 的调试面板是非常好用的排查工具。运行一次对话后点击运行详情你能看到流程里每个节点的输入、输出、耗时、token 消耗。排查为什么回答驴唇不对马嘴时先看知识库检索节点返回了什么内容再看 LLM 节点收到的提示词拼接结果是不是正确。我见过很多次问题不在模型而在提示词拼接时把检索片段漏掉了或者格式化错误导致模型没读到知识。发布后可以选择接入 Web App 的聊天组件或者用 API 把 Chatflow 应用接到自己的系统里。Chatflow 的 API 天然支持多轮会话只需要保持 Conversation ID 一致你就可以把应用嵌到网页、企业微信机器人或其他 IM 工具中。4. 反过来做 Workflow一条自动内容处理流水线的搭建过程4.1 选择 Workflow 的场景Workflow 的应用场景更偏自动化。我举个最常用的例子批量文章摘要和标签提取。你有一个内容库每天会进入上百篇新文章每篇都要生成摘要、提取标签、打上情绪倾向分类。这种需求如果用 Chatflow 来做会很别扭因为人工一篇篇去对话太慢。但用 Workflow 就能自动化输入文章正文输出摘要、标签、分类、发稿建议整体跑完不到一分钟。4.2 从 Start 定义输入我新建 Workflow 后第一步是配置 Start 节点的输入字段。我需要两个字段一个是title字符串一个是content文本段落。这两个字段会被应用的外部调用方传递进来比如你写个 Python 脚本调 Dify 的 Workflow API每次请求把一篇文章数据传过来。在设计入参的时候我会刻意想清楚所需的数据类型。如果后续要对列表做批量处理我甚至会设置一个数组类型的入参然后在流程里用迭代节点来逐个打开处理。入参设计越贴近真实业务结构后面写代码节点就越轻松。4.3 用 LLM 节点做摘要再用代码节点做 JSON 清洗流程的核心是三个 LLM 节点并行处理摘要生成、标签提取、情绪分类。摘要生成我给了一个比较严格的提示词要求模型用不超过 200 字总结文章风格客观中性不夹带评价。标签提取我要求模型输出格式为 JSON 数组比如[AI, Dify, 自动化]。情绪分类则要求模型输出一个枚举值比如积极/中性/消极三选一。但这里有一个大坑模型的输出并不总是一个合法的 JSON。由于温度、模型稳定性的原因模型可能会在 JSON 前后夹带正常语言或直接不闭合花括号。所以我在每个 LLM 节点之后都加了一个代码节点写一段简单的 Python 或 JavaScript 来清洗并解析。代码节点里我做的是用正则把 JSON 片段的起始位置[或{找出来截取子串再用json.loads解析解析失败就返回一个预设兜底值。这个过程能避免后面 End 节点返回解析失败而整条流水线崩掉。4.4 End 节点输出与外部调用流程最后汇总到 End 节点。End 输出有两种形式直接文本输出或结构化 JSON 输出。做自动化集成时请不要用文本输出尽量用结构化 JSON这样外部系统接起来最方便。我会把所有字段放进一个data字段里然后 End 节点选择 JSON 格式返回完整结构。发布之后你可以在访问 API菜单里找到对应 Endpoint用 Postman 或者 curl 就能直接调用。拿它的响应数据来做后续入库、发版、推送都是很容易的事情。如果你用 Dify 社区版自部署跑了多个 Workflow 应用还可以在工具里把某些 Workflow 添加成一个工具供 Chatflow 调用。比如我上面做的摘要工作流后期就被我直接在另一个客服机器人里当成工具来调用。这种嵌套编排是纯写代码时很难获得的灵活度。5. 选择和调优过程中最容易踩的坑以及我的排查方法5.1 选错流程类型的后果最典型的新手错误是想做一个对话机器人却选了 Workflow导致前面没有聊天输入框用户无法维持多轮对话。反过来想把自动化流水线做成 Chatflow却发现每次跑完都要有一个用户提问才能触发上下文还一直在累积数据结果也变得难以用 API 稳定复用。所以最初的决定非常关键。我的选择习惯可以总结成一句话先想谁触发和怎么结束。如果是用户主动发起、有来有回Chatflow如果是系统发起、一次拉倒Workflow。这个判断能解决 90% 的纠结。5.2 知识库检索效果不好先调相关性阈值和重排我在 Chatflow 里聊过检索评分阈值的问题这里再补充一个细节如果你的知识库准确率一直上不去不一定是模型的问题很可能是召回环节的问题。最基础的调整是按下面顺序排确认知识库分段是否合理分段过大语义会被稀释分段过小语义不完整检索容易漏召回。确认是否配置了 rerank 模型。不配 rerank就好像搜索引擎只做了初选不做精排效果很难保证。调相关性阈值拿测试集跑一遍记录因为低于阈值被拦截的正确答案比例。换嵌入模型或者改进分段策略——比如 Markdown 格式的文档可以按标题切分保留文档结构信息。我一般不会一上来就换模型那是最贵也最费事的一步。先做前三个优化准确率往往就能上一个台阶。5.3 调试日志的使用方式Dify 的调试日志不只是用来看一眼报错信息我更推荐把它当成流程回归测试工具。做法是建一个固定测试用例集合每次修改完流程后都把这些用例跑一遍打开运行详情逐节点检查输出。特别要关注节点之间的数据传递格式是否变化。比如代码节点里输出的是一个对象后面模板转换节点引用的字段路径如果写错了整个流程就会卡住。这种错误在单次调试里很常见遇到后不要只修当前路径要回到起点看这个变量上游到底传来的是什么结构。还有一个排查技巧在关键分支前加一个临时的模板转换节点把当前流程里的关键变量打印出来然后再接一个 HTTP 或代码节点把结果输出到日志里。这比反复刷新页面去猜中间状态要高效得多。5.4 聊聊自部署里两个高频问题镜像拉取失败和更新版本除了画布里的逻辑问题Dify 本地部署和使用过程中还有两个出现频率特别高的问题和 Chatflow/Workflow 本身无关但会影响你整个平台的使用体验。第一个是镜像拉取失败。Dify 采用容器化部署启动时需要从镜像仓库拉取多个组件镜像。如果你所在网络环境访问外网不稳定镜像下载经常会卡住或者超时。遇到这种问题先检查 docker 是否能正常拉取 Docker Hub 的镜像。如果拉不动可以给 Docker 配置镜像加速器。配置完成后再到 Dify 项目目录下重新执行docker compose up -d它会自动检查本地镜像缺失的镜像会重新拉取已经下载好的不会重复下载。第二个是更新版本。Dify 社区版迭代很快升级前务必先备份数据库和存储目录。我在升级几个版本时试过直接拉最新代码然后重启容器结果发现数据库结构有变更旧数据不兼容。正确做法是先看官方的 Release 说明确认是否需要执行数据库迁移再停止旧容器拉取新代码执行迁移再启动新容器。升级完成后检查应用市场里的插件、工具、模型供应商是否都重新连接成功特别是模型供应商的 API Key 有没有因为环境变量变化而丢失。不过要注意Dify 版本更新属于平台级操作如果你对自己的数据有很强依赖建议先在测试环境验证一遍再上生产。5.5 Chatflow 和 Workflow 配合使用的一个高阶玩法最后分享一个我最近在用的模式把 Chatflow 作为交互入口把 Workflow 作为后台执行体两者通过工具节点串起来。场景是这样的我做一个客服助手用户在对话里要求帮我查一下订单状态。Chatflow 负责理解用户意图从对话里抽取出订单号然后调用一个 Workflow 工具这个 Workflow 负责请求内部订单系统接口、拿到原始 JSON、清洗字段、组装回复内容。Chatflow 拿到 Workflow 返回的结构化数据后用 LLM 生成口语化的回复。这样做有两个明显好处第一订单查询逻辑被封装成独立 Workflow可以被其他应用复用第二Chatflow 的画布保持简洁对话逻辑和业务逻辑解耦。改订单系统的接口字段只需要动 Workflow不用大改 Chatflow。搭建时注意把 Workflow 添加为工具后工具输入参数的名称必须和 Workflow Start 节点的参数名一一对应。如果参数名对不上Chatflow 调用时就会出现传参失败调试日志里却不会提示得那么明确只能自己一个一个比对。我第一次做这个接口对接时就卡在这个地方后来仔细排查才发现是某个参数名差了一个下划线。这可能是 Dify 使用中比较进阶的场景了。等你把单个应用玩熟以后再尝试这种嵌套编排对整体架构的理解会有一个质的提升。我个人在实际使用过程中的体会是别把 Chatflow 和 Workflow 当成两个需要较劲选边的技术栈它们更像是你工具箱里的钳子和螺丝刀——钳子能夹能拧螺丝刀也能撬能刮但真正做项目时你会自然而然地选更顺手的那个。判断标准就是看业务有没有多轮交互和会话上下文的需求。顺着这个思路去选再配合今天给的节点配置和调优细节你大概率能少走很多弯路直接把应用跑到能稳定上线。