工作流条件分支与迭代进阶
第 10、11 章介绍了工作流画布与常用节点。当业务出现「多条路径」或「一批数据逐项处理」时，就需要条件分支（IF/ELSE） 与 迭代（Iteration） 节点。本章讲清它们的实战用法。
1. 条件分支：让流程「看情况走」
条件节点依据变量判断，把执行导向不同分支。例如按用户意图分流：
[Start]
→ [分类 LLM] 输出 intent
→ [IF] intent == "退款"
→ 走「退款处理」分支
→ [ELSE]
→ 走「通用问答」分支
→ [End]# 条件节点配置示意
if_node:
variable: "{{#classify.intent#}}"
conditions:
- op: equals
value: "退款"
goto: refund_branch
else:
goto: general_branch💡条件变量先用 LLM 规整
自由文本难直接判断，先用一个 LLM 节点把用户输入归类为固定枚举（退款/咨询/投诉），再交给 IF 判断，流程更稳、分支更清晰。
2. 迭代节点：批量处理列表
当输入是一组条目（如一批订单、一组文件），用迭代节点逐项执行子流程并聚合结果。
输入：订单列表 [O1, O2, O3]
迭代节点：
对每一项：查状态 → 判断是否超时 → 拼成一行摘要
输出：["O1 已发货", "O2 超时待处理", "O3 已签收"]3. 变量聚合与下游消费
迭代结果通常是数组，下游 LLM 或代码节点需把它聚合为可读文本再使用：
{{#iteration.output#}} 是一个数组
用代码节点 join 为换行字符串，再喂给总结节点：
O1 已发货
O2 超时待处理
O3 已签收⚠️留意迭代的 token 成本
列表越长，迭代次数越多，每次都可能调用 LLM。处理上百条数据时，考虑先在代码节点做过滤，只把需要模型判断的条目送入迭代，控住成本。
4. 嵌套与断路
复杂流程可在分支内再套迭代。但要避免「分支永远不汇合」——确保各路径最终都连到 End，否则运行会卡住或结果缺失。
🎯动手做
搭一个工作流：先用 LLM 把输入归类为 A/B/C 三类，IF 分别走三条分支，其中一条分支内用迭代节点处理一个包含 3 个元素的列表，最后汇总成一句话输出。
小结
- 条件分支用「先归类、再判断」最稳
- 迭代节点逐项处理列表，结果需聚合后再用
- 大数据量先过滤再迭代，控制成本
- 所有分支必须汇到 End；下一步用 API 把流程接进外部系统 →