基础三：常用节点应该怎么选

Dify 的节点很多，但大多数需求都可以从六类能力中选择：让模型理解内容、取得外部事实、控制路线、处理数据、连接系统，以及返回结果。选节点时问“这一步需要什么能力”，比记住菜单位置更可靠。

理解与生成

LLM 用于摘要、改写、解释、比较和生成。输入应包含任务说明、必要上下文和清楚的输出要求。需要固定 JSON 时优先使用结构化输出能力，再由后续节点校验，不要只在提示词里说“请严格返回 JSON”。

Question Classifier 用于把一段用户表达路由到少数已知类别，例如售前、售后、投诉和其他。类别应互斥并提供清楚描述。它适合决定走哪条路，不适合提取订单号或生成最终回答。

Parameter Extractor 用于从自然语言中提取结构化字段，例如姓名、日期、平台列表和订单号。先定义字段名称、类型、是否必填和含义；如果输入本来就是结构化数据，就不必再调用模型提取。

Knowledge Retrieval 用于从已建立索引的知识库取回相关片段。它解决“给模型哪些事实”，不负责形成最终答案。检索结果应作为上下文交给 LLM，并在知识不足时允许拒答。

Document Extractor 用于把上传的文档转换成后续节点可读取的文本。它不等于完整的版面理解或业务字段提取；通常后面还要连接参数提取、LLM 或代码节点。

List Operator 用于筛选、排序或选择文件与数组元素。当输入是文件列表或结构化数组时，先用列表操作缩小范围，比把全部内容直接交给模型更省成本。

IF/ELSE 适合可明确写成条件的分支，例如状态码是否为 200、必填字段是否为空、分数是否达到阈值。能用规则判断的事情，不要额外调用分类模型。

Iteration 用于对列表中的每个元素执行相同子流程，例如为多个平台分别生成内容，或逐个处理文件。它处理的是“有一组元素”。

Loop 用于在满足停止条件前重复执行，例如逐轮修正结果。循环必须有最大次数和失败出口；如果次数本来固定且输入是数组，Iteration 通常更合适。

Variable Aggregator 用于把互斥分支产生的同类结果汇合成一个下游变量。它不是文本拼接器，也不会自动把不同数据类型变成一致结构。各分支的输出类型应先对齐。

Template 用于固定格式拼接、字段排版和简单转换。标题、分隔符和稳定的输出骨架交给模板，比交给 LLM 更便宜、更一致。

Code 用于精确计算、复杂校验、JSON 转换和模型不应承担的确定性逻辑。代码节点应保持短小，明确处理空值和异常，不要在其中偷偷承担整个业务系统。

Variable Assigner 用于更新会话变量或流程状态，例如记录当前办理阶段和已经确认的字段。只有后续轮次确实需要这些状态时才保存，避免把大量原文长期留在会话中。

HTTP Request 适合直接调用已知的 REST API，尤其是请求和响应结构清楚、无需模型决定是否调用的场景。必须处理鉴权、超时、状态码和错误分支。

Tool 是对外部能力的可复用封装，可以来自插件、自定义 API 或另一个 Workflow。多个应用都要使用同一能力时，封装为工具比复制 HTTP 配置更容易维护。

Agent 用于让模型根据目标和中间结果选择工具。只有步骤无法预先确定时才使用，并限制工具权限、最大迭代和写操作确认。

Answer 面向聊天用户，可以在流程中逐步或最终返回自然语言。Output 面向一次性 Workflow 和 API 调用方，应该提供稳定的结构化结果。

最常见的错误，是因为某个节点“更智能”就优先选它。可靠的顺序应当是：规则能解决就用规则，确定流程能解决就用 Workflow，只有确实需要自主选择动作时才用 Agent。