---

关于作者

• 深耕领域：大语言模型开发 / RAG 知识库 / AI Agent 落地 / 模型微调
• 技术栈：Python | RAG (LangChain / Dify + Milvus) | FastAPI + Docker
• 工程能力：专注模型工程化部署、知识库构建与优化，擅长全流程解决方案

「让 AI 交互更智能，让技术落地更高效」
欢迎技术探讨与项目合作，解锁大模型与智能交互的无限可能！

---

Dify 工作流节点完全指南：构建生产级 AI 应用的完整攻略

从零开始：每个伟大的 AI 应用，都源于一个简单的想法，然后被拆解成一系列可控的步骤。在 Dify 的世界里，这些步骤被称作“节点”，它们是构建智能工作流的基石。

零、前置知识：理解 Dify 的核心概念

在深入探讨节点类型之前，我们需要先建立对 Dify 平台的基础理解。如果你已经熟悉 Dify 的基本概念，可以直接跳过这一节进入正文。

0.1 什么是 Dify？

Dify 是一个开源的大语言模型（LLM）应用开发平台，它的核心理念是让开发者能够快速构建、部署和管理 AI 应用程序。Dify 提供了两种类型的应用模式：**Chatflow（对话流）**和 Workflow（工作流）。

生活中的比喻：想象你要准备一顿晚餐。传统的方式是把所有食材一起下锅，结果可能是半生不熟或者味道混杂。Dify 的做法是让你把烹饪过程拆分成多个独立的步骤——洗菜、切菜、炒菜、调味——每个步骤专注于自己的任务，最后组合成一道完整的菜肴。节点就像是这些独立的烹饪步骤，各自专注做一件事，然后通过“端菜”这个动作连接起来。

0.2 Chatflow 与 Workflow 的区别

这是很多初学者容易混淆的概念。简单来说：

• Chatflow（对话流）：专为对话场景设计，适用于客服机器人、语义搜索等需要多轮交互的应用。Chatflow 内置了对话记忆（Memory）功能，可以在多轮对话中保持上下文。

• Workflow（工作流）：面向自动化和批处理场景，适用于高质量翻译、数据分析、内容生成、邮件自动化等。Workflow 没有 Memory 相关配置，无法启用。

关键差异对比：

特性	Chatflow	Workflow
对话记忆	✅ 支持	❌ 不支持
流式输出	✅ 支持	✅ 支持（部分节点）
用户输入节点	✅ 支持	❌ 使用 Start 节点
回答节点	✅ Answer 节点	❌ 使用 Output 节点
适用场景	对话式交互	自动化流程

生活中的例子：Chatflow 就像是与朋友的实时聊天，你们可以一来一回地交流。而 Workflow 就像是写一封邮件——你把内容整理好，一次性发送出去，不需要等待对方的即时回复。

0.3 变量的基础概念

在 Dify 工作流中，**变量（Variable）**是连接各个节点的桥梁。理解变量是掌握节点使用的前提。

变量的来源主要有三种：

1. 系统变量（System Variables）：Dify 预置的变量，如用户输入（sys.query）、上传的文件（sys.files）等

2. 节点输出变量：每个节点执行后产生的输出，会成为下游节点的输入

3. 对话变量（Conversation Variables）：仅适用于 Chatflow，用于在多轮对话中存储和传递信息

生活中的比喻：变量就像是烹饪过程中的“食材”和“成品”。你从冰箱（系统）拿出原材料（系统变量），经过加工（节点处理），产出半成品或成品（节点输出变量），这些产出可以传递给下一个步骤继续加工。

---

一、为什么需要工作流节点？

每个开发者都曾面临过这样的困境：你需要构建一个看似简单但实际复杂的 AI 应用。一个典型的场景是——构建一个企业客服机器人。

1.1 传统方案的困境

在不使用工作流的情况下，你可能会尝试把所有逻辑塞进一个庞大的 Prompt 中：

你是一个客服助手。用户会询问关于产品的问题。
如果用户问价格，请回答价格信息；
如果用户问售后政策，请回答售后政策；
如果用户问技术支持，请提供技术支持...

这种方法存在明显的问题：

1. Prompt 难以维护：随着功能增加，Prompt 会变得越来越长、越来越难以管理

2. 逻辑难以调试：当回答出现问题时，你很难定位是哪个部分的逻辑出了问题

3. 无法处理复杂流程：有些场景需要多步骤处理，比如先查知识库、再调用外部 API、最后格式化输出

4. 难以复用：不同的应用可能需要类似的逻辑，但无法复用已有的 Prompt

1.2 Dify 节点的解决方案

Dify 工作流的核心理念是将复杂的 AI 应用拆解成一系列独立的步骤，每个步骤由一个节点来完成。这就像现代工厂的流水线一样，每个工人只负责一道工序，最终组装出完整的产品。

通过这种方式：

• 每个节点专注于一个任务，易于理解和维护
• 可以独立测试和调试每个节点
• 逻辑清晰，数据流向明确
• 节点可以复用，构建新的工作流

---

二、Dify 节点全景图：20 种节点一览

在开始详细介绍每个节点之前，让我们先通过一张全景图了解 Dify 提供的所有节点类型。

下面，我们将逐一详细介绍每一类节点。

---

三、起始与结束类节点：工作流的边界

起始与结束类节点定义了工作流的入口和出口，是每个工作流必不可少的基础组件。

3.1 Start 节点：一切的开始

Start 节点是工作流的起点，它定义了启动工作流所需的输入参数。无论你构建什么样的应用，都需要从 Start 节点开始。

3.1.1 节点功能详解

Start 节点的核心功能是定义工作流的输入变量。这些变量可以是：

• 用户输入（User Input）：用户在界面上输入的文本
• 文件上传（File）：用户上传的文档、图片等
• 系统变量：Dify 预置的变量

Workflow 应用 vs Chatflow 应用：

• Workflow 应用的 Start 节点提供以下系统变量：

  • sys.files：用户上传的文件列表
  • sys.workflow_id：工作流 ID
  • sys.app_id：应用 ID

• Chatflow 应用的 Start 节点提供更丰富的系统变量：

  • sys.query：用户输入的查询文本
  • sys.files：用户上传的文件
  • sys.conversation_id：对话 ID
  • sys.user_id：用户 ID

3.1.2 配置说明

在 Start 节点中，你可以定义两种类型的输入：

1. 文本变量：用于接收用户的文本输入

   • 单行文本：适用于简短的输入，如姓名、关键词
   • 多行文本：适用于长文本输入，如问题描述

2. 文件变量：用于接收用户上传的文件

   • 支持的文件类型：文档、图片、音频、视频
   • 可以设置是否允许多文件上传

3.1.3 实际用例

用例一：简单的问答应用

配置：
- 添加一个文本变量 "query"，用于接收用户问题
- 用户输入："如何重置密码？"
- 这个变量会传递给后续的 LLM 节点或知识检索节点

用例二：文档处理应用

配置：
- 添加一个文件变量 "document"，用于接收上传的 PDF 文件
- 添加一个文本变量 "language"，用于指定输出语言
- 流程：
  1. Document Extractor 节点提取 PDF 文本
  2. LLM 节点根据提取的内容生成摘要
  3. 根据 language 变量指定的语言输出结果

3.2 End 节点：优雅的终点

End 节点标识工作流的终点，定义最终的输出内容。一个工作流可以有多个 End 节点（通常在不同的分支路径上），但至少需要一个。

3.2.1 节点功能详解

End 节点的主要功能是：

1. 声明输出变量：必须声明一个或多个输出变量，这些变量可以引用任意上游节点的输出变量
2. 格式化输出：定义最终返回给用户的内容格式

3.2.2 与 Answer 节点的区别

很多初学者会混淆 End 节点和 Answer 节点。关键区别在于：

• End 节点：用于 Workflow 类型应用，表示工作流的正式结束
• Answer 节点：用于 Chatflow 类型应用，可以有多次输出，支持流式输出

重要提示：End 节点不能用于 Chatflow 应用。

3.2.3 实际用例

用例：多分支工作流的终点

在这种情况下，每个分支都有自己的 End 节点，Dify 会根据实际执行的分支返回对应的输出。

3.3 Answer 节点：对话式响应

Answer 节点是 Chatflow 特有的节点，用于向用户返回响应内容。与 End 节点不同，Answer 节点不是终止性的，可以放在工作流的任意位置，实现多次输出。

3.3.1 节点功能详解

Answer 节点的核心功能：

1. 流式输出：支持流式输出，内容可以逐步呈现给用户
2. 多节点输出：可以在一个工作流中放置多个 Answer 节点，在不同阶段输出内容
3. 富媒体支持：可以输出文本、图片、文件等多种内容类型

3.3.2 配置说明

Answer 节点的配置包括：

• 输出内容：可以是固定文本、变量、或两者的组合
• 引用追踪：开启后，会自动追踪内容的来源（如知识库引用）
• 输出变量：可以引用任意上游节点的输出

3.3.3 实际用例

用例：分步输出处理进度

在这个例子中，用户会先收到一条中间消息，然后才收到最终的摘要结果。这种设计可以提升用户体验，特别是处理时间较长的任务。

3.4 Output 节点：结构化输出

Output 节点用于 Workflow 应用，定义工作流的输出格式。它与 End 节点类似，但更专注于结构化输出的定义。

3.4.1 节点功能详解

Output 节点的核心功能：

1. 定义输出结构：可以指定多个输出变量及其类型
2. API 友好：输出格式更适合 API 集成场景
3. 数据转换：可以对输出数据进行格式化处理

3.4.2 实际用例

用例：返回结构化的 API 响应

场景：构建一个翻译 API

配置：
- 输入变量：source_text（要翻译的文本）、target_language（目标语言）
- 输出变量：translated_text（翻译后的文本）

Output 节点配置：
- translated_text: {{llm.output.text}}
- metadata: {{llm.response_metadata}}

这样，调用 API 的开发者可以获得结构化的响应，便于程序处理。

---

四、大语言模型类节点：Dify 的核心大脑

LLM 类节点是 Dify 工作流中最核心的部分，它们赋予了工作流理解和生成自然语言的能力。

4.1 LLM 节点：与语言模型对话

LLM 节点是 Dify 工作流中使用频率最高的节点，用于调用大语言模型处理各种任务。它是几乎所有 AI 应用的核心组件。

4.1.1 节点功能详解

LLM 节点的核心能力：

1. 多模型支持：支持 OpenAI、Anthropic、Azure OpenAI、本地部署模型等多种模型
2. 多模态输入：支持文本、图像、文档等多种输入类型
3. 上下文管理：可以连接知识检索节点，注入外部知识
4. 结构化输出：支持 JSON Schema 定义输出格式
5. 对话历史：可以包含多轮对话历史（Chatflow 模式）
6. Jinja2 模板：支持在 Prompt 中使用 Jinja2 模板语法

4.1.2 配置详解

LLM 节点的配置可以分为以下几个部分：

模型选择：

• 选择使用的语言模型
• 配置模型参数（温度、最大 token 数等）

提示词配置：

提示词模板示例：
你是一个专业的{{role}}。请根据以下信息回答用户的问题。

{% if context %}
参考信息：
{{context}}
{% endif %}

用户问题：{{query}}

回答要求：
1. 使用{{language}}回答
2. 简洁明了，不超过100字

上下文变量（Context）：

• 用于注入外部知识（通常是知识检索节点的输出）
• 支持引用溯源，用户可以看到答案的依据

记忆（Memory）：

• 仅适用于 Chatflow
• 可以配置是否包含对话历史
• 可以设置记忆的窗口大小

输出格式：

• 普通文本：直接输出文本
• 结构化输出：定义 JSON Schema，模型会按 Schema 输出

4.1.3 技术亮点：Jinja2 模板支持

LLM 节点的 Prompt 编辑器支持 Jinja2 模板语法，这为动态 Prompt 构建提供了强大的能力。

变量替换：

用户名称：{{user.name}}
订单编号：{{order.id}}
商品列表：
{% for item in order.items %}
- {{item.name}}：{{item.price}}元
{% endfor %}

条件逻辑：

{% if user.vip %}
尊敬的VIP用户{{user.name}}，您享受专属折扣！
{% else %}
您好{{user.name}}，成为VIP享受更多优惠！
{% endif %}

循环遍历：

以下是为您推荐的产品：
{% for product in recommended_products %}
{{loop.index}}. {{product.name}} - {{product.price}}元
   特点：{{product.features}}
{% endfor %}

4.1.4 实际用例

用例一：基于知识库的问答

配置说明：

1. Knowledge Retrieval 节点从知识库中检索相关内容
2. LLM 节点的 Context 变量连接到 Knowledge Retrieval 的输出
3. LLM 基于检索到的内容生成答案

用例二：结构化数据提取

场景：从用户反馈文本中提取结构化信息

输出格式定义：
{
  "sentiment": "positive/negative/neutral",
  "category": "product/service/support/other",
  "key_points": ["要点1", "要点2"],
  "urgency": "high/medium/low"
}

用例三：多模态文档理解

配置步骤：

1. 在 Start 节点添加文件变量 “document”
2. 添加 Document Extractor 节点提取文档内容
3. 在 LLM 节点的 Prompt 中引用提取的内容

4.2 Agent 节点：让 LLM 自主思考

Agent 节点是 Dify 最强大的创新之一。与 LLM 节点遵循固定流程不同，Agent 节点赋予 LLM 自主决策的能力，让它能够根据任务需求动态选择和调用工具。

4.2.1 节点功能详解

Agent 节点的核心特点：

1. 自主推理：LLM 可以自己决定下一步做什么，而不是按照预设的流程执行
2. 动态工具选择：可以根据任务需求选择调用哪些工具
3. 多步骤执行：可以循环执行“思考→行动→观察”的过程，直到完成任务
4. Agent Strategy：可插拔的推理策略模块

4.2.2 Agent Strategy 详解

Dify 提供了多种 Agent Strategy（代理策略），每种策略适用于不同的场景：

Function Calling（函数调用）：

• 原理：将外部工具映射为 LLM 可以调用的函数
• 优点：精确调用，推理路径短，适合结构化的工具调用
• 适用场景：API 调用、数据库查询、结构化任务处理

生活中的例子：就像你在餐厅点餐，服务员（LLM）只需要根据菜单（工具定义）
选择对应的菜品（调用函数），不需要过多的思考。

ReAct（推理+行动）：

• 原理：交替进行推理和行动，LLM 会先思考当前状态和目标，然后选择工具执行，并根据结果调整下一步行动
• 优点：能够利用外部信息，推理过程可追溯，适用范围广
• 适用场景：需要外部知识的问答、信息检索、复杂任务执行

生活中的例子：就像你自己在家找东西。你会先思考“上次好像放在书房了”，
然后去书房找（行动），如果没找到，你会想“会不会在卧室”，然后去
卧室找（新一轮行动）。这个“思考→行动→观察→再思考”的循环就是 ReAct 的核心。

ReWOO（解耦推理）：

• 原理：将推理过程和工具调用分离，先制定完整的计划，再执行
• 优点：token 消耗低，效率高
• 适用场景：批量处理、多步骤复杂任务

4.2.3 工具配置

Agent 节点可以调用多种类型的工具：

1. 内置工具：Dify 提供的工具，如搜索引擎、DALL·E 图像生成等
2. 自定义工具：用户自己开发的工具
3. MCP 工具：通过 Model Context Protocol 集成的工具
4. 子工作流：其他 Dify 工作流

工具描述的重要性：

工具描述直接影响 LLM 是否选择调用该工具。好的工具描述应该包含：

• 工具的用途（什么时候应该使用）
• 工具的参数说明
• 返回结果的格式

4.2.4 实际用例

用例一：智能研究助手

用例二：旅行规划代理

Agent 可以：

1. 搜索目的地的天气和景点信息
2. 查询航班和酒店价格
3. 根据用户偏好生成行程安排
4. 实时调整行程以应对变化

用例三：代码调试助手

Agent 可以：

1. 分析用户提供的错误信息
2. 搜索可能的解决方案
3. 生成修复代码
4. 解释修复的原因

---

五、知识与检索类节点：让 AI 有“知识”

知识类节点赋予了 AI 应用访问和利用外部知识的能力，这是实现高质量问答系统的关键技术。

5.1 Knowledge Retrieval 节点：RAG 的核心

Knowledge Retrieval 节点是 Dify RAG（Retrieval-Augmented Generation，检索增强生成）能力的核心组件。它从知识库中检索与用户问题相关的内容，作为 LLM 的上下文。

5.1.1 节点功能详解

Knowledge Retrieval 节点的核心能力：

1. 语义检索：基于向量嵌入的语义搜索，找到语义相关的内容
2. 混合搜索：结合关键词搜索和语义搜索，提升检索准确性
3. 元数据过滤：支持根据文档元数据进行筛选
4. 重排序（Rerank）：对初步检索结果进行重排序，提升质量
5. 引用溯源：自动追踪信息来源，用户可以查看答案的依据
6. 多知识库支持：可以同时检索多个知识库

5.1.2 技术原理

RAG 的工作流程：

知识库检索节点的工作原理：

1. 接收用户问题（通常是 sys.query 或上游节点的输出）
2. 将问题向量化，在知识库中搜索相似的文档块
3. 可选：使用重排序模型对结果进行优化
4. 输出检索到的文本内容及其引用信息

5.1.3 配置详解

输入配置：

• Query Variable：要检索的内容，通常是用户输入 sys.query

知识库选择：

• 可以选择一个或多个知识库
• 每个知识库可以独立配置检索参数

检索设置：

• 召回数量：返回最相似的 N 个文档块
• 相似度阈值：只返回高于阈值的检索结果
• 元数据过滤：根据文档的元数据（如类型、时间）进行筛选

5.1.4 实际用例

用例一：企业知识库问答

场景：构建内部 HR 政策咨询机器人

配置：
1. 创建知识库，上传 HR 政策文档
2. 流程：
   - Start 节点接收用户问题
   - Knowledge Retrieval 检索相关政策
   - LLM 基于检索内容生成答案
   
优势：
- 可以处理大量 HR 文档
- 答案有据可查
- 支持持续更新文档库

用例二：产品手册查询

场景：电子产品使用问题解答

配置：
1. 创建知识库，上传产品手册、FAQ 等
2. 配置元数据过滤（如按产品型号过滤）
3. 用户输入产品型号和问题，系统检索对应文档

用例三：高级 RAG 工作流

这是 Agentic RAG 的典型架构，通过多次检索和评估，不断优化检索结果。

5.2 Document Extractor 节点：提取文档内容

Document Extractor 节点用于从上传的文档中提取文本内容。它是处理用户上传文件的第一步。

5.2.1 节点功能详解

Document Extractor 支持的文件类型：

• 文本文档：TXT、Markdown、HTML
• Office 文档：DOCX、DOC
• PDF 文档：文本型 PDF（推荐使用 pypdfium2）
• 电子表格：Excel（XLS、XLSX）、CSV
• 演示文稿：PowerPoint（PPT、PPTX）
• 邮件格式：EML、MSG
• 其他格式：EPUB、VTT、JSON、YAML

重要提示：主要是二进制内容的文件（如图片、音频、视频）需要使用专门的工具或外部服务来处理。

5.2.2 处理流程

用户上传文件 → sys.files 变量 → Document Extractor → 提取的文本内容 → LLM 节点

5.2.3 实际用例

用例一：简历筛选系统

用例二：合同分析

配置：
1. 用户上传合同 PDF
2. Document Extractor 提取合同文本
3. LLM 分析合同条款，提取关键信息（金额、期限、违约条款等）
4. Code 节点将结果格式化为结构化数据
5. Output 节点返回结构化结果

---

六、逻辑控制类节点：让工作流学会“思考”

逻辑控制类节点赋予了工作流条件判断和流程控制的能力，是构建复杂业务逻辑的基础。

6.1 If-Else 节点：条件分支

If-Else 节点是最基础的逻辑控制节点，它根据条件将工作流拆分成多个分支。

6.1.1 节点功能详解

If-Else 节点支持以下功能：

1. 多分支：支持 IF、多个 ELIF（else if）、ELSE 分支
2. 多种条件类型：文本比较、数值比较、包含判断等
3. 复杂条件：支持 AND、OR 逻辑组合
4. 变量引用：可以引用任意上游节点的输出作为条件

条件类型详解：

条件类型	说明	示例
等于	精确匹配	{{query}} == "价格"
不等于	精确不匹配	{{category}} != "技术支持"
包含	文本包含	{{query}} contains "价格"
不包含	文本不包含	{{query}} not contains "投诉"
为空	值为空	{{email}} is empty
不为空	值不为空	`{{phone}} is not empty
大于/小于	数值比较	{{score}} > 60

6.1.2 实际用例

用例一：简单的路由分流

用例二：复杂的多级分类

用例三：基于评分的处理分流

场景：根据用户满意度评分采取不同行动

配置：
- 评分变量：{{satisfaction_score}}

条件配置：
1. IF: {{satisfaction_score}} >= 9
   → 发送感谢消息，邀请好评
   
2. ELIF: {{satisfaction_score}} >= 7
   → 发送感谢消息
   
3. ELIF: {{satisfaction_score}} >= 5
   → 询问具体不满原因
   
4. ELSE: {{satisfaction_score}} < 5
   → 转人工客服处理

6.2 Question Classifier 节点：意图识别

Question Classifier 节点使用 LLM 对用户输入进行分类，本质上是意图识别（Intent Classification）。它是构建智能客服系统的关键技术。

6.2.1 节点功能详解

Question Classifier 的核心能力：

1. 语义分类：使用 LLM 理解用户问题的语义进行分类
2. 可配置分类：自定义分类标签和描述
3. 上下文感知：可以包含对话历史，提高分类准确性
4. 灵活输出：每个分类标签对应一个输出分支

6.2.2 配置详解

输入配置：

• Input Variable：要分类的内容，通常是 sys.query

分类定义：

示例分类配置：

分类1：产品咨询
- 标签：product_inquiry
- 描述：用户询问产品功能、价格、规格等信息

分类2：技术支持
- 标签：technical_support
- 描述：用户遇到技术问题，需要故障排除或使用帮助

分类3：售后服务
- 标签：after_sales
- 描述：用户询问退换货、维修、保修等售后问题

分类4：其他
- 标签：other
- 描述：不属于以上类别的其他问题

分类指令：

可以为分类器提供详细的指令，帮助 LLM 更好地区分不同类别：

请根据以下标准对用户问题进行分类：
- 产品咨询：询问产品功能、价格、型号等信息
- 技术支持：遇到错误代码、操作困难、功能异常
- 售后服务：退换货、维修、保修、退款
- 其他：不属于上述任何类别

6.2.3 实际用例

用例一：客服机器人意图分流

用例二：多轮对话中的意图追踪

在多轮对话中，Question Classifier 可以结合对话历史进行更准确的分类：

配置：
- 启用 Memory
- 窗口大小：5（包含最近5轮对话）

效果：
- 用户第一轮说："我想买电脑"
- Classifier 分类为：产品咨询
- 用户第二轮说："玩游戏用"
- Classifier 结合历史理解为：产品咨询（游戏电脑推荐）

6.3 Iteration 节点：批量处理

Iteration 节点用于遍历数组，对数组中的每个元素执行相同的处理逻辑。这是实现批量处理的核心节点。

6.3.1 节点功能详解

Iteration 节点的核心概念：

1. 输入变量：要遍历的数组
2. 迭代变量：当前迭代的元素（item）
3. 迭代体：对每个元素执行的子工作流
4. 输出变量：所有迭代结果的数组

处理模式：

• 顺序处理：按顺序一个一个处理数组元素
• 并行处理：同时处理多个数组元素（更高效）

错误处理：

• Terminate（终止）：遇到错误时停止整个迭代
• Continue on Error（继续）：跳过错误项，继续处理后续元素
• Remove Failed Results（移除失败）：只返回成功的结果

6.3.2 实际用例

用例一：批量发送通知

用例二：批量文档处理

场景：批量处理多份简历，提取关键信息

输入：简历数组（10份PDF简历）

Iteration 节点内部：
1. Document Extractor：提取当前简历的文本
2. LLM：提取关键信息（姓名、学历、经验、技能）
3. Code：格式化输出

输出：10份简历的结构化信息数组

用例三：多平台内容适配

场景：将一篇文章适配到多个平台发布

输入：article（原始文章）

Iteration 节点遍历 platforms 数组：["Twitter", "LinkedIn", "微信"]

每个迭代内部：
1. LLM：根据平台特点改写内容
2. 格式化输出

输出：各平台适配后的内容数组

6.4 Loop 节点：循环执行

Loop 节点与 Iteration 类似，但更灵活——它可以循环执行直到满足某个条件才退出。这在需要迭代优化的场景中特别有用。

6.4.1 节点功能详解

Loop 节点与 Iteration 节点的对比：

特性	Iteration	Loop
执行次数	已知（数组长度）	未知（直到满足条件）
迭代变量	数组元素	可自定义
退出条件	遍历完成	自定义条件
适用场景	批量处理	迭代优化

6.4.2 实际用例

用例一：Deep Research（深度研究）

用例二：迭代优化生成结果

场景：生成广告文案，直到满足质量要求

Loop 配置：
- 初始变量：product_info（产品信息）
- 退出条件：quality_score >= 8

循环体：
1. LLM：生成广告文案
2. Code：计算质量得分（基于预设标准）
3. If-Else：判断是否满足退出条件

---

七、数据处理类节点：让数据流动起来

数据处理类节点负责数据的转换、格式化、聚合等操作，是构建复杂工作流不可或缺的工具。

7.1 Code 节点：自定义逻辑

Code 节点是 Dify 工作流中最灵活的数据处理工具，它允许你编写 Python 或 JavaScript 代码来执行任意自定义逻辑。

7.1.1 节点功能详解

Code 节点的核心能力：

1. 多语言支持：支持 Python 和 JavaScript
2. 数据转换：对任意格式的数据进行转换和处理
3. 数学计算：执行复杂的数据计算
4. API 响应处理：解析和提取 HTTP 响应的数据
5. 错误处理：可以配置遇到错误时的处理策略

安全机制：

Code 节点在沙箱环境中运行，具有以下限制：

• 禁止访问文件系统
• 禁止发起网络请求
• 禁止执行系统命令

7.1.2 配置详解

输入变量：

使用 Code 节点前，需要在"输入变量"中声明要引用的变量：
- 从 Start 节点获取用户输入
- 从 HTTP 节点获取 API 响应
- 从其他节点的输出中获取数据

代码编写：

# Python 示例：数据处理
def main(data: dict) -> dict:
    # data 是从输入变量获取的数据
    result = {
        "name": data.get("name", ""),
        "age": data.get("age", 0),
        "status": "adult" if data.get("age", 0) >= 18 else "minor"
    }
    return result

// JavaScript 示例
function main(data) {
    return {
        name: data.name || "",
        age: data.age || 0,
        status: data.age >= 18 ? "adult" : "minor"
    };
}

7.1.3 错误处理

Code 节点支持完善的错误处理机制：

1. 启用错误处理：在节点配置中开启

2. 配置处理策略：

   • None：不处理错误，直接抛出
   • Default Value：使用预设的默认值
   • Fail Branch：触发失败分支，执行备用逻辑

3. Code Fix 功能：Dify 还可以利用 LLM 自动修复代码错误

7.1.4 实际用例

用例一：JSON 数据提取

场景：从 HTTP API 的复杂响应中提取需要的数据

输入：{{http_response}}（API 完整响应）

代码：
def main(http_response):
    # 提取嵌套数据
    return {
        "user_name": http_response["data"]["user"]["name"],
        "user_email": http_response["data"]["user"]["contact"]["email"],
        "order_count": len(http_response["data"]["orders"])
    }

用例二：数据计算

场景：计算订单的总价和折扣

输入：
- items: [{"price": 100, "quantity": 2}, {"price": 50, "quantity": 3}]

代码：
def main(items):
    subtotal = sum(item["price"] * item["quantity"] for item in items)
    discount = subtotal * 0.1 if subtotal > 500 else 0
    total = subtotal - discount
    
    return {
        "subtotal": subtotal,
        "discount": discount,
        "total": total
    }

用例三：数据格式转换

场景：将 API 返回的数据转换为标准格式

输入：外部系统的订单数据（格式不统一）

输出：统一的内部格式

7.2 Template 节点：Jinja2 模板

Template 节点使用 Jinja2 模板语言进行文本格式化处理。与 Code 节点相比，Template 节点不需要编写代码，通过模板语法即可实现复杂的数据转换。

7.2.1 节点功能详解

Template 节点的核心能力：

1. 变量替换：将变量插入到文本中
2. 条件逻辑：根据条件显示不同内容
3. 循环遍历：遍历数组生成重复内容
4. 过滤器：对数据进行格式化处理
5. 交互式表单：生成 HTML 表单收集用户输入

7.2.2 Jinja2 语法详解

变量替换：

{# 基本变量 #}
用户名：{{ user.name }}
订单号：{{ order.id }}

{# 嵌套属性 #}
商品价格：{{ product.price }}
用户城市：{{ user.profile.address.city }}

{# 数组访问 #}
第一个商品：{{ items[0].name }}

条件逻辑：

{% if user.vip %}
欢迎回来，VIP 用户{{ user.name }}！
{% elif user.registered %}
欢迎{{ user.name }}，您是我们的注册用户。
{% else %}
欢迎游客，请问需要注册吗？
{% endif %}

循环遍历：

您的订单明细：
{% for item in order.items %}
{{ loop.index }}. {{ item.name }}
   数量：{{ item.quantity }}
   单价：{{ item.price }}元
   小计：{{ item.quantity * item.price }}元
{% endfor %}

订单总计：{{ order.total }}元

过滤器：

{# 字符串过滤器 #}
{{ user.name | upper }}
{{ user.bio | truncate(50) }}

{# 数字过滤器 #}
{{ price | round(2) }}

{# 列表过滤器 #}
{{ tags | join(", ") }}

7.2.3 实际用例

用例一：生成格式化邮件

输入变量：user_info（用户信息）, order_info（订单信息）

模板：
亲爱的{{ user_info.name }}您好！

您的订单 {{ order_info.order_id }} 已确认。

商品明细：
{% for item in order_info.items %}
- {{ item.name }} x {{ item.quantity }}
{% endfor %}

订单金额：{{ order_info.total }}元
配送地址：{{ user_info.address }}

感谢您的购买！

用例二：构建 Prompt 模板

输入：context（上下文）, query（问题）

模板：
你是一个专业的{{ profession }}。请根据以下参考信息回答用户的问题。

参考信息：
{% for item in context %}
{{ loop.index }}. {{ item.content }}
{% endfor %}

用户问题：{{ query }}

请用专业的语言回答，并注明参考来源。

用例三：生成交互式表单

<form>
  <label>姓名：<input type="text" name="name" /></label>
  <label>邮箱：<input type="email" name="email" /></label>
  <label>问题类型：
    <select name="type">
      <option value="product">产品咨询</option>
      <option value="support">技术支持</option>
      <option value="other">其他</option>
    </select>
  </label>
  <button type="submit">提交</button>
</form>

7.3 Variable Aggregator 节点：汇流成河

Variable Aggregator 节点用于将多个分支的输出合并为一个统一的变量。这在多分支工作流中非常有用。

7.3.1 节点功能详解

Variable Aggregator 的核心作用：

1. 合并分支输出：将不同分支的执行结果合并
2. 简化下游逻辑：下游节点只需要引用一个变量
3. 统一变量名：即使不同分支产生相同类型的输出，也不需要为每个分支单独配置下游节点

7.3.2 实际用例

用例：简化多分支工作流

没有 Variable Aggregator 的问题：

• 需要为每个分支配置独立的 LLM 节点
• 工作流变得复杂难维护

使用 Variable Aggregator 的优势：

• 所有分支的结果自动合并
• 下游只需要处理一个变量
• 工作流更加清晰

7.4 Variable Assigner 节点：变量赋值

Variable Assigner 节点用于给变量赋值，主要用于 Chatflow 应用中的对话变量管理。

7.4.1 节点功能详解

Variable Assigner 的核心作用：

1. 会话状态保存：在多轮对话中保存用户信息
2. 变量持久化：使变量在多轮对话中保持
3. 数据积累：将新信息追加到已有的数组变量中

7.4.2 实际用例

用例一：保存用户偏好

场景：记住用户在第一轮对话中选择的语言

配置：
1. LLM 节点提取用户输入的语言偏好
2. Variable Assigner 将语言写入 conversation 变量

变量：language
值：{{llm.output.language}}

用例二：对话历史积累

场景：在多轮对话中积累聊天记录

配置：
1. 创建 conversation 变量 memories (array[object])
2. 在每轮对话后，Variable Assigner 追加当前消息到 memories

追加内容：
{
  "role": "user",
  "content": "{{sys.query}}"
}

7.5 Parameter Extractor 节点：从自然语言提取参数

Parameter Extractor 节点使用 LLM 从自然语言中提取结构化参数。这在需要将用户口语化输入转换为结构化数据时特别有用。

7.5.1 节点功能详解

Parameter Extractor 的核心能力：

1. 语义理解：理解用户输入的意图
2. 结构化提取：将非结构化文本转换为结构化 JSON
3. 工具调用准备：为后续的工具调用或 HTTP 请求准备参数

7.5.2 配置详解

输入配置：

• Input Variable：要提取参数的文本（通常是 sys.query）

参数定义：

示例参数定义：

参数1：action
- 类型：string
- 说明：用户想要执行的操作
- 可选值：search, buy, query, cancel

参数2：target
- 类型：string
- 说明：操作的目标对象

参数3：time
- 类型：string
- 说明：时间相关的信息

提取模式：

• Function Call / Tool Call：使用模型的函数调用能力（推荐）
• Prompt-based：基于 Prompt 的提取

7.5.3 实际用例

用例：机票预订助手

用户输入："帮我订一张下周去上海的机票"

Parameter Extractor 输出：
{
  "action": "book_flight",
  "destination": "上海",
  "departure_date": "下周",
  "passenger_count": 1
}

这些参数可以传递给：
- HTTP 节点查询航班
- 后续的 LLM 节点确认预订信息

用例：智能搜索

用户输入："帮我找一下最近发布的关于 AI 的文章"

Parameter Extractor 输出：
{
  "topic": "AI",
  "time_range": "recent",
  "content_type": "article"
}

7.6 List Operator 节点：数组操作

List Operator 节点用于对数组进行过滤、排序、选择等操作。这在处理文件列表、数据集时非常有用。

7.6.1 节点功能详解

List Operator 的核心能力：

1. 过滤（Filter）：根据条件筛选数组元素
2. 排序（Sort）：按指定字段排序
3. 选择（Select）：选取特定位置的元素

7.6.2 过滤条件配置

字符串过滤：

• contains：包含指定字符串
• not contains：不包含
• starts with：以指定字符串开头
• ends with：以指定字符串结尾
• equals：精确匹配

数值过滤：

• equals：等于
• not equals：不等于
• greater than：大于
• less than：小于
• greater or equal：大于等于
• less or equal：小于等于

7.6.3 实际用例

用例一：分离混合文件类型

配置说明：

• List Doc：过滤条件 file_type == "document"
• List Img：过滤条件 file_type == "image"

用例二：排序和选择

场景：从搜索结果中选取评分最高的3个

输入：products 数组，每个元素包含 name, price, rating

List Operator 配置：
1. Sort：按 rating 降序排序
2. Select：取前 3 个

输出：评分最高的3个商品

---

八、外部集成类节点：连接外部世界

外部集成类节点让 Dify 工作流能够与外部系统交互，扩展了应用的能力边界。

8.1 HTTP Request 节点：调用外部 API

HTTP Request 节点用于发起 HTTP 请求，调用外部 API 或服务。这是 Dify 与外部系统集成的核心技术。

8.1.1 节点功能详解

HTTP Request 节点的核心能力：

1. 多种请求方法：支持 GET、POST、PUT、DELETE、HEAD、PATCH
2. 请求参数配置：URL、Headers、Query Parameters、Body
3. 认证支持：API Key、Bearer Token、Basic Auth 等
4. 动态参数：可以在请求中引用变量
5. 文件处理：支持文件上传和下载
6. 错误处理：可配置请求失败时的处理策略

8.1.2 配置详解

请求配置：

基础配置：
- 方法：POST
- URL：https://api.example.com/users

Headers：
- Content-Type：application/json
- Authorization：Bearer {{api_key}}

Query Parameters：
- page：{{page}}
- limit：{{limit}}

Body（JSON）：
{
  "name": "{{user.name}}",
  "email": "{{user.email}}",
  "preferences": {{user.preferences | tojson}}
}

超时配置：

• 连接超时：默认 10 秒
• 读取超时：默认 30 秒

8.1.3 实际用例

用例一：天气查询

配置示例：

URL: https://api.weather.com/v3/forecast
参数:
  - city: {{city}}
  - date: {{date}}
  - key: 您的API密钥

用例二：发送邮件

配置：
- 方法：POST
- URL：https://api.sendgrid.com/v3/mail/send
- Headers：
  - Authorization：Bearer {{sendgrid_api_key}}
  - Content-Type：application/json
- Body：
  {
    "personalizations": [{
      "to": [{"email": "{{to_email}}"}]
    }],
    "from": {"email": "noreply@example.com"},
    "subject": "{{subject}}",
    "content": [{
      "type": "text",
      "value": "{{content}}"
    }]
  }

用例三：调用 AI 模型

配置外部模型 API：
- 方法：POST
- URL：https://api.anthropic.com/v1/messages
- Headers：
  - x-api-key：{{anthropic_api_key}}
  - anthropic-version：2023-06-01
- Body：
  {
    "model": "claude-3-sonnet-20240229",
    "max_tokens": 1024,
    "messages": [
      {"role": "user", "content": "{{user_message}}"}
    ]
  }

8.2 Tools 节点：工具集成

Tools 节点用于调用 Dify 内置工具、自定义工具或子工作流。相比 HTTP Request 节点，Tools 节点提供了更便捷的工具集成方式。

8.2.1 节点功能详解

Tools 节点支持的工具类型：

1. 内置工具：Dify 官方提供的工具

   • 搜索引擎（如 Google、Brave Search）
   • 图像生成（DALL·E、Stable Diffusion）
   • 文件处理工具
   • 更多…

2. 自定义工具：用户自己开发的工具

   • 可以基于 Python 函数创建
   • 支持自定义参数和返回值

3. MCP 工具：通过 Model Context Protocol 集成的外部工具

4. 子工作流：其他 Dify 工作流（需要先发布为工具）

8.2.2 工具 vs HTTP Request

特性	Tools	HTTP Request
认证配置	工具内配置，更便捷	需要手动配置
错误处理	内置完善机制	需要手动配置
调试	支持工具级别调试	支持节点级别调试
适用场景	通用工具调用	特定 API 调用

8.2.3 实际用例

用例一：实时网络搜索

配置：
1. 添加 Brave Search 工具
2. 设置输入：{{sys.query}}
3. 返回搜索结果供 LLM 使用

用例二：图像生成

配置：
1. 添加 DALL·E 工具
2. 设置 prompt：{{image_description}}
3. 生成的图像可以通过 Answer 节点返回给用户

用例三：调用子工作流

场景：订单处理是一个独立的工作流

配置：
1. 将订单处理工作流发布为工具
2. 在主工作流中添加该工具
3. 输入订单信息，获取处理结果

8.3 Human Input 节点：人工介入

Human Input 节点用于在自动化流程中引入人工介入，暂停工作流等待人工确认或输入。

8.3.1 节点功能详解

Human Input 节点的核心作用：

1. 审批流程：需要人工审批才能继续执行
2. 信息确认：需要人工确认某些信息
3. 复杂决策：需要人工做出机器难以处理的决策
4. 异常处理：处理自动化流程无法应对的异常情况

8.3.2 实际用例

用例一：内容审核

用例二：价格审批

场景：AI 生成报价后需要经理审批

流程：
1. LLM 根据客户需求生成报价
2. Human Input 节点暂停，等待经理审批
3. 经理可以批准、拒绝或修改报价
4. 根据审批结果执行后续流程

用例三：客服转接

场景：AI 无法处理的问题转接人工

配置：
- If-Else 节点判断问题复杂度
- 简单问题：AI 直接回答
- 复杂问题：Human Input 节点转接人工客服
- 人工客服处理完成后返回结果

---

九、实战工作流案例

为了帮助大家更好地理解如何使用这些节点构建实际应用，下面介绍几个完整的工作流案例。

案例一：智能客服机器人

需求：构建一个企业客服机器人，能够回答产品咨询、技术支持、售后问题等不同类型的问题。

设计思路：

节点配置详解：

1. Start 节点：

   • 添加文本变量 query（用户问题）

2. Question Classifier 节点：

   • 输入变量：query
   • 分类：产品咨询、技术支持、售后服务、其他

3. Knowledge Retrieval 节点（3个）：

   • 分别连接对应的知识库
   • 输入变量：query

4. LLM 节点（4个）：

   • Context：对应 Knowledge Retrieval 的输出
   • Prompt：根据不同类型定制

5. Variable Aggregator 节点：

   • 合并所有 LLM 的输出

6. If-Else 节点：

   • 条件：检查 confidence 字段是否低于阈值

7. Human Input 节点：

   • 显示待审核内容
   • 允许批准或转接人工

8. Answer 节点：

   • 输出最终答案

案例二：文档处理与问答系统

需求：用户上传 PDF 文档，系统自动提取内容，用户可以针对文档内容提问。

设计思路：

简化版本（使用 RAG）：

案例三：批量邮件处理系统

需求：批量处理用户反馈邮件，自动分类并生成处理建议。

设计思路：

案例四：AI 播客生成器

需求：用户上传文档，系统自动生成 AI 播客（类似 NotebookLM）。

设计思路：

案例五：Deep Research 工作流

需求：针对某个主题进行深度研究，自动搜索、阅读、整合信息。

设计思路：

Loop 节点详细配置：

• 最大迭代次数：10（防止无限循环）
• 退出条件：连续3次迭代没有新发现

Agent 节点配置：

• 工具：搜索引擎、网页阅读器
• 策略：ReAct
• 指令：专注于收集事实和数据

---

十、快速决策指南

为了帮助大家在实际工作中快速选择合适的节点，这里提供一个快速决策指南。

10.1 根据任务类型选择

你的任务	推荐节点	说明
让 LLM 生成文本/回答问题	LLM	最常用的节点
让 LLM 自主调用工具	Agent	需要动态决策的场景
从知识库获取信息	Knowledge Retrieval	RAG 场景
处理用户上传的文件	Document Extractor	PDF、Word 等文档
根据条件执行不同逻辑	If-Else	分支判断
识别用户意图	Question Classifier	意图分类
批量处理数据	Iteration	数组遍历
循环执行直到满足条件	Loop	迭代优化
执行自定义代码逻辑	Code	需要编程实现
格式化输出文本	Template	Jinja2 模板
合并多分支输出	Variable Aggregator	分支结果合并
跨轮次保存数据	Variable Assigner	会话状态保存
从文本提取结构化参数	Parameter Extractor	参数提取
过滤/排序数组	List Operator	数组操作
调用外部 API	HTTP Request	外部服务集成
调用内置/自定义工具	Tools	工具调用
需要人工确认	Human Input	审批/审核场景

10.2 节点组合模式

模式一：基础 RAG

Start → Knowledge Retrieval → LLM → Answer/End

模式二：多知识库路由

Start → Question Classifier → [多个] Knowledge Retrieval → LLM → Answer

模式三：Agent 驱动

Start → Agent (带工具) → Answer/End

模式四：批量处理

Start → HTTP Request → Iteration → [LLM/Code/Tools] → Variable Aggregator → End

模式五：带审核的自动化

Start → [处理节点] → If-Else → [Human Input] → Answer/End

---

十一、总结

Dify 工作流提供了 20 种功能丰富的节点，构成了构建 AI 应用的强大工具箱。这些节点可以大致分为六大类：

11.1 节点分类回顾

1. 起始与结束类（4个）：Start、End、Answer、Output

   • 定义工作流的入口和出口
   • 处理用户输入和系统输出

2. 大语言模型类（2个）：LLM、Agent

   • 赋予工作流理解和生成语言的能力
   • Agent 节点实现了自主决策的突破

3. 知识与检索类（2个）：Knowledge Retrieval、Document Extractor

   • 实现 RAG 能力，让 AI 有"知识"
   • 处理各种格式的文档

4. 逻辑控制类（4个）：If-Else、Question Classifier、Iteration、Loop

   • 让工作流能够"思考"和"决策"
   • 支持复杂的流程控制

5. 数据处理类（6个）：Code、Template、Variable Aggregator、Variable Assigner、Parameter Extractor、List Operator

   • 处理和转换数据
   • 连接各个节点的数据流

6. 外部集成类（3个）：HTTP Request、Tools、Human Input

   • 连接外部世界
   • 扩展应用的能力边界

11.2 核心哲学

通过本文的学习，我们可以看到 Dify 工作流设计的核心哲学：

1. 职责分离：每个节点只专注于一个任务
2. 数据流动：通过变量在节点之间传递数据
3. 可视化编排：通过图形界面直观地构建工作流
4. 灵活性与控制：既有简单的节点，也有强大的自定义能力

11.3 下一步

掌握这些节点后，建议你：

1. 从简单开始：先构建简单的工作流，熟悉基本节点的使用
2. 逐步深入：尝试更复杂的场景，如 Agent、Iteration、Loop 等
3. 参考案例：学习官方和社区的工作流案例
4. 实践出真知：动手构建自己的应用，在实践中加深理解

Dify 的节点体系是为了让 AI 应用的构建变得像搭积木一样简单。希望这篇指南能够帮助你更好地理解和使用这些节点，构建出强大的 AI 应用！

---

参考资料：

• Dify 官方文档
• Dify GitHub
• Introducing Dify Workflow - Dify Blog
• Dify Agent Node Introduction
• Dify Workflow Documentation