Heartbeat 心跳机制让 Agent 从被动应答走向主动服务引言用过聊天机器人的读者大概都有类似的体验你不说话它就永远沉默。哪怕服务器磁盘已经告急、日历上的会议十分钟前就该提醒、昨天的日报任务悄悄挂掉了——只要没人开口Agent 便一无所知。这种你问我答的交互范式把 Agent 桎梏在一个等待指令的位置上离真正意义上的助理相去甚远。本文聊聊打破这一局面的关键设计心跳机制Heartbeat。以开源 Agent 框架 OpenClaw 为例我们拆解它如何让 Agent 周期性醒来巡检自身职责范围内的世界并在有事与没事之间做出得体的选择。一、被动响应范式的三块短板传统 Chatbot 乃至很多定时推送机器人本质上都在被动框架里打转。以一个常见的每天定点推送 GitHub Trending任务为例它看起来实现了主动实际暴露了三个问题无条件执行。到了预设时间无论今天有没有值得关注的内容推送雷打不动地发出去。不做筛选。消息格式千篇一律哪怕条目全是你不关心的领域也照推不误。没有反馈回路。如果抓取或搜索过程失败了任务本身浑然不觉用户也毫不知情。这类高级闹钟式实现缺的不是定时能力而是判断能力——它不能在执行前评估状态、在执行后决定是否值得打扰用户。心跳机制补的正是这块拼图。二、心跳机制的核心思想定时唤醒先判断再行动心跳机制可以概括为一句话让 Agent 按固定间隔被唤醒醒来第一件事不是干活而是读一遍自己的巡检清单评估当前状态然后决定告警还是闭嘴。一个形象的类比Cron 任务像闹钟到点就响心跳 Agent 像巡逻的保安每半小时在园区转一圈没事不打扰值班室发现异常立刻上报。二者的差异不在于是否定时而在于定时之后干什么。2.1 心跳的执行流程以 OpenClaw 为例一次完整的心跳大致经过四步定时触发 ──► 时段过滤 ──► 上下文加载 ──► 执行与静默拦截 (every:30m) (activeHours) (SOUL/MEMORY/ (HEARTBEAT_OK Session 注入) 被 Gateway 丢弃)定时触发默认每 30 分钟唤醒一次间隔可配置。活跃时段过滤非活跃时段比如深夜直接跳过本轮心跳省下不必要的 Token 开销。上下文加载唤醒后Agent 的人格设定、记忆文件、会话历史照常注入它是在完整人格的状态下巡检而不是一个失忆的临时实例。执行与静默拦截Agent 按清单逐项检查无事则输出静默信号该信号在网关层被拦截用户全程零感知。2.2 静默信号实现无事不打扰的关键这是整个机制里最精巧的一环。约定一个特殊标记OpenClaw 中为HEARTBEAT_OK当它出现在回复的开头或结尾、且剥离标记后剩余内容不超过约 300 字符ackMaxChars阈值时网关直接丢弃整条消息。标记出现在回复中间则不做特殊处理。反过来说告警消息里绝不能包含这个标记否则会被误拦截。调试时还有一个小技巧可以直接用自然语言让 Agent立刻执行一次心跳巡检。但要清楚这种对话式触发会以普通回复的形式呈现检查结果与真正的定时心跳走网关静默拦截行为不同。验证真实静默效果应观察心跳日志或等一个自然周期确认没有新消息到达。三、Heartbeat 与 Cron不是替代而是分工心跳机制落地时最常见的问题是它和传统的 Cron 定时任务到底什么关系答案是分工协作可以用一句口诀概括心跳看状态Cron 干活。维度Cron 任务Heartbeat 心跳触发方式精确时间点 / cron 表达式 /--at一次性固定间隔轮询默认 30 分钟触发后行为无条件执行预设动作先读清单评估再决定行动输出特征每次必有产出无事时静默信号被拦截会话形态可选主会话或独立会话默认主会话携带完整上下文模型选择可按任务指定不同模型统一用心跳配置的模型典型场景生成报告、抓取数据、定点提醒状态监控、异常检测、例行巡检成本特征每个任务独立计费多项检查合并为一次调用选型时可以按五个问题依次判断需要在精确时间点执行吗是→Cron需要与主会话隔离吗是→Cron多项同频检查能合并吗是→Heartbeat是一次性提醒吗是→Cron 的--at需要指定特定模型吗是→Cron 的--model都不满足就归入心跳。成本差异值得单独强调。假设你有 5 个监控项邮件、日历、磁盘、任务、代码仓库都希望每半小时看一眼。拆成 5 个 Cron 任务每轮触发 5 次 Agent 调用、烧 5 份 Token合并进 1 份心跳清单每轮只花 1 份。差距是五倍量级——这不是优化技巧而是架构选择直接决定的成本结构。生产环境中最常用的组合是Cron 干活 Heartbeat 巡检Cron 在 7:00 用独立会话抓取数据写入文件心跳在 8:00 检查文件是否生成、内容是否合格。Cron 专注做事、互不干扰心跳带着完整上下文做质检和兜底。对于耗时较长的任务流还可以让 Cron 触发、心跳持续监控完成情况形成启动—盯梢的闭环。当然心跳并非万能。需要精确时间每周一 9:00 发周报、一次性提醒、重型计算会阻塞主会话、必须用高阶模型处理的任务都应该交给 Cron。另外拿 5 分钟的高频心跳去盯一个一天只变化两次的日历纯属烧钱。四、心跳清单的设计方法心跳的行为由一份巡检清单文件OpenClaw 中为HEARTBEAT.md定义。这份文件的定位是清单不是任务手册——每次心跳它都会被注入 Prompt写多长就烧多少 Token。官方建议控制在 200 tokens 以内而社区最常见的错误恰恰是把清单写成几百行的操作文档。4.1 检查项的四要素一条合格的检查项应包含四段信息- 在 08:00-09:00 时段内执行此项检查 - 检查 memory/ 下今天的日报文件是否存在 - 如果不存在发送告警「今日日报未生成请检查任务状态」 - 如果存在且内容完整回复 HEARTBEAT_OK即时段条件 → 可验证的判断标准 → 异常时的具体动作 → 正常时的静默约定。四者缺一不可尤其最后一条——清单末尾必须明确以上均无异常时回复 HEARTBEAT_OK这个停止条件否则 Agent 总能找出点事来说。4.2 三种组织形态清单有由简到繁的三种写法按任务规模选择自由文本每条检查项一行适合三五项以内的场景如磁盘超过 85% 告警紧急邮件扫描未来 2 小时日程提醒均无异常回复 HEARTBEAT_OK。轮转调度维护一个状态文件记录各检查项的上次执行时间戳每次心跳只执行最过期的一项。适合检查项超过五个、且各自频率不同的场景。结构化任务块框架直接解析结构化的任务定义名称、间隔、提示语只有到期的任务才会注入本轮 Prompt没有任务到期时整次心跳直接跳过是官方推荐的省 Token 姿势。4.3 关键配置项心跳行为在主配置文件中调优日常最核心的是三件套every心跳间隔默认 30 分钟设为 0 可禁用target消息投递目标如最近联系的渠道activeHours活跃时段窗口配合本地时区使用。进阶项还包括lightContext只加载清单不加载完整上下文进一步省 Token、isolatedSession每次心跳用独立会话省 Token 但丢失对话历史、model为心跳指定便宜模型等。修改后需重启网关生效。五、典型主动服务场景定时巡检是最基础的用法磁盘水位、服务存活、收件箱紧急邮件、未来两小时的日程逐项检查、阈值判断、异常告警。智能早报展示了心跳与 Cron 的深度配合。把日报拆成三个阶段7:00 第一轮 Cron 广覆盖抓取三个领域的资讯并写入文件附上覆盖评估7:30 第二轮 Cron 读取评估结果对薄弱领域定向补充搜索完成后在文件末尾打上采集确认标记8:00 心跳巡检该文件——文件缺失则告警日报未生成缺确认标记则提醒二轮采集未完成一切齐备则静默。相比单次抓取这种两轮抓取 一次巡检的结构既提升了覆盖质量又把成本拆散到可控的单元里。异常告警是心跳的主场监控项设定可量化阈值越过阈值才发声平时保持安静。记忆守护则是一个容易被忽视的场景。很多 Agent 调教者会在配置里写每日对话要点需归档之类的规则然后发现 Agent 执行几天后悄然断档——因为纯文本规则只是期望会话压缩、上下文丢失都可能让规则失效。解法是把软规则升级为硬巡检在心跳清单中加一项每 4 小时检查今天的记录文件是否存在不存在则回顾对话并补写。这条规则揭示了一个朴素道理规则只是期望机制才是保障——好的系统从不依赖自觉而靠定期检查兜底。4 小时的频率也是权衡的结果既避免 30 分钟级的高频浪费又保证重要决策在被上下文压缩吞掉之前落盘。六、频率与成本防空转、防打扰心跳的运营成本几乎完全由两个变量决定清单长度 × 心跳频率。相应地防空转和防打扰的设计要点可以归纳为四条精简至上。清单控制在 200 tokens 以内每项一两行。写得越长烧得越快。阈值必须可量化。写磁盘超过 85% 告警而不是磁盘快满了告警。模糊的判断标准会让 Agent 每次都能找到话说用户很快就会把它的推送当噪音忽略——这就是典型的狼来了反模式。必须有停止条件。清单末尾明示静默约定给 Agent 一个明确的没事就闭嘴的出口。设定时段窗口。每个检查项标注适用时段如 08:00-09:00避免凌晨三点推送今日日报未生成这种荒诞消息全局层面用 activeHours 圈定活跃时段。两个高频翻车案例值得引以为戒。其一是Token 焚烧炉清单写了一整页心跳间隔又设成 15 分钟费用账单直接起飞——修复方法无非精简清单、放宽间隔到 30–45 分钟。其二是把心跳调成 1 分钟做快速测试结果消息刷屏淹没对话历史Agent 反复回显人格设定和错误信息甚至把用户的敏感信息暴露出去。后者还提醒我们给 Agent 下指令时光说做什么不够还得说清不做什么行为边界的约束不可省略。七、常见坑速查把定时推送当心跳无条件执行、不做筛选、无反馈回路的推送只是披着主动外衣的闹钟。清单写成操作手册每次心跳都整页注入 Prompt成本失控。告警里混入静默标记告警消息会被网关误拦截用户收不到。对话式触发验证静默对话里 Agent 总会回复点什么真正的静默要看心跳日志或等自然周期。重型任务塞进心跳代码库分析、长文本生成会阻塞主会话这类活应交给独立会话的 Cron。软规则无人兜底写在配置里的行为约定没有机制保障迟早断档。小结心跳机制的本质是把 Agent 的运行模型从事件驱动、被动应答扩展为事件驱动 时间驱动的混合模型。它的三个设计支点缺一不可定时唤醒提供时间维度完整上下文保证判断质量静默拦截守住无事不打扰的体验底线。而它与 Cron 的分工——心跳看状态、Cron 干活——则给出了成本与灵活性之间的工程平衡。更进一步心跳还回答了 Agent 自治中的一个深层问题如何让期望的行为持续发生答案是把它从文本规则变成有周期、有检查、有兜底的机制。从被动应答到主动服务差的从来不是一句 prompt而是一颗按节律跳动的心脏。