Cron Retry

核心用法

Cron Retry 是一项自动化运维技能，专门解决定时任务（cron jobs）因网络瞬时故障而失败的问题。它通过与心跳（Heartbeat）系统集成，定期检查所有 cron 任务的状态，识别因网络错误（如连接超时、DNS 解析失败、消息发送失败等）而标记为 error 的任务，并在网络恢复后自动重试运行。

主要使用场景包括：

• 集成心跳监控：在 HEARTBEAT.md 中添加 Cron Recovery Check 指令，实现无人值守的自动恢复
• 手动故障排查：通过 clawdbot cron list 查看所有任务状态，结合 jq 过滤出失败任务，针对性重试
• 智能错误识别：内置网络错误模式匹配，准确区分可重试的瞬态故障与不应重试的逻辑错误

显著优点

1. 高自动化：无需人工干预，心跳触发即可自动检测并恢复
2. 精准过滤：严格区分网络错误（ECONNREFUSED、ETIMEDOUT 等）与逻辑错误、认证失败，避免无效重试
3. 防循环设计：检查 lastRunAtMs 时间戳，防止重复创建重试任务形成死循环
4. 透明可观测：每次恢复尝试都会生成报告（"Recovered X jobs"），便于审计
5. 轻量集成：仅需在心跳配置中添加几行 Markdown 指令即可启用

潜在缺点与局限性

• 依赖心跳频率：恢复延迟取决于心跳触发间隔，非实时响应
• 误判风险：某些边缘网络错误可能被误判为逻辑错误而跳过，或反之
• 幂等性要求：被重试的任务本身需要具备幂等性，否则可能导致重复操作（如重复发送消息）
• 无指数退避：文档未提及重试间隔退避策略，高频心跳可能导致过于密集的重试
• 单点状态依赖：依赖 cron list 返回的状态准确性，若底层存储不一致可能导致误判

适合人群

• 运行大量网络依赖型定时任务的自动化代理用户
• 需要高可用消息推送、数据同步等场景的开发者和运维人员
• 使用 Telegram/Discord 等即时通讯 API 进行定时通知的用户（sendMessage 失败是典型场景）
• 网络环境不稳定（移动网络、间歇性连接）但仍需可靠任务执行的环境

常规风险

| 风险类型 | 说明 | 缓解措施 |

|---------|------|---------|

| 重复执行 | 非幂等任务被重复运行 | 确保任务逻辑幂等，或在任务内部实现去重 |

| 资源耗尽 | 心跳过于频繁导致密集重试 | 合理设置心跳间隔，监控重试频率 |

| 状态漂移 | 并发修改 `lastStatus` 导致误判 | 依赖底层 cron 工具的原子性保证 |

| 误恢复 | 非网络错误被误判为重试 | 定期审计恢复报告，调整错误模式匹配规则 |

总体评估

Cron Retry 是一项设计简洁、实用性强的容错技能，特别适合网络不稳定环境下的自动化运维。其"检测-分类-重试-报告"的闭环设计体现了良好的工程实践，但使用者需注意任务的幂等性设计和心跳频率调优。

核心功能

Cron Retry Skill 是一个面向自动化运维的辅助型技能，专注于解决定时任务（Cron Jobs）因瞬时网络故障而失败后的自动恢复问题。该技能通过与系统心跳机制集成，在检测到网络恢复后智能重试失败任务，无需人工干预。

核心用法

该技能采用"Heartbeat 集成"架构设计：

1. 自动检测：系统心跳周期内调用 cron list 获取所有定时任务状态
2. 智能筛选：过滤出 lastStatus="error" 且 enabled=true 的任务
3. 错误匹配：分析 lastError 内容，识别网络相关错误模式（如 ECONNREFUSED、ETIMEDOUT、Network request failed 等）
4. 安全重试：对符合条件的任务调用 cron run 重新执行
5. 结果报告：输出恢复统计，便于审计追踪

用户只需在 HEARTBEAT.md 中添加约 100 字的配置说明即可启用，也可通过命令行工具手动执行恢复检查。

显著优点

| 维度 | 优势 |

|------|------|

| **架构轻量** | 纯 Markdown 文档型技能，零代码依赖，零运行时开销 |

| **精准恢复** | 严格区分网络错误与逻辑错误，避免对配置错误、认证失败等非瞬时问题进行无效重试 |

| **防循环保护** | 通过检查 `lastRunAtMs` 等状态字段，防止重复重试导致死循环 |

| **即插即用** | 与现有 cron 工具链无缝集成，无需修改业务代码 |

| **审计友好** | 每次恢复操作均生成明确报告，支持运维追溯 |

潜在局限

1. 错误覆盖有限：当前仅识别 8 种网络错误模式，对于某些中间件特定的连接错误可能漏检
2. 无退避策略：文档未提及指数退避（exponential backoff），高频心跳场景下可能产生瞬时流量尖峰
3. 依赖外部工具：需依赖 jq 等命令行工具进行高效的 JSON 筛选，环境受限场景下可用性降低
4. 状态依赖准确性：重试决策完全依赖 lastStatus 和 lastError 字段的准确性，若上游系统状态更新延迟，可能导致误判

适合人群

• DevOps/运维工程师：管理大量依赖外部 API 的定时任务（如消息推送、数据同步）
• SRE 团队：需要提升系统在网络不稳定环境下的自愈能力
• 中小型项目开发者：无复杂编排基础设施，希望通过简单配置增强任务可靠性

常规风险

| 风险类型 | 说明 | 缓解措施 |

|----------|------|----------|

| 重复执行风险 | 网络实际未恢复但误判为可重试，导致重复失败 | 依赖 `lastRunAtMs` 检查，但建议用户监控重试频率 |

| 副作用累积 | 部分任务非幂等，重复执行可能产生副作用 | 技能明确建议仅重试网络错误，业务逻辑错误需人工处理 |

| 依赖系统稳定性 | 重试有效性取决于 `cron` 工具本身的可靠性 | 该技能为纯文档指导，实际稳定性由底层工具链保障 |

该技能作为纯文档型、零依赖、零数据收集的安全典范，在获得 S+ 级安全认证 的同时，为定时任务运维提供了轻量且有效的可靠性增强方案。