Dify 工作流怎么设计？复杂 AI 流程如何拆节点？

Dify 工作流解决什么问题？

Dify 工作流适合处理一个 Prompt 很难讲清的 AI 流程。比如先判断用户意图，再检索知识库，再调用订单系统，最后生成回复并做安全校验。如果这些都塞进一个提示词，测试时可能能跑，上线后出错却不知道错在哪一步。工作流的价值是把复杂任务拆成可观察、可调试的节点。

核心节点怎么理解？

开始节点定义输入字段，比如用户问题、文件、客户 ID。LLM 节点负责分类、总结、改写和生成。知识库检索节点负责召回资料，条件判断节点负责分支，代码节点适合字段校验、JSON 解析和简单计算，HTTP 节点用来调用外部系统，结束节点定义对外输出。

取舍很重要：模型适合理解语言，不适合做确定性计算。金额相加、字段判空、数组转换这类事，用代码节点更稳也更便宜。知识库检索为空时，也不要继续让 LLM 猜答案，应直接走兜底分支或转人工。

复杂流程如何拆节点？

拆分原则是：失败原因不同、调试方式不同、责任边界不同，就拆开。一个客服流程可以拆成“意图识别 → 参数提取 → 知识库检索 → 订单接口查询 → 回复生成 → 安全校验”。这样每个节点都有输入输出，定位问题比看一大段 Prompt 容易得多。

不要一开始就画十几个节点。更稳的做法是先跑通最短链路，再根据真实失败样本加分支。节点越多，可控性越强，但延迟、配置和维护成本也会上升。工作流应该从问题里长出来，而不是为了显得高级而复杂。

数据流转和异常怎么处理？

节点之间通过变量传数据，命名要清楚，比如 user_question、retrieved_docs、order_status。常见坑是上游输出数组，下游当字符串用；HTTP 请求失败，下游还按成功结果生成回复；LLM 输出 JSON 字符串，下游却当对象取字段。关键位置可以加代码节点做类型校验。

生产可用的工作流一定要有异常分支。检索为空、接口超时、用户缺字段、JSON 解析失败，都应该有明确处理。否则用户只会看到“系统异常”，团队也很难复盘。

追问

Workflow 和 Chatflow 有什么区别？

Chatflow 更适合对话助手、知识库问答和轻量工具调用。Workflow 更适合多步骤、强结构、固定输入输出的业务流程。边界是 Chatflow 配置快，但复杂分支容易乱；Workflow 更可控，但节点多了会增加延迟。选择标准不是名字，而是流程是否需要状态和分支。

什么时候用代码节点？

确定性逻辑优先用代码节点，比如字段校验、格式转换、JSON 解析和简单计算。LLM 可以判断语义，但不应该负责可验证的计算。踩坑点是让模型输出“严格 JSON”后直接交给业务系统，边界输入下很容易多一句解释。加代码校验会多一步，但稳定性更好。

知识库检索为空怎么办？

不要让模型继续猜。应该用条件节点判断检索结果数量或相似度，低于阈值就返回“资料未覆盖”或转人工。取舍是兜底回答看起来没那么聪明，但比编造答案安全。很多知识库事故不是检索失败，而是失败后还让模型硬答。

工作流输出怎么保证稳定？

先在 LLM 节点约束字段，再用代码节点解析和校验，失败时重试或走异常分支。只靠提示词要求固定格式不够，模型偶尔会输出解释文字。对接业务系统时，输出字段最好做版本管理。否则工作流里改一个字段名，调用方可能立刻报错。