定时任务标准化合约：解决Cron Job协作混乱与状态管理难题

1. 项目概述：为定时任务建立“交通规则”

在自动化运维和持续集成（CI）领域，定时任务（Cron Job）就像是系统里的“定时闹钟”和“自动工人”。它们负责在后台默默执行数据备份、日志清理、状态检查、报告生成等一系列重复性工作。然而，随着系统复杂度提升，这些“工人”之间的协作很容易出乱子。想象一下，一个工人刚把产品打包好放在A仓库，另一个工人却误以为产品还在B仓库，直接读取了昨天的旧数据，导致整个交付流程错乱。更常见的是，因为脚本编写者习惯不同，有的脚本执行成功却忘了“举手报告”，有的脚本失败后却留下了“成功”的假象，让监控系统成了“睁眼瞎”。

openclaw-cron-standard这个项目，正是为了解决这类问题而生。它不是一个全新的调度框架，而是一套针对 OpenClaw 自动化平台的“定时任务标准化合约”。简单说，它定义了一套所有定时任务脚本和其触发器（在OpenClaw中称为“Prompt”）都必须遵守的“交通规则”，确保任务从声明、执行、到结果汇报的整个生命周期清晰、可靠、无歧义。它的核心价值在于“通过约定优于配置，消灭因微小差异导致的系统性脆弱”。无论你是负责维护庞大CI/CD流水线的DevOps工程师，还是编写业务自动化脚本的后端开发者，只要你的系统依赖定时任务，这套标准都能帮助你构建出更健壮、更易维护的自动化体系。

2. 核心问题与标准化价值

在深入合约细节前，我们有必要先看看，如果没有规则，定时任务通常会以哪些方式“崩溃”。这些不是理论风险，而是我在多年运维实践中反复踩过的坑。

2.1 定时任务常见的“崩溃模式”

1. 陈腐结果文件（Stale Result Artifacts）：这是最经典的“幽灵错误”。任务A每小时运行一次，生成一个result.json文件。某次运行因为网络问题失败了，但脚本没有清理旧的result.json。下一次运行时，任务可能因为某种原因（如重复声明检查）跳过了实际执行，但触发器却直接读取了上次留下的、内容已过时的result.json，并基于错误数据做出了响应或决策。
2. 字符串漂移导致的逻辑断裂（String Drift）：在分布式或协作开发中，不同脚本对同一状态的描述可能略有不同。比如，脚本A检查到任务已被占用，输出ALREADY_CLAIMED并退出；脚本B可能输出already-claimed（带连字符）或JobLocked。触发器里的判断逻辑如果只匹配其中一种，其他脚本的输出就会被误判，导致任务静默失败或执行重复。
3. 无条件读取结果文件：触发器在调用包装脚本后，不检查脚本的退出状态或输出，直接尝试读取结果文件。如果脚本因为重复声明而根本未执行，结果文件不存在，触发器就会抛出“文件未找到”错误，将一次正常的“跳过执行”误报为一次运行失败。
4. 包装脚本与触发器合约不匹配（Contract Mismatch）：包装脚本期望触发器以某种方式调用它（例如，传递特定参数，或从特定路径读取配置），而触发器却用了另一种方式。两者都能单独运行，但组合起来就会导致任务静默失败（not-delivered），因为执行环境或预期接口对不上。这个问题在多人维护或脚本更新时尤其常见。
5. 误导性的健康检查（Misleading Health Checks）：很多系统会将任务定义（如jobs.json）和任务运行时状态（如成功、失败、运行中）混在一起。健康检查程序直接去jobs.json里读取一个内嵌的state字段。如果任务更新了，但状态字段没重置，或者任务根本还没到点运行，健康检查就会看到一个陈旧或根本不代表当前运行周期的状态，发出错误警报。
6. 通知回归（Notification Regressions）：一个原本会向聊天工具发送执行结果的任务，被修改为只内部记录日志（delivery.mode: “none”）。修改者可能忘了更新相关的监控或通知规则，导致重要失败不再告警，直到问题积累爆发才被发现。

openclaw-cron-standard的价值就在于，它通过一个共享的、版本化的“技能包”，将这些散落在各个脚本里的最佳实践和防御性代码，固化为一套统一的、可复用的标准。它让“正确的方式”成为“唯一的方式”，从而从根本上杜绝了因个人习惯或疏忽引入的脆弱性。

3. 标准化合约详解

这套合约主要规范了四个角色的行为：包装脚本（Wrapper）、触发器（Prompt）、健康检查/调试工具（Health/Debug）以及交付系统（Delivery）。下面我们逐一拆解。

3.1 包装脚本（Wrapper）规则

包装脚本是实际执行业务逻辑的“外壳”，它的核心职责是管理任务声明（Claim）和结果产出的生命周期，确保每次执行都是原子的、状态明确的。

1. 每次运行前清理陈旧结果：这是实现“结果文件作为单次运行唯一真相源”的前提。脚本开始时应删除或移动旧的结果文件（如result.json）。这确保了之后创建的文件100%代表本次执行的结果。

   #!/bin/bash RESULT_FILE=“/path/to/result.json” # 规则1：运行前清理旧结果 rm -f “$RESULT_FILE”

   注意：在并发极高的场景下，删除和创建之间可能存在极小的时间窗口。通常Cron的分钟级调度足以避免这个问题。若需极端强一致，可考虑使用原子重命名（mv）或使用带锁的文件操作。

2. 通过唯一的共享助手进行声明：所有任务应调用同一个claim_task函数或脚本，来尝试声明（锁定）本次执行权。这避免了声明逻辑的重复和潜在的差异。

   # 规则2：通过共享助手声明 if ! claim_task “my_task_id”; then # 声明失败的处理逻辑（见规则3） exit 0 fi

3. 优雅处理重复声明：如果声明助手返回“任务已被声明”，包装脚本必须打印精确的字符串ALREADY_CLAIMED（全大写，下划线），然后以成功状态（exit 0）退出，并且绝不写入结果文件。

   # 规则3：重复声明的处理 if ! claim_task “my_task_id”; then echo “ALREADY_CLAIMED” # 必须全大写，下划线 exit 0 # 必须成功退出 fi

   为什么是成功退出？因为从系统调度角度看，本次触发周期内任务已被成功执行（或正在执行），当前实例主动放弃执行是符合预期的正常行为，而非错误。这能防止Cron将此类跳过误报为失败，从而发送不必要的错误邮件。

4. 只为真实执行或失败写入结果：只有在成功声明并实际执行业务逻辑后，才根据执行结果（成功或失败）生成result.json。如果业务逻辑失败，结果文件应包含错误信息，这总比没有结果文件要好，因为它明确记录了一次失败。

   # 规则4：仅在实际执行后写结果 if perform_business_logic; then echo ‘{“status”: “success”, “data”: {...}}’ > “$RESULT_FILE” else echo ‘{“status”: “error”, “message”: “业务逻辑失败”}’ > “$RESULT_FILE” exit 1 # 业务失败，以错误状态退出 fi

5. 业务逻辑与生命周期助手分离：声明、结果写入、错误处理等应抽离为独立的函数或库，业务逻辑脚本只关心核心操作。这提升了代码的可测试性和可维护性。

   # 规则5：分离关注点 source “/path/to/cron_standard_lib.sh” cleanup_old_result if ! claim_task; then handle_duplicate_claim fi # 以下是纯净的业务逻辑 output=$(do_real_work) write_result “$output”

3.2 触发器（Prompt）规则

触发器是调度系统（如Cron）调用包装脚本的入口点。它的职责是正确解读包装脚本的行为，并据此决定如何响应（如发送通知）。

1. 先运行包装脚本：触发器的第一步永远是执行包装脚本，并捕获其输出和退出码。

   # 在Prompt配置或脚本中 output=$(bash /path/to/wrapper.sh 2>&1) exit_code=$?

2. 识别“已声明”并静默处理：检查脚本输出中是否包含ALREADY_CLAIMED。如果包含，则触发器应回复NO_REPLY（或等效的静默指令），并立即结束，不再进行后续任何读取结果或发送通知的操作。

   # 规则2：检查ALREADY_CLAIMED if echo “$output” | grep -q “ALREADY_CLAIMED”; then echo “NO_REPLY” exit 0 fi

   为什么必须检查输出而不是仅依赖退出码？因为规则3要求包装脚本在重复声明时以成功状态退出。仅靠退出码无法区分“成功跳过”和“成功执行”。输出字符串是双方约定的明确信号。

3. 仅在非重复声明后读取结果JSON：只有在确认本次是实际执行（非ALREADY_CLAIMED）后，触发器才去读取包装脚本生成的结果文件（result.json）。这保证了读取到的数据一定是本次执行的新鲜产物。

   # 规则3：安全读取结果 if [[ -f “/path/to/result.json” ]]; then result=$(cat “/path/to/result.json”) # 根据result内容构造回复消息 construct_reply “$result” else # 理论上，非重复声明且无结果文件，意味着包装脚本可能出错了。 echo “ERROR: Wrapper ran but produced no result.” exit 1 fi

4. 将结果文件作为真实运行的唯一真相源：所有关于本次执行的信息——状态、数据、错误详情——都应从result.json中获取。包装脚本的退出码（除非是脚本本身崩溃）和输出（除了ALREADY_CLAIMED）不应再作为判断依据。这实现了合约的“单一真相源”原则。

3.3 健康检查与调试（Health/Debug）规则

这套规则确保了运维人员看到的系统状态是实时、准确的，而不是混乱的混合信息。

1. 区分定义文件与状态文件：

   • jobs.json：这是任务定义文件。它描述任务“应该是什么样”——何时运行、调用什么命令、使用什么参数。它相对静态，只在部署或配置变更时修改。
   • jobs-state.json：这是运行时状态文件。它记录任务“实际发生了什么”——上次运行时间、状态（成功/失败）、输出摘要等。它由调度系统或包装脚本在每次运行后动态更新。

2. 健康状态只查询状态文件：任何健康检查、监控仪表盘或告警规则，在判断任务是否健康时，必须读取jobs-state.json，并完全忽略jobs.json中可能存在的任何state字段。因为后者可能是过时的，甚至只是模板值。

   # 正确做法：从状态文件读取 import json with open(‘/root/.openclaw/cron/jobs-state.json’) as f: state_data = json.load(f) task_status = state_data.get(‘my_task’, {}).get(‘last_status’) # 错误做法：从定义文件读取（严禁） with open(‘/root/.openclaw/cron/jobs.json’) as f: job_def = json.load(f) # 这里的 ‘state’ 字段不可信！ # bad_status = job_def[‘jobs’][‘my_task’].get(‘state’)

3. 处理“从未记录”的状态：当jobs-state.json中找不到某个任务的记录时，这可能有多种含义：a) 任务刚部署，从未运行过；b) 状态文件被意外删除；c) 任务配置已删除但状态残留未清理。健康检查逻辑必须能区分这种情况和“任务运行失败”的状态，通常可以将其标记为UNKNOWN或PENDING_FIRST_RUN，而不是直接告警。

3.4 交付（Delivery）规则

这条规则关乎任务执行结果如何通知外界，是确保“正确的信息在正确的时间以正确的方式送达正确的人”的关键。

1. 明确交付模式：在任务定义中，必须明确指定delivery.mode。

   • delivery.mode: “announce”：用于那些依赖于将回复文本（Reply Text）交付到某个通道（如Slack、邮件）的任务。例如，“每日数据库备份报告”任务，其核心目的就是生成一条消息并发送给团队。
   • delivery.mode: “none”：用于以下情况： a) 任务通过其他方式发送消息（例如，在业务逻辑中直接调用messageAPI 或 SDK）。 b) 任务本身就是静默的，不需要任何通知（例如，清理临时文件）。 c) 任务的输出仅用于更新内部状态文件，无需对外广播。

2. 不要滥用“none”模式：不能为了图省事，将所有任务的交付模式都设为none。如果一个任务原本设计为向团队频道发送报告，将其改为none会导致通知静默消失，造成通知回归。修改交付模式必须是一个有意识的、经过评审的决定。

4. 实操：将一个混乱的Cron任务改造为标准合约

假设我们有一个现存的任务：/usr/local/bin/backup_report.sh，它每天凌晨2点运行，检查数据库备份状态并发送报告到Slack。目前它问题很多：没有声明机制，可能重复运行；结果文件累积；触发器直接读取输出，经常误报。

4.1 第一步：分析现有脚本

原始的backup_report.sh可能长这样：

#!/bin/bash # 原始脚本 - 存在诸多问题 BACKUP_DIR=“/backups” RESULT_FILE=“/tmp/backup_status.txt” SLACK_WEBHOOK=“https://hooks.slack.com/...” # 直接检查备份，没有锁 latest_backup=$(find “$BACKUP_DIR” -name “*.sql.gz” -mtime -1 | head -1) if [[ -z “$latest_backup” ]]; then echo “CRITICAL: No backup found in last 24h!” > “$RESULT_FILE” curl -X POST -H ‘Content-type: application/json’ --data “{\“text\“:\“$(cat $RESULT_FILE)\“}” “$SLACK_WEBHOOK” exit 1 else echo “OK: Latest backup is $latest_backup” > “$RESULT_FILE” # 注意：成功时没有调用curl发送消息！依赖触发器。 exit 0 fi

而Cron条目可能是：0 2 * * * /usr/local/bin/backup_report.sh

问题诊断：

1. 无声明机制，如果脚本运行慢，Cron可能启动第二个实例。
2. 每次都写入/tmp/backup_status.txt，旧文件可能被误读。
3. 失败时自己发Slack，成功时却不发，行为不一致，完全依赖触发器读取文件并发送。但触发器可能因为文件不存在或格式问题而失败。

4.2 第二步：创建共享助手库

首先，我们创建一个共享库文件/usr/local/lib/cron_std_lib.sh，实现标准合约的核心函数。

#!/bin/bash # cron_std_lib.sh - 标准化合约助手库 readonly STATE_DIR=“/root/.openclaw/cron” readonly STATE_FILE=“${STATE_DIR}/jobs-state.json” readonly LOCK_DIR=“/tmp/cron_locks” mkdir -p “$STATE_DIR” “$LOCK_DIR” # 函数：声明任务 # 参数: task_id # 返回: 0-声明成功，1-声明失败（已被声明） claim_task() { local task_id=“$1” local lock_file=“${LOCK_DIR}/${task_id}.lock” # 使用flock进行文件锁，确保原子性 exec 200>“$lock_file” if flock -n 200; then # 获取锁成功，声明成功 echo “[$(date -Is)] Task ‘$task_id’ claimed.” >&2 return 0 else # 获取锁失败，任务已被声明 echo “ALREADY_CLAIMED” >&2 return 1 fi } # 函数：清理旧结果文件 # 参数: result_file_path cleanup_result() { local result_file=“$1” rm -f “$result_file” } # 函数：更新任务状态 # 参数: task_id, status (success/error), message update_task_state() { local task_id=“$1” local status=“$2” local message=“$3” local timestamp=$(date -Is) # 读取现有状态文件，或初始化 local state_data if [[ -f “$STATE_FILE” ]]; then state_data=$(cat “$STATE_FILE”) else state_data=“{}” fi # 使用jq更新JSON，确保格式正确 # 这里简化处理，实际可使用jq命令 # 假设我们有一个python小工具来更新JSON python3 -c “ import json, sys data = json.loads(sys.argv[1]) if sys.argv[1] else {} task_id = sys.argv[2] data[task_id] = { ‘last_run’: ‘$timestamp’, ‘status’: ‘$status’, ‘message’: ‘$message’ } print(json.dumps(data, indent=2)) “ “$state_data” “$task_id” > “$STATE_FILE.new” && mv “$STATE_FILE.new” “$STATE_FILE” } # 函数：写入标准结果JSON # 参数: result_file_path, status, data_json write_standard_result() { local result_file=“$1” local status=“$2” local data_json=“$3” local timestamp=$(date -Is) cat > “$result_file” <<EOF { “timestamp”: “$timestamp”, “status”: “$status”, “data”: $data_json } EOF }

4.3 第三步：重写包装脚本

基于共享库，重写backup_report.sh为符合标准的包装脚本。

#!/bin/bash # /usr/local/bin/backup_report_wrapper.sh - 符合标准的包装脚本 source “/usr/local/lib/cron_std_lib.sh” TASK_ID=“daily_backup_check” RESULT_FILE=“/var/run/cron_results/${TASK_ID}.json” BACKUP_DIR=“/backups” # === 遵循标准合约 === # 1. 清理旧结果 cleanup_result “$RESULT_FILE” # 2. & 3. 声明任务，处理重复声明 if ! claim_task “$TASK_ID”; then # claim_task 失败时会输出 ALREADY_CLAIMED 并返回1 # 我们直接退出，不写结果文件 exit 0 fi # === 业务逻辑 === # 4. 只有实际执行时才写结果 latest_backup=$(find “$BACKUP_DIR” -name “*.sql.gz” -mtime -1 2>/dev/null | head -1) if [[ -z “$latest_backup” ]]; then # 业务失败 error_msg=“CRITICAL: No backup found in last 24h!” # 写入结果文件（记录失败） write_standard_result “$RESULT_FILE” “error” “{\\\“message\\\“: \\\“$error_msg\\\“}” # 更新状态文件 update_task_state “$TASK_ID” “error” “$error_msg” # 包装脚本以错误退出，告知上层本次执行失败 exit 1 else # 业务成功 success_msg=“OK: Latest backup is $latest_backup” # 写入结果文件（记录成功） write_standard_result “$RESULT_FILE” “success” “{\\\“message\\\“: \\\“$success_msg\\\“, \\\“file\\\“: \\\“$latest_backup\\\“}” # 更新状态文件 update_task_state “$TASK_ID” “success” “$success_msg” # 包装脚本成功退出 exit 0 fi

4.4 第四步：配置标准触发器

在OpenClaw的Prompt配置（或你的调度系统配置）中，按照触发器规则进行配置。

# 示例：OpenClaw Prompt 配置 (YAML) name: “daily_backup_report” schedule: “0 2 * * *” command: “/usr/local/bin/backup_report_wrapper.sh” delivery: mode: “announce” # 此任务依赖回复文本的交付 parser: “standard_cron”

触发器的内部逻辑（或一个标准的解析器standard_cron）会这样工作：

1. 执行backup_report_wrapper.sh。
2. 捕获其输出。如果输出中包含ALREADY_CLAIMED，则触发NO_REPLY逻辑，结束。
3. 如果没有ALREADY_CLAIMED，则检查退出码。
   • 如果退出码非0，尝试读取RESULT_FILE中的错误信息，构造告警消息并交付。
   • 如果退出码为0，读取RESULT_FILE中的成功信息，构造通知消息并交付。
4. 交付系统根据delivery.mode: “announce”将消息发送到预定频道。

4.5 第五步：配置健康检查

编写一个健康检查脚本，只读取jobs-state.json。

#!/bin/bash # /usr/local/bin/check_cron_health.sh STATE_FILE=“/root/.openclaw/cron/jobs-state.json” TASK_ID=“daily_backup_check” if [[ ! -f “$STATE_FILE” ]]; then echo “UNKNOWN: State file not found.” exit 3 fi # 使用jq查询状态 last_status=$(jq -r “.[\\\“$TASK_ID\\\“].status // \\\“MISSING\\\“” “$STATE_FILE” 2>/dev/null) last_run=$(jq -r “.[\\\“$TASK_ID\\\“].last_run // \\\“never\\\“” “$STATE_FILE” 2>/dev/null) case “$last_status” in “success”) echo “OK: Task ‘$TASK_ID’ last ran successfully at $last_run.” exit 0 ;; “error”) error_msg=$(jq -r “.[\\\“$TASK_ID\\\“].message // ‘Unknown error’” “$STATE_FILE” 2>/dev/null) echo “CRITICAL: Task ‘$TASK_ID’ failed at $last_run: $error_msg” exit 2 ;; “MISSING”) echo “WARNING: No state recorded for task ‘$TASK_ID’. It may not have run yet.” exit 1 ;; *) echo “UNKNOWN: Unexpected status ‘$last_status’ for task ‘$TASK_ID’.” exit 3 ;; esac

然后将此脚本加入你的监控系统（如Nagios, Zabbix, Prometheus等）。

5. 常见问题与排查技巧实录

即使遵循了标准，在实际部署和运行中仍会遇到各种问题。以下是我在推行此类标准过程中积累的常见问题清单和排查思路。

5.1 问题：任务明明成功了，但监控一直告警“状态缺失（MISSING）”

• 排查步骤：

  1. 检查状态文件权限：运行包装脚本的用户（通常是root或某个服务账户）是否有权写入/root/.openclaw/cron/目录？执行sudo -u <cron_user> ls -la /root/.openclaw/cron/并尝试手动创建文件。
  2. 检查update_task_state函数：在包装脚本中，业务逻辑成功后是否确实调用了update_task_state？在脚本中添加set -x或在关键点echo调试信息，查看执行流。
  3. 检查JSON语法：手动查看jobs-state.json文件。一个常见的错误是，当多个任务并发写入时，如果更新逻辑不是原子性的（例如先cat再append再write），可能会产生损坏的JSON。使用jq . jobs-state.json验证文件格式。
  4. 检查健康检查脚本逻辑：确认健康检查脚本中jq查询的键名是否与update_task_state中使用的task_id完全一致（大小写敏感）。

• 实操心得：始终在包装脚本的最后一步调用状态更新。即使业务逻辑失败，也应更新状态为“error”。一个“错误”状态远比“缺失”状态更有助于诊断。可以考虑在脚本开头设置一个trap，确保在脚本异常退出时也能尝试更新状态。

5.2 问题：出现了重复执行，但日志里没有ALREADY_CLAIMED

• 排查步骤：

  1. 确认锁机制生效：claim_task函数使用的锁文件路径（/tmp/cron_locks）是否在所有可能运行该任务的服务器或容器中都是共享且持久的？如果是在容器化环境中，/tmp可能是临时的，需要挂载共享卷。
  2. 检查锁的粒度：task_id是否唯一？两个不同的任务是否意外使用了相同的ID？
  3. 检查flock可用性：某些最小化的Linux发行版或容器镜像可能没有安装util-linux包，导致flock命令不存在。使用which flock检查。
  4. 检查脚本超时：如果任务运行时间非常长，超过了Cron的调度间隔，即使有锁，第二个进程在等待锁释放后（如果用了flock -w超时）仍然会执行。这时需要评估任务周期是否合理，或者使用更高级的调度器（如只运行单实例的Celery beat）。

• 避坑技巧：不要只依赖文件锁。对于关键任务，可以在数据库或分布式缓存（如Redis）中设置一个带有过期时间的原子键值作为锁，这样更可靠。文件锁更适合单机场景。

5.3 问题：触发器报告“Wrapper ran but produced no result”

• 排查步骤：
  1. 检查结果文件路径：包装脚本中定义的RESULT_FILE路径和触发器读取的路径是否绝对一致？使用绝对路径，避免相对路径的歧义。
  2. 检查磁盘空间：结果文件所在磁盘是否已满？运行df -h检查。
  3. 检查包装脚本退出码：触发器逻辑是否正确处理了包装脚本非0退出码？可能脚本因权限、依赖等问题早于write_standard_result调用就崩溃了。在包装脚本开头添加exec 2>&1将标准错误重定向到标准输出，方便触发器捕获所有日志。
  4. 模拟测试：手动以Cron用户身份运行包装脚本，观察其行为：sudo -u cron_user /usr/local/bin/backup_report_wrapper.sh。

5.4 问题：交付模式混乱，有些该通知的没通知

• 排查步骤：

  1. 审查任务定义：逐一检查jobs.json中每个任务的delivery.mode设置。为每个任务明确其通知意图：是必须广播（announce），还是静默或自行处理（none）。
  2. 测试交付链路：对于mode: “announce”的任务，可以临时修改触发器，将其输出记录到日志文件而不是真正发送，确认消息内容是否正确生成。
  3. 检查历史变更：如果某个任务的通知突然消失，使用Git历史或配置管理工具的历史记录，查看最近谁修改了该任务的delivery.mode或相关的触发器逻辑。

• 最佳实践：将delivery.mode作为任务定义的必填字段，并在代码审查时重点检查。可以编写一个简单的验证脚本，在CI/CD流水线中检查所有Cron任务配置，确保没有任务遗漏此字段或使用非法值。

5.5 高级技巧：合约的扩展与变体

标准合约是基础，但真实场景可能需要变通。

• 场景：需要传递参数的任务：包装脚本可能需要接收参数（如--env production）。只需确保这些参数不影响声明和结果文件的生命周期逻辑。可以将task_id设计为包含参数哈希值，以确保不同参数的任务实例互不干扰。

  TASK_ID=“daily_backup_check_$(echo “$@” | md5sum | cut -d‘ ’ -f1)”

• 场景：长时间运行的任务：对于运行时间超过调度间隔的任务，除了声明锁，还应该在状态文件中记录“开始时间”和“心跳”。健康检查可以检查“开始时间”，如果任务运行超时，则标记为僵死，并可能触发恢复操作。
• 场景：结果文件需要保留历史：有时需要查看过去几次的运行结果。可以修改cleanup_result逻辑，将旧结果文件轮转或归档到带时间戳的路径下，而非直接删除。同时，触发器合约需要明确指定读取最新的结果文件。

推行openclaw-cron-standard这类合约，最大的挑战往往不是技术，而是习惯。它要求开发者和运维人员从“写一个能跑的脚本”转变为“设计一个符合合约的可靠组件”。初期可能会觉得繁琐，但一旦团队形成习惯，它将极大地降低系统维护成本，让定时任务从“脆弱的黑盒”变成“可信赖的公共服务”。