你在画布上拖了一个节点：调一个 API，查一次数据库，或者让 AI 生成一段内容。
然后你遇到了两个朴素的问题：怎么让这个节点"有时候跑、有时候不跑"？怎么让它"循环跑"？
比如：订单金额超过 1000 才走这个分支；把客户列表里的每个客户都过一遍这个流程；上游失败了就不该继续，但有时候失败了又得继续。
大多数平台的答案非常统一：拖一个特殊节点进来。
想要条件判断？拖一个"条件分支"节点，从它引出两条线。想要循环？拖一个"循环"节点，把要重复的内容塞进去。
控制流不是业务节点自带的能力，而是画布上的"外来物种"——你需要它的时候，去节点库里翻出来，拖进画布，重新连线。
这个方案没什么不好，行业里大家基本都这么做。但它有一个被低估的代价，藏在一个很具体的地方。
一、为了一个判断，你要改一次画布的结构
先看一个最常见的场景。
你有一个节点，它处理订单。大部分订单金额不大，只有少数大额订单需要额外走一道人工审核。于是你在画布上做了这么一件事：
把一个"条件分支"节点插进链路中间——左边连进来，右边引出两条线，一条通向"继续处理"，一条通向"人工审核"。原本一条直线的画布，变成了一个分叉。
这个操作本身不难。但你有没有注意到，你为了表达"这个节点要不要跑"，修改了画布的拓扑结构。
问题来了：
第一，判断逻辑和业务逻辑分家了。 节点自己不知道自己什么时候该跑。它的命运写在另一个节点里——那个"条件分支"节点决定往哪边走。业务节点是哑的，控制流节点是唯一的"大脑"。你看着画布上那个处理订单的节点，完全看不出来它只在金额大于 1000 时执行。
第二，小判断也要大动干戈。 只是"这个节点要不要跳过"这种一句话的事，却要在画布上多出两个节点、两条连线。画布上的一半节点是业务，另一半是控制流——时间一长，你分不清谁是干活儿的，谁是指挥的。
第三，嵌套和组合让画布指数级变乱。 条件里套条件、循环里套条件、条件里套循环……每加一层，就要在画布上多摊开几个节点。复杂流程的画布最后会变成一团蜘蛛网，节点连线互相穿插，改一个分支要小心翼翼找半天线头。
这些都是"控制流 = 特殊节点"这个方案的代价。它不是什么致命缺陷，但它确实存在——尤其是当你的画布里充满了"这个节点要不要跑"这种轻量级问题时，这个代价会反复出现，积少成多。
二、另一种设计：每个节点都自带控制流
我们做了一个不太一样的选择：把控制流内置到每个节点里。
不管你拖的是什么类型的节点——调 API、查数据库、让 AI 生成——它的配置面板里都自带三组控制能力：
第一，前置条件：满足才跑，不满足整个分支跳过。
你可以给任何节点配一个条件："只有上游的返回值大于 1000 才执行我"。条件不满足时，这个节点被标记为跳过——而且注意，不是只跳过它自己，它下游的分支会一起跳过。
这是刻意的语义。判断"这个节点跑不跑"，几乎总是意味着"这条业务路径走不走"。如果只跳过当前节点、下游照跑，那下游拿着空值继续干活，才是真正的灾难。所以前置条件的语义是：条件不满足，这整条分支都不走。
第二，循环控制：满足规则就一直循环，连续失败自动熔断。
你想"把列表里的每个客户都过一遍"？不用拖循环节点，直接在节点上打开循环开关，配好循环参数和终止条件就行。支持两种循环：按条件循环（满足就继续，直到条件不再成立），按列表循环（遍历每个元素跑一次）。
循环最怕什么？死循环。AI 应用的循环尤其危险——一个不稳定的调用在循环里反复失败、反复重试，账单会悄悄烧穿。所以循环配了熔断：连续失败 N 次，自动停，不让你在死循环里烧钱。
第三，事件等待：等不到就挂起，超时就放弃。
有的节点要等一个外部事件——等 webhook 推数据，等人工在另一个系统里点了确认。配了事件等待，节点会在等待状态挂起，整个画布暂停，事件到达了再唤醒继续跑。万一事件一直不来呢？有个超时兜底，等够时间就放弃，不让你无限期挂起。
这三组能力，是每个节点的标配，不是某个特殊节点的特权。
这意味着什么？意味着你想让"这个订单节点只在金额大于 1000 时执行"，不用动画布一根线——翻到节点的配置面板，配一个条件，完事。画布结构不变，业务路径和判断逻辑待在同一个地方，你看着节点就能知道它什么时候跑、跑几遍。
三、为什么"每个节点都自带"，是个更省心的设计
有人会问：把控制流塞进每个节点，节点配置不是变复杂了吗？
这里要分清一件事：复杂的是平台在开发时扛下来的，不是用户在用时承担的。
对用户来说，这个设计恰恰是更简单的——因为它在两个维度上同时做了减法：
维度一：画布变简单了。 轻量判断不再产生新的节点和连线。画布上剩下的，几乎全是真正干活的节点。你看一眼画布，就知道这条流程在处理什么，而不是在一堆控制流节点里找业务逻辑。
维度二：判断跟着业务走。 "这个节点什么时候跑"就写在节点自己的配置里。你想知道订单节点为什么有时候不跑，打开订单节点的配置，条件就写在那儿——不用去画布上找一个叫"条件分支"的节点，看它怎么连的线。
打个比方。特殊节点方案像公司里的"审批岗"——所有事都要送到审批岗那里过一道，你问业务部门"这事为什么没批"，业务部门说"你去问审批岗"。节点自带方案像"授权到岗"——每个岗位自己知道自己什么情况下有权做事，你问业务部门，他自己就说得清。
对编排平台来说，还有一层更本质的好处：节点自己决定命运，平台就不用替它猜。
在《画布的保存按钮背后，站着一个编译器》那篇文章里我们讲过，保存画布的时候，平台会把拓扑结构编译好，运行时只读结果。但"结构"解决的是"谁先跑、谁后跑"，解决不了"这个节点这次到底跑不跑"——后者是运行期才知道的事，依赖本次运行的实际数据。
把判断下沉到节点，正好补上这块：结构在编译期定死，决策在运行期由节点自己做。 平台不需要在运行期去解析"那个条件分支节点要往哪边指"，每个节点自己就带着答案。
四、但复杂拓扑，还是需要"控制流节点"
说到这里，可能会产生一个误会：是不是所有控制流都塞进节点，画布上就不需要控制流节点了？
不是。拓扑级控制流我们同样纳入了设计——为复杂拓扑预留了三个控制流节点类型，专门应对节点级控制流覆盖不到的场景。
条件分支节点：多路路由——一个输入，根据条件走到多个分支之一。适合"订单金额分三档，走三条不同的处理路径"这种多路判断。
循环控制节点：把一整段子流程包在循环里重复跑。适合"这五个节点组成一个完整步骤，要对每个客户整体重复一遍"这种场景。
上游汇聚节点：多个上游分支的结果汇聚到一起，统一喂给下游。适合"三条路径都跑完了，汇总结果"这种场景。
为什么要保留它们？因为判断的"粒度"不同。
"这个节点跑不跑"是节点级的问题，塞进节点配置最合适——改了不改拓扑，判断跟着业务走。但"这整段流程往哪边走"是拓扑级的问题——它改变的是流程的形状，不是某个节点的命运。这种问题，用独立的控制流节点来表达，画布反而更清晰：你能看到流程在哪个点分叉、在哪个点汇聚。
所以这不是二选一，是分层：
- 节点级控制流（每个节点自带）：处理"这个节点要不要跑、循环几遍、等多久"——轻量，不改拓扑，判断跟着业务走。
- 拓扑级控制流（独立控制流节点）：处理"这段流程往哪边走、哪个分支执行"——复杂，需要显式的分叉和汇聚。
轻量的判断，不该逼用户改拓扑；复杂的拓扑，不该硬塞进节点的配置面板。两种方案各管一段，正好覆盖从"一句话的判断"到"整段流程的分叉"全谱系。
五、行业里大家都怎么做？
把控制流做成特殊节点，是编排领域的普遍做法，各家的实现各有特点。
n8n 提供 IF 节点（二元判断）和 Switch 节点（多路分支）。想循环，做法是把节点输出接回前面的节点形成回路，再用 IF 节点判断什么时候停——循环是"画拓扑"画出来的。
Dify 把控制流单独列为一类节点：条件分支（IF/ELSE）、迭代（对列表循环）、循环（直到满足条件）。用条件，就在画布上放一个条件分支节点。
ComfyUI 有"条件执行"节点，按条件选择执行路径；节点的 Mode 也支持 Always/Never/Bypass 这类节点级开关——这是少数带了"节点自身开关"思路的实现。
阿里云 PAI、华为云 AppStage 也都提供"条件分支"节点，走的是同样的特殊节点路线。
数据调度领域（阿里 DataWorks 等）用的是 do-while 节点、for-each 节点——循环被做成"容器节点"，要重复的内容包在容器里。
可以看到，行业的主流是"控制流 = 特殊节点/容器节点"。各有各的道理：特殊节点可视化更显式，复杂分支一眼就能看出分叉在哪里；容器节点把循环范围画得明明白白。
我们的选择是：把轻量判断下沉到每个节点，同时把拓扑级控制流纳入设计。 这不是说谁比谁好——不同粒度的控制流问题，本来就需要不同的载体。只是在"这个节点要不要跑"这种高频轻量问题上，我们选了让节点自己决定，而不是让用户为了它改一次画布。
六、回到那两个朴素的问题
回到开头：怎么让一个节点"有时候跑、有时候不跑"？怎么让它"循环跑"？
我们的答案是：不用拖特殊节点，不用改画布。翻到节点的配置面板，自己决定。
决定权在节点手里，而节点的命运，由你写的条件说了算——这正是《画布的保存按钮背后，站着一个编译器》的延续：结构在保存时编译好，决策在运行时交给节点。平台负责把路修好，节点自己决定怎么走。
如果你也在做一个可视化编排平台，不妨问问自己：你的画布上，有多少节点是真正干活的，有多少是"为了表达判断"而存在的？ 如果后者越来越多，或许该考虑把控制流还给节点自己。
这篇文章讲的是我们在策熔平台上做可视化编排时的一个设计选择——控制流内置到每个节点，同时保留拓扑级控制流节点。如果你也在设计编排类产品，欢迎在评论区聊聊你的控制流方案。
