OpenClaw 跑起来之后，大部分人还是把它当聊天工具用：你问一句，它答一句，不问它不动。直到有一天你发现，那些每天重复的活——早上巡检一遍知识库、下班前整理当日工单、每周核对一次模型账单——其实都可以让它自己按时做。
OpenClaw 内置了调度器（官方现在叫 Automations，命令行的 cron 命令是它的别名），负责把定时任务持久化、到点唤醒 Agent，并把结果推到你指定的对话或 webhook。调度跑在 Gateway 进程里，也就是说 Gateway 得一直开着，任务才会按时触发。好消息是任务定义存在 SQLite 状态库里，重启不会丢。
三种定时方式，先分清再配置
调度器支持三种常见的时间方式，加上事件触发的流式任务。日常用得最多的是前三种。
at 是一次性提醒，比如”20 分钟后提醒我检查发布清单”，适合一次性安排，跑完默认自动删除。every 是固定间隔，比如 every 1h、every 1d，适合节奏稳定的任务。cron 是精确的表达式调度，比如每天早上八点半、每周一上午，适合有明确业务时间要求的场景。创建之后用 openclaw automations list 查看任务，get 看详情，remove 删除，随时能改。
最容易踩的坑：时区
不带时区的时间戳会被当成 UTC 处理。国内团队如果直接写”每天早上 8 点”，实际触发时间会是北京时间下午 4 点，任务看起来就像没跑。正确做法是给 cron 表达式显式加 –tz Asia/Shanghai。这个坑在中文社区里几乎每个用 OpenClaw 做定时任务的人都会遇到，配置之前先想清楚时区，能省掉大半天的排查时间。
防重叠和超时：定时任务的两道安全阀
定时任务跑起来之后，真正让人头疼的是两件事：任务重叠和任务卡死。一个巡检任务如果上一次还没跑完，下一次又触发了，两个任务同时操作同一批数据，结果很难看。OpenClaw 的 pacing 参数就是干这个的，给任务设 pacing.min 和 pacing.max，比如 15m 到 4h，让调度器在任务实际完成之前别急着触发下一次。
超时方面，隔离会话的 Agent 任务默认有 60 分钟的看门狗，超时会中止并清理会话；命令行任务默认 10 分钟、脚本负载 5 分钟。任务长时间跑不完，与其靠运气，不如在创建时用 –timeout-seconds 明确设上限，让异常尽早暴露。
三个真实场景
每日知识库巡检：每天早上八点半用 cron 触发一个消息任务，让 Agent 检查知识库里的过期条目、失效链接和重复内容，结果推送到运营群。这就把 知识库陈旧内容巡检 从”想起来才做”变成了每天自动发生的动作。
日报推送：每天下班前用 cron 触发，让 Agent 汇总当天工单、异常和待办，按固定格式推给负责人。跑之前先想清楚任务需要哪些工具权限，官方建议给定时任务单独设置工具范围，别让一个日报任务带着全部权限到处跑。
每周成本核对：用 every 1w 或 cron 在每周一触发，让 Agent 拉取模型调用、工具调用和重试数据，生成成本对比。这个场景和 运行成本看板 搭配使用，账单异常能在一周内被发现，而不是月底才追悔莫及。
定时任务也要纳入运行治理
定时任务看起来是”无人值守”，但它一样要留运行证据、要进监控。每次触发的输入、输出和关键操作都应该有记录，方便事后复盘——这和 运行证据导出 的原则一致。定时任务的执行情况也可以进 运行指标仪表盘，看哪些任务经常失败、哪些任务超时，再决定要不要改配置或转人工。
另外提醒一句：如果升级前用的是旧的 heartbeat 结构化配置，升级后用 openclaw doctor –fix 可以把旧任务自动迁移成常规定时任务，别手动重建。定时任务和 回放评测 也可以结合——给定时任务配一份固定样本，定期回放，确认它一直在做正确的事，而不是一直在重复错误的流程。
总结
OpenClaw 定时任务的价值，是把 Agent 从”被动应答”变成”主动值班”。配置本身不复杂，真正要注意的是时区、防重叠、超时上限和任务权限。先把一个高频场景跑起来，比如每日巡检，你会很快发现，Agent 该干的活从来不需要你每天亲手提醒它。
