Dify Workflow 概述
Dify 是一个面向大语言模型应用开发的平台，其 Workflow 功能通过可视化编排方式，将大语言模型、知识库、外部工具以及业务逻辑整合为可执行的自动化流程。Dify Workflow 会把复杂的 AI 应用拆分为多个职责明确的处理节点，再通过节点之间的连接关系控制任务执行顺序和数据流向，从而实现结构化、可复用的 AI 应用开发。
传统的大语言模型应用通常采用单次 Prompt 调用处理用户请求。这种方式虽然能完成文本生成、信息提取和问答等任务，但模型需要在一次调用中同时完成任务理解、业务判断和结果生成。当业务逻辑逐渐复杂时，单次模型调用容易出现步骤遗漏、结果格式不一致以及执行过程难以控制等问题。
Dify Workflow 通过显式定义任务执行步骤，将复杂任务拆分为相互独立的处理单元。开发者可以分别配置模型调用、知识检索、条件判断、代码处理和外部 API 请求，并通过变量传递实现节点间的数据交互。这样一来，AI 应用具备更清晰的执行逻辑，也为后续调试、维护和性能优化提供了基础。
Workflow 与 Chatflow 的区别
Dify 提供 Workflow 和 Chatflow 两种主要的流程编排应用类型。两种应用共享可视化画布和节点系统，但在交互模式、执行方式以及上下文管理方面存在明显区别。
Workflow 主要面向一次性任务处理和自动化执行场景。 Workflow 在接收到输入数据后，按照预先定义的节点关系完成任务，并返回指定处理结果。不同 Workflow 调用之间默认不保留会话状态，因此 Workflow 适合文档处理、自动报告生成、数据分析、批量任务执行以及业务系统集成等场景。
Chatflow 主要面向需要多轮交互的对话式应用。 Chatflow 在每次接收到用户消息时执行对应的处理流程，并通过会话上下文维持连续交互。Chatflow 可以利用会话变量和模型记忆管理历史信息，因此更适合智能客服、交互式问答助手以及需要持续维护用户状态的应用。
两种应用的输出方式也存在差异。Workflow 使用输出节点将变量返回给调用方，而 Chatflow 使用直接回复（Answer）节点生成面向用户的消息。Workflow 还支持定时、Webhook 和集成事件等触发方式，Chatflow 则由用户消息启动。
Dify Workflow 的设计原理
基于节点的流程编排
Dify Workflow 采用节点式编排机制。工作流中的每个节点负责执行特定操作，节点之间通过连线建立执行依赖关系。节点接收来自上游的输入变量，在完成自身逻辑后生成输出变量，并将处理结果提供给下游节点。
一个典型的工作流通常包含输入、数据处理、逻辑控制和结果输出等环节。输入节点负责接收任务参数，处理节点负责执行模型推理或数据转换，逻辑控制节点负责决定后续执行路径，输出节点负责向外部应用返回结果。
工作流的基本执行链路可以表示为：用户输入 → 数据预处理 → 业务逻辑判断 → 模型或工具执行 → 结果格式化 → 输出
Dify 的可视化画布将这些环节组织为明确的执行路径。开发者可以根据任务复杂度增加处理节点、构建条件分支或嵌套重复执行逻辑，而不需要把所有业务规则集中塞进单个 Prompt 中。
基于变量的数据传递
变量机制是 Dify Workflow 实现节点协作的基础。Dify 将节点输入、节点输出以及工作流运行过程中产生的数据组织为不同类型的变量，使下游节点能够直接引用上游节点的处理结果。
Dify 支持字符串、数字、布尔值、对象、文件以及数组等数据类型。变量类型决定了数据的组织方式，也影响下游节点能否正确使用对应的数据。
例如，一个邮件处理工作流可以在开始节点定义 customer_name 和 email_content 两个输入变量。其中，customer_name 使用字符串类型保存客户名称，email_content 使用长文本字段保存邮件原文。后续 LLM 节点可以引用这两个变量生成邮件回复，而输出节点可以将模型生成的 text 映射为 email_reply，作为工作流的最终输出。
Dify 在提示词、模板和部分节点配置中支持 {{variable_name}} 形式的变量引用。变量引用在运行时会被实际数据替换，因此相同的工作流能够针对不同输入执行统一的处理逻辑。
工作流设计需要特别关注变量名称、数据类型和可访问范围。变量名称应保持清晰且具有业务语义，节点输出应与下游节点的输入要求一致。对于需要跨越多个节点传递的数据，开发者应尽量采用结构化对象或明确的字段定义，避免下游节点重复解析非结构化文本。
串行执行与并行执行
Dify Workflow 支持串行和并行两种节点执行方式。
- 串行执行要求节点按照依赖关系依次运行。下游节点需要等待上游节点完成处理后才能开始执行，因此串行模式适合存在明确数据依赖的任务。例如，知识检索节点需要先返回相关文档，LLM 节点才能基于检索结果生成回答。
- 并行执行允许多个不存在直接依赖关系的分支同时运行。并行模式适合多来源数据查询、多维度文本分析以及独立子任务处理。多个并行分支可以在执行完成后将各自结果提供给共同的下游节点，但并行分支之间不能直接引用彼此尚未产生的输出。
并行执行能够降低相互独立任务的总体等待时间，但它并不适用于所有业务逻辑。开发者需要根据数据依赖关系决定节点的执行方式，并对模型并发调用、外部服务限制以及资源消耗进行评估。
确定性逻辑与模型推理的分离
Dify Workflow 的核心设计原则之一，是将确定性逻辑与非确定性的模型推理进行分离。LLM 节点适合处理语义理解、文本总结、内容生成以及复杂自然语言分析。条件分支、代码、模板转换等节点则适合处理可以通过明确规则实现的判断、计算与格式化操作。
这种职责划分可以减少不必要的模型调用。例如，固定格式的邮件署名不需要由 LLM 每次重新生成，模板转换节点即可稳定完成排版。类似地，数值比较和字段是否为空等规则判断可以直接使用 If-Else 节点，而无需依赖模型进行推理。
工作流通过这种混合编排方式，将模型的语义处理能力与确定性程序逻辑结合起来，从而提高执行结果的一致性与可控性。
Dify Workflow 核心节点详解
Dify Workflow 提供多种节点类型。不同节点分别承担输入输出、模型推理、数据处理、逻辑控制、外部系统集成以及流程管理等职责。
开始节点（Start Node）
开始节点负责定义工作流的入口和初始化输入。Dify Workflow 支持用户输入和触发器两种启动方式。
用户输入节点允许开发者定义文本、数字、文件等输入字段。用户或外部 API 调用方可以在启动工作流时传入对应的数据，节点随后将输入内容转换为可供下游引用的变量。
触发器节点负责在特定条件满足时自动启动工作流。Dify 支持定时触发器、Webhook 触发器和集成触发器。定时触发器适合周期性报告生成，Webhook 触发器适合接收外部 HTTP 请求，集成触发器适合响应外部系统事件。
开始节点的设计需要明确输入数据的类型、必填要求和业务含义。输入字段的定义会直接影响后续节点的变量引用和流程配置。
大语言模型节点（LLM Node）
LLM 节点负责调用大语言模型完成自然语言处理任务。该节点是 Dify Workflow 实现语义理解、内容生成与智能分析的主要组件。
LLM 节点允许开发者选择已配置的模型供应商和具体模型，并设置 Temperature、Top P 等生成参数。Temperature 主要影响模型输出的随机性，较低的参数通常适合信息提取和规范化输出，较高的参数可以用于需要一定创造性的内容生成任务。
LLM 节点通过 Prompt 定义模型的执行目标和行为约束。对于聊天模型，开发者可以使用 System、User 等消息角色区分系统级任务指令和动态用户输入。System Prompt 通常定义模型角色、业务规则、输出限制和异常处理要求，User Prompt 则通过变量引用传入实际任务数据。
LLM 节点还支持上下文变量和结构化输出。上下文变量可以接收知识检索结果，使模型基于外部资料进行回答。结构化输出可以通过 JSON Schema 定义字段名称、类型及约束，便于后续代码节点、条件分支节点和外部接口直接处理模型结果。
对于生产级工作流，LLM 节点还需要配置适当的错误处理策略。模型调用可能受到请求限制、超时以及外部服务异常等因素影响，因此重试、错误分支和替代模型等机制可以提高工作流的运行稳定性。
知识检索节点（Knowledge Retrieval）
知识检索节点负责从 Dify 知识库中获取与查询相关的信息。该节点通常与 LLM 节点共同构建检索增强生成（Retrieval-Augmented Generation，RAG）流程。
RAG 将知识检索与文本生成划分为两个阶段。知识检索节点首先根据用户问题查询知识库，并返回相关文档片段；LLM 节点随后将检索结果作为上下文，结合用户问题生成回答。
知识检索节点支持配置查询变量、知识库范围以及检索策略。开发者可以通过 Top K 控制返回结果数量，通过 Score 阈值过滤相关性较低的内容，通过 Rerank 模型对候选文档进行重新排序。知识库元数据过滤还可以进一步缩小检索范围。
知识检索节点通过 result 变量返回包含文档片段和相关元数据的数组。LLM 节点可以在上下文配置中绑定该变量，并通过 Prompt 明确要求模型依据检索资料回答。
RAG 架构能够降低模型依赖参数化知识回答业务问题的风险，但检索机制并不能完全消除模型幻觉。工作流仍然需要处理检索为空、信息冲突以及证据不足等情况，并为模型定义适当的拒答或降级策略。
条件分支节点（If-Else）
If-Else 节点负责根据明确的判断条件决定后续执行路径。该节点提供 IF、ELIF 和 ELSE 等分支结构，并支持通过多个条件组合构建业务规则。
条件分支节点可以执行字符串包含判断、数值比较、变量为空检查以及布尔逻辑运算。开发者还可以使用 AND 和 OR 关系组合多个判断条件。
例如，邮件处理工作流可以检查 email_content 是否包含指定产品名称。当条件成立时，工作流进入产品知识检索分支；当条件不成立时，工作流进入通用邮件处理分支。
If-Else 节点适合处理判断规则清晰的业务逻辑。规则判断由节点配置直接执行，因此该节点通常不需要额外调用大语言模型。
问题分类器节点（Question Classifier）
问题分类器节点负责对输入文本进行语义分类，并将任务路由到对应的执行分支。
问题分类器与 If-Else 节点的主要区别在于判断方式。If-Else 节点依赖明确的比较条件，而问题分类器依赖大语言模型理解文本语义，并根据预先定义的分类描述选择最匹配的类别。
开发者可以为问题分类器配置分类名称、分类描述以及分类模型。例如，智能客服系统可以定义产品咨询、售后支持、故障反馈和其他问题等类别。问题分类器随后根据邮件内容选择相应分支，使不同业务类型使用独立的知识库和处理逻辑。
问题分类器适合自然语言表达复杂、关键词规则难以完整覆盖的任务。分类准确性取决于模型能力和类别边界定义，因此开发者需要通过明确的分类描述和测试样本减少类别混淆。
参数提取器节点负责将非结构化文本转换为结构化数据。该节点通常使用大语言模型识别文本中的实体、字段和业务参数，并按照预先声明的数据结构返回结果。
参数提取器支持字符串、数字、布尔值、数组以及对象等参数类型。开发者需要配置输入变量、提取模型、参数名称、字段类型和字段描述，并通过提取指令进一步限定处理规则。
例如，客户邮件可能包含多个独立问题。参数提取器可以将邮件内容解析为 question_list 数组，并将每一个问题保存为独立的字符串元素。后续迭代节点即可基于该数组对问题进行逐项处理。
参数提取器还提供 __is_success 和 __reason 等状态变量。工作流可以依据这些变量判断提取操作是否成功，并在结构化数据缺失或提取失败时进入相应的错误处理分支。
迭代节点（Iteration）
迭代节点负责对数组中的每个元素重复执行同一组子流程。该节点适合批量文本处理、多问题问答和数组数据转换等场景。
迭代节点接收数组类型的输入变量，并为数组中的每个元素执行内部工作流。内部节点可以通过当前元素和索引变量访问对应的数据，迭代执行完成后，节点将多个子任务结果汇总为数组输出。
例如，参数提取器生成 question_list 后，迭代节点可以逐项读取问题，并依次执行知识检索和 LLM 回答。整个流程不需要预先确定问题数量，而是根据实际数组长度执行对应次数的子流程。
迭代节点支持顺序和并行处理模式。顺序模式适合需要控制执行顺序的任务，并行模式适合处理相互独立的数组元素。节点还支持错误终止、保留空值继续执行以及移除失败结果等处理策略。
循环节点（Loop）
循环节点负责执行具有状态依赖的重复处理逻辑。该节点与迭代节点的区别在于，循环的当前执行结果可以作为下一轮执行的输入。
迭代节点主要处理数组中彼此独立的元素，而循环节点主要处理需要逐步优化、累积状态或重复检查的任务。
例如，内容质量优化工作流可以先生成初始文本，再由评估节点生成质量分数。当分数低于预设阈值时，循环节点可以将当前文本重新传递给 LLM 进行修订，直到满足终止条件。
循环节点支持定义循环变量、最大执行次数和退出条件。开发者需要为循环配置明确的停止规则，避免不必要的模型调用和无限重复执行。
变量聚合器节点（Variable Aggregator）
变量聚合器节点负责将多个互斥执行分支的输出映射为统一变量。
条件分支和问题分类器通常会生成多条不同的执行路径。不同分支虽然采用不同的处理逻辑，但它们可能需要向下游提供相同类型的数据。
变量聚合器可以接收这些互斥分支的输出，并为后续节点提供统一的数据入口。例如，产品咨询分支和通用问询分支分别生成邮件正文，变量聚合器可以将两个分支的文本输出映射为同一个结果变量。
变量聚合器要求被聚合变量的数据类型保持一致。该节点主要适用于每次只执行一条路径的互斥分支，不适用于同时执行的并行分支。并行任务的结果合并通常需要通过代码节点或模板转换节点完成。
代码节点（Code）
代码节点负责执行自定义 Python 或 JavaScript 程序，以实现复杂数据计算、格式转换和规则处理。
代码节点可以通过输入变量接收上游数据，并要求程序按照声明的输出结构返回结果。开发者可以使用该节点实现 JSON 数据清洗、字符串处理、数组转换、数值计算以及自定义字段校验。
代码节点运行在隔离的执行沙箱中。沙箱限制文件系统访问、外部网络请求和系统命令执行，因此代码节点适合执行计算和数据转换，而外部服务访问应由 HTTP 请求节点或工具节点完成。
代码节点的优势在于执行逻辑明确且结果可预测。对于不涉及自然语言推理的数据处理任务，代码节点通常能够减少模型调用并提高结果稳定性。
模板转换节点（Template）
模板转换节点负责使用 Jinja2 模板引擎对数据进行组合、转换和格式化。
模板转换节点支持变量替换、条件表达式、循环语句以及常见的数据过滤操作。开发者可以通过模板定义固定的输出结构，并将动态业务数据插入对应位置。
例如，邮件处理工作流可以由 LLM 生成邮件正文，再由模板转换节点统一添加客户称呼、段落格式和签名信息。模型负责内容生成，模板负责格式约束，两者共同实现语义处理与确定性输出的分离。
模板转换节点还适合生成 Markdown 内容、结构化文本和固定格式的通知消息。对于格式要求严格的任务，模板节点能够减少模型输出结构不一致的问题。
文档提取器与列表操作符
文档提取器节点负责将用户上传的文档转换为可供后续节点处理的文本。该节点支持 PDF、Word、Excel、Markdown 和其他多种文档格式，并将提取内容作为 text 变量输出。
文档提取器适合文档总结、合同分析、资料整理以及文件问答等场景。工作流可以先使用文档提取器读取文件内容，再使用 LLM 节点完成摘要生成或信息提取。扫描件和以图片为主的文件可能需要额外的视觉识别或 OCR 处理。
列表操作符节点负责对数组执行筛选、排序和元素选择。该节点可以根据文件类型、扩展名、大小等属性筛选数组内容，也可以从筛选结果中选择首个元素、最后一个元素或前若干项。
列表操作符适合多文件混合输入的处理场景。例如，工作流可以将上传文件中的图片与文档分离，再分别交给视觉模型和文档提取器处理。
工具节点与 HTTP 请求节点
工具节点负责调用 Dify 已集成的外部能力。开发者可以通过 Dify Marketplace 安装工具，并在工作流中完成参数配置与调用。
工具节点通常适用于搜索引擎查询、第三方服务集成以及平台已经提供标准封装的操作。工具的输入参数可以来自用户输入，也可以来自上游模型和参数提取器的输出。
HTTP 请求节点则提供更加通用的外部系统访问能力。该节点支持 GET、POST、PUT、PATCH 和 DELETE 等 HTTP 方法，并允许开发者配置请求地址、请求头、查询参数、请求体以及身份验证方式。
HTTP 请求节点能够将上游变量动态注入 API 请求，并将响应正文、状态码和响应头等数据提供给下游节点。开发者可以利用条件分支检查响应状态，也可以使用代码节点进一步解析返回的 JSON 数据。
生产环境中的 HTTP 请求节点需要配置合理的超时、重试和错误处理策略。接口凭据应通过安全的认证配置或 Secret 类型环境变量管理，避免将敏感信息直接写入提示词或普通日志。
Agent 节点
Agent 节点负责在工作流内部执行具备一定自主决策能力的任务。与普通 LLM 节点主要按照提示词生成结果不同，Agent 可以根据任务目标动态选择工具，并通过多轮工具调用完成复杂操作。
Agent 节点将模型推理与工具执行结合起来，使模型能够根据中间结果决定后续动作。工作流可以为 Agent 提供任务描述、上下文、可访问工具以及执行限制，并接收 Agent 返回的最终结果。
Agent 节点适合需要多阶段探索、动态信息查询和工具协作的任务。例如，研究型工作流可以要求 Agent 根据问题检索资料、分析检索结果，并在信息不足时继续调用适当的工具。
Agent 的执行路径具有一定动态性，因此开发者需要控制工具权限、最大执行轮次和任务范围。外层 Workflow 仍然负责控制整体业务流程、输入输出及异常处理，而 Agent 负责完成被分配的动态子任务。
变量赋值器与人工介入节点
变量赋值器节点负责修改特定变量的值。该节点在 Chatflow 中可以更新会话变量，使用户偏好、任务进度等信息在同一会话的多个交互轮次之间保持有效。循环场景也可以借助变量更新实现状态累积。普通 Workflow 的独立调用不应被视为具备默认的跨调用会话持久化能力。
人工介入节点负责在关键执行阶段暂停工作流，并通过表单请求人工审核或补充信息。该节点可以将模型生成的内容展示给指定人员，并根据人工选择继续不同的执行路径。
人工介入节点适合内容审核、业务审批以及高风险操作确认等场景。节点支持配置提交方式、表单字段、用户决策和超时策略，从而将自动化处理与人工监督结合起来。
输出节点（Output）与直接回复节点（Answer）
输出节点负责将 Workflow 的处理结果返回给调用方。开发者需要为输出节点配置变量名称，并绑定上游节点实际生成的数据。
输出节点支持返回字符串、数字、对象、数组和文件等类型。工作流还可以包含多个输出节点，并将已经执行的输出节点结果合并为最终输出。输出节点本身不意味着所有其他执行分支立即终止。
当前 Dify 节点文档将 Workflow 输出节点定义为可选节点。无需返回数据的自动化工作流可以不配置输出节点，但需要向 Web 应用、API 或其他工具返回处理结果时，工作流应明确配置相应的输出变量。
Chatflow 使用直接回复节点向用户返回对话消息。直接回复节点可以引用上游变量，并支持在对话过程中逐步展示内容，因此更适合交互式应用的响应输出。
Workflow 调试、发布与运行优化
工作流调试
Dify 提供工作流运行测试与节点执行信息，开发者可以通过测试验证流程连接关系、变量配置和节点输出。
开发者应优先检查输入变量与下游节点的数据类型是否一致，以及节点是否正确引用上游结果。LLM 节点需要关注 Prompt 的输入内容和生成结果，知识检索节点需要关注查询内容与返回片段的相关性，条件分支节点需要关注判断规则是否覆盖预期业务场景。
对于复杂工作流，开发者应构造正常输入、空值输入、多问题输入以及外部服务异常等测试场景。测试过程需要覆盖不同执行路径，避免仅根据单个成功样例判断工作流已经具备生产可用性。
错误处理与容错设计
生产环境中的工作流需要考虑模型调用失败、接口超时、数据解析异常和知识检索结果为空等情况。
Dify 的部分节点支持重试、默认值或错误分支。开发者可以根据操作类型选择合适的容错机制，并通过 If-Else 节点对状态变量和响应码进行判断。
对于可重复执行的读取类操作，重试机制能够处理部分临时错误。对于具有外部副作用的提交、创建或删除操作，工作流还需要避免重复执行导致的数据不一致问题。
错误处理不应仅以工作流能否继续执行为目标。开发者还需要确保下游节点能够区分成功结果、缺失数据和异常结果，避免将错误内容作为正常业务数据继续传递。
性能与成本优化
Workflow 的整体执行成本主要受到模型调用次数、输入输出 Token 数量、外部服务调用次数以及节点执行方式等因素影响。
开发者可以通过减少冗余的 LLM 节点、优化 Prompt 长度和控制检索结果数量降低 Token 消耗。对于纯数据处理任务，代码节点和模板转换节点可以替代部分模型调用。对于不存在依赖关系的任务，并行执行能够减少总体等待时间。
知识检索节点的 Top K、Score 阈值和 Rerank 策略需要综合考虑检索质量与上下文长度。过多的检索片段可能增加模型输入成本，也可能引入与问题无关的信息。
迭代和循环节点尤其需要设置合理的执行规模。大数组处理与高轮次循环可能产生大量模型请求，因此工作流设计需要关注单次调用成本和总体任务规模。
应用发布与 API 集成
Dify Workflow 在完成配置和测试后，可以通过发布操作生成可供外部访问的应用版本。
采用用户输入作为入口的 Workflow 可以通过受支持的 Web 应用、服务 API 等方式对外提供能力，也可以根据平台配置发布为其他应用可调用的工具。触发器启动的 Workflow 则主要服务于自动化执行场景。
Workflow API 支持阻塞式和流式执行模式。阻塞式模式在工作流完成后返回结果，流式模式可以在执行过程中持续返回相关事件。
API 响应中的 outputs 对象保存工作流的输出变量。task_id 可以用于控制运行中的流式任务，workflow_run_id 可以用于关联执行记录、查询运行状态及跟踪工作流事件。
工作流的画布修改并不会自动替换已发布版本。开发者需要在完成修改和验证后重新发布更新，才能使线上应用使用新的流程配置。
运行监控与持续优化
Dify 的监控与日志功能可以帮助开发者分析工作流的运行情况。运行记录能够反映任务状态、执行耗时、Token 消耗及相关输入输出信息。
开发者可以通过日志识别执行失败的节点，分析耗时较高的处理步骤，并检查模型生成结果与预期业务目标之间的差异。
工作流的持续优化应建立在运行数据与实际业务反馈之上。开发者可以根据高频问题调整知识库内容，根据错误记录改进节点容错逻辑，并根据成本指标优化模型选择和流程结构。
这种以运行观察、问题分析、配置优化和版本发布为核心的迭代机制，是 Dify Workflow 实现 LLMOps 的重要基础。
参考链接
发表于 半小时前
|
查看: 4|
回复: 0
