第14课：OpenClaw｜定时任务与Cron【让OpenClaw“无人值守”】

前几节课，你已经完成了OpenClaw的核心部署和技能扩展------它能操作文件、浏览网页、收发邮件、接入聊天软件。这些能力让OpenClaw具备了"能干事"的底子，但还缺最后一环：主动性。

到目前为止，我们一直在做"人问AI答"的事。你发一条指令，AI执行一次。这种模式在需要定期执行的任务面前显得力不从心------你不可能每天凌晨3点爬起来告诉AI"开始备份"，也不可能每半小时手动催它"检查一下新邮件"。OpenClaw从"响应式工具"到"自主执行者"的最后一步，恰恰是让它拥有时间感知能力。

OpenClaw通过两种互补的定时机制打通了这条路径：Cron负责精确到分钟的刚性调度 ，适合"每天9点准时出日报"这类确定性任务；Heartbeat负责周期性巡检，适合"每隔一段时间检查有没有异常"这类柔性监控。前者是闹钟，后者是心跳监护仪。

读完本节课，你将不仅学会创建定时任务，还能根据具体场景在Cron与Heartbeat之间做出正确选择，理解会话隔离、投递机制、指数退避等运行细节，最终让OpenClaw成为一台真正24小时无人值守的自动化引擎。

14.1 定时任务的两种核心机制

在动手创建定时任务之前，必须理清OpenClaw自动化的两套独立引擎------这是整个章节的逻辑起点，也是社区用户最容易踩的坑。

14.1.1 Cron：刚性调度的精确之选

一句话概括：Cron是Gateway内置的定时调度器，负责将"什么时候执行"和"执行什么内容"拆解开来，在精确的时间点唤醒智能体完成任务，并将结果投递到指定渠道。

OpenClaw Cron不是Linux Crontab的简单移植，而是面向AI智能体专门设计的调度中枢。它保存任务、计算下一次触发时间、在合适的时间唤醒智能体执行任务，并在需要时把结果投递回聊天通道、主会话或Webhook。

关键澄清：Cron不是Skill，也不是插件或工具。Skill解决的是"AI能做什么"，Cron解决的是"这件事什么时候自动触发"。两者不是同一层------Skill是执行部件，Cron是调度中枢。Cron可以调度带有浏览器、消息、日历、邮件、文件处理等能力的任务，但Cron本身不是这些能力的一部分。

Cron支持三种触发方式：

触发类型	说明	典型场景
at	指定时间点执行一次	"20分钟后提醒我"
every	固定间隔重复	"每2小时运行一次"
cron	标准5位Cron表达式	"每天9点执行"

14.1.2 Heartbeat：柔性巡检的批量通道

一句话概括：Heartbeat在主会话中以固定间隔运行周期性检查，通过读取HEARTBEAT.md批量处理多个轻量任务------无事静默，有事主动通知，一次AI调用完成多项检查，大幅节省Token成本。

Heartbeat会在主会话中运行周期性智能体轮次，让模型能够在不频繁打扰用户的情况下主动呈现需要关注的事项。默认每30分钟触发一次，读取HEARTBEAT.md清单逐项检查------无任务时仅返回静默响应，有任务时才主动推送通知。

Heartbeat的运行逻辑是分层的：先执行低成本确定性检查（进程、文件、队列深度、API状态等），再根据阈值进行规则判断，仅在需要解决模糊不确定性问题时才调用大模型。这种"先低成本探测、按需调用模型"的模式是Heartbeat节省Token的本质。

14.1.3 Cron vs Heartbeat：最易混淆的三个维度

维度	Cron	Heartbeat
定位	Gateway内置调度器	主会话定期运行机制
精度	精确到分钟	固定间隔（默认30分钟），不保证整点
上下文	默认隔离会话（无历史记忆）	主会话，可继承历史对话
最佳场景	固定时刻、固定周期、一次性提醒	批量轻量巡检、需上下文的任务
Token消耗	每次运行独立调用模型	批量合并检查，一次调用完成多项

至关重要的一点：主会话类型的Cron任务，本质上是先排入一个系统事件，再通过Heartbeat执行通道把任务跑起来。Cron与Heartbeat不是替代关系，而是明确的协作关系------Cron依赖Heartbeat的会话上下文来执行主会话任务。

14.1.4 选型指南：到底该用哪个？

需求场景	推荐选择	理由
每天9:00准时推送晨报	Cron	需要精确到分钟的时间控制
每5秒检查一次服务状态	Heartbeat	无需高精度，可批量合并检查
检查邮箱、日历、待办	Heartbeat	多个轻量任务合并，节省Token
每周五22:00自动备份	Cron	固定周期，确定性任务
检测目录有新文件后处理	文件监听（第11课）+ Cron兜底	监听为主，Cron定期兜底

简单判断法则：需要精确到某个时刻→Cron；需要按固定节奏"扫一眼"→Heartbeat。

14.2 创建、修改、暂停、删除定时任务

14.2.1 用CLI命令创建任务（推荐方式）

OpenClaw提供了完整的CLI命令集来管理定时任务，通过openclaw cron子命令实现。

创建一个周期性任务：

# 每日9点生成晨报，通过飞书推送
openclaw cron add \
  --name "晨间简报" \
  --cron "0 9 * * *" \
  --tz "Asia/Shanghai" \
  --session isolated \
  --message "请整合今日日历事件和未读邮件摘要，生成结构化晨报" \
  --announce \
  --channel feishu \
  --to "your_user_id"

# 每2小时执行一次系统健康检查
openclaw cron add \
  --name "系统健康巡检" \
  --every "2h" \
  --session isolated \
  --message "请检查服务器CPU使用率、内存占用和磁盘空间，生成健康报告"

命令参数详解：

参数	说明	示例
--name	任务名称，便于识别和管理	"每日早报"
--cron	Cron表达式（分 时 日 月 周）	"0 9 * * *"
--every	固定间隔（替代cron）	"2h"、"30m"
--at	一次性任务时间	"2026-05-10T15:30:00Z"
--tz	时区	"Asia/Shanghai"
--session	会话类型（main/isolated）	"isolated"
--message	要执行的自然语言指令	"生成日报"
--announce	将结果公开投递	---
--channel	投递渠道	"telegram"、"feishu"
--to	投递目标（用户/群组ID）	"user_123456"

参数解析 ：isolated会话会在一个全新的、无历史记忆的上下文中运行定时任务，避免历史对话污染当前任务；main会话则使用主会话的上下文，适合需要记忆的任务。一次性任务（--at）默认在成功执行后自动删除，可通过--keep-after-run保留。

创建一个一次性提醒：

# 30分钟后提醒我开会
openclaw cron add \
  --name "会议提醒" \
  --at "30m" \
  --session main \
  --message "提醒：请准备10分钟后的团队会议材料"

--at参数支持两种格式：相对时间（如30m、2h、1d）和绝对ISO时间戳（需指定时区）。

14.2.2 通过JSON文件批量管理

对于需要版本控制或多任务统一维护的场景，可以手动编辑~/.openclaw/cron/jobs.json文件：

{
  "jobs": [
    {
      "id": "morning-brief-001",
      "name": "晨间简报",
      "schedule": {
        "kind": "cron",
        "expr": "0 9 * * *",
        "tz": "Asia/Shanghai"
      },
      "sessionTarget": "isolated",
      "payload": {
        "kind": "agentTurn",
        "message": "请整合今日日历事件和未读邮件，生成结构化晨报"
      },
      "announce": true,
      "delivery": {
        "channel": "feishu",
        "to": "your_user_id"
      }
    }
  ]
}

⚠️ 【修改安全提醒】 ：Gateway运行期间会将jobs.json加载到内存中。手动编辑前必须先暂停Gateway或使用openclaw cron reload命令重载，否则修改可能被内存缓存覆盖。官方推荐优先使用openclaw cron add/edit命令进行更改。

14.2.3 查看与管理任务

# 列出所有定时任务
openclaw cron list

# 查看任务运行历史（含状态、耗时、Token消耗）
openclaw cron runs --id <job-id>

# 立即手动触发测试
openclaw cron run <job-id> --force

# 编辑现有任务（打开系统编辑器）
openclaw cron edit <job-id>

# 暂停任务
openclaw cron disable <job-id>

# 恢复任务
openclaw cron enable <job-id>

# 删除任务
openclaw cron remove <job-id>

# 重载配置文件（编辑jobs.json后执行）
openclaw cron reload

14.2.4 Cron表达式速查

Cron表达式格式为"分 时 日 月 周"，各字段取值范围：

字段	范围	特殊符号
分钟	0-59	* , - /
小时	0-23	* , - /
日	1-31	* , - / ?
月	1-12	* , - /
周	0-6（0=周日）	* , - / ?

常用示例：

表达式	含义
0 9 * * *	每天上午9:00
30 8 * * 1-5	工作日上午8:30
0 */2 * * *	每隔2小时
0 0 * * 0	每周日午夜
0 22 * * 5	每周五晚上10点

14.2.5 指数退避重试机制

OpenClaw的Cron任务内置了智能重试机制：循环任务在连续失败后会使用指数退避策略进行重试（30秒→1分钟→5分钟→15分钟→60分钟），并在下一次成功运行后恢复正常调度。这意味着即使模型API临时不可用、网络抖动或第三方服务超时，任务也会自动恢复，无需人工介入。

避坑指南 ：如果openclaw cron list能看到任务，但该执行时却没跑，优先检查：

1. 确认Gateway服务是否正常运行（openclaw gateway status）
2. 检查时区配置是否正确（--tz参数）
3. 查看任务运行历史（openclaw cron runs --id <job-id>）定位具体失败原因

14.3 Heartbeat机制：确保Agent长期健康运行

14.3.1 Heartbeat的核心作用

Heartbeat在OpenClaw定时体系中扮演着独特角色。它不是传统意义上的"定时任务执行器"，而是一个基于主会话的定期体检机制。以下是Heartbeat在系统中的三大支柱作用：

• 系统监控与健康检查：定期给整个OpenClaw系统做"体检"，检测各模块状态、渠道连通性、队列深度等核心指标
• 任务状态与流量监控：维护后台任务执行状态，监控各会话的消息流量，及时发现异常堆积
• 定时触发任务的执行与调度：作为Cron主会话任务的实际执行通道，系系统事件与Agent执行的桥梁

技术细节：Heartbeat本身不创建后台任务记录。任务记录仅用于ACP运行、子Agent和隔离Cron任务。Cron与Heartbeat的区别不在"谁功能更强"，而在"谁在什么情况下使用"------Heartbeat特别适合需要历史记忆的巡检任务，因为它运行在主会话上下文中。

14.3.2 HEARTBEAT.md清单配置

Heartbeat的工作内容由HEARTBEAT.md文件定义，位于workspace根目录。当Heartbeat被触发时，模型会读取这个文件，逐项执行清单中的检查动作。

HEARTBEAT.md标准模板：

# 每日自动化检查清单

## 系统健康检查
- 检查Gateway进程是否为running状态
- 验证各Channel（Telegram/飞书/钉钉）连通性
- 检查系统监控队列深度是否异常
- 如遇异常，记录日志并尝试自动恢复

## 任务执行队列状态监控
- 检索所有执行中的Agent运行状态
- 清理长时间未响应的会话
- 上报任务完成进度

## 定时触发任务执行与调度
- 执行预定义的定时触发动作
- 输出本次心跳所完成的任务列表
- 基于历史心跳数据，智能预测并调整任务优先级

14.3.3 Heartbeat配置详解

在openclaw.json中配置Heartbeat行为：

{
  "agents": {
    "defaults": {
      "heartbeat": {
        "every": "30m",
        "target": "last",
        "directPolicy": "allow",
        "lightContext": true,
        "isolatedSession": false,
        "skipWhenBusy": true,
        "activeHours": {
          "start": "08:00",
          "end": "22:00"
        },
        "includeReasoning": false
      }
    }
  }
}

配置参数说明：

参数	默认值	说明
every	30m	执行间隔，支持m（分钟）、h（小时）、s（秒）。设为0m可禁用
target	"none"	结果投递渠道，"last"表示投递给最近使用的渠道，"none"表示不投递
directPolicy	"allow"	是否允许投递到私信/DM目标
lightContext	false	是否仅注入HEARTBEAT.md（跳过SOUL.md等）
isolatedSession	false	是否每次运行使用全新会话（无历史对话）
skipWhenBusy	false	当Agent繁忙时是否跳过本次心跳
activeHours	空	限定运行时段（当地时间），超出时跳过
includeReasoning	false	是否单独发送推理过程消息

14.3.4 触发心跳的多种方式

# 立即触发一次心跳（立即模式）
openclaw heartbeat run --mode now

# 等待下一个调度时刻触发
openclaw heartbeat run --mode next

# 查看心跳调度状态
openclaw heartbeat status

# 带自定义消息触发
openclaw heartbeat run --text "紧急巡检：检查系统异常状态"

14.3.5 空闲超时与会话清理

Heartbeat的另一项职责是管理会话生命周期。通过配置session.pruneAfterDays和session.maxEntries等参数，可以设置会话空闲超时自动清理策略（详见第7课7.5节）。Heartbeat会定期检查并清理超时的会话状态，避免会话日志无限膨胀。

14.3.6 Cron与Heartbeat的智能协同

在复杂自动化场景中，Cron与Heartbeat可以协同工作：Heartbeat负责高频轻量检查（如每10秒监控服务状态），一旦检测到异常，触发Cron调度详细诊断脚本执行深度分析。这种分级响应的设计既保证了监控的实时性，又在按需调用时控制模型成本------日常巡检由Heartbeat的低成本确定性检查完成，仅在确认异常时才触发Cron调用大模型进行深度诊断。

14.4 结合Channel推送定时执行结果

14.4.1 投递参数详解

Cron任务的输出投递由--announce、--channel和--to三个参数控制。

--session决定会话类型：

会话类型	特点	适用场景
isolated（推荐）	全新会话，无历史记忆，结果通过--announce投递	周期性报告、数据抓取、无需上下文的任务
main	在主会话中运行，结果保留在对话上下文	需要历史记忆的任务，如"回顾昨天的检查结果"

# 正确方式：隔离会话 + 显式投递
openclaw cron add \
  --name "每日摘要" \
  --cron "0 9 * * *" \
  --session isolated \
  --message "抓取头条新闻生成摘要" \
  --announce \
  --channel telegram \
  --to "user_123456"

--announce vs --deliver：

• --announce（当前推荐）：将任务输出公开投递给指定渠道或会话
• --deliver（已弃用别名）：保留仅为兼容性，新任务应使用--announce

14.4.2 多渠道投递配置

# 投递到Telegram私聊
--channel telegram --to "user_123456"

# 投递到飞书群聊
--channel feishu --to "group:your_group_id"

# 投递到Discord频道
--channel discord --to "channel:1234567890"

# 投递到主会话（不公开）
--session main

14.4.3 失败投递的降级策略

当指定投递目标不可达时，OpenClaw会按以下优先级回退：首先使用delivery.failureDestination配置项，然后使用全局cron.failureDestination，最后才回退到任务的主announce目标。

建议在openclaw.json中配置统一的失败通知目标：

{
  "cron": {
    "failureDestination": {
      "channel": "telegram",
      "to": "admin_user_id"
    }
  }
}

14.4.4 --no-deliver静默运行

如果只需要任务执行而不需要任何输出投递（如静默数据同步），可以使用--no-deliver：

openclaw cron add \
  --name "静默备份" \
  --cron "0 2 * * *" \
  --session isolated \
  --no-deliver \
  --message "执行数据库增量备份，无需通知"

此时任务运行结果仅记录在日志中，不会向任何渠道推送消息。但如果隔离Cron运行只返回静默令牌（如NO_REPLY），系统会同时抑制直接对外投递和回退的排队摘要路径，因此不会向聊天回发任何内容。

14.5 实战案例1：每日定时生成待办事项

14.5.1 需求与准备工作

需求描述：让OpenClaw每天早晨9:00自动整合当日日历事件、邮件摘要和待办清单中高优先级未完成任务，生成结构化晨报并推送到飞书群。这是OpenClaw社区中最受欢迎的常规场景之一。

前置条件：

• 已安装并启用Calendar Skill（日历技能）
• 已安装并启用todo-manager Skill（待办管理技能）
• 已配置邮件自动化（IMAP/SMTP，见第13课）
• 飞书Channel已配置并获取用户/群组ID

验证命令：

openclaw skills list | grep -E "calendar|todo-manager|imap-smtp-email"
openclaw channels list | grep feishu

14.5.2 创建定时任务

openclaw cron add \
  --name "晨间简报" \
  --cron "0 9 * * *" \
  --tz "Asia/Shanghai" \
  --session isolated \
  --message "请按以下顺序执行：1. 读取今日日历事件并列出会议议题和时间；2. 扫描未读邮件中高优先级邮件，提取发件人和主题摘要；3. 从待办清单中筛选今日截止或超时的高优先级任务；4. 将所有信息整合成结构化晨报，分三个模块输出：日历会议、邮件摘要、待办任务，最后给出优先级排序建议" \
  --announce \
  --channel feishu \
  --to "group:your_group_id"

14.5.3 通过JSON配置文件添加

{
  "jobs": [
    {
      "id": "morning-brief-001",
      "name": "晨间简报",
      "schedule": {
        "kind": "cron",
        "expr": "0 9 * * *",
        "tz": "Asia/Shanghai"
      },
      "sessionTarget": "isolated",
      "payload": {
        "kind": "agentTurn",
        "message": "请整合今日日历事件、未读邮件摘要及todo-manager中所有高优先级未完成任务，生成结构化晨报"
      },
      "announce": true,
      "delivery": {
        "channel": "feishu",
        "to": "group:your_group_id"
      }
    }
  ]
}

14.5.4 测试与调试

# 查看任务是否注册成功
openclaw cron list | grep 晨间简报

# 手动触发测试（立即执行）
openclaw cron run morning-brief-001 --force

# 查看运行历史和输出
openclaw cron runs --id morning-brief-001

# 检查飞书群是否收到消息，如果未收到，查看日志定位投递问题
openclaw logs | grep -E "cron|feishu"

14.5.5 进阶：结合Heartbeat的兜底机制

如果希望确保晨报在9:00附近的某个时间段内必然生成（即使用户在此期间主动与Agent对话打断了调度），可以在HEARTBEAT.md中添加兜底规则：若当前时间为9:00±5分钟内且今日尚未生成晨报，则触发生成。这种双重保障设计在OpenClaw社区实践中被反复验证为高可靠性的自动化模式。

14.6 实战案例2：每周自动备份重要数据

14.6.1 需求描述

让OpenClaw每周五晚上10:00自动将指定目录的重要数据打包备份，同时清理超过30天的旧备份文件，备份完成后通过Telegram发送包含备份大小、耗时、旧文件清理数量的执行报告。这是一个典型的运维自动化场景。

前置条件：

• 文件系统Skill已启用并配置磁盘写权限（见第11课）
• Telegram等Channel已配置并入outbound通道
• 目标备份和日志的父级路径无需严格绑定，Cron任务在Gateway进程空间内运行

14.6.2 创建定时备份任务

openclaw cron add \
  --name "周度数据备份" \
  --cron "0 22 * * 5" \
  --tz "Asia/Shanghai" \
  --session isolated \
  --message "请执行以下备份流程：1. 创建备份目录，格式为 /backup/data_YYYYMMDD；2. 将 /important_data 目录完整打包为 tar.gz 压缩包，放入备份目录；3. 扫描备份目录，删除超过30天未修改的所有 .tar.gz 文件；4. 生成执行报告，包含：备份文件大小/个数、耗时秒数、清理文件数量、备份磁盘剩余空间；5. 通过条件发送tg消息：若备份文件大小超过1GB或清理文件数超过预期，立即发送Telegram告警消息" \
  --announce \
  --channel telegram \
  --to "user_123456"

14.6.3 配置文件方式

{
  "jobs": [
    {
      "id": "weekly-backup",
      "name": "周度数据备份",
      "schedule": {
        "kind": "cron",
        "expr": "0 22 * * 5",
        "tz": "Asia/Shanghai"
      },
      "sessionTarget": "isolated",
      "payload": {
        "kind": "agentTurn",
        "message": "执行数据备份和清理流程，生成执行报告并推送通知"
      },
      "announce": true,
      "delivery": {
        "channel": "telegram",
        "to": "user_123456"
      }
    }
  ]
}

14.6.4 验证与故障排查

# 手动触发测试（建议先用测试目录验证）
openclaw cron run weekly-backup --force

# 检查备份文件是否生成
ls -la /backup/

# 查看任务运行历史
openclaw cron runs --id weekly-backup

# 查看Telegram是否收到报告

⚠️ 【安全红线】：备份任务涉及文件删除操作，建议先开启审批模式，并设置文件删除前需要用户确认。同时要确保备份目录有足够磁盘空间，可在指令中增加空间检查步骤：备份前检查剩余空间，不足时先触发报警而不是直接执行。

14.6.5 故障排查要点

备份任务可能出现的问题及排查方法：

问题现象	可能原因	解决方案
备份目录无文件	路径未加入allowedPaths白名单	检查并更新openclaw.json中的tools.file.allowedPaths
任务未准时执行	时区配置错误	确认--tz "Asia/Shanghai"是否正确
任务运行但无输出	使用了--no-deliver	移除该参数或改用--announce
连续失败后停止	触发了重试上限	查看openclaw cron runs定位失败原因，调整指令后重新执行
模型长时间未响应	任务复杂度高/超时	在Cron任务配置中显式增加超时时间；如使用阿里云百炼Coding Plan，在skills的配置文件中调整timeout

14.7 定时任务的性能监控与日志审计

14.7.1 任务运行审计

所有Cron任务的执行都会创建后台任务记录，状态轨迹依次为：queued → running → terminal（最终状态：succeeded、failed、timed_out、cancelled或lost）。

# 查看任务运行历史（含状态、耗时、Token消耗）
openclaw cron runs --id <job-id>

# 查看所有任务最新运行状态
openclaw cron list

# 获取详细执行日志（含模型调用细节）
openclaw logs | grep "cron"

运行历史包含每次执行的开始时间、结束时间、执行状态、Token消耗、输出摘要等关键审计信息。定期回顾这些历史对优化任务调度策略至关重要。

14.7.2 系统健康检查

# 整体健康检查
openclaw health

# Gateway服务状态
openclaw gateway status

# 查看已启用Cron及其调度状态的报告，下方会显示未来的某个调度点
openclaw cron status

# 查看所有Channel是否在线
openclaw channels status

14.7.3 执行历史自动清理配置

为防止日志无限膨胀，OpenClaw提供了内置清理策略：

{
  "cron": {
    "sessionRetention": "24h",
    "runLog": {
      "maxBytes": 10485760,
      "keepLines": 1000
    }
  }
}

参数	默认值	说明
sessionRetention	24h	完成后保留隔离运行会话的时长，到期后自动清理
runLog.maxBytes	10MB	每个任务的运行日志文件最大字节数
runLog.keepLines	1000	超过maxBytes时保留的最近运行记录条数

14.7.4 并发控制与资源优化

在高并发场景下，合理设置并发上限是保证系统稳定的关键。相关内容在第7课7.4节"Lane队列机制"中有详细讲解。

时效性相关的关键限流参数：

• 全局并发上限 （agents.defaults.maxConcurrent）：控制同时运行的Agent任务数，未配置的lane默认为1，main lane默认为4，subagent lane默认为8。当Cron任务与其他会话任务争抢资源时，此参数影响执行延迟
• 队列积压观测 ：openclaw logs | grep -i "queue\|lane"可观察到排队等待超时的警告信息
• 超时配置：Cron任务可以独立设置timeout时间，避免单个复杂任务长时间占用调度资源

14.7.5 第三方监控工具

对于企业级部署，社区提供了增强型监控方案：

• clawdoctor：提供GatewayWatcher监控Gateway进程状态（30秒）、CronWatcher检查Cron任务失败和逾期（60秒）、SessionWatcher检测Agent会话错误和卡死（60秒）
• claw-lens-cli：可视化审计工具，读取OpenClaw写入磁盘的会话JSONL、缓存跟踪、Cron配置和Agent记忆，将所有数据解析到SQLite并通过Express API提供前端查询

14.7.6 性能调优建议

优化方向	操作
降低Token消耗	将轻量级巡检任务从Cron迁移到Heartbeat，利用其合并检查机制减少模型调用次数
避免资源竞争	将耗时任务安排在非高峰时段（如凌晨执行），通过activeHours限制Heartbeat运行时段
异步结果反馈	使用--announce --channel将任务结果投递到Channel，避免阻塞主会话
任务优先级策略	利用Lane Queue的lane池隔离机制：Cron任务使用cron和cron-nested lane，普通会话使用main lane，独立排空互不阻塞
主会话型Cron任务	注意其本质是排入系统事件后通过Heartbeat通道执行，若Heartbeat重度堵塞会导致任务延迟------必要时可改用isolated模式绕开心跳通道

14.7.7 故障排查阶梯

当定时任务出现异常时，按以下阶梯逐层排查：

1. openclacron status → 报告已启用，显示下次唤醒时间（nextWakeAtMs）
2. openclaw cron list → 确认任务存在，且拥有有效的调度/时区
3. openclaw cron runs --id <job-id> → 查看具体运行记录，区分状态（succeeded/failed/timed_out）
4. openclaw logs --follow → 观察实时运行日志

14.8 本节小结

本节课完整覆盖了OpenClaw定时任务体系的方方面面，核心知识点可浓缩为：

• Cron vs Heartbeat：Cron负责精确到分钟的刚性调度，是Gateway内置调度器；Heartbeat负责固定间隔的柔性巡检，运行在主会话上下文中。选型的黄金法则------精确时间点用Cron，周期性批量巡检用Heartbeat

• 任务创建与管理 ：通过openclaw cron add CLI命令或编辑~/.openclaw/cron/jobs.json创建任务，支持Cron表达式、固定间隔、一次性提醒三种调度方式；循环任务内置指数退避重试机制（30s→1m→5m→15m→60m），自动恢复瞬时故障

• 会话隔离 ：isolated模式每次在新会话中执行任务，适合无状态周期性报告；main模式使用主会话上下文，适合需要历史记忆的巡检

• 结果投递 ：--announce将任务输出推送到Telegram/飞书/钉钉等Channel；--no-deliver静默运行不推送；--session main将结果保留在主会话

• Heartbeat清单 ：HEARTBEAT.md定义巡检内容，支持批量合并检查、主动时段限制、繁忙时自动跳过，一次模型调用完成多项检查

• 监控审计 ：openclaw cron runs查看运行历史和Token消耗；openclaw health检查系统整体健康；clawdoctor/claw-lens-cli提供企业级可视化监控

• 安全基线 ：文件删除类任务开启审批模式；敏感路径必须加入allowedPaths白名单；为Cron任务单独配置失败投递目标

至此，你的OpenClaw已经具备了完整的自主运行能力------能听（Channel）、能记（Memory）、能读（文件）、能上网（浏览器）、能收发邮件、能按定时调度工作。下一节课将正式进入企业IM集成专题，把这些原子能力组合成团队协作的生产力系统。

14.9 课后习题

1. Cron vs Heartbeat选型判断

以下场景分别适合使用Cron还是Heartbeat？请给出判断理由：

• A. 每天凌晨2点自动备份数据库
• B. 每隔5分钟检查服务器CPU是否超过85%
• C. 每周一上午10点生成销售周报
• D. 需在20分钟后发送会议提醒
• E. 检查后台队列中是否有超过10秒未处理的消息

2. 实战命令操作

在你的OpenClaw环境中，创建一个每5小时运行一次的任务"系统健康检查"，指令内容为"检查CPU使用率、内存占用和磁盘空间，输出简短健康报告"。不投递到任何渠道，仅在日志中记录结果。写出完整的创建命令。

3. HEARTBEAT.md配置

请根据你的个人日常办公场景，编写一份HEARTBEAT.md文件，至少包含4项检查清单（如：检查邮箱、检索日历、待办提醒、问候语等）。然后启用Heartbeat并观察一段时间内的自动化运行效果。

4. 投递目标配置与重试

假设你的飞书机器人Channel因token过期暂时掉线，而Cron任务"晨间简报"配置了--announce --channel feishu。写出两种确保该任务结果不丢失的冗余配置方案（提示：失败降级策略和备选渠道）。

5. 故障排查演练

创建以下任务并模拟故障：openclaw cron add --name "故障任务" --every "30s" --message "此任务会产生错误"。观察该任务在连续失败后重试间隔的变化（30秒→1分钟→5分钟），用openclaw cron runs记录重试历史，并在输出中解释指数退避重试对该任务稳定性的保障价值。

6. 综合设计题（选做）

设计一个"7×24无人值守自媒体内容自动生成"系统：每日6:00抓取指定网站新闻标题和摘要→9:00整理成日报草稿→由人工在飞书确认后正式发布→22:00自动统计今日发布文章的阅读量并生成周报。使用Cron、Channel、邮件自动化和浏览器技能，画出完整的任务调度时间线，并说明各环节的异常处理策略。

🔗《30节课精通 OpenClaw》系列课程导航

去订阅

第一部分（第1-5课） ：基础认知与入门部署------解决"这是什么、怎么搭建"的问题；

第二部分（第6-10课）：核心原理深度剖析------解决"底层怎么工作"的问题；

第三部分（第11-15课） ：应用场景与平台集成------解决"能用来做什么"的问题；

第四部分（第16-21课） ：技能开发与定制扩展------解决"如何自己扩能力"的问题；

第五部分（第22-26课）：高级特性与性能优化------解决"怎么用得更好"的问题；

第六部分（第27-30课） ：安全、运维与生态进阶------解决"如何安全可靠地规模化"的问题；