我不止一次在社群里看到有人问：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 当成两个需要较劲选边的技术栈，它们更像是你工具箱里的钳子和螺丝刀——钳子能夹能拧，螺丝刀也能撬能刮，但真正做项目时你会自然而然地选更顺手的那个。判断标准就是看业务有没有"多轮交互"和"会话上下文"的需求。顺着这个思路去选，再配合今天给的节点配置和调优细节，你大概率能少走很多弯路，直接把应用跑到能稳定上线。
