How to Fix Your OpenClaw's Memory

来源: X @_sean_matthew
作者: Sean Matthew (认证账号)
发布日期: 2026年3月12日
查看: 1,669 次 | 5 转帖 | 41 喜欢 | 50 书签

摘要

作者分享了修复 OpenClaw 内存问题的四个关键优化，帮助降低 token 消耗并提升 Agent 稳定性。

问题背景

几周前，作者的 OpenClaw 出现问题：

Agent 不断遗忘重要上下文
Skills 没有正确触发
Cron job 停止运行
Telegram 中持续出现上下文相关错误
会话越长，token 消耗越多

最初以为是模型问题（当时使用 Kimi K2.5），后来切换到 Sonnet 4.6 有所改善，但真正的问题在于 OpenClaw 的内存和上下文管理方式。

四个修复方案

Fix 1: 防止压缩（Compaction）时丢失重要上下文

问题: OpenClaw 有有限的上下文窗口，会话变长时会压缩旧消息为摘要，但重要的指令和细节会丢失。

解决方案:

Memory Flush - 在压缩前将重要信息写入磁盘
Session Pruning - 积极清理旧的上下文

核心原则：只在上下文窗口中的内容是临时的，存在磁盘上的才会保留。

Fix 2: 让检索真正生效

问题: 重要信息虽然保存在磁盘上，但 Agent 不会主动查找，或者默认检索效果不够好。

解决方案:

安装并配置 QMD (Tobi Lutke 的混合搜索引擎，结合关键词匹配、向量语义搜索和 LLM 重排序)
在 AGENTS.md 顶部添加明确的检索指令，让 Agent 在执行任务前搜索相关上下文
建立 LEARNINGS.md 文件，记录每次犯错后的规则，防止重复相同错误

Fix 3: Heartbeat 成本陷阱

问题: Heartbeat 每 30 分钟唤醒一次，每次都是完整的 API 调用，携带整个会话上下文（可能 10,000-15,000 tokens），非常昂贵。

解决方案:

{
  "agents": {
    "defaults": {
      "heartbeat": {
        "every": "30m",
        "lightContext": true,
        "model": "google/gemini-3.1-flash-lite-preview",
        "activeHours": {
          "start": "08:00",
          "end": "23:00"
        }
      }
    }
  }
}

关键优化:

lightContext: true - 只加载 HEARTBEAT.md，而不是整个系统提示
使用便宜模型 - 如 Gemini 3.1 Flash-Lite，甚至可以用本地模型
限制活跃时间 - 不需要凌晨 3 点检查，将心跳调用减半
保持 HEARTBEAT.md 精简 - 只保留最基本的检查清单

Fix 4: 完整系统提示审计

问题: AGENTS.md、SOUL.md、TOOLS.md、IDENTITY.md、USER.md、HEARTBEAT.md、MEMORY.md 都会自动加载，作者从未审计过它们的大小和冗余。

解决方案: 让 Claude Code 审计整个系统提示，识别冗余、重复和不必要的部分并精简。

真正的问题不是换模型，而是裁剪不必要的系统文件。

总结

推荐的优化顺序:

Memory Flush - 压缩前将重要上下文写入磁盘
Session Pruning - 防止长会话拖拽无效上下文
Retrieval + 启动指令 - 升级 QMD，确保 Agent 明确搜索 prior context
Heartbeat 优化 - 轻量上下文、便宜模型、限制活跃时间、精简 HEARTBEAT.md
系统提示审计 - 裁剪冗余内容

核心观点: 构建 OpenClaw 时，选择的模型只是其次，真正的价值在于确保 Agent 有良好的内存和上下文管理系统。

3.9 KiB Raw Blame History Unescape Escape

How to Fix Your OpenClaw's Memory

摘要

问题背景

四个修复方案

Fix 1: 防止压缩（Compaction）时丢失重要上下文

Fix 2: 让检索真正生效

Fix 3: Heartbeat 成本陷阱

Fix 4: 完整系统提示审计

总结

相关资源

3.9 KiB

Raw Blame History