应使用condition+loop实现三次限时时重试：先用condition判断http响应状态是否为2xx，非2xx走“否”分支进入loop；loop设最大次数3、超时8秒；“继续条件”为{{log.retry_count}}

☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜

你需要让扣子工作流在API失败、LLM输出异常或变量为空时自动重试并给出合理反馈，而不是一崩就全链路中断、用户收不到任何消息。

用Condition+Loop实现三次限时时重试

第一步：在HTTP节点后接一个Condition节点，判断{{response.status}}是否为2xx区间。别直接写== 200，因为201、204也合法——写错会把正常响应当失败。

第二步：把Condition的“否”分支连到Loop节点，Loop配置中设最大循环次数为【3】，超时时间设为【8秒】。扣子默认不限重试次数，一次DNS抖动就能触发无限循环，计费和token双双失控。

第三步：Loop的“继续条件”必须写成{{log.retry_count ，不能写<code>{{response.status != 200}}——后者在首次失败后永远为真，形成死循环。

这一步操作起来很简单，直接把Loop节点拖到Condition的“否”出口就行，但关键在于表达式逻辑必须闭环。

大模型节点后强制接Condition做空值与格式降级

方法一：在LLM节点后立刻接Condition节点，判断{{llm_1.output}}是否为空字符串或包含“我无法回答”等兜底话术。如果命中，走失败分支调用备用Prompt或返回预设JSON。

方法二：用代码节点先做JSON校验，再进Condition。插入代码节点，输入：
try { JSON.parse(input); return { valid: true }; } catch(e) { return { valid: false, error: e.message }; }
然后Condition判断{{code_1.output.valid}}是否为true。

扣子 (Windows)

扣子 (Windows) 是字节跳动推出的一站式 AI Agent 平台客户端，支持多 Agent 协作、可视化工作流和知识库管理。最新版本新增 Claude Code 与 Codex CLI 接入、多端同步和项目级管理功能，同时优化了插件生态和 AI 响应速度，让用户在 Windows 上即可高效创建、运行和协作智能体，满足个人、团队及企业场景需求。

下载

【大模型节点的 output 永远是 String，哪怕 Prompt 写了 JSON】——这是最常被忽略的前提，90% 的“取不到字段”问题都源于此。不加校验直接{{llm_1.output.data.title}}，遇到非JSON输出必然报错。

变量聚合节点统一兜底空值分支

当你有多个条件分支（比如成功路径、限流路径、鉴权失败路径），每条路径输出不同变量名，下游节点又必须读取统一字段时，必须用变量聚合节点收口。

把所有分支的输出线全部接入一个变量聚合节点；在该节点中设置统一输出变量名，例如final_result；勾选“取第一个非空值”。这样无论哪条分支执行，下游都只认这个变量，不会因读空值而中断。

注意：变量聚合节点不能替代业务逻辑判断，它只是让数据流“不断链”，状态含义仍需后续节点校验。

错误日志记录与飞书告警联动

第一步：在每个Condition的失败分支里，插入代码节点，写入日志结构：
return { error_code: input.error_code || "UNKNOWN", retry_count: (input.retry_count || 0) + 1, timestamp: new Date().toISOString(), raw_response: input.response };

第二步：把这个代码节点的输出变量（如{{code_2.output}}）传给飞书机器人节点，模板消息里带上{{code_2.output.error_code}}和{{code_2.output.timestamp}}。

第三步：飞书消息正文末尾加一句：“点击此处跳转工作流日志 → {{workflow_log_url}}”，其中workflow_log_url需在代码节点中拼接当前任务ID生成可追溯链接。