AI编程助手健忘症自救：用claude-mem搭建跨会话长期记忆系统

用了几个月AI编程助手之后我发现自己陷入了一个循环每次开新会话都要把项目背景、技术栈、当前卡点重新交代一遍。明明昨天刚跟会话聊过的方案今天新开一个窗口它就完全不记得了我又得从头解释。后来我认真折腾了一个叫claude-mem的思路——本质上是给AI助手装一套长期记忆系统把跨会话的关键信息存下来、整理好在下一次对话开始的时候自动喂回去。这套东西我自己实践下来效果非常明显也从最开始只会手动拷贝粘贴逐渐演变成了一套半自动的管线。这篇就完整记录一下我的折腾过程包含架构选型、实现细节、踩坑实录如果你也在被AI助手的健忘症困扰这套思路可以直接落地。先说清楚这是什么东西。claude-mem不是某个神秘组件它是一类会话记忆增强工具的统称和参考实现核心目标就是解决会话上下文的断裂问题。它能自动保存每次对话的关键内容定期生成摘要并在下次启动会话时把相关的历史记忆注入到上下文中。对于重度使用AI编程助手的开发者、写技术文档的博主、以及任何需要和AI进行长期多轮协作的人来说这东西能省掉大量重复沟通成本。1. 为什么AI助手需要一个外部记忆1.1 原生会话窗口的天然缺陷不管是哪家大模型驱动的编程助手本质上都是一个无状态的对话系统。它看到的是你当前发给它的上下文窗口窗口之外的内容一概不知。这个设计本身没有错属于大模型推理机制决定的——每次推理都是独立的前向计算没法像人一样在脑子里长期驻留一份不断更新的记忆。但问题在于实际工作流是连续的。你可能这周都在改一个模块的重构今天让助手生成了某个工具函数明天又要基于它继续做测试。如果每天都开新会话助手就完全不知道昨天已经写好了哪些东西你只能把代码片段、设计方案重新贴一遍。更崩溃的是贴进去之后还会遇到上下文窗口被占满的问题聊不了多久就提示Token超限。我试过几种常规解法效果都不理想手动维护一个项目文档每次开新会话把文档贴进去。这个方法最原始但维护成本高写着写着就忘了更新。直接不关会话让对话一直挂着。这个方法看着省事但上下文越长模型响应越慢费用越高而且一旦超过窗口限制前面的内容会被强行截断。使用模型自带的超长上下文把整个历史对话一股脑塞进去。这个只有表面可行实际用起来大量Token都浪费在无关内容上模型抓不住重点。真正好用的做法是像人一样做笔记——对话发生的当下就把关键信息提炼出来按主题归档需要的时候再定向调取。这就是记忆增强工具的出发点。1.2 claude-mem解决的问题范围claude-mem解决的是三个层面的问题第一层是跨会话连续性。它把每次会话的产出保存到一个持久化存储中下次对话时可以通过指令或自动机制调出相关信息。这一层解决的是忘记的问题。第二层是信息密度控制。原始会话可能有几千行内容但其中有价值的往往只是几十行。记忆系统要做的是把高密度信息从低密度对话中分离出来避免下次注入时浪费宝贵的上下文空间。这一层解决的是太笨重的问题。第三层是主动检索能力。当你在新会话中提问时记忆系统能根据当前问题自动定位相关历史片段而不是把所有历史都砸过去。这一层解决的是找不到的问题。我记得第一次完整跑通这套流程时的感受新会话里我说了一句继续昨天的重构记得对接口做兼容它直接把昨天的设计决策、已改文件列表、待办警告都带了出来那个体验确实让人一激灵。从此我就再没回到过手动复制粘贴的老路上。2. 整体架构与关键选型2.1 记忆系统的整体工作流我给这套系统设计了四个阶段模型参考了人类记笔记到复习的完整链路捕获监听每次会话过程中产生的文本流完整落盘。提炼会话结束后或者达到一定体量时调用模型对原始内容做摘要提取决策、代码产出、注意事项。归档把摘要写入结构化存储同时保留原始内容和检索索引。注入新会话启动时读取相关的历史记忆以系统提示词或上下文片段的形式注入。这四步看起来简单但每一步都有很多实现取舍。比如捕获是整段抓还是按事件抓提炼是一次完成还是递归多轮归档是存纯文本还是数据库注入是全量还是检索——这些选择直接影响最终的使用体验。2.2 捕获方式的方案对比捕获环节是整个系统的入口如果这一步漏数据后面全白搭。我对比过三种常见的捕获方案方案一手动导出。让AI助手自己把当前会话导出成文件然后手动移动到这个工具指定的目录。这个方案实现最简单稳定可靠缺点是每次都要多一步操作容易忘。比较适合使用频率不高的人。方案二协议层拦截。如果编程助手本身提供事件钩子hook可以在会话事件发生时自动触发捕获动作。比如会话开始、每次消息完成、会话结束分别调用接口把内容追加到存档。这个方案的体验最顺滑是和工具配合最好的方式。方案三终端包装器。用脚本包一层命令在命令执行时用管道同时抓取stdout和stderr。好处是和具体工具解耦任何对话式工具都能接坏处是输出流里会混入大量非对话内容比如命令回显、进度条之类的需要额外做过滤。我自己用的方案二是主方案三做兜底。日常主要依赖事件钩子自动捕获偶尔遇到钩子不生效的情况用手动导出弥补。捕获频率和粒度的控制也很重要。最开始我贪多每轮都记录完整对话结果存档文件膨胀得很快。后来调整策略按一次完整的问答块为单位切分单条消息不落盘攒够一个交互回合再写入。这样既保证了完整性又控制了文件数量。2.3 存储格式纯文件还是数据库存储层的选择直接影响后续检索写的代码量。我最初用的是纯文本文件加目录结构按日期和会话ID命名memory/ 2025-06-01/ session_abc123.md session_def456.md 2025-06-02/ session_ghi789.md好处是直观、可读、方便手动检查坏处是检索基本只能靠文件名加代码里的字符串匹配一旦记忆量大了搜索效率低得让人心烦。后来我迁移到了SQLite专门用了一张表存会话元数据一张表存记忆片段还开了全文搜索。对于一个单机使用的工具来说SQLite是最合适的——不需要单独跑服务文件即数据库备份拷贝非常方便。这一步迁移我做了很久回归测试时还发现几个旧数据字段没映射对但迁移完之后的体验提升是质的。这里有个经验如果你只是想快速验证这套玩法直接用JSONL文件就行每行一条JSON记录写入追加、读取遍历几百条记忆的时候性能完全够。等确定要长期用了再迁到SQLite不迟。没必要一开始就上复杂方案。2.4 检索方案关键词匹配还是向量检索检索是决定记忆注入质量的关键。有两种主流方向关键词匹配和向量语义检索。关键词匹配具体说就是用SQLite的FTS5做全文搜索把记忆片段分词后建立倒排索引。查询时直接跑SQL按匹配度排序返回。优点是实现简单、速度秒回、结果完全可控缺点是得保证查询词和记忆文本有字面上的重叠如果说法不一样就会漏检。向量语义检索是用嵌入模型把文本转成向量然后用距离计算找语义相近的内容。优点是能处理换个说法的情况比如你昨天说的是修复了数组越界崩溃今天问为什么程序之前会闪退语义检索引擎也能关联上缺点是引入了额外模型依赖增加了系统复杂度而且小规模数据下优势并不明显。我实际的做法是两级检索第一级用全文搜索锁定候选集如果候选集太小或者匹配度太低再启动向量检索作为兜底。日常大多数情况下全文搜索就够了。只有当记忆库超过几千条、或者我确实经常换说法提问时向量检索的价值才会放大。选型层面还有一个容易被忽视的点中文支持。SQLite默认的分词对中文很不友好英文按空格分词没问题中文就连成一整块基本搜不到。我用的是预处理方案写入时先用分词工具把中文切成词序列以空格拼接后再存进FTS索引。这样既保留了全文搜索的高效又解决了中文分词问题。3. 核心实现细节与实操过程3.1 会话捕获与归档的完整实现先说捕获这部分的落地。我使用事件钩子机制配置非常简单。先创建一个配置目录在里面放一个配置文件内容大概是这样的{ memory_dir: ~/.claude-mem/store, capture: { enabled: true, hook_mode: event, min_block_size: 1 }, summary: { enabled: true, interval_messages: 50, model: 当前使用的模型, max_summary_length: 2000 }, retrieval: { fts_enabled: true, vector_fallback: false, max_results: 5, relevance_threshold: 0.6 } }配置好之后每次会话开始时钩子脚本会生成一个唯一的会话ID格式是YYYYMMDD_HHMMSS_随机后缀同时创建对应的存档文件。当每次交互块完成时钩子捕获文本流追加写入存档文件。写入的格式我做了约定## 用户提问 [内容] ## 助手回复 [内容] ## 元信息 时间: 2025-06-01T10:23:1108:00 工作目录: /path/to/project 相关文件: src/utils/parser.rs这个相关文件字段很有用——如果助手回复里涉及了代码文件钩子会解析回复中的文件路径并记录到元信息里。后期检索时我可以直接在文件路径和记忆片段之间建立关联查parser.rs就能找到所有和这个文件相关的历史对话。会话结束的标志是进程退出或者超时。结束时钩子会做三件事补写最后的未刷新内容、把会话标记为completed、触发一次摘要生成。如果是异常退出我会标记为interrupted这类会话的摘要质量通常不高后期检索时会降低权重。3.2 自动摘要生成的两级策略摘要这一步是整个系统里最需要调参的地方。最开始我图省事每个会话结束以后做一次完整摘要后来发现两个问题一是长会话摘要时容易丢细节二是摘要质量不稳定。后来我改成两级摘要策略。第一级叫增量摘要发生在会话进行中——每当交互块数量达到50个就对最近这50个块做一次局部摘要生成一个中间文件同时把这些块的原始内容标记为已摘要后续如果会话还在继续新的内容会另开新块累积。第二级叫周期聚合摘要发生在每天结束时或者活动静默超过12小时后把所有增量摘要汇总成一份当天的整体摘要。这个设计的思路是摘要本身也是一个有损压缩过程一次性压得太多丢失率高分而治之每次压缩的损失都小最后汇总时质量更有保障。用大白话说就是先做流水账笔记再定期整理成周报。摘要生成的提示词模板也很关键。我踩过好几次坑——早期模板太开放让模型总结一下这个会话结果它开始写散文全是用户提出了一系列问题助手给出了详细解答这种废话。后来我把模板改成强结构化输出请基于以下对话片段提取事实性信息。要求 1. 只记录用户和助手明确表达的内容不要推测动机。 2. 输出格式为列表每条以[类型]开头。 3. 类型包括决策、实现方案、代码产出、依赖关系、错误修复、待办事项、用户偏好。 4. 不要输出用户说/助手说这类转述直接写事实。 5. 如果某条信息与更早的记忆重复标注[重复]并简述关联。 对话片段 [对话内容]实测这个模板的产出质量高很多每条摘要都是可直接作为上下文再次使用的原子信息。比如决策确定使用SQLite替代JSONL存储理由是需要支持全文检索再比如错误修复解析器无法处理UTF-8 BOM已在打开文件时跳过前三个字节。这类信息在后续会话中直接复用价值极高。3.3 记忆注入与查询的实际用法记忆注入的时机一般在新会话初始化阶段。在会话启动钩子中读取当天的聚合摘要和由检索模块提供的相关历史片段拼成一段记忆上下文插入到系统提示词的末尾。我给注入设置了两种模式主动模式新会话启动时自动注入最近三天的聚合摘要让模型对新项目状态有基本的背景认知。被动模式正常对话过程中不做注入只有当你输入特定指令比如#mem 继续昨天的接口兼容改造时系统才按指令中的关键词去检索历史记忆并注入。实际使用中被动模式更常用。原因是主动模式容易注入太多无关内容干扰模型的注意力。刚开始我把所有历史都塞进上下文结果模型反而忽略了一些关键约束有种信息过载的感觉。后来改成默认只注入概要详细记忆按需调取效果明显好转。查询指令的解析逻辑也不复杂。识别到记忆指令后提取指令中的关键词去掉停用词拿剩余关键词去FTS5全文索引里搜索。SQL大概是这样的SELECT fragment_id, content, datetime, relevance FROM memory_fragments WHERE content MATCH ? ORDER BY rank LIMIT 5;匹配结果按相关性排序返回再注入到上下文。这里有个细节注入的每条记忆前会加一行引用标注比如以下内容来自历史会话时间2025-06-01这样模型能区分当前对话和历史记忆避免时间线混乱。3.4 维护脚本和自动化配置整套系统离不开几个辅助脚本。我的目录是这样的~/.claude-mem/ bin/ capture.sh # 捕获钩子入口 summarize.py # 摘要生成 search.py # 检索入口 inject.sh # 新会话注入 config.json # 配置文件 store/ # 记忆数据目录 logs/ # 运行日志自动化方面我用了两个机制一是钩子触发事件发生时调用相应脚本二是定时任务兜底每天固定时间跑一次聚合摘要和索引重建防止漏触发。定时任务里还会做一次数据清理——超过90天的原始对话内容只保留摘要部分原始文本移到归档目录减小存储体积。capture.sh的核心逻辑其实很短核心就是收到一行输入判断是否是一个完整交互块的结束然后追加写入归档文件。有一个小坑是并发问题——多个会话同时写入时文件锁要处理好否则会出现内容互相覆盖。我用的方案是按会话ID分配独立文件从架构上就规避了并发写冲突。summarize.py的设计重点是幂等性。每次会话结束后可能被多次触发如果不做幂等控制同一个会话会生成多份重复摘要。我的做法是在会话存档中标记summary_version字段摘要完成后记上版本号下次触发时检查版本号相同版本直接跳过。4. 常见问题与排查实录4.1 记忆注入后反而变笨了这个问题很有迷惑性。现象是开了记忆功能之后模型回答质量下降甚至开始瞎编。排查之后发现原因在于注入的记忆片段和当前问题的相关性不高模型在试图给不相关的旧记忆找关联时产生了幻觉。解决思路分两步一是收紧检索阈值。默认返回5条有时候5条里有两条是边缘相关后来我把阈值调到只返回相关度高于0.6的片段宁可少注入也不注入无关内容。二是在注入时明确标注历史记忆可能不适用于当前任务请以当前对话内容为准。这相当于给模型加了一道官方免责声明实践证明很有效。4.2 摘要丢关键细节摘要压缩永远面临信息丢失风险尤其长会话。我遇到过最典型的会话初期的某个用户明确约束到会话结束已经经过了几十轮增量摘要时模型觉得它不重要就给过滤了。等新会话打开系统注入的摘要里完全没有这个约束导致方案直接跑偏。处理办法是增加用户约束的摘要优先级。在摘要模板中单列一类用户明确说过的必须/禁止/不要/只能这类信息强制保留不参与常规的摘要压缩。同时我加了一个安全机制原始对话全文保留90天如果某次检索发现摘要信息不足可以回退到原始存档找完整上下文。4.3 中文检索空空如也这个坑前面提过这里再详细说一下。FTS5默认的分词器对中文就是灾难整段中文文本被当成一个token你搜重构两个字什么都匹配不到。而且最坑的是你用不匹配的查询词去测试费了很大劲也不知道问题在哪。解决方法是预处理分词。写入FTS索引前先用分词库把中文文本切词然后空格拼接存储。这样继续昨天的重构方案会被切成继续 昨天 的 重构 方案搜索时同样把查询语句过了分词再跑匹配。实测召回率提升明显简单方案解决大问题。4.4 多个项目的记忆串味如果你同时维护多个项目记忆库混在一起会出大乱子。我之前把所有项目的记忆存到一个库里去A项目会话里询问B项目的旧代码检索系统还能搜出来导致A项目的对话经常混入B项目的术语简直一团浆糊。解决办法是给记忆数据按项目隔离。实现很简单每个会话启动时读取当前工作目录的路径把目录名或项目名作为project字段写入元信息和存档文件检索时强制带项目过滤条件。SQL改动很小SELECT fragment_id, content, datetime FROM memory_fragments WHERE project ? AND content MATCH ? ORDER BY rank LIMIT 5;这里我强烈建议项目隔离别用数据库查询时筛选的方式最好直接按目录隔离存储文件。因为这样不仅查询时干净备份和清理也更简单。5. 实操中的体会与后续扩展5.1 使用习惯决定工具效果同样的工具不同人用效果差异很大。我观察到的规律是用好claude-mem的人大多会在会话中有意识地输出结构化信息。比如让AI助手生成方案时要求它把决策原因单独列出来结束一个任务时要求它简明汇总成果。这相当于给记忆系统提供高质量原料摘要出来的内容自然就精准。反过来如果跟模型随意闲聊式对话会话里全是零散的改这里再看一下不对记忆系统能提取的信息就很稀薄。所以我现在的习惯是重要对话前先明确告诉助手接下来这个会话产出的关键决策请用列表帮我同步一遍这样记忆文件里的捞出来就是结构化内容。5.2 还能往什么方向扩展这套系统目前已经满足了我的日常需求但还有几个方向值得继续做。一个是记忆关联图。现在记忆是线性的文本片段但实际信息和信息之间是有拓扑关系的——某个决策关联了若干文件某个文件又关联了若干优化点。如果能把碎片串成知识图谱检索时就可以做多跳关联比如重构parser.rs会影响哪些历史决策就能自动追溯出来。另一个是定期记忆复盘。我打算做一个每周摘要的汇总页把一周内的所有关键决策、修复、待办事项按项目列出来。这个文档对写周报、做复盘、梳理优先级都很有用。实现上就是在现有两级摘要上再叠加一层周聚合工作量不大。还有一个方向是多模态记忆。现在只能记录文本信息但调试过程中经常有截图、复现步骤、日志片段这些内容如果能归档进记忆库并在检索时关联引用覆盖的场景会更完整。我在实际使用中体会最深的一点是记忆系统设计的好坏很大程度上取决于什么时候该记、什么时候该忘。记太多检索噪音大忘太快关键信息失联。我目前的策略是按时间和相关性双重衰减——时间越久远权重越低相关度越低越不注入。但这个参数还需要不断调不同项目、不同使用习惯的人最优参数都不一样。最后再分享一个小技巧把search.py单独作为一个命令接入手动工作流中。聊天之外我还经常在终端里直接跑claude-mem search 接口兼容性设计来定位之前的讨论这种操作方式比翻聊天记录效率高得多。如果你想上手这套方案我建议从最小闭环开始先把捕获和存储做出来其他环节逐步加。别一开始就追求完整架构跑通一次记录-摘要-注入的循环你对这套系统的理解会完全不一样。