工作流节点超时配置不当会导致Agent卡在“运行中”，需针对HTTP插件、NL2SQL查询、异步发起节点三类手动设阶梯超时值（30/80/150/10秒），并用Condition+Code节点兜底处理超时分支，最后通过模拟超时验证配置有效性。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
在扣子平台中，工作流节点因超时配置不当导致Agent长时间卡在“运行中”、无报错也不推进，是线上服务不可用的高频原因。默认30秒超时对图像生成、数据库聚合、PDF解析等任务完全不够，而盲目调大又可能掩盖真实故障。
确认哪些节点必须改超时
先检查工作流中是否存在以下三类节点：HTTP插件调用（尤其带文件上传/下载）、NL2SQL查询（涉及多表JOIN或百万级数据扫描）、异步任务发起节点（如调用Stable Diffusion API）。这三类节点若未手动修改超时值，90%概率会在高负载时段触发静默挂起。
打开每个节点右侧配置面板，找到「超时时间」字段——不是所有节点都默认显示该选项，需点击「高级设置」展开才能看到。
为不同任务类型设阶梯式超时值
第一步：轻量API（天气、翻译、短文本摘要）→ 保持默认30秒，不建议下调；
第二步：中等耗时任务（单表MySQL查询、OCR识别一页PDF、向量库相似检索）→ 统一设为80秒；【必须设为80而非60，因为网络抖动+DNS解析+SSL握手平均占用12~18秒】
第三步：重计算任务（NL2SQL含GROUP BY + ORDER BY LIMIT 100、批量图像生成5张以上、视频封面帧提取）→ 设为150秒；若实测仍超时，立刻切换为异步节点，不要继续堆高超时值。
第四步：异步任务发起节点本身 → 超时设为10秒，它只负责发请求，不该等结果；结果由后续回调节点处理。
用代码节点兜底超时分支
方法一：在超时风险高的节点后，立即接一个Condition节点，判断{{response.status}}是否等于"timeout"；
方法二：在Condition的“否”分支走正常逻辑，“是”分支接Code节点，执行以下操作：
① 写入日志：log.error("Node X timeout at {{context.timestamp}}");
② 设置降级变量：context.set("fallback_used", true);
③ 返回预设占位数据：return { "status": "fallback", "data": "暂无法获取实时数据，请稍后再试" };
这一步不能省——没有显式返回，下游节点会因读取空值直接中断，且错误日志里不体现超时源头。
验证超时配置是否生效
进入工作流调试模式，点击右上角「模拟输入」，在输入框下方勾选「启用超时模拟」，选择目标节点并设定比当前配置少5秒的模拟值（例如节点设了80秒，这里填75秒）；
运行后观察日志是否出现[TIMEOUT EMULATED]标记，并确认Condition节点是否准确进入“是”分支；
成功后取消勾选，再用真实慢接口测试一次，确保真实超时路径与模拟路径行为一致。
