工作流设计模式

五种结构模式覆盖大多数编排需求：顺序、迭代扇出、条件、决策路由和循环。先选模式，再选节点——模式决定了出错时该看哪里。

顺序模式

线性执行：A → B → C → D

适用场景：文档处理流水线（抽取 → 分段 → 嵌入 → 入库），每一步都依赖上一步的输出。

执行计划按拓扑分层，但同一层里的节点仍然逐个执行：从一个句柄连出两条线不会让它们并发跑。如果没有数据依赖，把它们合并成一个节点（或一次工具调用）通常比拆开更快。

迭代扇出模式

用一个迭代节点对数组逐项执行容器内的子节点：{{items}} → 迭代容器（item / index） → results 数组。

适用场景：多源数据聚合、批量内容处理、对每条记录调用一次模型。

• 面板里没有 Parallel 节点。迭代节点的并行执行开关和最大并行数（默认 10）目前只做参数校验，执行器仍逐项串行处理，因此不要指望靠它缩短耗时——先减少输入项数和每次迭代内的节点数。
• 迭代上限由执行器强制：单次迭代最多处理 1000 项（MAX_ITERATIONS），超出部分会被截断并记一条告警；未配置上限时按 100 项处理。编辑器不暴露该字段，需要通过定义或 API 设置。
• 每个条目拿到清晰的 item/index 输入和追加到 results 的输出，比用无界循环更容易复现问题。

条件模式

确定性的 if/else：A → if(条件表达式) → B else C，条件表达式用 Jinja2 语法比较上游变量（如 {{analysis.urgency}} == "high"）。

适用场景：字段级路由——金额区间、是否带附件、客户等级、变量是否为空。这类判断交给条件节点，省一次模型调用，也更容易审计。

条件分支不完整（缺少 True 或 False 分支、分支没配条件、引用了不存在的变量）会被检查清单拦下。

决策路由模式

用决策节点让模型在类型化的选项或有序等级上判断一次，再按结果路由：

开始 → 决策（choice: refund / technical / billing）→ {refund | technical | billing | manual_review}

适用场景：工单分诊、退款审批、风险分级——"该走哪条路"取决于自然语言语义，而你又需要知道模型有多确定。

三条固定做法：

1. 给兜底分支一个出口：设置置信度阈值（如 0.6）并把兜底连到人工队列或暂停节点。阈值只在置信度严格小于该值时改道，等于阈值仍走模型选中的分支。
2. 不要用决策节点做确定性判断：金额是否超过 5000、字段是否为空这类规则用条件节点；模型判断留给语义。
3. 用调试运行的追踪校准阈值：probabilities 分布平坦说明判断说明或输入状态要改，两个选项概率接近才该调阈值。

与问题分类器的取舍：分类器让对话模型输出 JSON 再从文本里解析类别，没有置信度保证；需要稳定结构和置信度时用决策节点。字段、示例与失败路径见编排工作流 → 决策节点和工作流节点 → 决策节点。

循环模式

迭代执行：A → while(条件) → B → A

适用场景：有界重试、需要累积状态的批处理。

配置显式终止条件和有限上限。编辑器默认循环上限为 10 次，输入范围 1–1000；执行器再强制最大 1000 次。两层上限只是防跑飞，不能替代"条件一定会终止"的设计。处理数组或对象时优先用迭代节点，让每个条目有清晰输入输出，而不是依赖无界循环。

安全检查清单：

• 上限与输入规模匹配（迭代超过 1000 项会被静默截断）
• 确保条件能朝终止方向推进
• 处理空输入和单条失败
• 把重试与业务迭代分开：节点级重试策略（LLM / HTTP 最多 3 次，工具 / Agent / 决策 / 知识库 2 次，子工作流 1 次，代码 / 模板 / 条件 0 次）不该和循环次数混在一起
• 决策分支要有兜底出口，别让"模型不确定"变成流程中断

相关文档

• 编排工作流 — 画布、节点配置与触发器
• 工作流节点 — 节点类别与决策节点配置
• Agent vs Workflow — 选择合适的抽象
• 系统架构 — 组件概览
• 提示词工程 — 提示词编写指南