夜雨聆风同一个任务，传统方案跑了 72 小时，触发了 23 次会话重置；换成 OpenClaw 的记忆方案，只触发了 3 次，而且每次重置后都能把关键上下文找回来。
这个数据来自 GitHub上的一次实验。
我第一次看到时没太在意，觉得不就是长期记忆嘛，大家都在做。但仔细看完它的架构设计之后，我意识到这件事没那么简单——它改的不只是"记了多少"，而是整个记忆的存在方式。
这篇文章想把 OpenClaw 记忆系统的核心设计说清楚：它到底记了什么，怎么存，怎么找回来，以及为什么即便有了这套系统，token 消耗还是会飞起来。
先把一个误区说清楚
很多人，包括我自己，会把"上下文窗口"和"记忆"混为一谈。
但这其实是两回事。
上下文（Context）是指模型在单次请求中能"看到"的所有信息，包括系统提示词、历史对话、工具调用结果等。
它有几个典型特征：仅在当次请求有效，有容量上限（Claude 200K tokens，GPT-4 128K tokens），而且每次请求都要重新传输计算，成本不低。
如果你把"上下文"当作记忆的全部，那事情会变得很麻烦：随着对话增长，你要么不断撑大上下文直到溢出，要么主动裁剪历史导致信息丢失。
根据 Anthropic 做的一项开发者调研，有 68% 的 AI 应用团队都在为"上下文丢失"的问题苦恼，而解决方案几乎无一例外都是在上下文窗口上做文章。
OpenClaw 走了一条不同的路：把记忆从上下文里剥离出来，单独建一套可持久化、可搜索的存储层。存在磁盘上的结构化信息才叫记忆，理论上可以无限增长，跨会话保留，按需检索，存储成本几乎为零。
可以这么理解：上下文是 AI 的"工作台"，决定当下能处理什么；记忆是 AI 的"知识库"，决定长期能积累什么。两者不是同一层的东西。
双源记忆：动态 + 静态
OpenClaw 把记忆分成两类，一类叫动态记忆，一类叫静态记忆，分别对应不同的存储格式和产生方式。
动态记忆是最原始的原材料。每次用户和 Agent 交互，系统就自动把对话内容追加到 JSONL 格式的会话日志里，路径在 ~/.openclaw/agents/{agentId}/sessions/*.jsonl。格式非常简单，每行一条记录，记录消息类型、角色、内容，甚至包括工具调用。这就是 AI 的"流水账"，未经加工，但完整。
静态记忆则是提炼过的长期记忆，以 Markdown 文件的形式存在，路径在 ~/.openclaw/workspace/MEMORY.md 和 memory/*.md。它记录的是真正需要长期保留的东西：用户偏好、身份信息、回答风格要求、重要决策等。
从直觉上来说，这其实挺符合人类大脑的运作方式的。
我们记住的也是一个个重点时刻、一件件具体的事，而不是每天发生的所有琐事。把片段串联起来才是记忆，琐事会随时间淡忘。
我感觉这套机制实现了工程设计和生物学逻辑上的统一，说起来有点哲学，但确实挺妙。
静态记忆是怎么产生的
这里有三条路径，其中最关键的是第三条。
途径一：用户手动写入。直接编辑 MEMORY.md，告诉 Agent 你想让它记住什么。"你要称呼我为老板"、"我喜欢简洁的回复"，这类信息用手动方式最可靠，也最不容易在压缩中丢失。
途径二：会话结束时自动转换。当用户执行 /new 命令重置会话时，系统会触发 session-memory Hook，自动从 JSONL 日志里提取最近 15 条对话，用 LLM 生成一个描述性文件名（比如 api-design、bug-fix），然后写成 memory/YYYY-MM-DD-{slug}.md 文件。
途径三：Memory Flush 自动写入。这个机制处理的是最容易被忽视的场景：当会话上下文接近 token 上限时，在系统压缩（compaction）之前，会先触发一个特殊的 Agent 回合——专门让 Agent 把"需要持久保存的重要信息"主动写入记忆文件。
这步的指令很直接：让 Agent 自己判断什么是"durable memories"（持久记忆），然后存起来。之后再执行真正的压缩，把历史消息用 LLM 做有损摘要——默认只保留"decisions、TODOs、open questions、constraints"，不保留具体数值和时间点等细节。
这个设计的代价是显而易见的：压缩有损，精确信息容易丢失，"具体几点"之类的细节不一定能留下来。
但是这不是 bug，而是在"记忆完整性"和"系统效率"之间做的权衡。
如果你有特别重要的精确信息，最好主动让 Agent 帮你记到长期记忆里。
记忆是怎么被"找回来"的
记忆存起来只是第一步，更关键的是：当 Agent 需要用到某段记忆时，它能准确找到吗？
每当一个新的 Markdown 记忆文件产生，系统后台就会自动触发索引构建流程。整个流程分四步：
分块。Markdown 文件先按行遍历，默认每 400 tokens 为一个块，相邻块之间有 80 tokens 的重叠（保证跨块检索的连续性），遇到 Markdown 标题优先断开以保持语义完整。
向量化。每个块的文本转成向量 Embedding（支持 OpenAI、Gemini 和本地模型），存入数据库的向量表里。已经生成过的块会走缓存，不重复调用 API。
全文索引。同时为每个块建立 FTS5 全文检索索引，用于关键词搜索。
写入 SQLite。以上所有数据——元信息、向量、全文索引——全部存进一个本地 SQLite 数据库。不需要 Elasticsearch，不需要 Milvus，就一个轻量级文件。
搜索时，系统同时启动两个引擎：向量搜索（语义相似度，基于余弦距离）和 BM25 关键词搜索（词频统计，找包含精确关键词的内容）。两个引擎的结果按 70:30 的权重合并，最终得分 = 0.7 × 向量相似度 + 0.3 × BM25 得分，得分低于 0.35 的结果直接过滤掉。
这个 70/30 的比例是内部测试跑出来的：1000 次复杂查询，纯向量搜索召回率 76%，纯 BM25 召回率 68%，70/30 的混合策略召回率达到 89%。两种方法的互补性确实显著。
Agent 怎么和记忆系统交互
Agent 访问记忆只有两个工具：memory_search 和 memory_get。
memory_search 触发上文提到的混合检索，传入查询文本，返回相关片段列表（包含文件路径、行号、相关度得分和内容摘要）。
memory_get 则是精确读取，在搜索找到目标位置后，只取需要的那几行内容，不把整个文件都塞进上下文，这是控制 token 消耗的关键设计。
系统提示词里会明确告诉 Agent：在回答任何涉及历史工作、决策、日期、人物、偏好或待办事项的问题之前，必须先执行 memory_search。这不是建议，是强制约束。所以你会看到 Agent 在回答前会先做一次记忆检索。
Agent 也可以主动写入记忆，用的是标准文件操作工具，写入对应的 memory/YYYY-MM-DD.md 文件之后，MemoryIndexManager 通过 fs.watch 检测到文件变更，会自动触发增量索引更新。整个过程是实时的。
安全边界也有：memory_get 只能读取特定路径下的 .md 文件，绝对路径和 .. 都会被拒绝，不会越界读取系统文件。
那为什么 token 还是消耗飞起？
这是用了 OpenClaw 之后很多人的困惑，我一开始也觉得——既然有记忆层了，上下文应该很轻量啊，为什么账单还是那么高？
答案是：记忆层只解决了历史信息堆积的问题，但有很多其他的固定开销根本无法压缩。
每次请求都要带上 System Prompt，里面包含核心指令、工具说明、Bootstrap 文件（AGENTS.md、SOUL.md、IDENTITY.md 等，每个文件最大 20000 字符）、运行时信息等，估算下来光系统提示词就要 5000～25000 字符。
工具定义也是固定成本。OpenClaw 默认启用十几个工具，每个工具的 JSON Schema 都要随请求一起发送，browser 工具因为有 16 种 action，光 Schema 就要约 800 tokens。算下来每次请求工具定义这一项就要 3000～5000 tokens，而且完全无法压缩。
再加上会话历史的惰性压缩——压缩阈值通常设得很高（默认 20000 字符），在触发压缩之前历史一直在累积；Memory Flush 本身又是一次独立的完整 LLM 调用，每次压缩前都要额外付一次调用成本；每次 memory_search 返回的结果片段也会进上下文；一个简单任务可能触发多轮工具调用，每次都是双向计费。
所以记忆层的真正价值，不是"降低单次请求成本"，而是让无限长的对话成为可能——没有记忆层，上下文会在某个时间点彻底爆炸；有了记忆层，即便会话重置，重要信息依然可以通过检索找回来，这就是开头那个 23 次 vs 3 次数据背后的逻辑。
如果真的想降成本，得从减少固定开销（精简 System Prompt、禁用不需要的工具）和换更便宜的基础模型入手，记忆层管不了这部分。
最后想说的
OpenClaw 的记忆系统，架构上其实并不复杂：两类存储（JSONL + Markdown），一个轻量级数据库（SQLite），两种索引（向量 + 全文），两个工具接口（search + get）。拆开来看每个部分都是成熟的技术，但把它们组合成一个真正能持续积累知识、跨会话保持状态的系统，中间有不少细节上的取舍。
最让我觉得有意思的一点，是整个设计对"遗忘"的处理是主动的而不是被动的：有损压缩不是缺陷，而是选择；Memory Flush 在信息丢失之前主动抢救；用户手动写入是对系统判断的兜底。
这种"知道什么该记、什么可以忘"的思路，可能才是 AI 应用在记忆工程上真正值得借鉴的地方。
注：文中部分架构分析基于 OpenClaw 开源代码，代码细节以实际版本为准。
点击上方卡片关注阿丸公众号
交流AI商业化、产品、技术、培训的朋友，可以加我个人微信沟通
