Dify 工作流→ 节点及相关功能

先说说几个核心判断——Dify的工作流节点设计，本质上是在帮我们拆解复杂任务，把一个个自动化步骤串成一条清晰的流水线。无论你是做客服系统、内容生成还是数据分析，理解这些节点之间的协作关系，才是用好Dify的关键。

下面这张图把Dify工作流的节点体系基本都囊括了，咱们一边看图一边聊。

一、

基础与流程控制类节点

工作流的起点，负责初始化变量或接收用户输入的数据，比如文本、文件、下拉选项等。它还支持系统变量（像用户ID、应用ID），用来记录全局信息。配置时可以定义输入字段的类型——文本、段落、文件——以及系统参数。简单说，就是告诉工作流“你从哪里开始，要接收什么东西”。

工作流的终点，用来汇总关键结果输出。需要你提前声明输出变量，而且支持多个分支各自对应不同的结束节点。这种设计在复杂流程中非常实用——不同路径可以走到不同的终点，互不干扰。

根据条件决定走哪条路，常见判断逻辑包括文本包含、数值比较等，支持 IF/ELIF/ELSE 结构。典型场景：客服意图分类，比如用户说“退换货”就走售后流程，说“涨价了”就走咨询流程。这就是动态流程切换的经典做法。

专门对付数组数据——像文本片段列表这种需要批量处理的场景。用它可以把长文本拆成小块，逐一交给大模型处理，绕过单次处理的长度限制。比如把一篇万字文章拆成几段，分别翻译后再拼回去，迭代节点就是干这个的。

跟迭代节点不同，它是依赖前序结果进行递归处理。需要设置终止条件（比如变量达到某个阈值）和最大循环次数，防止死循环。多用于优化类任务，比如自动调参、反复修正生成结果。

二、

数据处理与转换类节点

从用户输入或原始数据里捞出结构化参数，比如日期、关键词、数量等。相当于一个智能筛子，把非结构化文本里的关键信息结构化出来。

按模板格式化数据输出。最常见的用法是把一段JSON数据转换成自然语言描述，或者反过来把文本结构化成固定格式。这个节点适合做数据报告的自动生成环节。

动态更新变量值，或者把多个变量的信息整合到一起。比如某个分支计算结果后更新全局变量，或者把不同节点产出的结果拼接成一条记录。

用 Python 或 Ja vaScript 脚本处理复杂逻辑——JSON解析、数学计算、字符串处理，甚至调用第三方库。它是工作流里“硬编码”的补充，遇到图形化节点搞不定的操作，就靠它来兜底。

识别用户意图，支持多标签分类。比如把一封邮件同时归类为“咨询+紧急”，或者在一个工单系统里区分“投诉”和“建议”。本质上是一个轻量级的分类器，可以搭配条件分支使用。

三、

AI与外部交互类节点

这是整个工作流的大脑——调用大模型（GPT-3.5、LLaMA等）来生成文本、分类、翻译或写代码。配置时需要选择模型、写好提示词（比如角色指令），再调一下温度、最大生成长度这些参数。一句话：你想要大模型做什么，就在这里定义。

从知识库里检索相关内容，作为LLM的上下文输入。这能大幅提升问答的准确率，尤其适合垂直领域——比如法律咨询、医疗问答，光靠模型本身的知识储备不够，得给它喂点私有资料。知识检索节点就是那个“喂资料”的管道。

调用外部API获取数据——查天气、抓网页、调第三方服务。支持GET/POST方法，可以配参数。如果想把工作流和外部系统打通，这个节点就是必经之路。

通过策略（Function Calling、ReAct等）让大模型自主调用工具，实现多步推理。举个例子：用户问“明天北京能飞吗？”，Agent节点可以先用搜索工具查天气，再查航班信息，最后给出综合判断。这是工作流里最智能的一环，相当于给了大模型“手和脚”。

集成第三方服务，比如数据库查询、发消息、调内部系统接口。支持内置工具的授权管理，也支持自定义工具开发。工具节点就是那根“插头”，把Dify和外部世界接起来。

四、

典型工作流案例

最简单的链条：开始节点（输入原文） → LLM节点（给改写指令） → 结束节点（输出结果）。如果想进阶，可以在中间加入HTTP节点抓取网页内容做参考，或者用知识库节点补充专业术语。这样出来的仿写就不只是换词，而是有根有据。

常见路径：开始节点（接收用户输入） → 知识检索（查找相关文档） → LLM生成回复 → 直接回复节点（流式输出）。这种架构能保证对话中每一次回答都有知识库支撑，不会凭空乱编。搭配迭代节点，还能处理长上下文对话的分段检索。