5.2 节点详解：分支、迭代与代码执行

5.2 节点详解：分支、迭代与代码执行

重型节点三件套：条件分支把"如果"画进流程，问题分类器把语义判断变成路由，代码执行把精确计算从模型手里拿回来。加上处理数组的迭代节点与发起外部调用的 HTTP 节点，这五件是工作流里最能"上强度"的零件——也是最常出事故的零件。

5.1 装好了脑子，本节拆零件。每个节点的讲法固定：机制、配置实例、典型事故。它们都将在 5.3 的流水线里上岗。

条件分支：把"如果"焊死在流程里

条件分支（IF/ELSE）按变量值选边。它最经典的岗位是硬规则守门：金额超限、字段为空、会员等级不符——这些绝不能交给模型判断的事情。给工单流水线配的第一道闸：

条件分支节点（起名 amount_check）
IF   order_amount 大于 5000        → 走人工审核边
ELIF order_amount 大于 0           → 走自动处理边
ELSE（金额缺失或为 0）             → 走补充信息边
​

配置界面的本质是表达式编辑器：左操作数选变量、中间选比较符、右边填值。多个条件可组合与/或。事故高发点是类型：order_amount 若是字符串，"900" 与 5000 比较会得出违反直觉的结果——数值判断前先确认上游给的是数字类型，必要时用代码节点先转一道。另一个高发点是** ELSE 边悬空**：条件分支的 ELSE 边不连节点，运行到时直接失败。每条边必须有去处，这是画布版的"函数所有分支都要 return"。

问题分类器：语义路由的正确工具

条件分支只认精确的值，"用户这句话是投诉还是咨询"这种语义判断得交给问题分类器。配置方式：写几个类别描述（它内部用一次 LLM 调用做判断），输入接 start.question，输出是多条边：

问题分类器节点（起名 classifier）
输入：{{#start.question#}}
类别一：售后政策咨询——退货条件、运费规则、发票等政策类问题
类别二：投诉与不满——表达不满、要求投诉、情绪激烈的发言
类别三：其他闲聊——与售后无关的寒暄与提问
​

写类别描述的诀窍与 3.2 节的系统提示词同源：正向描述加例子，比否定式描述可靠。"其他闲聊"这种兜底类一定要留，否则万物的归宿都是第一个类别。分类器输出还有个 class_name 变量可被下游引用——5.3 会用它拼工单的类型字段。

代码执行：把数学还给数学

模型做四则运算不可靠（这不是传闻，是概率），精确计算必须进代码节点。它跑在平台自带的沙箱容器里（2.1 部署时见过的那个），支持 Python 与 JavaScript。约定：输入变量在代码里直接用，输出必须是名为 result 的对象：

def main(args):
    # 输入：args 里是节点配置声明的输入变量
    order_amount = float(args.get("order_amount", 0))
    member_level = args.get("member_level", "普通会员")

    # 投诉类工单的优先级：金额与情绪双因子打分
    priority_score = 0
    if order_amount > 1000:
        priority_score += 2        # 大额订单加权
    elif order_amount > 200:
        priority_score += 1
    if member_level == "铂金会员":
        priority_score += 1        # 会员等级加权

    level = "高" if priority_score >= 3 else "中" if priority_score >= 2 else "低"
    return {"result": {"priority": level, "score": priority_score}}
​

沙箱的两条铁律要记牢：没有网络（外部调用是 HTTP 节点的事）、执行有超时（默认几秒，死循环直接被掐）。第三方库按部署配置而定，自部署环境可以装，但先用标准库解题永远更稳。代码节点的输出 code.result.priority 就能被下游分支引用——注意它是个字典，引用时取到字段。

迭代与 HTTP：数组与外呼

迭代节点处理数组：输入一个列表，对每项执行一段子流程，输出结果列表。工单流水线暂用不上，给个备用场景——批量处理十条客服留言，各生成一条摘要，迭代节点包住一个 LLM 节点即可。它的心智模型就是 for 循环包子图，数组里每个元素跑一遍。

HTTP 节点是流程对外部系统的嘴。方法、地址、头、体都可配，变量引用能塞进任何位置。提交工单的关键配置：

HTTP 节点（起名 create_ticket）
方法：POST
地址：https://cs.example.com/api/v2/tickets
请求头：Content-Type: application/json
        Authorization: Bearer 工单系统令牌
请求体（JSON）：
{
  "type": "{{#classifier.class_name#}}",
  "priority": "{{#code.result.priority#}}",
  "content": "{{#start.question#}}",
  "order_id": "{{#start.order_id#}}"
}
输出：响应 JSON 存入 create_ticket.body，下游可取工单号
​

HTTP 节点默认不校验业务结果——接口返回 200 但业务失败（比如工单系统返回错误码包在 200 里）时它照样"通过"。需要校验就再接一个条件分支，检查响应体里的业务字段。超时与失败重试在节点配置里设置，对外呼节点永远显式设置超时，别用默认值硬扛。

⚠️ 常见坑一：把密钥明文写在 HTTP 节点里。虽然 YAML 导出时可以选不含密钥，但画布协作者都看得见节点配置。外部凭据放专门的环境变量或密钥管理，节点里引用。常见坑二：代码节点里调外部接口，撞上沙箱无网络的红牌——设计时就想清楚：算账归代码，外呼归 HTTP。常见坑三：迭代节点套迭代还套 LLM，一次运行几百次模型调用，token 账单爆炸。迭代内尽量用小模型，或先抽样。

💡 关键直觉：五个重型节点各守一个词——分支守"规则"，分类器守"语义"，代码守"精确"，迭代守"批量"，HTTP 守"外呼"。需求里的每句话几乎都能落到这五个词之一，落到哪个词，就用哪个节点。

本节要点回顾

• 条件分支：硬规则守门，注意变量类型与 ELSE 边必须有去处；
• 问题分类器：语义路由，类别描述用正向加例子，兜底类必留；
• 代码节点：精确计算的家，输入经 args、输出必为 result 对象，沙箱无网络有超时；
• 迭代节点：数组循环包子图，嵌套 LLM 时警惕 token 爆炸；
• HTTP 节点：外呼唯一正道，超时显式设置，业务结果要自接分支校验；
• 密钥不入画布：凭据走环境变量，节点只引用。

零件齐了。下一节上总装线：从一张空画布开始，把工单分类流水线完整搭出来、调通、发布。