Dify Workflow vs Chatflow 2026：你该建哪个？
Dify 里的 Chatflow 和 Workflow 看起来都是拖节点，行为却完全不同：一个记着上文，一个每次从零开始。选错不是改个开关能救的，图要重建。这篇给判断规则、节点差异和成本差别。
Dify Workflow vs Chatflow 2026：你该建哪个？
Dify 里新建应用时会让你选类型，Chatflow 和 Workflow 看起来都是拖节点连线，实际行为差得远：一个记着前面说过什么，一个每次从零开始。
选错的代价不小——Dify 不支持两种类型之间直接转换，图要重建。所以先花三十秒想清楚一件事：用户会不会追问。
一句话区别：状态
| Chatflow | Workflow | |
|---|---|---|
| 触发方式 | 用户在对话框里发消息 | 单次调用（API、按钮、定时） |
| 对话记忆 | 有，跨轮保留 | 无，每次运行独立 |
| 变量生命周期 | 会话变量跨轮持续 | 运行结束即销毁 |
| 输出形态 | 流式回答，可多段 | 一组结构化输出变量 |
| 适合 | 客服、助手、咨询、多轮任务 | 摘要、分类、抽取、批处理、路由 |
| 调试难度 | 高，状态会互相影响 | 低，输入确定输出可复现 |
| token 成本 | 每轮重发历史，随轮次增长 | 单次，可预估 |
Chatflow：给会追问的场景
典型特征：用户第一句说"帮我看看这份合同有什么风险"，第二句说"第三条再详细说说"。第二句里的"第三条"只有在记得上文时才有意义。
Chatflow 提供的配套能力都围绕这个：会话变量（跨轮保存用户身份、已确认的参数）、记忆窗口（保留最近 N 轮）、回答节点（可以分多段流式输出）、消息内的追问按钮。
建 Chatflow 的判断标准：
- 用户需要补充信息、改口、追问细节
- 流程里存在"先问清楚再执行"
- 需要多轮才收集完的参数（比如先问城市再问日期）
它的隐性成本是 token：每一轮都要把历史消息重新发给模型，聊到第十轮，输入可能是第一轮的好几倍。控制手段是缩短记忆窗口、把稳定信息放进系统提示词、把长文档放进知识库而不是塞进历史。
Workflow：给一次进一次出的场景
典型特征：输入一份 PDF，输出摘要和三个关键条款；或者输入一条客服消息，输出分类标签和路由目标。用户不需要和它对话，调用方是程序或按钮。
Workflow 的节点集更偏工程：开始节点定义输入变量、结束节点定义输出变量、HTTP 请求节点调外部接口、代码节点做数据变形、条件分支做路由、迭代节点处理数组。
它的好处是可测试：同样的输入应该得到相近的输出，能写自动化用例，能接 CI，出问题能定位到具体节点。
决策规则
问自己三个问题，任何一个答"是"就选 Chatflow：
- 用户会不会追问上一句的内容？
- 流程中是否需要向用户确认或索要参数？
- 输出是否需要边生成边展示给用户看？
三个都答"否"，选 Workflow。这时候用 Chatflow 只会让成本上升、行为不可预测。
一个常见的误判：「客服机器人」听起来像自动化流程，实际十有八九是 Chatflow，因为客户一定会追问。
那些真会咬人的差异
| 差异点 | Chatflow | Workflow | 影响 |
|---|---|---|---|
| 变量作用域 | 会话变量跨轮持久 | 运行内有效 | 想在 Workflow 里"记住上次"是做不到的 |
| 直接回答节点 | 可用，支持流式分段 | 不可用，只能靠结束节点输出 | 想边生成边显示，Workflow 做不到 |
| 迭代/循环 | 支持但要注意上下文膨胀 | 支持，更适合批处理 | 大批量数据处理放 Workflow |
| 并发 | 每个会话独立跑，资源占用随会话数上升 | 单次运行，易横向扩 | 高并发场景 Workflow 更省 |
| 版本与发布 | 改动影响线上会话体验 | 可灰度，可回滚 | 生产环境优先 Workflow |
混合架构：两个都要的时候
有一种情况会同时需要：对话式入口 + 确定的处理流程。做法是把 Workflow 当成工具，让 Chatflow 调用：
- Chatflow 负责接待、澄清需求、收集参数
- 参数齐了，调用一个 Workflow 应用（Dify 支持跨应用调用）做实际处理
- 结果回到 Chatflow，用自然语言呈现
这样对话的灵活性归 Chatflow，业务逻辑的确定性归 Workflow，两边都能单独测试。
常见问题
Q：建错了能转吗？ A：不能直接转换，节点图要重建。这也是为什么值得在动手前先答那三个问题。可以先在 Workflow 里把逻辑跑通，再搬到 Chatflow 里加对话层。
Q：哪个更便宜？ A：Workflow。Chatflow 每轮重发历史，轮次越多差距越大。客服类应用如果对话很长，记得限制记忆窗口。
Q：Workflow 能实现多轮吗？ A：不能真正多轮。你可以在外部保存状态、每次调用时把状态作为输入传进来，但那是在 Workflow 外面做会话管理，不如直接用 Chatflow。
Q：哪个更适合做 RAG？ A：都支持知识检索节点。区别在交互：需要追问细节的知识库问答用 Chatflow；一次问一次答、要接进别的系统的用 Workflow。
Q：能接本地模型吗？ A：能，模型供应商里配 Ollama 或任何 OpenAI 兼容端点即可。注意 Chatflow 对模型的指令遵循要求更高，小模型容易忘记格式约束。
Q：发布成 API 有区别吗？ A：Chatflow 的 API 是对话式（带 conversation_id），Workflow 的 API 是一次请求一次响应。接第三方系统时，Workflow 的接口形态通常更好对接。
注：Dify 的节点集与 API 形态随版本迭代，具体能力以官方文档当前版本为准。
相关文章
❓ 常见问题
Can I convert between them?
No direct conversion - you rebuild the graph. Pick right the first time.
Which is cheaper?
Workflow - single-shot means no history re-sends.
Can a Workflow call a Chatflow?
Yes - Dify allows cross-app calls, so automation can invoke conversational apps.
Which is better for RAG?
Both support knowledge bases; Chatflow keeps the conversational follow-ups that RAG chat usually needs.
本站文章由编辑人工撰写，收录的工具均经过实测或公开资料核验。文中链接指向工具官网或 GitHub 仓库，仅作信息参考，不构成付费推广。