OpenClaw记忆系统之一二

2026 年 1 月底，OpenClaw 在 GitHub 上爆了。不到两周 189k Star，是 GitHub 历史上增长最快的开源项目之一。

卖点很直接：跑在你自己机器上的 AI Agent，通过 WhatsApp、Telegram、Slack 等消息渠道接受指令，能写代码、发邮件、控制浏览器、管理文件。还有个 Heartbeat 调度器，每隔 30 分钟自动醒来处理任务，不需要人触发。有人让它在自己睡觉时去谈车价，省了 4200 美元；有人让它替自己跟保险公司打官司。

这篇只看记忆系统，另外有些存储问题值得单独聊聊。

记忆怎么工作

官方文档一句话说清楚了："The files are the source of truth; the model only remembers what gets written to disk."

结构很简单，两层： MEMORY.md 存长期记忆，放用户偏好、决策、持久性事实； memory/YYYY-MM-DD.md 是每日追加日志，记当天的运行上下文。Session 启动时自动加载今天和昨天的日志，加上 MEMORY.md，全部注入上下文。

检索用 SQLite + sqlite-vec 做向量搜索，FTS5 做 BM25 关键词搜索，两路结果加权融合。整个栈没有任何外部依赖，不用 Docker，不用守护进程，下载就能跑。

还有一个机制叫 pre-compaction flush：长会话快到上下文窗口上限时，OpenClaw 会先触发一个Agentic Turn，让模型把重要内容写到磁盘，再做压缩。既然 LLM 上下文有物理上限，那就在窗口关闭前主动存档。

这套设计很不错，道理也简单：记忆是纯文本，能使用Git管理、能 grep、能直接编辑，没有厂商锁定，迁移成本接近零。

跑起来之后的问题

1. 写不写记忆，由 LLM 自己决定

官方文档里有这么一句话："If you want something to stick, ask the bot to write it into memory." 写入不写入靠模型推理，检索不检索也靠模型推理。这不是系统保证，是概率事件。跑久了会发现，遗忘不是偶发的 bug，是正常状态。

2. Compaction 会让记忆静默损坏

MEMORY.md 是注入进上下文窗口的，Compaction 发生时会被一起摘要压缩，有损，甚至直接截断。Pre-compaction flush 能缓解，但本质上还是靠 prompt 补救，不是系统层面的保障。Session 重启后 Agent 无状态，连续性完全取决于启动时读了哪些文件。

3. 向量检索找不到关系，只能找相似

向量相似度擅长找语义接近的内容，但两条本身语义距离不近、却存在隐含关联的记忆，它就处理不了。比如：

记忆 A：production 数据库跑在新加坡节点，延迟敏感
记忆 B：定时任务每晚 2 点执行备份

几周后问"备份任务会不会有延迟问题"——向量检索大概率不会同时把这两条拉回来，更不会主动把它们之间的关联推断出来。Agent 给出的回答看起来合理，但缺了关键上下文。这类问题在记忆规模小时不明显，用得越久越会觉得它在某些事情上靠不住，但又说不清楚哪里出了问题。

4. 记忆质量直接卡住能力上限

有量化数据可以参考：OpenViking（一个 OpenClaw 记忆插件）在 LoCoMo10 长对话数据集上做了对比测评，据项目自报数据，默认 memory-core 的任务完成率是 35.65%，消耗约 2461 万 input tokens；换掉记忆系统后完成率升到 52.08%，token 消耗降到约 426 万。不是第三方独立测评，但方向性的结论和系统设计的逻辑是吻合的。记忆质量直接卡着 Agent 的能力上限，也直接影响推理成本。

5. SQLite 只能跑单机

这不是设计失误，SQLite 在单用户本地场景本来就是合适的选择。但它不支持多实例并发写、跨机器共享、水平扩展。场景一旦变成多个 Agent 实例需要读写同一份记忆，这套架构就出现问题了。

社区的应对方向

两个月内，社区冒出了几个不同的方向。

自动化捕获（Mem0、Hindsight）：把记忆捕获从 Agent 推理循环里拿出来，放到系统层自动完成。对话结束后自动提取事实，对话开始前自动注入相关记忆，Agent 不需要感知记忆系统的存在。Hindsight 还处理了一个有意思的细节：注入的记忆进入对话后会被再次提取，如果不管会导致记忆指数级膨胀，所以它在存储前自动剥离自己注入的标签。
知识图谱（Cognee）：提取实体和关系，显式建图，检索时遍历关系路径。这样跨记忆的关联就不再靠模型推断，而是在图上直接可查。
结构化映射（OpenViking）：把 Agent 的上下文按类型映射成文件系统目录结构，Agent 可以用 ls、find 这类确定性操作定位信息，向量检索只用来定位目录，目录内再做精确检索。给语义检索加上结构约束，减少噪音。
共享记忆基础设施：Hindsight 提供了团队模式，多个 OpenClaw 实例共享同一个外部记忆服务。一个 Agent 学到的东西另一个 Agent 可以立即用——从单机记忆走向共享记忆基础设施的第一步。

存储层的问题出在哪

AI Agent 的记忆访问模式和传统应用差别很大。

写入驱动不同：传统应用的写入由代码路径控制，时机和内容都是确定的。Agent 的写入由推理过程驱动，稀疏、突发，没法预判。
查询模式不同：传统应用读取是 key lookup，精确匹配。Agent 读取是"找和当前对话相关的内容"，是语义查询，不是精确查询。
生命周期参差不齐：session 级别的上下文几小时就过期，用户偏好要存几年，项目决策记录在项目活跃期随时都要用。这些周期差异很大的数据现在都堆在同一个目录里，靠文件名区分，管理成本随时间线性增长。
小文件问题：OpenClaw 每次会话追加几百字节到几 KB 的日志，文件数量线性增长，索引要跨文件全量维护。这和对象存储在高频小文件场景下面临的挑战是同一个问题，只是换了个应用层的包装。

什么存储适合Agent记忆

这个问题现在没有定论，但各方都在抢着给出答案，谁能说服开发者，谁就拿下这个市场。

向量数据库：说 Agent 记忆本质上就是 embedding，交给他们来管最合适。但精确查找和关系推理明显不足，而且单独部署一个向量数据库服务，对本地优先的 Agent 来说运维成本太高。
关系数据库：说你需要事务、需要关系、需要 SQL，向量不过是其中一列。但 embedding 在里面始终是个二等公民，语义查询能力是外挂进来的。
文件系统：说 Agent 天然按目录和路径组织信息，FS 语义才是正解。但传统 FS 没有语义检索能力，多机共享更是另一个大坑。
对象存储：解决了规模和共享的问题，但标准 S3 接口没有目录语义、没有语义检索能力，也不支持原子操作——没有 CAS 写、没有跨对象事务，文件系统的原子 rename 在 S3 上要用 copy+delete 模拟，记忆里的结构信息（内容、索引、元数据）很难保持一致。

真正适合 Agent 记忆的存储，我的理解是大概需要同时具备：文件系统级别的写入语义（原子操作、目录层次）、内建的语义检索能力、不同生命周期数据的分层管理，多 Agent 场景下合理的一致性保证，以及能支撑记忆规模持续增长的横向扩展能力。这个缺口真实存在，接下来如何发展我们拭目以待。