OpenClaw 长期记忆系统的设计思路

如果你把长期记忆理解成一个检索接口，系统通常很快就会出问题。

更准确的理解是：长期记忆是一套信息生命周期管理机制。它至少包含四个关键动作：

1. 写入
2. 检索
3. 更新
4. 遗忘

这四个动作彼此相关，但不该混成一步。

为什么很多系统一开始就走偏

一个常见错误是从“怎么搜”开始想，而不是从“为什么存”开始想。

结果通常会变成这样：

• 写入毫无门槛
• 检索全库扫一遍
• 更新靠覆盖文本
• 遗忘根本没做

这样的系统早期看起来很灵活，后期却最难维护。

一、写入：决定系统以后会不会脏

写入是整个记忆系统里最该保守的环节。

如果什么都写，系统就会积累三类噪声：

• 临时状态
• 模型猜测
• 没有复用价值的原始片段

更稳的写入标准通常是：

1. 这条信息跨会话仍然有价值。
2. 它会影响后续判断、约束或执行。
3. 它能被结构化，而不是只能原样堆进去。

适合写入的内容

• 用户明确表达的稳定偏好
• 项目级约束和边界
• 已验证过的解决方案摘要
• 任务中间状态的关键检查点

不适合直接写入的内容

• 一次性调试输出
• 没有验证的模型推断
• 语义重复但来源不清的摘要
• 原始聊天记录全文

二、检索：目标不是找得多，而是找得准

很多记忆系统的默认做法是“先把最像的几条拉出来再说”。

这在搜索产品里可能够用，但在执行系统里不够稳，因为“语义相似”不等于“当前可用”。

对 OpenClaw 这类执行型系统来说，检索应该先回答两个问题：

1. 当前任务需要的是事实状态、经验知识，还是追溯记录
2. 当前优先按什么主体召回，比如用户、项目、任务或工具

一个更稳的检索顺序

1. 先查 State Memory
2. 再查 Knowledge Memory
3. 只有需要追溯时再查 Archive Memory

因为多数执行错误不是缺“相关内容”，而是缺“当前有效的事实”。

检索时应该做的额外限制

• 限定主体，比如当前项目或当前用户
• 限定时间窗口，避免过旧信息默认进入
• 限定置信度和来源
• 限定最大条目数，防止上下文再次膨胀

三、更新：不要把新信息直接粗暴覆盖旧信息

更新是最容易让系统自相矛盾的环节。

比如系统曾经记住：

项目 Alpha 允许自动发布

后来新的人工确认把它改成：

项目 Alpha 当前阶段禁止自动发布

如果你只是把第二句话再写进去，检索时两条都能被召回，模型就会拿到互相冲突的上下文。

更稳的做法是让更新显式表达关系：

• 新条目是否覆盖旧条目
• 旧条目是否退为历史版本
• 是否保留追溯链路

一个简单的更新策略

稳定事实：使用 supersedes 关系显式覆盖
中间状态：只保留最近有效版本
知识总结：追加新版本，不直接删除旧版
归档记录：不覆盖，只打标签

这样后续检索时才有机会优先拿到“当前有效”的内容。

四、遗忘：不是附属功能，而是系统自我保护

很多人不愿意碰遗忘，因为总担心删掉以后找不回来。

但如果没有遗忘，系统就会遇到两个更现实的问题：

• 过时信息持续进入默认召回
• 检索空间越来越大，噪声越来越重

所以遗忘的本质不是“消失”，而是“退出默认工作流”。

更推荐的遗忘机制

1. Expire 对会过期的状态设置失效时间，到期后不再默认召回。

2. Demote 把低价值条目从工作层降到归档层。

3. Supersede 被新事实覆盖后，只保留为历史版本。

4. Purge 对明显错误、重复污染或无追溯价值的数据做彻底清理。

一张更实用的设计表

动作	设计重点	最容易犯的错
写入	先判断价值和层级	什么都写
检索	按任务意图和主体查层	全库混搜
更新	显式版本关系	新旧事实混存
遗忘	退出默认召回链	永不清理

一个适合 OpenClaw 的流程示意

事件进入
  -> 分类是否值得长期保留
  -> 选择记忆层
  -> 结构化写入
  -> 冲突检测
  -> 版本更新或待人工确认
  -> 周期性做过期和降级处理

OpenClaw 在这里很适合做编排器：

• 接收事件
• 调用分类器
• 触发存储
• 定时运行清理与检查任务
• 把冲突或高风险更新送给人工确认

如果你只能先做一件事，先做什么

不要先做复杂检索。

先把下面三条规则写清楚：

1. 哪些信息绝不自动写入
2. 哪些状态允许覆盖旧版本
3. 哪些条目默认几天后退出召回

这三条一旦清楚，系统的稳定性通常会比你换数据库还更明显。

延伸阅读

• 如何给 OpenClaw 打造一套能解决实际问题的长期记忆系统
• 给 OpenClaw 加长期记忆时，最容易做错的 7 个地方
• 如何验证一套 AI 长期记忆系统真的在解决问题