前几天我刚写过一篇复盘，讲我是怎么把 OpenClaw 调得越来越重、越来越僵的。

那篇文章写的是问题。 这篇文章写的是后续真正落地的一次修正。

这次我没有再去追求什么“更完整的规则体系”，而是只做了一件事：

把真正该自动运行的东西，和只该留在文档里的东西，重新分开。

最终改动不多，但我觉得这比继续堆规则有价值。

一、这次要解决的不是“坏”，而是“乱”

系统其实已经能跑：

  • 主会话能承接上下文
  • MEMORY.md 和每日 memory/YYYY-MM-DD.md 都在
  • Dreaming 任务也已经挂着
  • Telegram 通道也通

问题在于，运行层的职责开始有点打架了。

最典型的两个点：

  • HEARTBEAT.md 里写了“每天 8:30 汇报学习内容”
  • Cron 里也有一条“每天 8:30 汇报学习内容”

这意味着同一件事同时存在两种调度思路：

  • 一种是心跳轮询时“顺手看看要不要做”
  • 一种是精确定时“这个点必须做”

这不是冗余得更稳，而是定义冲突。

因为 Heartbeat 和 Cron 天生就不是同一种东西。

二、我这次重新划清了两条线

1. 精确定时，一律交给 Cron

像这种需求：

  • 每天固定时间汇报
  • 每周固定时间提醒
  • 某个时间点必须触发

本质上都属于精确定时任务。

这种任务不应该依赖 Heartbeat。

Heartbeat 更适合的，是下面这类事情：

  • 邮箱 + 日历 + 天气这种可以顺手合并的巡检
  • 不要求精确到分钟
  • 时间稍微漂一点也没关系

所以这次我直接把规则写死了：

  • 精确定时 = Cron
  • 可漂移巡检 = Heartbeat

HEARTBEAT.md 默认清空，只保留说明，不再挂固定汇报任务。

2. 长期上下文，只保留真正长期的东西

另一个要收口的地方，是上下文本身。

之前比较容易混的，是下面这几层：

  • 当前会话里讨论出来的临时细节
  • 每天日志里的过程性记录
  • 真正长期有效的偏好、原则、坑点

这三种东西不能混着放。

我现在的处理方式是：

  • memory/YYYY-MM-DD.md 记录原始过程
  • MEMORY.md 只保留长期有效的结论
  • 临时任务细节默认不进入长期记忆

比如：

  • “以后固定 8:30 报告”这种运行规则，应该交给 Cron
  • “用户希望全程中文、先核实再下结论”这种，才应该留在长期上下文里
  • 某次临时排障时的碎片细节，不应该永久塞进 MEMORY

这听起来很朴素，但对 Agent 很重要。

因为上下文不是越多越好。 上下文的价值，在于它有没有长期复用价值。

三、这次顺手还修了一个容易忽略的坑

我在检查 Cron 的时候，发现那条“8:30 Sydney”的任务，实际 cron 表达式写错了。

任务名字叫：

  • 8:30 AM Sydney learning report

但调度表达式当时不是一个真正的“悉尼时间早上 8:30”。

这类问题特别典型：

  • 名字看起来对
  • 描述看起来也对
  • 但真正执行的调度字段不一定对

如果不核对实际配置，很容易产生一种错觉：

“任务已经配好了，只是偶尔没跑。”

实际情况可能是：

“它从一开始就没在你以为的时间跑。”

所以我这次没有只改文档，而是把 Cron 任务本身也一起修了：

  • 改成真正的 Sydney 08:30
  • 执行时走轻上下文
  • 模型切到更适合这种短汇报的 fast
  • thinking 压到 low
  • timeout 放宽，避免上一次那种超时

这套组合的目标很简单：

不是让它显得更聪明，而是让它更稳定地把小事做完。

四、我最终定下来的默认规则

为了避免后面再混，我把默认规则收成了这一版：

运行规则

  • 主会话负责承接长期上下文
  • 用户不需要手动“清上下文”或“补上下文”
  • 真正长期的偏好和原则写进长期记忆
  • 临时任务细节默认不固化

调度规则

  • 精确定时任务走 Cron
  • 低频巡检才走 Heartbeat
  • HEARTBEAT.md 默认留空
  • 固定学习汇报由 Cron 直接发送

这套规则没有很“高级”。 但它比“再补一层规则”有用得多。

五、为什么我现在更相信“少一点，但准一点”

过去几次折腾下来，我越来越确定一件事：

AI 助理系统真正怕的，不是规则少，而是职责不清。

只要职责一乱，后面就会出现一串连锁问题：

  • 文档和运行规则混在一起
  • Heartbeat 和 Cron 重复干活
  • 临时信息被误塞进长期记忆
  • 用户以为在“优化”，实际是在增加系统摩擦

这次修复本质上不是一次功能升级。

它更像一次系统减脂：

  • 去掉重复职责
  • 去掉错误分层
  • 去掉不该常驻的运行负担

最后留下来的，不一定更多，但一定更稳。

如果你也在调 OpenClaw、或者别的长期运行型 Agent，我现在会建议你先问自己三个问题：

  1. 这条规则是“设计说明”，还是“运行时必须注入”的东西？
  2. 这件事需要“固定时间触发”，还是“有空顺手检查”就行？
  3. 这条信息真的是长期有用，还是只是今天这次对话里的临时细节？

只要这三个问题答清楚，很多“越配越乱”的问题，前面就能拦住。

信息采集和实际修正时间：2026-04-17（UTC）/ 2026-04-18（Australia/Sydney）。