让AI告别“失忆症”：长期记忆系统的设计实践与架构演进

在使用AI助手时，你是否曾遇到过这样的尴尬：前一天告诉它“我喜欢简洁的回答”，第二天新建对话后，它又开始长篇大论；你在某个项目中积累的技术偏好，换一台设备就全部消失。这种“用完即忘”的特性，被形象地称为AI的“失忆症”——每次对话结束，上下文窗口关闭，所有信息便烟消云散。对于需要长期协作的场景而言，这无疑是一道难以逾越的鸿沟。Memory系统的出现，正是为了解决这一核心痛点：让AI真正拥有跨越会话、跨越时间的长期记忆能力。你告诉它一次，它能记住下次、下下次、甚至一个月后。

本地存储的共性困境

当前主流的AI编程助手普遍采用本地文件存储方案来实现记忆功能。Cline使用固定目录下的Markdown规则文件，启动时扫描加载，本质上是为AI提供一本操作手册；OpenCode更直接，将记忆写成Markdown文件，通过固定路径发现机制读取；OpenClaw则在此基础上增加了SQLite全文索引，支持关键词搜索。然而这三种方案存在一个共同的致命缺陷：记忆存储在本地设备上。换一台机器、重装系统、在不同设备间切换，记忆便荡然无存——就像通讯录只存在旧手机的SIM卡里，换手机后便无法恢复。这对于需要在多端协同工作的企业用户而言，几乎是不可接受的。

三层写入的精细化设计

针对记忆写入的场景差异，自研Memory系统设计了三条分工明确的写入路径。第一条是AI主动写入：当对话过程中AI判断某些信息值得长期保存——如用户偏好、项目技术约束、踩坑教训——它会调用memory_write工具主动记录，如同会议中随手记下的要点。第二条是上下文压缩时的自动提取：当对话长度接近上下文窗口上限（达到75%）时，系统自动触发记忆提取，用静默的LLM轮次扫描近期对话，将值得持久化的信息提炼写入Memory。为了避免重复提取和记忆冲突，系统采用SHA-256去重机制，并通过Reconciliation对账确保同一条事实只保留最新状态，删除操作则默认关闭以保护数据安全。第三条是定期整理合并：随着记忆积累，系统定时将关于同一主题的零散条目合并为精炼摘要，避免记忆膨胀。

按需检索而非全量注入

一个关键的设计决策在于：Memory内容不注入System Prompt。表面上看，将所有记忆塞入System Prompt是简单直接的做法，但随着记忆数量增长，问题会急剧暴露。首先是缓存失效问题——System Prompt变化导致LLM无法缓存处理结果，每次请求都要重新计算，成本和延迟双双上升。其次是注意力稀释问题——当存在大量无关记忆时，AI的注意力被分散，真正相关的3-5条关键信息反而被淹没。最后是上下文窗口浪费——记忆内容可能占用数千token，挤压了对话本身的空间。因此更优的方案是：System Prompt中只放置静态的工具使用指导，告知AI有memory_search、memory_read、memory_write等工具可用，让AI在需要时主动检索相关记忆。这就像考试时记住“关于X的内容查第3章”而不是背下整本百科全书，按需检索的精准度远高于全量注入。

多级合并与架构演进

记忆整理采用两阶段处理：分组与合并。系统首先将所有记忆条目的索引信息打包发送给LLM，让其判断哪些条目属于同一主题；然后读取同组条目的完整正文，合并生成精炼的摘要文档。合并后的新条目标注其吸收的源条目，源条目则被标记为“已归档”但不删除，支持双向追溯。随着记忆继续积累，合并后的摘要可能再次被合并，形成多级记忆图结构，深度上限设为3层以避免过度抽象。架构层面，Memory系统经历了从本地Markdown文件加SQLite FTS5全文索引，到RAG向量存储的演进。后者通过PostgreSQL加向量索引实现语义搜索，解决了关键词匹配无法捕捉同义表达的问题，同时通过biz_id实现用户和项目级别的数据隔离。在实现细节上，归档标志必须放在数据库列而非metadata中以保证分页准确性，名称去重则必须包含归档条目以避免创建重复副本。

Memory系统的核心挑战从来不是“怎么存”，而是如何让AI在正确的时间记住正确的东西、并高效地使用这些记忆。三层写入路径覆盖了显式偏好、隐含知识和记忆膨胀三种场景；按需检索机制保证了System Prompt的稳定性和AI注意力的精准度；LLM驱动的多级合并则让记忆系统能够持续进化而非沦为信息垃圾场。这三个问题解决后，AI才真正从“金鱼”进化为“有记忆的助手”。