Dify工作流→变量系统的结构化总结

在低代码AI开发领域，Dify的工作流节点系统算得上是真正意义上的破局者。它将那些原本需要大量手工编码的复杂任务，拆解成一个个可编排的智能单元——从简单的对话机器人，到需要多步逻辑的企业级自动化流程，几乎都能用这套思路搞定。说白了，就是用可视化的方式，把AI能力变成了搭积木。

Dify 中提供了五种应用类型：

• 聊天助手
  ：基于 LLM 构建对话式交互的助手

• 文本生成应用
  ：面向文本生成类任务的助手，例如撰写故事、文本分类、翻译等

• Agent
  ：能够分解任务、推理思考、调用工具的对话式智能助手

• 对话流
  ：适用于定义等复杂流程的多轮对话场景，具有记忆功能的应用编排方式

• 工作流
  ：适用于自动化、批处理等单轮生成类任务的场景的应用编排方式

这五种类型各有各的用武之地，不过在实际开发中，最常让人纠结的，其实是对

和的选择。下面咱们就把这两者掰开揉碎聊一聊。

Dify 工作流分为两种类型：

• Chatflow
  ：
  适用场景面向对话类情景，包括客户服务、语义搜索，以及其他需要在构建响应时进行多步逻辑的对话式应用程序。这类应用最大的特点，就是支持对生成的结果进行多轮对话交互，说白了，你可以在生成结果之后继续跟它“讨价还价”，调整最终输出。

常见的交互路径：给出指令 → 生成内容 → 就内容进行多次讨论 → 重新生成结果 → 结束

• Workflow
  ：
  面向自动化和批处理情景，适合高质量翻译、数据分析、内容生成、电子邮件自动化等应用程序。它的特点是“一条路走到黑”——你给指令，它生成结果，对话就结束了，不支持来回修改。

常见的交互路径：给出指令 → 生成内容 → 结束

下述 Dify 变量系统的结构化对比：

无论是 Chatflow 还是 Workflow，都是由一个个独立节点构成的。每个节点有自己的输入和输出，但输入项各不相同，输出的内容也五花八门。这就带来一个问题：

答案是

。变量就像是一个容器，可以存储并传递不固定的内容，在各个节点之间被相互引用，实现信息的灵活通信。没有变量，节点之间就是一座座信息孤岛。

系统变量

系统变量是 Dify 在 Chatflow / Workflow 应用内预设好的全局参数，所有节点都可以读取。系统级变量统一以 sys 开头。

Workflow

Workflow 类型应用提供以下系统变量：

变量名称	数据类型	说明	备注
sys.files [LEGACY]	Array[File]	文件参数，存储用户初始使用应用时上传的图片	图片上传功能需在应用编排页右上角的 “功能” 处开启
sys.user_id	String	用户 ID，每个用户在使用工作流应用时，系统会自动向用户分配唯一标识符，用以区分不同的对话用户
sys.app_id	String	应用 ID，系统会向每个 Workflow 应用分配一个唯一的标识符，用以区分不同的应用，并通过此参数记录当前应用的基本信息	面向具备开发能力的用户，通过此参数区分并定位不同的 Workflow 应用
sys.workflow_id	String	Workflow ID，用于记录当前 Workflow 应用内所包含的所有节点信息	面向具备开发能力的用户，可以通过此参数追踪并记录 Workflow 内的包含节点信息
sys.workflow_run_id	String	Workflow 应用运行 ID，用于记录 Workflow 应用中的运行情况	面向具备开发能力的用户，可以通过此参数追踪应用的历次运行情况

Chatflow

Chatflow 类型应用提供以下系统变量：

变量名称	数据类型	说明	备注
sys.query	String	用户在对话框中初始输入的内容
sys.files	Array[File]	用户在对话框内上传的图片	图片上传功能需在应用编排页右上角的 “功能” 处开启
sys.dialogue_count	Number	用户在与 Chatflow 类型应用交互时的对话轮数。每轮对话后自动计数增加 1，可以和 if-else 节点搭配出丰富的分支逻辑	例如到第 X 轮对话时，回顾历史对话并给出分析
sys.conversation_id	String	对话框交互会话的唯一标识符，将所有相关的消息分组到同一个对话中，确保 LLM 针对同一个主题和上下文持续对话
sys.user_id	String	分配给每个应用用户的唯一标识符，用以区分不同的对话用户
sys.app_id	String	应用 ID，系统会向每个 Workflow 应用分配一个唯一的标识符，用以区分不同的应用，并通过此参数记录当前应用的基本信息	面向具备开发能力的用户，通过此参数区分并定位不同的 Workflow 应用
sys.workflow_id	String	Workflow ID，用于记录当前 Workflow 应用内所包含的所有节点信息	面向具备开发能力的用户，可以通过此参数追踪并记录 Workflow 内的包含节点信息
sys.workflow_run_id	String	Workflow 应用运行 ID，用于记录 Workflow 应用中的运行情况	面向具备开发能力的用户，可以通过此参数追踪应用的历次运行情况

环境变量

环境变量的作用很直接——保护敏感信息。比如运行工作流时需要用的 API 密钥、数据库密码等，都适合放在环境变量里。它们被存储在工作流内部，而不是写在代码中，这样在不同环境间共享时也更安全。

：

• String 字符串
• Number 数字
• Secret 密钥

：

• 环境变量可在大部分节点内全局引用；
• 环境变量命名不可重复；
• 环境变量为只读变量，不可写入；

会话变量

会话变量面向多轮对话场景，而 Workflow 类型应用的交互是线性而独立的，不存在多次对话交互的情况，因此会话变量仅适用于 Chatflow 类型（聊天助手 → 工作流编排）应用。

• 会话变量
  允许应用开发者在同一个 Chatflow 会话内，指定需要被临时存储的特定信息，并确保在当前工作流内的多轮对话内都能够引用该信息，如上下文、上传至对话框的文件（即将上线）、用户在对话过程中所输入的偏好信息等。可以把它想象成给 LLM 准备的一个“备忘录”——随时可以翻看，避免因为记忆出错导致回答跑偏。

举个例子：用户在首轮对话时输入了语言偏好（比如“请用英文回答”），你可以把这个偏好存进会话变量里。后续几轮对话中，LLM 在回答时都会参考这个变量，自动使用指定语言回复用户。

：

• String 字符串
• Number 数值
• Object 对象
• Array[string] 字符串数组
• Array[number] 数值数组
• Array[object] 对象数组

：

• 会话变量可在大部分节点内全局引用；
• 会话变量的写入需要使用变量赋值节点；
• 会话变量为可读写变量；

• 为避免变量名重复，节点命名不可重复；
• 节点的输出变量一般为固定变量，不可编辑。