Dify 工作流什么时候该用、什么时候是在自找麻烦

Dify 里做一个应用，第一个决定就是选类型：是做一个直接对话的助手，还是编排一条工作流。

很多人默认选工作流——看起来更专业、更可控。然后就掉进坑里了：本来三句提示词能解决的事，画成了十几个节点的图，改一次要盯着看半天。

这篇讲怎么判断。

Dify 的应用类型、节点种类和界面会随版本调整，本文讲的是判断方法，具体功能以官方文档为准。

先问一个问题：这件事有没有固定步骤

这是最核心的判断标准。

如果处理逻辑是「理解用户想要什么，然后基于资料回答」——这是对话型需求。用聊天助手加知识库，配好提示词就行。硬要画成工作流，你会发现大部分节点都在做本来模型自己就能做的事。

如果处理逻辑是「第一步做 A，拿到结果做 B，根据 B 的情况决定做 C 还是 D」——这是流程型需求，工作流是对的。

区别在于：步骤是不是事先就确定的。 对话型场景里，该查什么、该怎么答，是模型根据当下情况决定的；流程型场景里，步骤是你定好的，模型只负责其中某几步的具体执行。

工作流真正适合的四类场景

一、需要固定几步顺序的处理。 比如：先提取用户输入里的关键信息 → 用这些信息查询 → 把查询结果整理成指定格式。每一步的输入输出都明确。

二、需要分类后走不同分支。 比如：先判断用户问的是售前还是售后，两类问题走完全不同的处理路径、用不同的知识库。

三、输出格式必须严格可控。 需要产出结构化的结果给下游系统用，不能是自由发挥的一段话。工作流可以在最后加一步做格式约束和校验。

四、要调用外部接口再加工。 查了外部数据之后还要做进一步处理，不是拿到就直接给用户。

节点图开始失控的四个信号

出现两个以上，说明这件事已经不适合继续用可视化编排了：

信号一：嵌套条件超过两三层。 画在图上是一堆交叉连线，改一个分支要先花五分钟看懂现在的结构。

信号二：要维护复杂的中间状态。 好几个变量在节点间传来传去，你得记住每个变量在哪一步被改过。

信号三：同一段逻辑在图里出现了多次。 代码里抽个函数的事，在节点图里变成复制粘贴，改一处要记得改另外四处——这是 bug 的温床。

信号四：调用顺序需要在运行时决定。 不是固定的 A→B→C，而是要根据情况动态决定先做哪个。节点图本质是静态连线，表达动态调度很别扭。

一个更简单的自测方法

把这个流程用嘴讲给同事听。

能用两三句话说清楚「先查知识库，查到就回答，查不到就转人工」——工作流完全够用，甚至可能不需要工作流。

讲了五分钟对方还在问「那如果是这种情况呢」——说明逻辑分支的密度已经超出了图形化表达的舒适区。这时候硬用节点图，不是在偷懒，是在给未来的自己挖坑。

失控之后该往哪走

有三个方向，按代价从低到高：

第一，拆成多个应用。 不要试图用一张图解决所有事。把「售前咨询」和「售后处理」拆成两个独立应用，各自的图都会简单很多，路由的事在更上层解决。

第二，把复杂逻辑下沉到代码节点。 Dify 支持在流程里嵌入代码。与其用二十个节点表达一段判断逻辑，不如在一个代码节点里写清楚——可视化的价值是让人看懂结构，不是让人用连线写程序。

第三，整个换成原生开发。 当逻辑复杂到代码节点也装不下、或者需要和外部系统深度联动时，继续留在平台里就是在跟工具较劲。

第三种情况的判断标准，我们单独写了一篇：什么时候必须从低代码转向原生开发。

工作流里最容易出问题的三个地方

如果确定了要用工作流，有三个地方值得提前想清楚，它们贡献了我们见过的大部分线上问题。

一、节点之间的数据格式没对齐

上一个节点输出的是什么结构，下一个节点期待的是什么结构——这件事在画图的时候很容易想当然。

模型节点的输出尤其不可控。你要它返回一个 JSON，它大部分时候会返回 JSON，但偶尔会在前后多加一句解释，或者用了不同的字段名。下游节点按固定结构去取值，就会取到空的。

处理办法：在模型节点之后加一步格式校验和兜底。校验不通过时，要么重试，要么走一条降级路径，而不是让错误一路传下去——错误传得越远，排查起来越难，最后你会在最末端看到一个莫名其妙的空值，而真正的问题发生在三步之前。

二、没想清楚失败了会怎样

工作流里任何一个节点都可能失败：接口超时、模型限流、外部服务返回异常。

画图的时候大家都在画正常路径，因为那是能跑通的、看得见成果的那条。异常路径要么没画，要么画了个笼统的「出错提示」。

至少要想清楚三件事：这一步失败了要不要重试？重试几次之后放弃？放弃之后用户看到什么？

尤其注意有副作用的节点——发消息、写数据、扣额度这类。这些节点重试的时候，会不会重复执行？如果会，后果能不能接受？

三、调试信息不够，出了问题看不出在哪

流程在线上跑挂了，你需要知道是哪一步、输入是什么、输出是什么。

如果没有刻意留这些信息，排查就只能靠猜和复现。而有些问题恰恰是特定输入才触发的，复现本身就很难。

建议在关键节点后留下可查的记录，尤其是模型节点的实际输入输出。这件事在开发阶段觉得多余，出问题时会庆幸自己做了。

一个常见的误区

「用工作流是为了让结果更稳定」——这个想法只对了一半。

工作流能让流程稳定，不能让模型输出稳定。如果某一步的问题是模型答得不稳，把它拆成三个节点也还是不稳，只是不稳的地方从一处变成三处。

输出不稳定的正确解法是：约束提示词、限定输出格式、在关键步骤后加校验。这些事在聊天助手里也能做，不需要为此改成工作流。

实际建议

先用最简单的形式跑通。 能用聊天助手解决就别上工作流，能用三个节点就别用十个。

加节点要有明确理由。 每加一个节点问一句：这一步为什么不能让模型自己完成？答不上来就删掉。

定期回头看图。 如果一张图你自己隔两周再看要重新理解一遍，那它已经太复杂了，该拆了。

在判断该用平台还是该做定制的阶段，也可以直接找我们聊聊——现成平台能解决的，我们会直说。