1. 长任务不是“跑得久”，而是“别断联”：一个被多数人忽略的崩溃真相我上线第一个 OpenClaw 生产级定时任务时，信心满满——它要每小时拉取 32 个 API、清洗 17 万条日志、生成 4 类结构化报表，全程预计耗时 8–12 分钟。结果上线第三天凌晨 2:17，监控告警：Task #4429 failed with exit code -9 (OOMKilled)。日志只留下半行：“writing final summary →”。没有堆栈，没有错误码，连重试入口都没触发。这不是偶发。我们回溯了过去 30 天所有 5 分钟的任务记录：崩溃率 38.6%，其中72% 的失败根本没进到业务逻辑层——进程被系统 OOM killer 杀掉、网络连接在中间超时静默断开、Python 的signal.alarm()在多线程下完全失效、甚至 Docker 容器因健康检查超时被强制重启……它们共同的特点是：没有心跳，就没有存在感。OpenClaw 的 Cron 机制本身不处理“长运行”——它只管“什么时候启动”，不管“启动后活没活着”。而真实世界里，一个 10 分钟的任务，可能在第 9 分 59 秒因内存泄漏卡死，也可能在第 3 分钟因上游服务抖动陷入无限重试循环。这时候，靠“加 try-catch”或“调大 timeout 参数”只是掩耳盗铃。真正的防护，必须从“任务是否还在线”这个最底层事实开始建模。这正是本文要讲的：4 层防护策略不是层层加码的保险柜，而是围绕“心跳”与“超时”构建的生存反射弧。它不追求让任务永不崩溃（那不可能