流程编排模式与调试技巧
六个可复用的编排模式 + 一套标准调试流程。搭建新 Agent 时，先看你的需求匹配哪个模式，不要从空白画布凭空开始。
六个常用编排模式
模式 1:直连问答 (最小 Chatflow)
Start ─▶ LLM ─▶ Answer适用：单一职责的问答助手。任何 Chatflow 都应该先搭出这个骨架跑通，再加复杂度。
模式 2:意图路由 (客服类标配)
Start ─▶ Question Classifier ─┬▶ 分支A(LLM 知识问答)─┐
├▶ 分支B(Tool 查数据) ─┼▶ Branch Aggregator ─▶ Answer
└▶ 分支C(兜底话术) ─┘适用：用户问题类型多样的场景。语义级分流用 Question Classifier，字段级判断 (如"金额 > 0") 用 IF Else。
模式 3:工具增强 (先查后答)
Start ─▶ Tool / Http Request ─▶ LLM(基于数据作答)─▶ Answer适用：回答需要实时数据 (行情、公告)。要点：让 LLM 只基于工具返回的数据作答,在提示词中明确"数据以工具返回为准，不得编造"。
模式 4:自主 Agent(让模型自己决定调什么)
Start ─▶ Agent(挂载多个工具)─▶ Answer适用：任务路径不固定、需要多步推理的场景。Agent 节点采用 Function Calling 模式：模型通过函数调用自主使用工具，循环执行直到任务完成。注意：自主性越强越要用试运行覆盖各种输入，并配合合规护栏。
模式 5:流水线加工 (Workflow 标配)
Start ─▶ Http Request(取数)─▶ LLM(结构化输出)─▶ Variables Transformer(排版)─▶ End适用：研报生成、内容加工等一次进一次出的任务。
模式 6:批量处理
Start ─▶ Iteration(并行)[ 子流程: LLM / Code ] ─▶ LLM(汇总)─▶ End适用：对列表逐项处理再汇总。数据量大时开 Iteration 并行模式，并配置错误处理避免单项失败拖垮整体。
编排原则
- 先跑通最小链路，再逐段加节点 —— 每加一个节点就试运行一次，问题定位永远只在最新加的一段
- 单一节点单一职责 —— 一个 LLM 节点又分类又生成又排版，不如拆成分类器 + 生成 + Transformer，分开各自可测
- 凡分支必有兜底 —— Question Classifier 设"其他"分类，IF Else 用好 Else 分支，不让任何输入走进死路
- 给节点写注释 —— 复杂流程里每个节点的注释写清"输入什么、做什么、输出什么",团队协作和三个月后的自己都会感谢你
- 控制成本 —— LLM/Agent 节点是主要成本来源：能用 IF Else/Code 判断的不用 LLM 判断;记忆窗口开够用的最小值;批量任务评估调用次数
标准调试流程
1. 单节点试运行
除 IF Else、Branch Aggregator 等纯路由/聚合节点外，处理类节点 (LLM、Agent、Tool、Code、Iteration、Loop、Parameter Extractor 等) 均可点击节点上的运行按钮单独测试 (以节点上是否出现运行按钮为准)。配置完一个节点立即试运行，不要攒到最后。
2. 全流程测试的用例设计
每个 Agent 至少准备三类用例：
| 用例类型 | 例子 | 验证什么 |
|---|---|---|
| 正常输入 | "什么是市盈率？" | 主流程正确 |
| 边界输入 | 空消息、超长文本、中英混杂、表情 | 流程不报错、有兜底 |
| 越界输入 | "帮我推荐一只必涨的股票" | 合规护栏生效 |
3. 常见故障定位表
| 现象 | 先查什么 |
|---|---|
| 流程没走到预期分支 | 试运行分类器/条件节点，看分类结果或条件值;检查分类描述是否可区分 |
| LLM 输出不稳定 | 提示词是否有明确格式约束;需要精确字段就改结构化输出 |
| Http Request 失败 | 先在节点内试运行看状态码;检查 URL、请求头、鉴权、参数 |
| Iteration 部分元素失败 | 查错误处理配置;单独拿失败元素的数据试运行子流程 |
| 回答带出了不该说的内容 | 把 bad case 加进 System Prompt 的 ❌ 示例;必要时在下游加规则校验 |
4. 上线前回归
提示词或流程有改动时，把三类用例完整跑一遍再发布，避免"改好一处、弄坏另一处"。