Claude长期记忆解决方案：用向量数据库构建外部记忆层

最近我折腾了个叫做 claude-mem 的小项目起因非常简单我实在受够了 Clude 的“金鱼式记忆”。上午刚让它帮我把整个项目的技术方案梳理清楚下午新建一个会话想接着写代码它居然一本正经地问我“你提到过的那个系统能再详细描述一下吗”那一刻我意识到再聪明的模型没有持久记忆也只是块白板。于是我开始认真研究怎么给 Clude 接一个“外部硬盘”最后沉淀出一套可以稳定复现的方案。这篇文章就把 claude-mem 的核心思路、完整实现和踩坑记录全部掏出来适合那些长期用 Clude 处理复杂任务、又想摆脱重复粘贴背景信息的开发者。1. 先搞明白Claude 的“失忆”问题到底出在哪1.1 上下文窗口不是硬盘是白板所有大语言模型产品本质上都无状态。你发送的每一条消息会连同系统提示词和历史消息一起拼接成一个上下文窗口模型读完这个窗口后生成答案生成完就结束。窗口里的内容不会自动持久化下一次对话就是一次全新的“空白启动”。你可以把上下文窗口想象成一块白板本次对话期间你写上去的每一行字模型都能看到但对话一旦结束白板就被擦干净什么都不留下。即使不新建会话只要窗口填充得太满早期内容也会被“滚动裁剪”只保留最近的一部分。所以 Claude 不是故意装失忆它压根没有在窗口之外保存任何东西的能力。理解这一点后我就明确了自己要解决的问题必须有一个外部记忆层把白板上的重要信息定期“抄”到硬盘上并在下次需要时重新“誊写”回白板。1.2 日常使用中最让人抓狂的三类失忆实际使用里我反复踩到三类坑每一种都足以让人崩溃。第一类跨会话记忆丢失。我在 A 会话里确定了技术选型——后端用某个框架、数据库选型、API 风格规范。到了 B 会话想基于这些前提继续写模块Claude 完全不知道 A 会话的存在。无奈之下只能把结论复制粘贴过去粘贴过程中还经常遗漏细节最后生成的内容和之前的决策矛盾。第二类长对话内的早期信息丢失。在一个会话里连续审阅几万字代码时前期讨论过的约束条件会被上下文窗口的裁剪机制悄悄丢掉。它会突然反问“这个模块之前有定义过吗”哪怕你明明在十轮前写过完整定义。第三类多项目互相污染。如果图省事在同一个会话里处理多个任务早期项目的细节会和当前项目纠缠不清。它可能把 A 项目的权限逻辑套到 B 项目的接口设计上要花大量时间纠正。这三类痛点让我下定决心单纯依赖模型自身能力是有限的必须搭一个可控的、可检索的外部记忆系统。这个系统就是后来的 claude-mem。2. claude-mem 的设计思路把对话变成可检索的外接硬盘2.1 五个核心环节记录、切片、向量化、存储、检索注入claude-mem 的完整工作流分成五步。第一步记录。在每次对话过程中拦截用户发送的消息和 Claude 返回的回复形成一条条对话记录。第二步切片。原始对话长度不一有些回答可能上千字。必须把长文本拆成适合向量化的“语义块”拆得好不好直接决定后续检索质量。第三步向量化。用嵌入模型把每个语义块转换成高维向量。语义相近的文本在向量空间里距离也更近。第四步存储。把向量和原文、元数据时间、会话 ID、重要度一起写入本地存储。向量负责语义检索元数据负责过滤和排序。第五步检索注入。每次要调用 Claude 前把当前问题也向量化在记忆库里做相似度搜索挑出最相关的几条记录拼成一个“记忆块”注入到给模型的输入里。这套流程本质上是做检索增强生成。区别在于我不只检索外部文档而是检索过去和 Claude 自己的每一次对话。它的记忆变得可追溯不再是黑盒。2.2 为什么选向量数据库而不是普通数据库最开始我也想偷懒用现成的 SQLite 做关键词搜索。结果发现自然语言表达同一件事的方式实在太多。昨天说“那个支持并发的下载任务”今天可能问“多线程批量拉取文件的事情”关键词download和多线程不一定能匹配上。普通数据库做字面匹配碰到这种说法差异就失效了。向量数据库通过嵌入模型把文本映射成高维向量语义相关的内容在向量空间里距离更近。比如“并发下载”和“多线程批量拉取”在语义上高度相似即使没有一个词重叠向量距离也会很近。我实测过同一组问题关键词搜索的命中率不到四成向量检索的命中率能到八成以上。不过向量检索也不是万能的它会有“只看相似度忽略时间和重要性”的毛病后面我加了重排和时间衰减来解决。2.3 记忆注入的插入点我放在了每次请求之前有几种常见的注入方案把记忆内容直接拼进系统提示词把记忆伪装成历史消息或者封装一个中间层在每次 API 调用前动态生成“记忆块”放在用户消息前面。我最终选了第三种。原因是前两种都太笨重系统提示词一旦过长会影响模型对当前任务的专注度伪装成历史消息则容易混淆对话的时序关系。中间层方案最灵活我写了一个包装函数所有调用都走这个函数内部自动完成“检索记忆 - 拼装记忆块 - 追加当前问题 - 调用模型”的流程上层业务代码几乎不用改。3. 从零实现一个精简版 claude-mem3.1 环境准备依赖清单与版本陷阱实现 claude-mem 不需要很重的设施我个人用的是 Python依赖也很少pip install claude-sdk sentence-embedder local-vector-store tiktoken我这里用到的claude-sdk是通用的接口封装sentence-embedder是嵌入模型封装local-vector-store是本地向量存储。三个包名示意即可实际可以根据你熟悉的技术栈替换。最容易踩的版本陷阱有两个。第一嵌入模型的版本必须固定。不同版本的嵌入模型输出的向量维度可能不一样如果你中途升级了模型旧向量和新向量维度对不上检索直接报错。第二向量存储的持久化路径不要放在/tmp这种临时目录否则系统一重启几个月积累的记忆全没了。我一开始就吃过这个亏后来把路径固定在一个带版本号的目录里比如mem_store_v2。3.2 存储层设计SQLite 管元数据向量库管语义我的做法是双存储SQLite 保存原文、会话 ID、时间戳、重要度等元数据向量库只保存向量和对应的 ID。这样既能用向量做语义检索又能用 SQL 做时间范围过滤、会话隔离两者互补。表结构我设计得很简单CREATE TABLE memories ( id TEXT PRIMARY KEY, session_id TEXT, role TEXT, content TEXT, created_at TIMESTAMP, importance REAL DEFAULT 1.0 );每次写入一条记忆时我会同步在 SQLite 里插入一行记录再把向量写入向量库向量 ID 和 SQLite 的id字段保持一致。检索时先向量搜索拿到 ID 列表再去 SQLite 取原文和元数据用于后续的重排。3.3 切片策略按“语义块”而不是按固定字符切切片是整个方案里最容易翻车的一环。一开始我图省事按 200 个字符硬切。结果一句话被拦腰截断向量化后的语义完全跑偏检索出来的记忆牛头不对马嘴。后来我定了三条启发式规则效果好很多把每一轮“用户问题 Claude 回答”整体作为一条候选记忆如果回答超过 500 字按照 Markdown 小标题或者自然换行拆成多条如果连续几轮对话都很短则把相邻的两轮合并成一条避免碎片化。还有一个额外技巧遇到代码块的时候不要从中间切。代码块里的变量名、函数名往往是有完整语义的切断了之后向量检索时很难匹配到正确片段。3.4 检索时的重排和过滤别只拿 Top1有记忆不等于有用错误的记忆比没有记忆更糟糕。我曾经直接取相似度最高的那条记录注入结果它和当前问题表面相关、实际无关Claude 被带偏答非所问。我现在做了三层处理召回阶段取 Top10按时间衰减系数和重要度重新排序取 Top3过滤掉相似度低于阈值的记录阈值我一般设在 0.35 左右。如果用户消息特别短比如只有“继续”或“然后呢”这样的词直接用这句话去检索几乎没有效果。我的处理是把上一条用户问题也拼接进来一起做向量化再去记忆库搜索。3.5 与 Claude 集成的代理函数透明地注入记忆下面是核心骨架代码我用的是虚构的 API 封装但流程可以直接照搬from typing import List, Dict import claude_sdk as claude from sentence_embedder import embed_text from local_vector_store import VectorStore class ClaudeMem: def __init__(self, store_path: str mem_store): self.vector_store VectorStore(pathstore_path) self.session_id None self.conversation_buffer [] def remember(self, content: str, role: str, importance: float 1.0): vector embed_text(content) record_id self.vector_store.insert(vectorvector, textcontent) # 这里同时往SQLite写入元数据 self._save_metadata( record_id, session_idself.session_id, rolerole, contentcontent, importanceimportance ) def recall(self, query: str, top_k: int 3) - List[Dict]: vector embed_text(query) candidates self.vector_store.search(vector, top_k10) # 重排逻辑时间衰减 重要度 reranked self._rerank(candidates, query) filtered [r for r in reranked if r.score 0.35] return filtered[:top_k] def ask(self, user_message: str) - str: # 结合上一条问题防止“继续”“然后呢”这类短消息检索不到东西 query user_message if self.conversation_buffer: query self.conversation_buffer[-1][content] \n user_message memories self.recall(query) memory_block self._build_memory_block(memories) augmented_message memory_block \n\n[用户当前问题]\n user_message response claude.complete( messages[{role: user, content: augmented_message}] ) self.conversation_buffer.append({role: user, content: user_message}) self.conversation_buffer.append({role: assistant, content: response}) self.remember(user_message, roleuser) self.remember(response, roleassistant) return response_build_memory_block会把选中的记忆统一格式化成一段话比如[对话记忆参考] - 2025-02-10 你提到后端技术栈确定使用某框架数据库采用 PostgreSQL。 - 2025-02-10 你强调并发下载模块要支持断点续传不要用轮询做进度检测。这段文本再和当前问题拼接。Claude 看到这些记忆后等于把之前的“白板内容”重新抄回来了。4. 实测效果与一路踩过的坑4.1 连续多日对话的效果对比我在一个模拟项目上做了对照组测试同样一个基于某框架的后端开发任务一组不使用记忆一组使用 claude-mem连续几天交替进行。测试场景无记忆的表现有记忆的表现claude-mem隔天追问“我之前定的数据库选型是什么”完全忘记需要重述背景能准确说出选型并提醒当时放弃另一种方案的原因跨会话让模型接着写某模块代码重新生成一套结构和之前不一致的代码直接引用之前的接口命名和编码风格同时维护 A / B 两个项目的对话容易把 A 项目约束带到 B 项目检索时按会话 ID 过滤互不干扰这个结果基本验证了我的核心判断大部分“失忆”可以通过外部记忆层解决而且检索注入的记忆块只要控制好体积不至于干扰模型对当前问题的判断。4.2 坑一中文语义分块导致记忆碎片化中文没有天然空格按固定字符数硬切的问题在中文场景被放大。我遇到过最典型的案例一条关于“权限校验中间件逻辑”的回答被切成两半前半段是“用户 A 可以访问资源 B”后半段是“但如果角色是管理员则跳过校验”切片后向量化两条记忆的语义都模糊不清。后来我改用“先按句号切句再把同一轮对话的句子聚合”的策略才解决这个问题。另一个代码相关的坑代码块绝对不能被切开。我开发了一个简易的保护机制切片前先检测到代码块标记保证整个代码块不会进入普通切片逻辑。4.3 坑二注入过多记忆导致“注意力涣散”记忆不是越多越好。有段时间我把召回 Top5 的记录全注入每一条都带完整原文导致提供给模型的上下文超过 1500 token。结果模型过度关注历史细节反而忽略了用户当前问题。后来我给记忆块设了预算单次注入不超过 3 条记忆每条记忆控制在 150 字以内总长度不超过 500 token。如果某条记忆特别长我会先让嵌入模型生成摘要再存摘要而不是存全文。这招立竿见影回答质量明显回升。还有人问重要度参数怎么定我的经验是带强烈偏好表达的内容重要度要高比如“我希望”“不要”“必须”这类词纯寒暄和提问性的内容重要度要低。另外最近 N 次的对话要给予时间上的额外权重。4.4 坑三隐私与数据安全问题claude-mem 会把对话原文存在本地。如果笔记本被偷或者别人动了文件里面的敏感信息就泄露了。我在生产环境的备份脚本里加入了 SQLite 加密并把向量库也放在加密卷里。同时增加了一个“敏感内容过滤”接口如果某条消息包含明显的关键词密码、密钥、手机号等就自动跳过记忆或者只保存“已脱敏的摘要”不保存原文。再就是遗忘机制。我实现了一个简单的定时清理任务超过 90 天且重要度低于 0.5 的记忆自动删除。用户也可以主动对 Claude 说“忘掉 XXX”这条指令会触发删除逻辑而不是被当作普通对话记进去。5. 进阶让 claude-mem 成为多会话通吃的长期大脑5.1 记忆的时间衰减与时序加权简单向量检索只看语义相似度结果可能是几个月前的一条闲聊记录和当前问题撞上语义排得很靠前。但事实上昨天刚讨论的内容通常比三个月前的内容更有参考价值。我给每条记忆的评分加了时间衰减项最终得分 相似度 * 时间衰减系数 * 重要度 时间衰减系数 exp(-age / tau)age是距离当前的天数tau是衰减半衰期。对于对话记忆场景我一般把tau设为 30 天。也就是说一周前的记忆只衰减到约 80%一个月前的衰减到约 37%三个月前的几乎不参与排名。这个参数可以根据你的业务调整如果是长期项目偏好tau可以调大到 90。5.2 多项目隔离与角色记忆很多人的记忆库里不只一个项目。如果不隔离A 项目的技术决策会被 B 项目的检索误召回。我的办法是给每条记忆加上project_id和user_id元数据检索时先按当前会话所属项目过滤再在剩下的向量集里做相似度搜索。角色记忆也可以这么做。比如“当前用户是后端开发”和“当前用户是前端开发”两种身份下需要的记忆侧重点完全不同。我甚至给每个角色设置了一套独立的向量库目录彻底隔离虽然存储空间多了一些但换来了干净的检索结果。5.3 后续扩展方向claude-mem 目前已经很够用但我觉得还能继续长成“长期大脑”。一个明确的方向是自动总结旧会话生成“长期摘要”。每天晚上我可以用 Claude 自己把当天所有会话浓缩成几条结构化摘要存入长期区原始对话只在短期区保留三天。这样既保留语义又极大压缩存储。另外如果是在团队场景可以把 claude-mem 接到共享知识库上。每个成员提问时不仅检索自己的历史记忆还能检索团队的公共文档。权限控制要跟上不然很容易把某个项目的内部细节暴露给不相关人员。最后再分享一个小技巧给 claude-mem 加一个“主动遗忘”的终极大招——当你发现某条记忆明显是错误的不要只让它过期直接按 ID 删除。我之前的版本犯了错之后错误记忆会一次次被检索出来Claude 每次都在同一个坑里跌倒。后来我实现了基于关键词的删除接口只要对 Claude 说“忘记关于 XX 的内容”就过滤出对应记录并移除。这比任何打分策略都管用。如果你也在和 Claude 的失忆问题搏斗不妨从这套精简版开始先把自己的重要对话“记忆化”再逐步调时间衰减和重排逻辑。