OpenClaw 的记忆系统是怎么工作的？

OpenClaw 用每日日志保存短期回忆，用 MEMORY.md 保存长期精选记忆，两者一起帮助 Agent 在不同会话之间保持连续性。

OpenClaw 的记忆存在哪里？

OpenClaw 的记忆通常以本地 Markdown 文件形式存放在工作区里，例如 memory/YYYY-MM-DD.md 和 MEMORY.md。

我可以手动修改 OpenClaw 的记忆吗？

可以。文件式记忆模型的一个核心优势，就是用户可以直接查看、编辑和纠正 Agent 记住的内容。

MEMORY.md 和每日日志分别适合放什么？

每日日志适合记录原始事件和短期笔记，MEMORY.md 更适合保存稳定偏好、重要决策、长期上下文和值得沉淀的经验。

深入解析 OpenClaw 记忆系统：它如何记住你

传统 AI 聊天机器人最大的痛点之一就是"健忘"。你告诉它们你的名字、项目细节和偏好，但只要开启新对话，一切又回到了原点。OpenClaw 采用了一种截然不同的方法。

通过将记忆视为基于透明文件架构的一等公民，OpenClaw 能够建立对用户的持久理解。在本文中，我们将深入探讨 OpenClaw 是如何"记忆"的。

双层记忆架构

OpenClaw 将其记忆分为两个不同的层级：短期上下文（每日日志）和长时智慧（MEMORY.md）。

1. 每日日志：意识流

每一天，OpenClaw 都会在你的 memory/ 文件夹中创建一个新文件，例如 memory/2026-02-06.md。这个文件充当当天事件的原始日志。

存储内容：对话摘要、完成的任务、遇到的错误以及顺带提及的细节。
作用：它让 Agent 能够回忆起你昨天或今天早上做了什么，而无需重新加载你生活中的所有聊天记录。
维护：这些文件是自动生成和追加的。你可以阅读它们，看看 Agent 到底"认为"今天发生了什么。

2. MEMORY.md：精选长时记忆

OpenClaw 上下文系统的皇冠明珠是 MEMORY.md。这不是日志，而是一份精选档案。

存储内容：
- 用户偏好："偏好 Python 而不是 JavaScript"，"提交信息中不要使用 Emoji"。
- 项目上下文："正在开发 Titan 项目，截止日期是 3 月 1 日"。
- 核心决策："我们决定使用 PostgreSQL 作为数据库"。
工作原理：OpenClaw（或你自己！）会定期回顾每日日志，提取智慧"金块"来更新 MEMORY.md。

透明且本地化

与云端模型不同（在那通过远程服务器上的隐藏向量数据库存储记忆），OpenClaw 的记忆仅仅是你硬盘上的 Markdown 文件。

这带来了巨大的优势：

隐私：你的个人数据永远不会离开你的机器。
可编辑性：如果 Agent 记错了什么，你只需打开文件并修正它。
可移植性：想把你的 Agent 转移到新笔记本上？只需复制文件夹即可。

用户最佳实践

为了充分利用 OpenClaw 的记忆系统，请遵循"写下来"原则。

"记忆是有限的——如果你想记住某件事，把它写进文件里。"

OpenClaw 被训练遵循这一准则。如果你有关键信息，请要求 OpenClaw "将其保存到我的记忆中"。它会更新 MEMORY.md，确保在未来的会话中——哪怕是几周或几个月后——它仍然确切地知道你需要什么。

搜索入口分流：OpenClaw 记忆不生效先看什么

如果你是从 “OpenClaw memory not working”、“OpenClaw 忘记上下文” 或 “agent 记不住偏好” 搜到这里，先把问题拆成四层：

确认写入位置：区分 MEMORY.md、每日 memory、任务态 TASK_MEMORY.md，以及当前 session 是否真的会读取它们。
确认运行场景：主会话、群聊、cron、子代理和任务 run 的记忆边界不同，不应默认共用同一份私密上下文。
确认内容是否值得长期保存：偏好、决策、项目约束适合进长期记忆；临时日志和敏感信息应留在更窄范围。
确认回读链路：不要只看文件已写入，还要验证下次任务启动时是否按规则读取并应用。

这类问题不要只归因于“模型忘了”。最短路径是同时核对写入文件、会话类型、读取规则和下一轮行为是否一致。

结论

记忆将聊天机器人变成了合作伙伴。通过理解 OpenClaw 简单、基于文件的记忆结构，你可以培养一个高度个性化的助手，它会随着你的成长而成长，从每一次互动中学习，随着时间的推移变得更加得力。

快速判断：什么内容该写进记忆？

如果你不确定一条信息该放进 OpenClaw 的哪层记忆，可以先这样分流：

写进 daily memory，适合原始事件、临时阻塞、会议笔记、当天上下文。
写进 MEMORY.md，适合长期偏好、稳定决策、会反复出现的项目事实、希望未来会话继承的经验。
不要沉淀进长期记忆，适合敏感、过期、或只对一次性短任务有用的信息。

这样做的目的，是让记忆保持可用，而不是越积越像噪音仓库。

让 OpenClaw “记住”之后，用户还要补验什么？

一个好的记忆流程，不该停在“帮我记住这件事”。至少还要补验三件事：

重要信息是不是被写进了正确的文件；
描述是不是足够准确，保证未来会话不会误解；
旧版本、冲突版本，是否还残留在别的记忆文件里。

这一步很关键，因为文件式记忆真正的价值，就在于它可审计、可复核、可主动维护。

当记忆看起来不对时，不要先清空全部文件

很多读者搜到这页，是因为 OpenClaw 在新会话里“记错了”项目、偏好或边界。先不要直接删除整个 memory/ 目录，可以按这个顺序收口：

先找冲突来源：同时检查今天、昨天的 daily memory 和 MEMORY.md，确认错误是临时日志噪音，还是长期记忆已经被污染。
只改最小范围：如果只是当天上下文错了，优先修正对应 daily file；如果未来每次都会继承这个错误，再改 MEMORY.md。
写下纠正原因：在同一段附近补一句“已废弃/已更正”的说明，避免未来 Agent 又从旧上下文里复活错误结论。
重开会话复测：新开一次会话，让 OpenClaw 复述相关偏好或项目事实，确认它读到的是修正后的版本。

这比“全删重来”更安全，也更符合文件式记忆的价值：可审计、可局部修复、可复验。

团队交接前，再补 3 个证据

如果这次记忆修复会影响团队协作，不要只说“已经改好了”。交接前至少补三类证据：

改动的是哪个文件、哪一段、为什么只改这一处；
重开会话或新任务后，旧错误没有再次出现；
后续如果同类冲突复发，应该先看哪份 daily note、MEMORY.md 或项目文档。

这样能把 memory 流量从“我想知道记忆是什么”推进到“我能安全修复和交接记忆问题”。

出现记忆事故时，先查哪一个文件？

当记忆开始影响实际任务，不要一上来把所有文件都读一遍或清空。先按故障形态选入口：

当天任务突然沿用了旧上下文：先查今天的 daily memory；如果旧事实来自上一轮会话，再查昨天的文件。
每次新会话都重复同一个错误偏好或项目事实：优先查 MEMORY.md，因为这是未来会话会继承的长期层。
只有某个项目目录里的 Agent 行为不对：先查项目级 AGENTS.md、TOOLS.md 或 task memory，不要急着改个人长期记忆。
需要给团队交接证据：把修正原因写在旧说法附近，说明为什么这条旧记忆已经失效。

这个按事故形态分流的方式，可以更快修复记忆问题，也能避免把一条小的过期笔记升级成全局上下文重置。

cron 或子代理里的记忆交接检查表

如果记忆问题出现在定时任务或委托给子代理的任务里，先把它当成交接问题处理，而不只是“模型没记住”：

确认这次 run 应该读取个人 MEMORY.md、任务态 TASK_MEMORY.md，还是只读项目级规则；
记录 Agent 实际遵循的规则来自哪个文件路径；
除非当前 run 明确允许加载个人记忆，否则不要把私密用户上下文带进共享频道；
修正记忆后，用最小安全任务复跑一次，确认下一次 Agent 启动会读到新规则。

这组检查特别适合 “OpenClaw cron memory”、“subagent memory not shared”、“为什么聊天里记得但任务里不记得” 这类搜索入口。真正的修复通常不是多写一条记忆，而是收紧加载边界，并证明下一轮读到的是目标文件。