定时任务和 Heartbeat 应该怎样选？
先确定是固定时间交付，还是周期检查变化，再明确时区和通知条件。
本页目录
直接回答
按计划执行的任务关注明确日程，Heartbeat 关注周期检查状态并决定是否行动，具体机制取决于宿主。每天固定当地时间生成经营报告，适合明确日程；持续观察项目是否有重要新进展，更接近心跳。先确定业务语义再选择调度，不机械复制时间表达式。
实践建议：将触发、业务执行和通知分开核对。按时启动但数据源失败，应报告执行失败；业务完成但通知失败，也应保留产物以便恢复。
适用场景
- 要每天生成报告或每隔一段时间检查变化。
- 已有提醒重复刷屏，或跨时区后在错误时间执行。
一步一步做
写清触发与时间范围
明确是每天某地时间、固定间隔，还是事件发生后执行。说明报告覆盖哪一天、按哪个时区截断。夏令时、机器休眠和服务暂停可能影响实际运行，需要在所用平台核对。
定义有意义的变化
监控写清什么值得通知：完成、失败、关键指标变化或需要你处理。状态没变时保持安静；每日汇总则说明即使无变化是否仍需要一份报告。
先手动跑通实际任务
确认数据读取、去重、结果格式和异常处理都可用，再添加触发。定时器只能重复执行现有流程，不能修复不可靠的业务逻辑。
处理重叠、错过与重复
整理建议：同一任务未结束时避免重复启动；决定错过计划后补跑还是跳过，并保存已处理范围。对发信、写入等操作用稳定任务标识防止重复结果。
验证调度与可控性
记录下次触发时间、运行日志和最终状态，检查一次实际自动运行。保留暂停、降频、手动补跑和失败通知入口；需要停止时能确认后续触发已撤销。
分开检查触发、执行、方法和交付四层
触发器负责何时开始，执行器真正调用工具，Skill 或 SOP 定义方法，产物和通知负责交付。若模板里的真实 Agent 调用仍被注释，打印开始和结束并不能证明生成了结果。每次记录运行 ID、输入窗口、执行状态、产物位置和通知状态，实际回读业务产物后才标成功。
按已安装版本核对心跳机制
2026-10-18 核对的 OpenClaw 官方说明使用数据库中的 monitor scratch 与 automation jobs；HEARTBEAT.md 是迁移输入，运行时不读取它。不能创建一个熟悉的文件名或复制示意 tasks/interval 字段就声称调度生效。先核对已安装版本、实际任务列表、周期、会话、交付对象和运行历史；迁移命令本身会变更状态，应先准备可恢复方案。
跨电脑或框架迁移先预演，再停旧启新
盘点Skill版本、执行命令/依赖、工作目录、输入输出路径、账号范围、模型接口、日程时区、去重账本和暂停状态。先在新环境做不产生外部副作用的试跑，记录不兼容项；凭据单独按授权配置。旧任务停用后再启用新任务，核对只有一个调度源，并保留回退方案。搬走配置文件不等于完成岗位迁移。
案例拆解
假设示例：每日工作汇总
如果使用者选择每日 Asia/Shanghai 09:00 汇总前一天工作，应将时区、内容日期和交付对象一起写清。这个具体时间只是例子，不是默认要求。私人晨报无有效信号时仍应遵守筛选标准，不为凑输出而编写内容。
行动检查
可复制模板
调度任务说明
任务目标：
触发方式：固定时间 / 固定间隔 / 周期检查变化
时区：
处理的数据时间范围：
成功结果与交付位置：
只有这些变化需要通知：
失败处理：
错过运行的处理：
重复/重叠控制：
暂停与手动重跑方法：
首次自动运行的核对方式：
运行证据与迁移验收
任务ID/配置版本：
触发时间/实际开始/结束时间：
数据窗口：
执行器确实调用了什么：
输入状态：完整 / 部分 / 缺失
业务产物路径及回读结果：
通知对象/已送达证据/未知结果：
重试是否会重做业务副作用：
旧环境与新环境依赖/路径/权限差异：
旧任务停用证据/新任务启用证据：
首次自动运行/暂停/恢复测试：
易错点
- Heartbeat 不是所有产品中的统一技术实现，实际选项应核对当前工具。
- 定时配置保存成功不等于任务已经按时运行过。
- 机器离线后的补跑行为不能凭经验猜测。
- 暂停文件、降频环境变量和手动参数只有执行器实现了才生效；它们不是所有平台内置功能。
- 本地定时通常依赖设备和执行程序可运行；不能因为写入计划就承诺关机后仍执行。
相关指南
官方参考
- OpenClaw：Heartbeat。文档核查记录：2026-10-18；使用前确认适用版本。