企业官网建设流程全解析

Chatflow 和 Workflow 是两种骨架：从 Dify 官方资料看“对话型”与“批处理型”应用的节点、记忆与变量差异

聊 Dify 选型的时候，很多讨论一上来就纠结“该用 Workflow 还是 Agent”。但真正动手搭应用之前，其实还有一层更靠前的分叉经常被跳过——应用类型。Dify 的工作流本身就分 Chatflow 和 Workflow 两种，它们不是同一根骨架的两种皮肤，而是从结束节点、记忆机制到开始节点的内置变量都不同的两套设计。选错骨架，后面编排节点时会处处别扭。

这篇文章依据《一文入门智能体：dify 超快速构建AI agent - 知乎》和 Dify 官方站点的公开资料，把这些容易被忽略的差异整理成一张对照表，帮你在动手前把第一层选型想清楚。

一、为什么“应用类型”是选型的第一层分叉

Dify 官方资料对工作流的基本定位是：通过将复杂任务分解成较小的步骤（节点），降低系统复杂度，减少对提示词技术和模型推理能力的依赖，从而提高 LLM 应用面向复杂任务的性能，并提升系统的可解释性、稳定性和容错性。

而 Dify 明确把工作流分成两类，知乎这篇入门文也原文引用了同样的划分：

• Chatflow：面向对话类情景，包括客户服务、语义搜索，以及其他需要在构建响应时进行多步逻辑的对话式应用程序。
• Workflow：面向自动化和批处理情景，适合高质量翻译、数据分析、内容生成、电子邮件自动化等应用程序。

关键区别在于交互路径。知乎资料给出了两种典型路径：

• Chatflow：给出指令 → 生成内容 → 就内容进行多次讨论 → 重新生成结果 → 结束
• Workflow：给出指令 → 生成内容 → 结束

也就是说，Chatflow 的产物是可以被“接着聊”的——用户可以针对上一轮结果反复调整；而 Workflow 的产物是一次性交付的，无法对结果进行多轮对话交互。一个交付的是“持续的对话体验”，一个交付的是“一次跑完的结果”。这个本质差别，直接决定了下面所有节点层面的设计差异。

二、应用类型—能力对照表

下面把表里最容易踩坑的几行展开说。

三、三个容易被忽略的设计差异

1. Answer 与 End：不只是名字不同

根据知乎资料的归纳：End 节点属于 Workflow 的结束节点，仅可在流程结束时选择；而 Answer 节点属于 Chatflow，用于流式输出文本内容，并且支持在流程中间步骤输出。

这个差异的实际意义很大。如果你在做一个客服类 Chatflow，可以让用户先看到“正在检索知识库”的中间反馈，再看到最终回答——因为 Answer 节点可以插在流程中途流式吐文本。而在 Workflow 里，你只能把所有结果攒到最后，通过唯一的 End 节点一次性交付。做批处理任务时这反而干净利落；但如果你想用它做一个需要边跑边反馈的对话应用，就会发现骨架不支持。

2. Memory：Chatflow 内置，Workflow 没有

知乎资料明确指出：Chatflow 内置聊天记忆（Memory），用于存储和传递多轮对话的历史消息，可在 LLM、问题分类等节点内开启；而 Workflow 无 Memory 相关配置，无法开启。

这不是配置技巧问题，而是架构差异。多轮对话要“接得住上下文”，前提是系统里有人负责存历史消息——Chatflow 把这件事内置了，你只需在具体节点决定要不要开启。而 Workflow 没有这个机制，因为它的设计场景本来就是单次触发、单次结束的批处理，没有“上一轮”可言。所以别指望在 Workflow 里通过什么开关补出对话记忆，做不到就是做不到。

3. 开始节点的内置变量：有没有sys.query和sys.conversation_id

知乎资料列出的差异很具体：

• Chatflow 开始节点内置变量：sys.query、sys.files、sys.conversation_id、sys.user_id
• Workflow 开始节点内置变量：sys.files、sys.user_id

注意少了什么：Workflow 里没有sys.query，也没有sys.conversation_id。sys.query是用户的对话输入，sys.conversation_id是对话会话的标识——这两个变量之所以只存在于 Chatflow，正是因为只有对话型应用才有“用户这句话”和“这段会话”的概念。批处理型应用的输入来源是文件（sys.files）和用户身份（sys.user_id），逻辑上是自洽的。如果你在编排 Workflow 时发现取不到用户输入文本，先别怀疑自己的操作，检查一下应用类型。

四、具体应用建议

什么情况选 Chatflow：

• 客服机器人、语义搜索这类需要用户反复追问、修正答案的场景。Chatflow 的交互路径支持“生成内容后多次讨论再重新生成”，加上内置 Memory 在 LLM、问题分类等节点可开启，天然适配多轮逻辑。
• 需要在回答过程中给用户中间反馈的场景，利用 Answer 节点可在中间步骤流式输出的特性。
• 需要按用户输入做路由的场景，sys.query和问题分类节点配合使用。

什么情况选 Workflow：

• 高质量翻译、数据分析、内容生成、电子邮件自动化等一次性完成、不需要跟用户来回讨论的任务。
• 输入以文件为主的处理管道，开始节点的sys.files变量直接可用。

判断口诀：问自己一句——“用户拿到结果之后，会不会还想接着聊？”会，用 Chatflow；不会，用 Workflow。

五、适用范围与局限

需要说明的是，本文的对照内容来源于知乎入门文对 Dify 的整理和 Dify 官方站点的产品介绍，属于对公开资料的梳理，而非笔者逐一实测的结论。Dify 作为开源项目（官方介绍其基于 Apache-2.0 协议，支持单条命令 Docker 部署，并包含完整的 Agent runtime 与 Workflow 编辑器）迭代较快，具体变量清单和节点行为可能随版本更新而变化，动手前建议以所用版本的官方文档为准。

另外，这张表只覆盖“应用类型”这一层分叉。选完类型之后，还有 Workflow 与 Agent 的组合方式（官方资料提到 agent 既可以独立使用，也可以作为 agent 节点加入工作流）、知识库接入等更细的选型问题，这些不在本文展开范围之内。

一句话总结：Chatflow 和 Workflow 是两种骨架，不是一个东西的两种叫法。先想清楚交付的是对话体验还是批处理结果，再动手编排节点，能省掉后面很多推倒重来的麻烦。

参考资料

以下链接为本文使用的公开资料。事实依据与检索摘录保存在本地记录中；资料内容与适用范围以原始页面为准。

• 一文入门智能体：dify 超快速构建AI agent - 知乎
• Dify - 构建生产级 AI 应用