工作流的分支条件是怎么定的？机制细节全梳理

在智能体编排平台上，分支条件相当于流程岔路口的指示牌：数据流到判断节点时，平台拿上游输出去比对若干规则，命中哪条就走向哪条路径。规则本身通常是一段表达式，比如「金额大于五百走人工确认、否则走自动通道」，扣子等平台的条件节点就是这种用法。

类比十字路口的红绿灯：绿灯直行、红灯停。失效之处在于，流程数据不是车，可能出现既不是绿灯也不是红灯的第三种情况——字段缺失、类型不对、值超出预期，这时没有规则命中，分支就卡住了。所以机制上必须给「都不命中」留一条退路。

条件是在哪个环节被判断的

按步骤拆：上游节点输出结构化数据进来；判断节点先做取值，把要比较的字段捞出来；再做类型转换与比较，得出真假；最后按真假路由，把数据发往对应下游。出去的是一次定向分发。理解这个环节顺序很重要，因为大量分支失灵源于取值那一步拿到空值，而不是规则本身写错。

表达式里能写什么

常见能力有三层：比较（等于、大于、包含）、逻辑组合（并且、或者、取反）、函数加工（取长度、转小写、截取片段）。写表达式的原则是让条件可枚举、可解释，每条分支都能用一句人话复述。写得太绕，排障时连自己都说不清为什么走进这条路径，得不偿失。

多个分支同时命中怎么办

平台普遍按从上到下的顺序取第一条命中的分支，后面的不再看。这意味着规则的排列顺序本身就是逻辑的一部分：把更特殊的条件放前面、更宽泛的放后面，否则宽条件会截胡。有些平台允许设置优先级，本质相同。想清楚顺序，比多写三条规则更管用。

默认分支存在的意义

默认分支是所有规则都不命中时的去向，可以走重试、走人工、走另一条降级路径。没有它，数据会在岔路口悬空，任务就挂起了。兜底走向哪里要有明确交代，并与补偿机制衔接：走错了路能不能退回来，见这篇补偿事务是怎么回滚的？反向操作。

四种走向摆在一起，平台的处置各不一样。

分支条件自查清单

• 每个判断节点都有默认去向
• 特殊条件排在宽泛条件前面
• 每条分支能用一句人话复述
• 取空值的情况有明确处理

一句话记住：岔路口要留退路，规则顺序就是逻辑。

分支写完不是终点：把各条路径跑进评测集，看每条分支的触发频率与正确率，纳入Agent 评测是怎么打分的？完成率；运行期再盯着各分支的流转量，异常波动靠长时任务看哪些监控指标？内部门道在这及早发现。文心一言、通义千问这类模型在理解含糊条件时的表现也有差异，拿不准就让模型复述一遍它理解的分支含义。把分支想全，流程才走得稳。

分支条件排障也有套路：先看数据是不是没到——上游输出为空，分支规则再对也没用；再看规则顺序对不对——宽条件把数据截走了；最后看默认分支是不是吞了本该命中的流量，默认分支触发率异常升高，往往说明前面某条规则写错了。养成先查数据、再查规则的习惯，能省下一大半排查时间。另外，分支条件要随业务变化定期回收：下线的活动、停用的路径，对应的规则要及时归档，留在单子里的僵尸规则是后期混乱的主要来源。把每次分支调整记录成变更说明，回头追溯时不用靠猜。

换个问法再问分支条件三句

• 条件里能引用上一个节点的结果吗？：能，取值环节支持引用上游输出字段，这正是串联判断的基础。
• 规则写得越多越好吗？：不是，规则互相重叠时顺序会变成隐形逻辑，先合并再排序更省心。
• 分支判断会消耗模型调用吗？：纯表达式判断不消耗，涉及语义理解的判断才会用到模型。