扣子工作流怎么搭：先想清楚这三件事再连线

扣子里做应用，第一个决定是：直接配一个对话 Bot，还是搭工作流。

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

这篇讲什么时候该搭、怎么搭不容易出事。

扣子的节点类型和界面会随版本调整，本文讲的是设计方法，具体操作以官方文档为准。

先判断：这件事有没有固定步骤

这是最核心的一条。

如果处理逻辑是「理解用户想问什么，然后基于资料回答」——不需要工作流。配一个带知识库的 Bot，把提示词写好就行。硬画成工作流，你会发现大部分节点都在做模型本来就能做的事。

如果处理逻辑是「先做 A，拿结果做 B，根据 B 的情况决定走 C 还是 D」——这才是工作流该干的。

区别在于步骤是不是事先就确定的。

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

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

二、分类后走不同分支。 先判断是售前还是售后，两类走完全不同的路径、用不同的知识库。

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

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

搭的时候最容易出问题的三个地方

这三个地方贡献了我们见过的大部分线上故障。

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

上一个节点输出什么结构，下一个节点期待什么结构——画图时最容易想当然。

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

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

二、只画了正常路径

任何节点都可能失败：接口超时、模型限流、外部服务异常。

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

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

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

三、没留调试信息

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

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

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

图开始失控的信号

出现两个以上，说明该换方式了：

• 嵌套条件超过两三层，改一个分支要先花五分钟看懂现在的结构
• 要维护复杂的中间状态，好几个变量传来传去，得记住每个在哪一步被改过
• 同一段逻辑出现了多次，改一处要记得改另外四处
• 调用顺序需要在运行时决定，而不是固定的 A→B→C

一个更简单的自测：把这个流程用嘴讲给同事听。两三句能说清 → 图没问题；讲了五分钟对方还在问「那如果这种情况呢」→ 已经超出图形化表达的舒适区了。

失控之后往哪走

按代价从低到高：

一、拆成多个应用。 别试图用一张图解决所有事。「售前咨询」和「售后处理」拆成两个，各自的图都简单很多。

二、把复杂逻辑收进单个节点。 与其用二十个节点表达一段判断，不如在一处写清楚。可视化的价值是让人看懂结构，不是让人用连线写程序。

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

第三种情况的判断标准见什么时候必须从低代码转向原生开发。

变量传递：最容易出错也最容易忽略的一环

节点之间靠变量传数据，这里有几个反复出问题的地方。

一、变量名靠记，改一处漏一处。 中间加了个节点、改了个输出字段名，下游引用的地方没跟着改——图上看不出任何异常，跑起来才发现取到空值。

应对：变量命名要有规律且见名知意。别用 result1 output2 这种，用 用户订单号 分类结果 这类一眼能看懂的。名字长一点没关系，改的时候能搜到才重要。

二、空值没处理。 上游可能返回空——查不到数据、接口超时、用户没提供某个信息。下游直接拿来用，轻则显示成空白，重则整条流程报错。

关键节点后加一步判断：拿到空值时走另一条路，或者给用户一个明确提示。

三、类型对不上。 一个节点输出的是数字，下游按文字处理；或者反过来。这类问题在图上完全看不出来，只能在实际跑的时候暴露。

四、多条数据的情况没想到。 上游查出来三条记录，下游节点是按一条设计的——这时候的行为往往不是你期望的。设计时就要问：这一步可能返回几条？

最实际的验证方法：搭完之后，用真实数据完整跑一遍，逐个节点看实际的输入输出。别用理想化的测试数据，用真实场景里那些不规整的数据。

一个常见的误区

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

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

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

实际建议

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

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

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

工作流和 Agent 的概念区别，我们单独写了一篇：工作流和 Agent 到底什么区别——虽然是以 Dify 为例，但这个区分对所有平台通用。

选型或落地上拿不准的，可以找我们聊聊。