一句话总结openclaw记忆:类人认知的分层蒸馏记忆架构
OpenClaw 是一款面向单用户或小团队的自托管 Agent 平台,其记忆系统的核心设计哲学是完全的可解释性与渐进式知识沉淀------ 它不依赖任何黑盒化的向量数据库或隐式索引,而是通过类人认知的分层蒸馏逻辑,让记忆的生命周期完全透明、可干预。
OpenClaw 的记忆系统遵循 "原始输入→短期缓存→中期整理→长期归档" 的类人认知流程,将记忆明确划分为四个核心层级,每个层级对应不同的存储介质、生命周期与访问规则。这种分层设计的本质,是对 "原始信息 - 有用信息 - 持久知识" 的价值过滤,每一层都承担着 "提炼高价值信息" 的功能。
记忆层级结构
OpenClaw 的记忆层级并非简单的 "时间分层",而是 "价值分层"------ 每一层的信息密度、持久化优先级与访问成本都有明确差异,层级之间通过自动化流程完成信息流转:
|--------|--------------------------------------------|---------------|-----------------------------------------------------------------------------------------------------------------|
| 记忆层级 | 存储介质 | 生命周期 | 核心功能 |
| 短期工作台 | CURRENT_STATE.md | 单次会话 / 24 小时 | 缓存当前会话的所有上下文,包括用户提问、工具调用结果、子 Agent 的中间输出,是 Agent 实时思考的 "工作区" |
| 中期日志 | 按日期命名的 Markdown 文件(如memory/2026-03-18.md) | 26 小时 | 每日 23:00 自动同步最近 26 小时的有效会话 ------ 同步前会过滤掉重复提问、错误工具调用等无效信息,仅保留有价值的交互记录 |
| 任务结果卡 | memory/tasks/*.md | 与任务周期绑定 | 子 Agent 的任务输出会以结构化格式沉淀于此,包含任务 ID、执行时间、核心结论与关联资源,是跨会话任务交接的标准化载体 |
| 长期记忆 | LanceDB 向量数据库 + Markdown 归档 | 永久(需手动清理) | 每周日 22:00 由系统自动精炼,提取中期日志与任务结果卡中的 "非时间敏感事实"------ 比如项目的技术栈选型、用户的长期偏好、反复验证的经验规则,最终以 Markdown 文件归档,并同步向量索引以支持快速检索 |
值得注意的是,OpenClaw 的记忆层级之间并非单向流转:比如当用户在新会话中调用某一历史任务的结果时,系统会自动将任务结果卡从长期记忆临时加载到短期工作台,待会话结束后再根据新的交互信息更新该结果卡,确保记忆的动态性。

核心机制解析
OpenClaw 的记忆系统通过三大核心机制,解决了传统记忆系统的 "遗忘" 与 "冗余" 问题:
(1)蒸馏式记忆流转:从 "原始记录" 到 "持久知识" 的价值过滤
OpenClaw 的记忆流转不是简单的 "复制粘贴",而是通过 "日增量同步 + 周度精炼" 的自动化流程完成价值提纯,每一轮流转都会降低记忆的冗余度、提升信息密度。具体而言:
- 日增量同步:每日 23:00 触发,仅处理最近 26 小时的会话数据 ------ 这个时间窗口既覆盖了当天的所有有效交互,又避免了跨天的冗余数据。同步时会过滤掉 "重复提问""工具调用错误日志""无意义的闲聊" 等无效信息,仅将用户的明确需求、Agent 的有效回答、工具调用的成功结果追加到当日的中期日志文件中。
- 周度精炼:每周日 22:00 触发,系统会遍历过去 7 天的中期日志与任务结果卡,通过 LLM 提取 "持久事实"------ 比如 "用户要求所有接口返回格式必须是 JSON:API 规范""支付模块的超时阈值经过测试,30 秒是最优值" 这类非时间敏感、可长期复用的信息。提取完成后,系统会将这些事实写入长期记忆的 Markdown 文件,同时清理过期的中期日志(保留最近 30 天的日志作为备份)。
- 幂等性保障:在每日同步与周度精炼流程中,系统会基于消息指纹(Message Fingerprint)对数据进行去重 ------ 即使同一信息被多次写入,也只会保留最新的版本,从根源上避免了记忆冗余。
这种设计的核心逻辑是:记忆的价值与冗余度成反比------ 只有通过持续蒸馏,才能让有限的存储资源承载高价值的长期知识,同时避免冗余信息干扰检索效率。
(2)QMD 混合检索:精准度与效率的平衡
OpenClaw 的检索系统以 QMD(Queryable Markdown)为核心,这是一种将 Markdown 的可读性与结构化检索能力结合的格式 ------ 每个 Markdown 文件都包含标准化的元数据(如创建时间、记忆类型、关联标签),既支持人类直接编辑,也支持机器的精确查询。其检索流程严格遵循 "任务优先、语义兜底" 的顺序,从高价值、高精准度的记忆开始匹配,逐步降级到泛化的语义检索,确保在有限的检索成本内获取最优结果:
- 任务结果卡检索:优先查询memory/tasks/目录下的结构化文件,根据任务 ID、执行时间或标签精准匹配 ------ 比如用户问 "上周的支付模块测试结果如何",系统会直接定位到对应日期的任务结果卡,无需遍历所有记忆。
- 语义检索:若任务结果卡无匹配项,则调用 LanceDB 向量索引,对长期记忆的 Markdown 文件进行语义匹配 ------ 向量索引基于 Gemini-embedding-2-preview 模型构建,支持多模态内容(如截图、音频转写文本)的检索。
- 全文检索:若语义检索仍无结果,最后会使用 SQLite FTS5 对所有 Markdown 文件进行全文匹配 ------ 这是兜底方案,但由于前期的蒸馏流程已经过滤了冗余信息,全文检索的效率依然能得到保障。
此外,QMD 检索还支持 "候选重排序":系统会先获取 4 倍于需求的候选结果,再通过本地 Qwen3 reranker 模型对结果按 "相关性""时效性""权威性" 三个维度重排序,进一步提升检索精准度。
(3)会话裁剪与缓存淘汰:有限上下文窗口的高效利用
为了避免上下文窗口溢出,OpenClaw 设计了 "软修剪 + 硬保留" 的双层机制,在保证关键信息不丢失的前提下,将上下文规模控制在模型可承受的范围内:
- 软修剪:当会话 Token 数量接近 4000 的软阈值时,系统会自动裁剪 "非关键历史"------ 具体规则是保留最后 N 条 Agent 回复(N 由keepLastAssistants参数配置,默认是 5 条),并对中间的大体积工具结果(如超过 1000Token 的 API 响应)进行摘要压缩,压缩后会在上下文中标注 "[已压缩,原始内容见工具结果日志]",方便后续追溯。
- 硬保留:所有工具调用的核心结果(如任务完成状态、关键数据返回值)、用户的明确指令(如 "必须使用 Python 3.11 版本")会被强制保留,不会因 Token 阈值被裁剪。
- TTL 缓存淘汰:对于超过 5 分钟未活跃的会话,系统会触发自动修剪 ------ 仅保留最近 3 条 Agent 回复与用户的核心需求,释放的内存用于新会话的缓存。
这种机制的核心权衡是:牺牲部分非关键历史的完整性,换取关键信息的可及性与系统的稳定性------ 比如在代码调试场景中,用户的前 10 轮尝试可能被压缩,但最后一次成功的调试参数会被完整保留。