夜雨聆风你有没有过这样的经历？昨天刚和 AI 讨论了半天的需求，今天再问它，它完全不记得了。你只能把之前说过的话再说一遍。这种感觉，就像每次走进办公室，都要重新告诉同事你是谁、你在做什么项目一样——既无奈，又浪费时间。
今天想和你聊聊，OpenClaw 是怎么解决这个问题的。
一、为什么记忆会成为行业难题？
现在的 AI 很强大，写代码、分析数据、生成报告……几乎什么都能做。但有一个根本性的问题始终没解决：AI 记不住事。
你在一个会话里让它改了三次需求，它只记得最后一次；你和它讨论了一整天的项目方案，第二天它就像失忆了一样问你“我们聊的是什么来着的？”。
这不是 AI 变笨了，而是架构层面的问题。大多数 AI 系统把对话历史当成“临时缓存”，用完就扔，根本没想过要长期保存。
而 OpenClaw 提出的解决思路是：让 AI 成为一个有记忆的伙伴，而不是每次都从零开始的工具。
它有三个核心优势：
使用便捷性：零配置启动，不用写复杂的提示词模板。系统自动完成状态追踪与信息整合，大幅降低了使用门槛，让 AI 从极客专属的工具变成普通人可用的日常伴侣。
主观能动性：不只是被动响应，还会主动预判你的需求。传统 AI 遵循“用户指令-执行-返回”的单向流程，而 OpenClaw 引入了主动推理机制，根据历史交互推断潜在需求，在适当时机提供建议。这种从“被调用”到“被信任”的转变，赋予了 AI 伙伴般的协作体验。
长期记忆：记住你的偏好、习惯、关键决策，跨会话持续工作。与即时上下文不同，长期记忆承载了用户的偏好模式、工作习惯、关键决策等跨会话信息，不会因会话结束而消散。
这三点里，最核心技术突破就是双源记忆系统。今天重点聊聊它。
二、别再把“上下文”和“记忆”混为一谈
在拆解技术实现之前，需要先澄清一个基本概念：上下文（Context）和记忆（Memory）到底有什么区别？
上下文 = 工作台
想象一下你正在写代码。你的工作台上放着当前打开的文件、正在调试的代码段、几个临时变量——这些都是为“现在正在做的事”服务的。
AI 的上下文也是这个道理。它包含本会话的对话历史、已加载的文档、当前任务的中间状态。工作台的特点是：临时、高频更替、用完就撤。 当用户要求 AI 继续修改一段代码时，系统需要立即调取刚才生成的内容——这属于上下文的工作范畴。
记忆 = 知识库
而你的知识库里存放的又是什么？是你多年积累的工作习惯、踩过的坑、做过的决策——这些信息不会随着今天的任务结束就消失。
AI 的记忆同样如此。用户的编码风格偏好、曾经否掉的方案、关键技术选型的考量——这些需要被长期保存，跨会话持续发挥作用。知识库的特点是：持久、有结构、需要时被检索。
为什么要区分清楚？
因为不同类型的数据需要不同的存储策略。强行用一套系统同时满足“临时工作”和“永久存储”，最后往往是两边都做不好。
OpenClaw 的做法是：让大模型处理上下文（短期记忆），让双源记忆系统管理长期记忆。
举一个具体的例子：你周二和 AI 说“下周一要给投资人做产品演示”，周四你只说“帮我准备演示材料”。没有记忆的系统会懵；但 OpenClaw 会从记忆里调取周二的内容，知道这是同一个项目，直接调用之前讨论过的核心卖点和目标受众。
这，就是工作台和知识库协同工作的效果。
三、双源存储：Markdown + JSONL 才是最佳拍档
OpenClaw 的存储层没有用单一的数据库，而是针对不同数据特性选用了两种格式：静态记忆用 Markdown，动态记忆用 JSONL。
静态记忆：为什么是 Markdown？
Markdown 有三个无法替代的优势：
1. 人类可读
当你需要检查某条记忆写了什么，直接打开文件就能看，不需要写 SQL 查询或用专门的工具。这在调试和审计时特别重要——每一条记录都是透明的、可追溯的。
2. 表达力强
Markdown 支持标题、列表、代码块、表格。一个用户的偏好设置可以用表格呈现，会议纪要用层级列表组织，技术文档直接嵌代码块。这种多模态的表达能力，是结构化数据库做不到的。
3. 版本友好
Markdown 是纯文本，天然兼容 Git。每次更新都是一次独立的 commit，想回溯历史版本、分分钟对比变更差异。对于需要合规审计的企业场景，这点至关重要。
静态记忆存什么？用户配置文件、重要文档摘要、系统级元数据——这些更新频率低、价值密度高、需要长期保留的内容。
动态记忆：为什么是 JSONL？
JSONL（JSON Lines）的核心优势是 append-only。
每条新记录直接追加到文件末尾，不需要读取整个文件再重写。假设一个项目有 5000 次 AI 调用，产生的交互日志会作为 5000 条记录追加，而不是触发 5000 次文件重写。
对比一下：Markdown 文件每次更新都要完整读取、修改、写入。文件大了之后，I/O 会成为瓶颈。而 JSONL 完美的解决了这个问题。
动态记忆存什么？会话交互日志、任务执行轨迹、中间结果缓存——这些写入频繁、需要时序记录、可能被后续引用的内容。
它们是如何协同的？
双源存储不是简单地把数据丢到两个文件里。OpenClaw 维护了一个统一的内存索引，记录每条记忆的键值、更新时间、存储位置。
当需要检索记忆时，索引层先定位文件位置，再读取具体内容。“索引在内存、数据在磁盘”的设计既保证了速度，又不会把全部数据堆在内存里。
还有一个额外的好处：容错性强。Markdown 和 JSONL 都是追加型文本文件，即使系统异常终止，损坏的通常只是文件末尾。重启后校验 JSON 格式就能定位问题、自动恢复，比二进制数据库的恢复简单得多。
四、检索机制：向量 + BM25 的加权融合
存储是基础，检索才是价值所在。OpenClaw 采用混合搜索策略：向量检索（70%权重）+ BM25（30%权重），召回率达到 89%。
向量检索：解决“语义相近但字面不同”的问题
向量检索的核心是把文本转成高维向量，用余弦相似度来匹配语义。
举个例子：你上周说“优化数据库查询性能”，这周问“让系统跑得更快”。字面上没有一个字相同，传统关键词匹配会失败，但向量检索能识别这是同一个意思。
OpenClaw 的向量模型在中文语义理解上做了专门优化，专业术语、口语表达、缩写简称都能处理。测试中，对同义表述的召回率达到 82%。
BM25：解决“精确匹配”的问题
但向量检索不是万能的。
当用户查“OpenClaw 记忆系统的召回率是多少”时，需要精确命中“召回率”这个词，而不是找语义相近的内容。这时候 BM25 出场了。
BM25 是全文搜索领域经典算法，基于词频和逆文档频率来评估相关性。对专有名词、项目名称、精确术语的匹配非常敏感。
70% : 30% 的权重是怎么定出来的？
这是通过 500 组不同检索意图的测试跑出来的。
• 向量权重 80%：语义理解类查询准了，但精确匹配类下降 5 个百分点 • 向量权重 60%：整体召回率明显下滑 • 70% / 30%：综合 F1 分数最高（0.87）
背后的逻辑是：大多数情况下，语义理解比精确匹配更有价值。当用户说“继续之前的那个需求”，系统应该理解这个“需求”指的是什么功能需求，而不是傻傻地只找包含“需求”二字的记录。但 30% 的 BM25 权重确保了，当用户目标明确时，不会因为“理解过度”而跑偏。
89% 召回率意味着什么？
在系统保存的 100 条相关记忆中，能召回 89 条。这个数字在 AI 记忆检索领域是领先的——行业平均在 70%-80%。
当然，89% 不是完美。系统设计了补偿机制：当置信度低于阈值时，会触发扩展检索（放宽相似度阈值、搜索相邻时间范围、必要时询问用户确认）。
五、Token 消耗：不得不算的经济账
任何 AI 系统落地都要面对一个问题：资源消耗。记忆越丰富，检索越准，但 Token 消耗也越高。
消耗从哪里来？
第一块：记忆写入，约 15%
每次会话交互产生的记忆写入大概消耗 150-300 个 Token。主要消耗在生成记忆摘要（如果需要）上。写入 Markdown 文件本身不消耗 Token，但生成摘要需要调用语言模型进行压缩提炼。
第二块：索引维护，约 20%
每次写入新记忆时，索引要同步更新（向量表示、关键词标签、时间戳、文件位置）。这部分不消耗 LLM Token，但嵌入模型的计算也是成本——向量计算由专门的嵌入模型完成，虽不计入 LLM 配额，却是不可忽视的算力开销。
第三块：检索召回，约 65%，最大头
每次需要调取历史记忆时，要执行向量检索 + BM25 融合 + 排序 + 上下文填充。典型的流程是：接收用户查询、分别执行两种检索、对结果加权融合与排序、选取最相关的 Top-K 条记忆、插入当前对话的上下文窗口。
假设每次召回 5 条记忆，每条 200 Token，单次检索就是 1000 Token。这是最主要的消耗来源。
OpenClaw 做了哪些优化？
1. 分层记忆策略
根据“热度”（访问频率）和“时效性”（创建时间）把记忆分三层：
• 热数据（7 天内）：始终在内存缓存里，不需要每次都算向量 • 温数据（7-30 天）：存在磁盘上 • 冷数据（30 天以上）：显式查询才加载
热数据的检索不需要每次都执行向量计算，直接从缓存读取，大幅降低了索引维护的开销。
2. 智能摘要机制
写入时自动生成压缩摘要，同时保留原文。检索时优先加载摘要，用户明确要详情才加载原文。这让单条记忆的 Token 占用从 450 降到 180，降了 60%。
3. 选择性召回
不是每次对话都需要记忆。系统会判断任务是否需要记忆支持——简单问答不需要，项目背景讨论才加载。按需加载过滤掉了约 35% 的不必要消耗。
最终成本
日活 20-30 次会话交互的情况下，双源记忆系统的增量 Token 消耗约每天 8000-12000 个，比未优化方案降低了 50% 以上。对于企业级部署，这个成本是可以接受的——带来的协作效率提升远超过投入。
六、为什么这不只是“让 AI 记住更多东西”？
说到底，大多数 AI 系统把“记忆”当成附属功能——有了更好，没有也凑合。OpenClaw 的做法是反过来：记忆是设计起点，不是后期叠加。
从存储架构的二元划分，到检索机制的融合策略，再到 Token 消耗的精细治理，每一层设计都围绕“让 AI 真正记住用户”这一目标。
这种设计的意义在于：重新定义人机协作的范式。
当 AI 记得你否决过什么方案、偏好什么交互风格、关心哪些核心指标，它就不再是一个召之即来挥之即去的工具，而是一个了解你的过去、关注你的当下、预判你的未来的数字伙伴。
这在企业场景里价值尤为明显：员工不用每次都重复背景信息，AI 助手能够自动补全上下文的缺口；在个人场景里，AI 记得你的日程和兴趣，真正变成“懂你”的助手。
而从技术选型上，这种“合适的技术用在合适的地方”的思路，也和当下盲目堆参数规模的趋势形成了有趣的对比。向量检索和 BM25 单打独斗都不完美，但 70/30 的权重融合实现了 1+1>2；Markdown 和 JSONL 各有局限，但分工协作后，持久性和高效性兼得。
写在最后
双源记忆系统让 OpenClaw 从“无状态的工具”变成了“有记忆的伙伴”。
它解决的问题，远不止“让 AI 多记住一些内容”这么简单。它证明了记忆可以成为 AI 产品的核心竞争力，也展示了多技术协同的实现路径——如何将向量检索、全文搜索、文本压缩、分层缓存等多个成熟技术有机整合为一个统一系统。
当 AI 能记住你的选择、偏好和故事，它就不再只是一个工具，而成为了数字世界中最了解你的那个人。
这，也许才是记忆系统最深远的意义。
