AI工作流出错怎么办：重试、兜底、告警与人工接管

去年帮一家做工业配件的客户排查线上问题。他们的报价单自动生成流程跑了三个月，某天开始发给客户的 PDF 全是空白模板。追问下来，是上游一个字段改了名，流程没报错，只是静默跳过了填充步骤。三个月里没人发现，因为没人看日志——在监控面板上，这条流程一直显示“运行成功”。

这类事故的共同点不是技术难，而是设计时只考虑了顺利路径。做AI 工作流自动化，真正花时间的部分往往不是“怎么跑通”，而是“跑不通的时候谁来收拾”。下面四条原则，是我们给客户做稳定性评审时反复用到的。

先承认：AI 工作流比传统脚本更容易出错

传统脚本出错通常是确定的：接口挂了、字段空了、权限没了。AI 工作流多了一层不确定性——同一段输入，模型两次输出可能不一样；结构化 JSON 偶尔多一个逗号就解析失败；上下文一长，token 超限直接报错；第三方模型 API 在高峰期返回 429。这些都是常态，不是意外。

所以稳定性设计的前提是：把失败当成必然发生的事件来排布，而不是等出事再补。

原则一：重试要按错误类型来，别一把梭

很多团队的做法是“失败就重试三次”，这在实际运行中既浪费钱也掩盖问题。至少要分三类：

可重试：429 限流、5xx 服务端错误、网络超时。用指数退避加随机抖动，比如 2 秒、4 秒、8 秒，每次再加 0 到 1 秒随机量，避免同一时刻大批任务齐刷刷重试把对方打挂。
不该重试：401/403 鉴权失败、400 参数错误、422 校验不通过。这类错误重试一百次结果一样，直接告警比什么都强。
有条件重试：模型输出的 JSON 解析失败。可以再试一次，第二次要把约束写得更死（只输出 JSON、不要解释、不要代码块标记）；两次都失败就转人工，不要陷入循环。

写操作必须做幂等。给每个任务生成业务幂等键，比如订单号加流程名加日期，重试前先查一次状态再决定要不要执行。我们踩过的坑：一条给客户发回访短信的流程因为网关超时触发重试，同一批人收到两条一模一样的短信，投诉直接捅到老板那里。修起来不难，难的是信任已经掉了一次。

还有一笔隐性成本：模型调用超时后重试，通常两次都会被计费。重试策略要和预算一起算，相关做法可以参考模型 API 与成本管理。

原则二：每个节点都要有超时，兜底要有默认动作

超时要分三层设，缺一层都会出问题：连接超时 3 到 5 秒；单节点超时，检索 3 到 5 秒、模型生成 30 到 60 秒、第三方接口 10 秒左右；整条流程超时，比如 5 分钟，超了直接进异常队列，不要让任务挂在“运行中”状态过夜。

兜底不是“报错就停”，而是每类节点提前想好退路：

知识库检索超时：降级为不带检索的直答，或者干脆转到人工，别让用户等三分钟拿到一个编出来的答案。
主模型不可用：切备用模型。大模型配小模型是常见组合，备用模型质量差一点，但能把流程兜住。
写库失败：先落到本地队列表，异步补写，主流程照常往下走。
通知类动作失败：记录并汇总，不要因为一条群消息没发出去就阻塞整个任务。

兜底的顺序要写进配置，不要写死在代码里。改一次降级顺序要发版，这个流程基本就没人维护了。

原则三：没有告警的自动化，等于把问题藏起来了

这句话我每次都跟客户讲。自动化的风险不在于失败，而在于失败了没人知道，业务方还以为一切正常，等你发现时损失已经累积了两三周。

告警设计有几个实打实的要求：

每条告警必须带流程名、任务 ID、失败节点、错误类型、脱敏后的输入摘要、追踪链接。只发一句“任务执行失败”，等于没发，收到的人还得自己去翻日志。
设聚合与静默窗口。同一种错误十分钟内合并成一条，否则群里刷屏，两周之后就没人点开了。
写明责任人。值班表要落到人，群消息不 @ 到具体的人，谁都觉得“不是我负责”。
每周看一次告警量曲线。一条稳定运行的流程，告警应该越来越少，如果一直持平，说明根因从来没修过，只是每次都被重试救了回来。

原则四：人工接管是设计的一部分，不是没做完

交付时把人工介入当成“遗留问题”，客户也这么理解，结果上线后一出异常就全线停摆。合理的做法是把人放进流程里：

状态机保留“待人工”状态，任务挂起而不是判死，等人处理完继续往下走。
后台提供一键重放和改参数重跑，别让人从头再填一遍表单。
输入输出全量留痕，接管的人能看到模型当时到底看到了什么，不然只能靠猜。
对外发送、金额计算、合同条款这类动作，前置一个审批节点，高风险动作必须经过人。
人接管这个动作本身也要记日志，否则下次复盘时，链条在这里就断了。

一张分级策略表，照着填就行

按影响面分级，不同级别用不同的重试、超时、告警和接管策略。这张表是我们给客户做评审时的底稿，实际项目会按业务调整：

级别	典型场景	重试与超时	告警方式	接管策略
L1 高风险	对外发报价、发合同、付款、客户群发	不自动重试，节点超时 10 秒即中断	电话加群告警，要求 5 分钟内响应	强制人工审批后才执行，审批留痕
L2 业务关键	工单创建、CRM 写入、日报推送	重试 2 次，退避 2 秒、4 秒，整条流程 3 分钟超时	企业微信群 @ 责任人，30 分钟内处理	失败进待人工队列，保留一键重放
L3 一般	内容摘要、标签生成、内部通知	重试 3 次，退避 2 秒、4 秒、8 秒	群消息，不 @，当日处理即可	自动降级，次日批量补跑
L4 低价值	日志归档、统计打点、埋点上报	重试 1 次，失败即丢弃	只进周报统计，不进群	不接管，接受丢失

填这张表的时候会暴露一个常见问题：很多被标成 L3 的流程，实际上处理的是对外内容，一旦出错就是 L1 的影响。级别定错，后面所有策略都跟着错。

上线前先过这六项

每个外部调用是否有明确的超时值，而不是用默认值。
写操作是否有幂等键，重放两次会不会产生重复数据。
是否至少有一条降级路径，而不是失败即停。
告警是否带 trace ID 和输入摘要，责任人是否落到人。
“待人工”状态是否存在于状态机里，后台是否有重放按钮。
有无一份清单，写清楚每条流程出问题时业务方该找谁。

如果这六项里有三项是空的，那这条流程目前只是“跑得动”，还谈不上“敢让它一直跑”。

下一步建议别贪多：挑一条影响面中等、频率高的流程，先把重试分类、超时兜底、告警内容这三件事补上，跑两周看告警曲线有没有下降。曲线降了，再往高风险流程上推。需要一起看现有流程的节点图，可以把结构发给我们，或者直接联系我们，电话 400-873-2750。平时我们也会把这类复盘写在知识库里，可以先翻翻有没有类似场景。