扣子工作流异常处理与重试机制设置指南

扣子工作流要留好三张底牌。你可能会问，具体怎么搞？问题出在哪？怎么治？

先说几个点：多分支空值，用变量聚合节点取首个非空值兜底；大模型输出，走Prompt格式约束、代码节点JSON校验、分支重试这条路子；外部API呢，按错误码分级处理，401这种过期token可以刷新重试，403权限类的就别想了，重试也没用。

工作中最头疼的场景莫过于——扣子工作流跑着跑着突然中断，节点报错，输出为空，分支直接不执行。很多人第一反应是配置出问题了，其实远不止如此。这背后，缺的是一个明确的异常拦截路径和可控的重试节奏。没有容错设计的工作流，一次网络抖动或者模型输出波动，整条链路就瘫了。

识别三类典型异常源头

先判断你遇到的是哪一类问题，再针对性处理，路径会清晰很多。

第一类：变量引用失败。比如报错“The input data is incorrect as fields cannot be extracted from null values”，表面上是字段提取失败，本质是多分支中某一路没执行，下游节点却强行去读这个分支的变量，空值一来，直接崩盘。

第二类：大模型节点不稳定。同一个prompt，有时候返回完美的JSON，有时候来一句“好的，我明白了”，有时候干脆超时。这种随机性，是工作流的大敌。

第三类：外部API调用失败。比如微信access_token过期，万物识别服务临时不可达，扣子平台返回401/403鉴权错误。这类问题如果混用一个方案处理，故障面会越放越大。

多分支空值问题：用变量聚合节点兜底

最稳妥的方式是插入一个变量聚合节点。把所有分支输出线全部连到这个节点上，设置统一的输出变量名，比如 【output_result】，并勾选“取第一个非空值”。这样不管哪条分支实际执行了，下游只认这个变量，不会因为读到空值就中断。

但注意，变量聚合节点不能替代真正的业务逻辑判断，它只是保证数据流“不断链”而已。业务含义该怎么校验，后续该搭的节点一个都不能少。

大模型节点输出不可控：多重保险强制校验

这里有三层保险，层层加码。

第一层：Prompt层加格式铁律。在大模型节点的system prompt末尾，硬性声明：“你只能输出严格符合以下JSON格式的字符串，禁止任何额外说明、换行、Markdown符号或中文解释”。格式写死，模型的选择空间就小了。

第二层：接代码节点做结构校验。大模型节点后面紧跟一个代码节点，脚本里做JSON.parse和字段校验。如果解析失败或者关键字段缺失，直接返回校验失败的结果。这一步很关键，它能杜绝模型输出“看起来像模像样但实际结构不对”的情况。

第三层：用分支节点分发结果。把代码节点的valid字段作为条件输入分支节点。valid为true，走正常业务流；valid为false，进入重试分支，最多触发2次。第2次还是失败？那就走兜底分支，填默认值继续，流程不中断。这才是真正的“容错”。

外部API调用失败：按错误码分级重试

第一步先分清错误类型。

看到401加code=10001，是token过期，刷新后重试就行。

看到403加code=20003，是scope权限不足，必须人工补权限，【不可重试】。

看到403加code=20005，是签名算法错配，密钥不一致，也【不可重试】。

第二步配置重试策略。在调用节点设置重试次数为2次，间隔分别设为1秒、2秒。如果后台支持，还可以加个指数退避。

第三步在重试前插入鉴权刷新节点。对401这种场景，在重试分支开头接一个HTTP节点调用/token/refresh接口，再用变量设置节点原子更新全局凭证变量。刷新成功后再重试原始请求，能避免重复刷出无效token，效率也更高。