Skywork任务链路重试机制，核心在于“智能”二字——不是简单粗暴地再试一次，而是让每次重试都更有章法：知道失败的根因、规划合理的等待时间、切换更优的执行路径、在关键节点果断止损或启动补偿。这套机制深度嵌入智能体链路，跟意图理解、工具调度、状态追踪拧成一股绳，才算真正发挥效用。
构建一套靠谱的重试机制，关键是回答几个问题：哪些失败值得重试？不同环节该用什么节奏？失败到一半怎么保证不回滚错？重试频率高了怎么防雪崩？下面逐层拆解。
识别可重试的失败类型
并不是所有失败都适合“再来一次”。Skywork任务链路只对三类错误开放重试通道：
- 瞬时性外部依赖故障——比如调用ERP接口时撞上503（服务暂不可用）、向量库查询超时（
Milvus timeout）、密钥Vault临时连不上； - 资源竞争类冲突——比如并发写入同一审批单导致数据库唯一约束冲突（
PostgreSQL unique_violation）、NATS消息重复投递引发的幂等校验失败； - 模型临时响应异常——比如规划引擎输出的JSON格式错误（
JSONDecodeError）、工具调用参数缺了但语义上能推断出来（tool_call_args_missing）。
而像用户输入非法（invalid_diagnosis_code）、策略引擎明确拒绝（OPA policy denied）、成本标签没配置这类业务规则错误，直接终止并返回结构化报错，不进入重试流程。
分层重试策略：按链路阶段动态适配
Skywork的六层架构中，每一层失败都需要匹配不同粒度的重试行为，不能简单跨层整体重放：
- 接入层（API网关）——对JWT鉴权失败、熔断器开启等场景，走固定间隔1秒×2次重试，而且只允许客户端重发带新Token的请求；
- Agent核心层——意图识别失败或规划中断时，启用指数退避（1秒→2秒→4秒），最多3次，同时自动切换ReAct或Plan-and-Execute模式重试；
- 协作层（NATS总线）——消息投递失败触发死信重投（DLQ retry），带上优先级路由标记，第二次失败后降级为异步队列处理；
- 工具与数据层——向量检索失败自动回落至关键词+规则匹配；数据库写入冲突则加
SELECT FOR UPDATE锁后重试，超过2次转入工干预工单。
状态快照 + 可逆执行保障重试安全
每次任务启动前，Skywork自动生成轻量状态快照——包含输入参数哈希、当前步骤ID、已调用工具列表、时间戳，存入PostgreSQL WAL日志旁的task_snapshot表。重试时，系统比对快照，跳过已经成功执行的原子操作，只重跑失败节点及后续依赖节点。
对有副作用的操作（比如发送邮件、调用支付接口），采用“预检-确认”两阶段模式：
- 第一阶段（pre-execution）只生成待执行摘要（例如“拟向张三发送审批通过通知”），写入审计日志并标记
pending； - 第二阶段（confirmation）在重试成功后触发，读取摘要执行真实动作，更新状态为
done； - 若重试多次仍失败，状态转为
compensate_required，由补偿工作流自动发起回滚（如撤回已发通知、关闭临时审批锁）。
监控与熔断联动：防重试雪崩
重试机制本身不能成为新的风险源。Skywork生产环境强制要求：
- 所有重试请求携带独立
X-Retry-ID头，与原始X-Request-ID关联，在Grafana中可下钻分析重试率热力图； - 当某任务类型在5分钟内重试次数超过总调用量的15%，Prometheus自动触发告警，并由策略引擎临时禁用该任务类型的自动重试，转入人工审核队列；
- GPU显存使用率超过88%时，副模型（Skywork-1B）的重试延迟强制拉长至最小3秒，主模型重试直接降级为同步阻塞式，避免并发重试加剧资源争抢。