OpenClaw心跳监控WebHook自动化任务设置指南
先说个核心判断：OpenClaw 里的心跳和 Webhook，是两套完全独立的自动化触发机制，千万别混为一谈。
心跳是智能体内部自带的定时巡检功能。默认每 30 分钟，智能体自动醒来，瞄一眼工作空间里的 HEARTBEAT.md 文件，逐条核对预设条件——比如检查某个文件还在不在、某个服务是不是还活着、日志里有没有特定关键词冒出来。满足任意一条，就执行对应动作；没动静？那就安静地继续睡回笼觉。
而 Webhook 呢？路子完全不同。它是给外部系统准备的“紧急呼叫按钮”。比如飞书、GitHub、Prometheus 这些系统，在事件发生时通过 HTTP POST 主动把消息推送到你的 Gateway 端点。Gateway 收到后需要先校验令牌、解析 payload，确认没问题了，才会启动一个隔离会话去执行预设任务。
说白了：心跳是“到点了自己看一眼”，Webhook 是“有人敲门才开门”。
心跳监控：定时被动巡检
先得说清楚一个事儿：心跳它不是“竖着耳朵听外面信号”，而是智能体按固定节奏自我唤醒。这个默认节奏是每 30 分钟一次，但完全可调。
- 想改短？执行
openclaw config set agents.defaults.heartbeat.every "15m"，每 15 分钟跑一次。 - 想关闭？设为
"0m"，心跳直接停摆。 - 最典型的用法：批量健康检查、轻量轮询。举个例子，每天定时扫描邮箱附件目录，看看有没有新上传的 PDF 文件，有的话自动处理。
Webhook：外部系统主动唤醒
Webhook 好比给系统装了个“遥控器”，等着外面来按。它暴露一个 HTTP 端点，比如 https://your-gateway.com/webhook/github。外部系统有动静了——GitHub PR 合并、Sentry 报错、企业微信审批通过——就向这个端点发 POST 请求。Gateway 校验令牌后，解析请求体，执行对应的 handler 任务。
- 注意，Gateway 配置里必须显式启用并设置 secret token，不是默认就有的。
- 请求体里的数据默认不可信，handler 里需要做字段校验和数据清洗，安全第一。
- 常用场景：GitHub PR 合并后自动跑测试、Sentry 报错时触发诊断脚本、企业微信审批通过后生成工单——这些都靠 Webhook 的实时推送达成。
两者如何协同？
这两者要是配合得好，能玩出什么花样？
- Webhook 接到告警 → 立刻触发一个即时诊断任务，把现场的日志、状态全部抓取下来。
- 心跳呢？定时去检查诊断结果目录，如果发现某个未处理的
report.txt落在那儿，就自动归档，同时通知负责人。 - 所以它们的角色很清晰：Webhook 负责“应急响应”，心跳负责“兜底巡查”。一个在火线冲锋，一个在后方清场。
常见误区提醒
再提醒一个很多人容易掉进去的坑：千万不要试图把 Webhook URL 写进 HEARTBEAT.md，让心跳去“调用它”。这既不可靠，也不安全，完全违背了设计原则。Webhook 的存在前提是“外部可信系统主动推送”，而不是让智能体假装成外部系统去拉数据。
如果确实需要主动拉取外部数据，正确的做法是使用内置工具（比如 curl 或 http.get），配合 Cron 定时任务或 TaskFlow 工作流来完成。这才是按规矩办事，既干净又稳妥。