从 Dify 工作流说起：常用节点怎么选、怎样组合？

Dify 是很多人接触 AI 工作流的起点。随着流程逐渐复杂，真正需要理解的已经不是怎样把节点拖到画布上，而是职责相近的节点应该怎样选择。

同一段用户输入，既可以让大模型按 JSON 格式输出，也可以交给参数提取器；一次业务接口调用，既可以使用 HTTP 请求，也可以封装成 Tool，或者通过 MCP 调用；条件分支、问题分类器和 Agent 都能影响后续执行路径，但三者的依据和控制范围完全不同。节点选错以后，流程通常也能运行，只是输出不够稳定，后续维护和问题排查会越来越困难。

本文以 Dify 和云程智能体开发平台中的常用节点为例，说明每类节点接收什么输入、产生什么输出、为什么需要单独设计，以及它们通常怎样组合成一条完整的工作流。

一、工作流节点可以分为六类

工作流中的节点虽然很多，按照职责可以归纳为六类。先确定当前步骤属于哪一类，再选择具体节点，比逐个记忆节点名称更容易形成清楚的设计思路。

节点类别	常见节点	主要职责	典型输出
输入与输出	用户输入、输出、回复	定义工作流与用户或调用系统之间的数据边界	用户字段、结构化结果、对话消息
AI 理解与决策	大模型、参数提取器、问题分类器、Agent	理解自然语言、生成内容或作出语义判断	文本、结构化字段、分类结果、Agent 执行结果
知识与文件	知识检索、文档提取器	从知识库或用户文件中取得可供处理的内容	知识片段、文档文本、文件信息
数据处理	字段映射器、模板转换、代码执行、列表操作、变量聚合器、变量赋值	用确定性规则整理和保存数据	字段、文本、对象、数组或状态变量
外部能力	HTTP 请求、Tool、MCP	调用工作流之外的业务系统和工具	响应正文、JSON、业务结果或错误信息
流程控制	条件分支、迭代、循环、人工介入	决定执行哪条路径、重复执行多少次、何时暂停和恢复	分支出口、结果数组、循环状态、人工处理结果

Dify 和云程智能体开发平台对节点的命名、配置界面略有不同，但主要职责基本落在这些类别中。一个节点是否有必要单独存在，关键不在于它能否被大模型或代码替代，而在于它能否提供更明确的输入输出、更稳定的运行行为和更容易检查的执行记录。

二、输入与输出节点定义应用的数据边界

用户输入、输出和回复节点看起来简单，却直接决定工作流怎样被页面、API 或其他应用调用。它们处理的不是某一步业务逻辑，而是整个工作流的输入输出协议。

节点	输入	输出	设计目的	常见组合
用户输入	用户填写的文本、数字、选项、文件等	按字段名和类型组织的输入变量	把外部请求转换为工作流内部可以引用的变量	用户输入 → 参数提取、文档提取、知识检索
输出	上游节点产生的一个或多个变量	字段名称、类型和取值明确的结构化结果	为 API 或其他系统提供稳定的返回结构	字段映射、代码执行、变量聚合 → 输出
回复	上游变量和回复模板	返回给当前会话的自然语言消息	在 Chatflow 中完成一轮对话并呈现结果	知识检索 → 大模型 → 回复

输入节点应当尽量把能够确定的约束提前写清。例如，发票附件应使用文件或文件列表类型，报销金额应使用数字类型，报销类别适合使用选项。这样既能在入口处拦截明显错误，也能避免后续节点反复解析同一份数据。

输出节点解决的是另一个问题：内部流程可以调整，但对外返回的字段应当保持稳定。工作流内部可以把 HTTP 请求换成 Tool，也可以调整模型和提示词，只要最终仍然返回 status、amount、message 等约定字段，调用方就不需要跟着修改。回复节点则面向对话用户，更适合返回经过组织的自然语言，而不是供程序继续处理的复杂对象。

因此，一条面向系统集成的 Workflow 通常以"用户输入---处理节点---输出"结束；一条面向多轮对话的 Chatflow 则通常以"用户输入---检索或处理---大模型---回复"完成当前轮次。

三、四种 AI 节点解决的是不同问题

大模型、参数提取器、问题分类器和 Agent 都会使用模型能力，但它们交给模型的任务并不相同。大模型节点负责生成，参数提取器负责把语言转换成字段，问题分类器负责选择预设路径，Agent 则负责在运行过程中决定行动步骤。

节点	主要输入	主要输出	为什么单独设计
大模型	提示词、用户问题、上下文、知识片段	文本或预先定义的结构化结果	适合总结、改写、推理和内容生成，任务形式最灵活
参数提取器	一段自然语言和字段定义	按名称、类型组织的字段，以及提取状态	把不固定的表达转换成下游节点可以直接使用的参数
问题分类器	用户问题和分类说明	命中的分类及对应分支	用语义判断选择预先定义的出口，流程边界仍由设计者控制
Agent	任务、上下文、可用工具和执行策略	最终结果、工具调用过程及相关运行信息	在步骤无法完全预先确定时，由模型根据中间结果继续选择工具和行动

大模型与参数提取器

如果结果主要供人阅读，例如生成摘要、解释政策或改写文案，应当使用大模型节点。如果下游需要的是订单号、日期、金额等明确字段，参数提取器更合适。它不仅要求模型按字段输出，还会把字段名称、类型、必填规则和默认值纳入节点配置，使后续 HTTP、Tool、条件分支可以直接引用。

让普通大模型节点输出 JSON 也能完成字段提取，但提示词、解析规则和异常处理都需要自行维护。参数提取器存在的意义，就是把"自然语言转结构化参数"固化为一个具有明确数据协议的步骤。在 Dify 中，参数提取器还会提供提取是否成功及失败原因等结果，便于后续分支处理。

常见组合是：

用户输入 → 参数提取器 → 条件分支检查必填字段
                         ├─ 完整 → HTTP / Tool / MCP
                         └─ 缺失 → 回复补充信息

问题分类器与条件分支

问题分类器判断的是语义类别，例如把"怎么申请退款""退款多久到账""商品已经损坏"分别归入申请、进度和售后分类。分类结果直接对应不同出口，后续路径在设计阶段已经确定。

条件分支判断的是明确变量，例如金额是否大于 5000、接口状态码是否为 200、字段是否为空。凡是可以写成稳定规则的判断，都应优先使用条件分支；只有判断依赖语义理解时，才需要问题分类器。

常见组合是"问题分类器 → 不同领域的知识检索 → 大模型 → 回复"。分类器先缩小知识和处理范围，后续节点不必用一套提示词同时处理所有问题。

Agent 与固定工作流

Agent 节点内部通常包含多轮"判断---调用工具---读取结果---继续判断"。它适合工具选择和执行次数无法提前确定的任务，例如让 Agent 根据故障描述决定查询监控、检索知识还是读取工单。

Dify 的 Agent 节点可以配置模型、策略和工具，由 Agent 在节点内部自主调用；云程平台的 Agent 节点可以调用已经配置并发布的 Agent 版本，再把工作流变量映射为 Agent 输入。两种方式都适合采用"外层工作流固定、局部 Agent 自主"的结构：身份校验、业务规则、人工审批和最终写入仍由工作流控制，只有确实需要动态判断的一段任务交给 Agent。

四、文档提取与知识检索不能互相替代

文档提取器和知识检索都会得到文本，但二者面对的资料来源和处理方式不同。

文档提取器读取本次工作流中上传的 PDF、Word、表格等文件，输出文档文本或文本数组。它适合处理每次都不同的临时材料，例如合同、简历、发票附件和会议记录。文档提取只解决"把文件内容取出来"的问题，后面通常还要连接大模型、参数提取器或代码节点完成总结、识别和校验。

知识检索读取的是已经进入知识库并完成解析、切片和索引的资料。它接收用户问题或检索词，输出相关知识片段及来源、文档信息等元数据。知识检索适合反复使用的制度、产品手册、操作规程和历史案例，后续大模型依据命中片段组织回答。

两类节点常见的组合分别是：

单份临时文件：文件输入 → 文档提取器 → 参数提取 / 大模型 → 输出

多份临时文件：文件列表 → 列表操作 → 迭代
                                   └─ 文档提取器 → 大模型
                              → 汇总结果 → 输出

知识问答：用户问题 → 知识检索 → 条件分支检查命中结果
                                ├─ 命中 → 大模型 → 回复
                                └─ 未命中 → 说明或转人工

知识检索结果通常是片段数组，不应未经处理就直接作为最终答案。大模型节点需要同时接收用户问题和检索片段，并在提示词中明确回答范围和引用要求。对于未命中的情况，也应通过条件分支单独处理，避免模型在没有资料依据时继续补全答案。

五、数据处理节点负责把结果整理成可用的数据

AI 节点和外部接口经常返回较复杂的文本、对象或数组。数据处理节点把这些结果转换成下游需要的形式，并尽量使用确定性规则完成计算、映射和格式化。

节点	输入与输出	适合完成的任务	常见前后节点
字段映射器	对象或 JSON → 指定字段	按路径提取、改名和设置默认值	HTTP / Tool / MCP → 字段映射 → 条件分支
模板转换	多个变量 → 一段文本	拼接提示词、通知内容和固定格式摘要	字段或知识片段 → 模板 → 大模型 / 回复
代码执行	字段、对象、数组 → 自定义结果	计算、清洗、复杂结构转换	参数提取 → 代码 → 条件分支 / 输出
列表操作	数组 → 过滤、去重、排序或截取后的数组	控制批量处理对象及顺序	文件列表 / 检索结果 → 列表操作 → 迭代
变量聚合器	多个候选变量 → 一个统一变量	汇合互斥分支的结果	IF / ELSE 各分支 → 变量聚合 → 公共后续节点
变量赋值	新值和可写变量 → 更新后的状态	更新会话状态、循环页码和累计结果	循环 / 对话处理 → 变量赋值 → 下一轮

字段映射器、模板转换和代码执行的边界尤其容易混淆。只需要从接口返回的对象中取出 data.status 和 data.amount 时，字段映射器最直接；只需要把姓名、时间和结果拼成通知文本时，模板转换更清楚；只有涉及计算、复杂条件或多层结构重组时，才需要代码执行。

变量聚合器并不是普通的"合并数据"节点。它主要用于互斥分支汇合：IF 分支输出 approved_result，ELSE 分支输出 rejected_result，每次只会有一个变量存在，聚合器把实际产生的结果统一为 output。如果两条并行路径都会产生结果，并且需要同时保留，应该使用代码或模板明确组合，而不是依赖候选变量取值。

变量赋值也不同于变量聚合。聚合器生成一个供下游读取的统一输出，变量赋值则修改会话变量或循环变量，使状态能够进入下一轮对话或下一次循环。例如分页查询每轮结束后更新页码，Chatflow 收集完联系电话后更新"资料收集状态"，都属于变量赋值。

六、HTTP、Tool 和 MCP 对应三种外部能力接入方式

工作流要查询订单、写入报销单或调用搜索服务，最终都需要访问外部能力。HTTP、Tool 和 MCP 的区别不在于能不能发出网络请求，而在于能力如何描述、复用和管理。

节点	配置和输入	主要输出	适用情况
HTTP 请求	URL、方法、鉴权、Header、Query、Body	状态码、响应正文、JSON、Header 等	已经有明确接口，需要在当前流程中直接调用
Tool	平台中已定义的工具及其参数	按工具定义返回的业务结果	同一项业务能力会被多个工作流或 Agent 复用
MCP	MCP Server、Tool 和输入 Schema	MCP Tool 返回的文本、对象或数组	外部能力已经按 MCP 协议提供，需要按统一方式发现和调用

HTTP 节点最接近一次直接的接口集成，调用细节都保留在当前工作流中。Tool 把接口名称、参数结构、鉴权和返回说明封装成可复用能力，工作流和 Agent 只需要按工具定义传参。MCP 则使用标准协议描述和调用外部工具，适合接入已经提供 MCP Server 的系统。

在固定业务流程中，如果调用顺序已经明确，应当直接连接 HTTP、Tool 或 MCP 节点，使每一步输入输出都可以检查。只有工具选择依赖任务内容和中间结果时，才需要把多个工具交给 Agent 动态选择。

外部节点通常不会单独使用。一条较稳定的业务调用链路是：

用户输入
  → 参数提取器：取得订单号、日期等参数
  → 条件分支：检查必填参数
  → HTTP / Tool / MCP：查询或办理业务
  → 字段映射器：提取状态、数据和错误码
  → 条件分支：区分成功、业务失败和系统异常
  → 模板转换 / 输出

这条链路把自然语言理解、接口调用、数据整理和错误处理分开。接口字段变化时检查映射节点，用户表达解析失败时检查参数提取器，业务返回异常时检查外部调用节点，不需要从一段大模型提示词中寻找所有问题。

七、流程控制节点决定路径、次数和暂停位置

流程控制节点本身通常不生产业务内容，它们根据已有数据改变后续节点的执行方式。

节点或结构	输入	输出或执行结果	设计目的	常见组合
条件分支	一个或多个明确变量及判断规则	命中的 IF、ELIF 或 ELSE 路径	用确定性规则选择互斥路径	参数提取 / 字段映射 → 条件分支 → 变量聚合
并行路径	同一个上游结果	多条路径分别产生结果	同时完成互不依赖的任务	文档提取 → 摘要、风险识别、关键词提取
迭代	一个数组	每一项子流程结果组成的数组	对一批已经存在的数据逐项执行相同处理	列表操作 → 迭代 → 汇总
循环	循环变量和退出条件	循环结束时的累计结果和状态	根据本轮结果决定是否继续下一轮	HTTP / 大模型 → 变量赋值 → 退出判断
人工介入	待确认内容、表单字段和动作	人工填写字段、选择动作及对应分支	在流程中暂停，等待审批、补充或复核后继续	规则校验 → 人工介入 → Tool 写入

条件分支与并行路径的区别在于，条件分支每次只执行符合条件的路径，并行路径则会同时执行多条互不依赖的处理。互斥分支结束后常用变量聚合器统一结果；并行路径需要同时保留结果时，应明确等待哪些路径完成以及怎样组合输出。

迭代处理的是一个已经存在的数组，执行次数通常由数组长度决定。进入迭代内部后，每轮会得到"当前项"和"当前索引"等局部变量，子流程处理当前项，容器最终收集每轮结果。Dify 和云程平台都支持这种数组驱动的处理方式；云程平台还可以为迭代设置串行、并行和最大并发数。

循环处理的是逐轮变化的状态。例如分页查询时，当前页码、累计数据和"是否还有下一页"都要在每轮结束后更新；内容反复修订时，本轮评分决定是否继续生成下一版。循环因此需要循环变量、退出条件和最大次数，内部通常与变量赋值节点配合。

两者的选择可以归结为一个问题：处理对象是否已经完整存在。已有文件数组、评论列表或检索结果时使用迭代；下一次是否执行要由本轮结果决定时使用循环。

人工介入节点会把运行中的工作流转换为待处理任务。运行引擎需要保存已完成节点、当前变量和待处理表单，用户提交"通过""驳回"或补充字段以后，再从暂停位置恢复。它通常放在高风险写入之前，而不是用来代替流程入口的普通用户输入。

八、节点之间传递的是有类型的数据

连线决定哪些节点具有执行关系，变量引用决定下游节点实际读取哪一份数据。一条业务查询流程中的数据可能这样传递：

用户输入/query
  → 参数提取器/order_id
  → HTTP 请求/json
  → 字段映射器/order_status
  → 条件分支读取 order_status

每个节点的输出都应当被看作一份数据协议。除了字段名称，还要确认字符串、数字、布尔值、对象、数组和文件等类型。数字 5000 与字符串 "5000" 在比较时含义不同；文档提取器需要文件变量，迭代节点需要数组变量；知识检索输出的是片段数组，而不是已经完成的自然语言答案。

Dify 通过变量选择器引用上游节点的输出。云程平台也采用变量选择方式，并在运行状态中按照节点标识和字段名区分输出，避免多个节点都产生 text 或 result 时互相覆盖。环境变量适合保存接口地址和固定配置，会话变量适合保存 Chatflow 跨轮状态，循环变量则只承担循环过程中的可变状态。

分支流程还会带来一个常见问题：没有执行的分支不会产生输出。如果公共后续节点直接引用某一分支的变量，走到另一条路径时就可能得到空值。互斥分支应当先通过变量聚合器形成统一输出，再交给后续节点。

调试时应沿着数据传递顺序查看节点运行记录，重点检查：

1. 当前节点实际读取了哪些字段，字段路径和类型是否正确；
2. AI、知识检索或外部接口返回了什么，是否符合节点约定的输出结构；
3. 条件分支选择了哪个出口，未执行路径中的变量是否被下游误用；
4. 迭代每一项和循环每一轮分别产生了什么结果；
5. 节点失败以后采用了终止、重试、默认值还是异常分支。

Dify 提供单节点测试、缓存变量和运行日志，便于在固定上游结果的情况下调整当前节点。云程平台的调试运行和运行历史会记录节点输入输出、耗时、错误、重试和分支信息；人工介入、迭代和循环还需要关注暂停状态、每项结果和退出原因。

九、五种常见的节点组合

理解单个节点以后，可以用下面几种组合检查一条工作流的结构是否合理。

业务场景	节点组合	组合要点
企业知识问答	用户输入 → 知识检索 → 未命中判断 → 大模型 → 回复	检索负责提供依据，大模型负责组织回答，未命中单独处理
自然语言查询业务数据	用户输入 → 参数提取器 → Tool / HTTP → 字段映射器 → 条件分支 → 输出	语言解析、系统调用和结果判断各自使用明确节点
批量处理文档	文件列表 → 列表操作 → 迭代（文档提取 → 大模型）→ 汇总 → 输出	迭代内部只处理当前文件，并根据外部服务能力控制并发
固定流程中使用 Agent	输入校验 → Agent → 结果检查 → 人工介入或输出	工作流控制业务边界，Agent 只处理步骤不确定的局部任务
审批后写入业务系统	参数提取 → 规则校验 → 人工介入 → Tool 写入 → 输出	人工确认放在高风险操作之前，写入结果继续检查和记录

这些组合并不是固定模板。设计时真正需要确认的是：当前步骤需要的是自然语言理解还是确定性处理，输入输出能否被下游直接使用，路径由规则、语义还是 Agent 决定，批量任务由数组驱动还是由运行状态驱动，以及外部操作失败后流程应当怎样处理。

节点的价值不只在于提供一项功能，更在于把一项处理约束成明确的输入、输出和运行行为。把这些边界设计清楚以后，工作流会更容易调试，也更适合继续接入知识库、Agent 和真实业务系统。