OpenClaw 三层记忆系统实战（第三篇）：让 AI 真正「理解」你的记忆

三层记忆系统跑了一段时间。遇到最大的问题是：向量搜索明明返回了结果，Agent 答非所问。

问题不在「记」，而在「找」和「用」之间有条鸿沟。今天聊两个实质性进展：五步查询法和四层架构。

一、一个真实场景

让 Agent 查一个配置，它返回：

命中：memory/2026-04-08.md
相关度：0.92
内容：「配置」

然后呢？它只知道「配置」这个词在这篇文章里出现过，但具体在哪、是什么配置、后来改了没有——统统不知道。

这就是只靠向量层的典型症状：能定位，但没上下文。

二、五步查询法

分层定位，逐级穿透。

收到提问
  ↓
Step 1: 向量库检索（100ms）
  → global scope + agent 私有 scope
  → 快速命中，返回片段 + 来源
  ↓ 找不到？
Step 2: MEMORY.md（50ms）
  → 长期偏好、稳定规则
  → 读最近 30 天
  ↓ 找不到？
Step 3: memory/YYYY-MM-DD.md（30ms）
  → 当天事项、临时限制
  → 读今天 + 昨天 + 前天
  ↓ 找不到？
Step 4: OB 知识库（500ms）
  → 技术文档、流程规范
  → grep 或 AI 读取
  ↓ 找不到？
Step 5: sessions_history（1-5s）
  → 原始会话记录
  → 最后手段

三条原则：

1. 找到即停止—Step 2 找到了就不往下走
2. 优先快检索—向量 100ms vs 会话 5s
3. 每次检索后记录—方便后续追溯

三、四层架构

光会找不够，还得知道东西放哪。

参考了程序员左哥的四层架构，我们整理了一套自己的版本：

判断标准

• 「以后都该这样」→ MEMORY.md
• 「今天发生了什么」→ daily memory
• 「这个 Agent 怎么工作」→ 规则文件

容易踩的坑

1. MEMORY.md 写成日记—把当天临时事项写进长期记忆，很快就会乱成一锅粥
2. 规则文件承担日报职责—制度和日报混在一起，维护成本翻倍
3. daily memory 写成制度—临时限制不要写进长期偏好

如何保证记忆真的被记住了？

1. 存储后立即验证 记忆写入后，立刻用 recall 搜一下，确认能返回。

2. 四文件交叉验证

定期抽查四个地方：
- MEMORY.md 里有没有长期偏好
- memory/YYYY-MM-DD.md 里有没有当天事项
- AGENTS.md / SOUL.md 里有没有工作规范
- DREAMS.md 里有没有被标记晋升的记忆

3. 提问测试法 每隔一段时间，故意问一个 Agent「应该」知道的问题，看它能不能答上来。

4. OB 知识库同步验证 知识库里的文档是否被向量库检索到？搜一个 OB 里的关键词试试就知道。

记忆有没有效，就看 Agent 能不能用上。

四、一个真实查询的例子

用户说：「那个配置改完没？」

用五步查询法：

Step 1：向量库搜「配置」

结果：无命中

Step 2：MEMORY.md

结果：找到「心跳配置」相关记录
但没提这次改动

Step 3：memory/2026-04-09.md

结果：找到当天记录
「配置已恢复，详见 OB/30-Knowledge/技术经验/心跳配置教训.md」

Step 4：读取 OB 文档

结果：确认配置已修复

整个过程 200ms 左右，Agent 知道去哪找、找到了怎么用。

五、关于梦境层

梦境层是 OpenClaw v2026.4.7 引入的新特性，是个后台自动化的设计。

哪些版本支持？

• v2026.4.7+：原生支持 memory-core 插件的 dreaming 配置
• 之前版本：用定时脚本整理作为替代方案

如何配置？

在 openclaw.json 中配置：

{
  "plugins": {
    "entries": {
      "memory-core": {
        "config": {
          "dreaming": {
            "enabled": true,
            "frequency": "0 3 * * *"
          }
        }
      }
    }
  }
}

聊天命令控制：

• /dreaming on - 开启
• /dreaming off - 关闭
• /dreaming status - 查看状态

梦境的工作阶段

1. Light 阶段 扫描 memory/ 目录下的日常记忆文件，识别高频出现的关键词。

2. REM 阶段 识别反复出现的信号——如果某个偏好连续多天被提到，标记为「可晋升长期」候选。

3. Deep 阶段 将合格内容写入 MEMORY.md，同时在 DREAMS.md 输出可读总结。

适合做的事

• 整理最近反复出现的短期信号
• 识别可能该升成长期记忆的内容
• 把短期材料做成可回看的总结

不适合做的事

• 不是主记事本（日报还写日报）
• 不是规则文件（制度要人工写）
• 不是临时提醒（今天的事写进 daily memory）

六、实际踩坑记录

最近遇到了「一问三不知」：

症状：问 Agent「昨天那个生图策略」，它说「不知道」，但记忆文件明明写着。

根因：

1. 检索触发机制失效—某些情况下 Agent 默认跳过所有记忆层
2. 记忆写入不及时—过度依赖定时任务，任务结束记忆还没写进去
3. 五层检索只用了两层—表面跑了五步，实际中间几步是空的

解决方案（原理层面）：

1. 任务执行时立即记录—执行完关键操作后立刻写 memory，不等定时任务
2. 加大定时任务超时—避免复杂整理任务被强制中断
3. 控制 token 加载量—启动时加载量控制住，避免上下文爆炸导致检索被跳过
4. 验证检索真的执行了—存储后立即测试能不能找到

经验公式：

记忆系统价值 = 记录质量 × 检索效率 × 经验复用率

三个乘数任何一个是零，结果都是零。

七、真实感受

以前 AI 每次都说「好的我记住了」，下次问还是一脸茫然。不是它不想记，是不知道记哪、怎么用。

现在跑这套流程之后：

• 用户提一个配置，Agent 能直接定位到具体文件
• 用户说「上次那个」，Agent 能从向量库找到相关上下文
• 团队新成员接手，看 MEMORY.md 就知道这个 Agent 的工作风格

不是 AI 变聪明了，是记忆系统变清楚了。

标签：#OpenClaw #AI助手 #记忆系统 #生产力工具 #教程

码字不易，如果对你有帮助，欢迎点赞收藏~