如果你用 Claude Code 干过超过一个星期的正经项目大概都有过这种体验昨天刚和它敲定的技术选型今天新开一个会话它像失忆一样重新问你一遍这个项目打算怎么做。不是模型变笨了而是默认状态下每次新会话对 Claude 来说都是一次格式化重启。上下文窗口再大也管不到上一场对话。claude-mem 这个开源工具就是冲着这个痛点来的把对话里真正值得记住的信息抽出来存进本地 SQLite再用向量检索的方式在后续会话里自动想起来。我把这个工具从装到用仔细折腾了一遍这篇文章不打算复述 README而是把记忆机制的底层原理、两条接入路径、一周实测下来的真实表现还有数据库膨胀、API 费用、明文隐私这几个绕不过去的坑一次讲清楚。适合已经把 Claude Code 当日常生产力工具、却被每次都要重新交代背景折磨得不轻的人。1. 每次对话都失忆的 Claude到底缺了什么1.1 无状态 LLM 与真实开发需求之间的鸿沟要理解 claude-mem 的价值先得搞清楚 Claude 为什么记不住事。大语言模型的本质是一个无状态的函数你给它一段输入它根据训练时学到的参数分布生成输出整个过程不保留任何记忆。所谓的多轮对话能力靠的是把前几轮的消息重新拼进输入里一次一次地带着历史往前走。这就像两个人聊天时每个人都得把之前说过的每一句话贴在脑门上说一句贴一句窗口满了就把最早的话丢掉。日常开发恰恰是长周期、多会话、强上下文依赖的活儿。一个功能从设计到上线往往跨好几天期间会有大量讨论、试错、决策变更。你在第一个会话里确定了用 PostgreSQL 而不是 MySQL因为要用 JSONB 做模糊检索第二个会话里让 Claude 写建表 SQL它根本不知道这个决策可能又提了一堆 MySQL 方案。你只能手动把结论粘回去然后祈祷它别忘。这还不算最难受的。更常见的是你在两个终端窗口同时开两个会话一个写后端接口一个调前端样式。两个会话各自为政项目背景、代码约定、命名规范都得分别教一遍。一个人带着一个项目反复当复读机这种体感时间久了真的很消耗耐心。claude-mem 的思路就是在这条鸿沟上搭一座桥会话结束后把关键信息沉淀下来下次需要时自动取回来。1.2 为什么我不建议把记忆塞进 system prompt有人会说记忆问题不是可以用 system prompt 解决吗把项目背景、关键决策、待办事项全部写进去每次新会话开头先读一遍。这个思路方向对但实际操作里有三个硬伤。第一system prompt 有长度上限而且非常珍贵。Claude 的上下文窗口要留给代码、报错信息、工具返回结果这些正在发生的事情你把历史背景占掉一大块留给当轮任务的容量就小了。项目越复杂背景说明越长最后你会发现自己陷入一种诡异的循环写 prompt 的时间比写代码的时间还长。第二手动维护 system prompt 是反人性的。今天改了架构决策明天新增了模块你得记得同步改那份项目说明书一旦忘记Claude 就会基于过时信息给你建议比没有记忆更糟。所有需要人主动维护的方案最终都会因为人的惰性而失效。第三静态文本没有检索能力。你写上十条历史决策Claude 读的时候只能全盘接收没法在当前问题里精准判断哪一条历史信息与此刻最相关——除非你自己指出来。而 claude-mem 这类工具做的正是动态检索不是把记忆全部倒给模型而是根据当前的问题挑出最相关的几条记忆给 Claude 看。这才是记忆和资料堆的本质区别。2. claude-mem 的记忆机制拆解SQLite 存事实Embedding 做召回2.1 记录什么从原始会话里提取值得记的内容第一次把 claude-mem 接进 Claude Code 后我最好奇的一件事是它到底怎么判断什么东西值得记总不可能把每句对话都原封不动存下来吧那样过两天数据库就炸了。实际跑起来就明白了。claude-mem 不是把会话当录音机而是当会议纪要员。它监听会话过程中的关键节点比如 Claude 给出了一个明确的技术选型理由、你拍板了一个接口设计、排查完了一个 bug、定下了一个命名规范这些内容会被抽出来压缩成一条条独立的记忆记录。每条记录包含正文内容、所属项目、创建时间、以及对应的向量表示。我在实际使用里观察到的规律是凡是结论性的、未来还可能被引用的内容基本都会被收进去而那种临时性的、一次性的闲聊会被过滤掉。这个过程涉及一次精炼提取调用一次模型把原始对话浓缩成结构化记忆。数据量上比直接存原文小得多语义上反而更干净。你会发现 claude-mem 记下来的东西往往恰好是你在新会话里最想重新告诉 Claude 的那几句话。2.2 存到哪里单文件 SQLite 和它的向量表存储层claude-mem 选的是 SQLite不是 PostgreSQL更不是专门的向量数据库。这一点我一开始不理解后来想明白了这个选择极其务实。SQLite 是一个单文件数据库整个记忆库就是一个.db文件默认放在用户目录下。对个人开发场景来说这有几个天然好处零运维不用装服务、不用管端口备份即拷贝把那个文件复制走记忆就全带走了查询性能对个人项目的数据量绰绰有余你一天产生几百条记忆一年也就几万条SQLite 处理这点数据毫无压力。向量检索的部分claude-mem 用了 SQLite 的向量扩展能力把每条记忆的 embedding 向量直接存在表里查询时用余弦相似度去匹配。整个方案在够用和轻量之间取了一个很舒服的平衡点。如果你用过专门的向量数据库会发现那个东西确实性能强但为了记录个人项目的对话记忆去部署一套 Milvus 或者 Qdrant完全是杀鸡用牛刀而且平白多了一个需要维护的依赖。2.3 如何想起来查询关键词的向量化召回链路claude-mem 的召回机制是我觉得最值得讲的部分。它不是一个简单的 LIKE 模糊搜索而是完整的向量语义检索。当你在新会话里向 Claude 提问或者 Claude 在处理某个任务时claude-mem 会把当前上下文的关键内容做一次向量化然后在 SQLite 的记忆表里算出每条历史记忆与当前上下文的相似度按分数排序把超过阈值的前 N 条记忆返回给 Claude。在这个过程中相似不是字面上的关键词相同而是语义相近。举个例子。假设你之前记录过一条支付模块的幂等键用了订单号用户ID组合后来你在新会话里问怎么防止用户重复提交订单这两个问题的字面关键词完全对不上但语义上是高度相关的。向量检索就能把它们关联起来。这是 claude-mem 最核心的价值所在——它让 Claude 真的能想起来而不是搜到。完整的链路是三段式写入阶段记忆被提取、向量化、存入 SQLite查询阶段当前上下文被向量化、与存量记忆算相似度、取 Top-N使用阶段召回的记忆以格式化文本的形式注入到 Claude 的对话上下文中提醒它这些历史信息可能对当前问题有用。3. 把 claude-mem 装进 Claude Code两条接线的完整配置3.1 前置条件Node 环境与 API Key先说环境要求。claude-mem 是用 Node.js 写的安装之前你得保证机器上有可用的 Node 运行时版本建议 18 以上。我在 macOS 上装的时候用的是系统自带的 node版本刚好满足要求在 Linux 服务器上装则碰到过 node 版本过老的问题用 nvm 切到 LTS 版本就顺畅了。其次是要有一个可用的 Anthropic API Key。claude-mem 做记忆提取和向量化都要调用模型接口所以这个 Key 是刚需不是可选项。如果你已经在用 Claude Code那这个 Key 应该已经有了直接在环境变量里暴露给它就行。安装本身很简单一条 npm 全局命令的事npm install -g claude-mem装完可以跑一下claude-mem --version确认安装成功。如果公司网络有代理限制npm 源可能拉不动记得先配好镜像源。我第一次装的时候卡在这一步换了 npm 镜像之后秒下完。3.2 接入方式一以 MCP Server 形式挂在工具链上claude-mem 最常见的接入方式是通过 MCP。MCP 全称是 Model Context Protocol你可以把它理解成 AI 应用的USB 接口——Claude Code 通过这些接口去调用外部工具获取上下文。claude-mem 把自己实现成一个 MCP ServerClaude 就能在对话过程中实时调用它的记忆读写能力了。以 Claude Code 为例接入命令大概长这样claude mcp add claude-mem -- npx claude-mem跑完这条命令Claude Code 的 MCP 配置里就多了一个 claude-mem 服务。之后你新建会话Claude 会自动发现这个服务并在合适的时机调用它的工具检索历史记忆、写入新的记忆、更新已存在的记忆条目。这种方式的优势是让 Claude 自己决定什么时候该回忆。你不必手动触发Claude 在对话中如果觉得当前问题和以往记忆可能有关系就会主动调用检索。实际用下来整个体验很接近这个助手真的知道我上次交代过什么而不是一个被动的搜索插件。3.3 接入方式二用 hooks 自动记录每次会话MCP 方式解决了读取记忆的问题但写入记忆这件事我发现有时候会漏。Claude 不会每一次对话都主动把结论存下来这其实挺考验它的主动性判断。为了不依赖这种判断我额外接了一条路径Claude Code 的 hooks 机制。hooks 是 Claude Code 提供的事件钩子可以在工具调用、会话结束等节点自动执行命令。我在配置里加了一个 PostToolUse 的 hook让每次工具调用结束后把当前会话的上下文自动送给 claude-mem 做记录。配置文件大致长这样{ hooks: { PostToolUse: [ { matcher: .*, hooks: [ { type: command, command: claude-mem record --from-hook } ] } ] } }这样写的好处是逢事必记每次关键操作都自动沉淀一条记忆不依赖 Claude 的自觉。缺点是记忆量会比 MCP 方式大不少后续的清洗成本高一丢丢。我现在是两条路径同时开着hooks 负责全量记录MCP 负责按需召回配合下来覆盖得比较完整。提示如果你和我一样同时开两条路径注意看下有没有重复写入。我在一开始配置的时候出现过同一条记忆被记了两遍的情况后来在 claude-mem 的配置项里开了去重问题就消失了。3.4 关键环境变量与权限检查清单配置环境变量是接入过程里最容易出问题的环节我把常用变量整理成了表照着检查基本不会踩坑变量名作用我的建议值ANTHROPIC_API_KEY模型调用凭证记忆提取与向量化都靠它换成你自己的 Key注意别写进公共配置CLAUDE_MEM_SQLITE_DB_PATH记忆库文件位置默认挺好多项目并存时建议显式指定CLAUDE_MEM_MODEL向量化用的模型默认即可追求中文效果可换文本模型CLAUDE_MEM_TOP_K每次召回多少条记忆5 到 10 之间比较稳太多会冲淡重点CLAUDE_MEM_SIMILARITY_THRESHOLD召回相似度阈值0.7 左右太低会带回一堆无关历史权限方面有一个很隐蔽的坑如果你用 hooks 方式接入而 Claude Code 是以某个特定用户身份跑的那 claude-mem 写入 SQLite 文件时需要这个用户对该路径有写权限。我在一台 Linux 服务器上遇到过看起来装好了但记忆永远写不进去的情况排查半天最后发现是数据库文件的所有者和运行用户不一致chown一下就好了。4. 一周实测记忆回填的真实效果和边界4.1 跨会话重提旧事的质量配置完成之后我拿一个真实的项目试了一周。那个项目前后持续五天横跨了十几个会话涉及接口设计、数据库表结构调整、前端组件方案选型。以前这种项目最痛苦的就是每天开工第一件事把昨天的结论重新复制给 Claude。装上 claude-mem 之后第二天新开会话我故意只丢了一句继续昨天的接口改造Claude 居然能说出昨天确定的字段命名和分页方案还追问了一句是否需要沿用之前排除的 Elasticsearch 方案那一瞬间确实有点震撼。回看记录Claude 之所以能答上来是因为它先调用了 claude-mem 的检索工具拿到了几条高度相关的历史记忆包括我之前拍板用 PostgreSQL 做全文检索的决策、接口返回结构的约定、以及当前版本不做 ES这条排除性结论。这些都是我在前一天的对话里随口说过的内容人类记不住但 claude-mem 记住了。跨会话召回的质量我用一句话总结结论性内容召回准确率很高过程性细节会有遗漏。凡是我们决定 X这种句式基本都能被完整捞回来但之前那个函数里有个边界条件需要注意这种只有代码里才看得到的信息得靠代码本身去提醒记忆库帮不上太多忙。4.2 误召回、旧信息覆盖与新事实写入随着记忆库里的条目越来越多新的问题也出现了误召回。第三条项目里有一个模块叫 payment另外一条记忆里恰好记录了页面支付按钮的颜色从绿色改成蓝色按理说这两件事属于业务逻辑和UI 样式两个维度但语义向量计算相似度时它们因为都涉及支付字样被一起召回了。Claude 拿到这条不相干的 UI 记忆后在讨论支付幂等性时突然冒出一句顺便说支付按钮现在是蓝色有点哭笑不得。这类问题的根源在于向量检索只看语义相似度不区分话题领域。我的缓解办法是调整召回阈值把CLAUDE_MEM_SIMILARITY_THRESHOLD从默认值往上提宁可少召回几条也不引入噪音。另外当一条记忆明显是被后续对话推翻了比如之前定了 A 方案后来你明确说还是用 Bclaude-mem 会更新旧记忆而不是追加新记忆。这个机制很重要不然 Claude 会同时看到两条互相矛盾的方案然后陷入纠结。我还专门测了事后更正的场景第一天说缓存用 Redis第二天改成其实直接内存缓存就够了。新会话里问 Claude 用的什么缓存方案它回答的是内存缓存而不是把 Redis 和内存缓存并列列出。这说明 claude-mem 的覆盖更新逻辑是生效的旧的过期结论没有继续干扰。4.3 多项目混用的串味问题我同时维护两个项目的时候发现了一个必须提前处理的点记忆串味。默认情况下所有会话的记忆都写进同一个 SQLite 文件。项目 A 的接口设计和项目 B 的错误排查会出现在同一次检索里。虽然向量相似度会让他们大概率分得开但总一些边缘情况比如两个项目都用到了登录鉴权这个词结果 Claude 在项目 A 里查登录问题的时候把项目 B 的登录实现也捞了出来给出了一段完全不适用的建议。解决方式很简单为每个项目指定独立的记忆库文件。启动每个项目的会话之前把CLAUDE_MEM_SQLITE_DB_PATH指到对应的路径上。我在.zshrc里为两个项目写了两个 alias一个切到 project-a 的记忆库一个切到 project-b 的。用起来没有任何额外成本但彻底避免了串味问题。5. 踩坑记录数据库膨胀、API 费用与数据安全5.1 SQLite 会无限变大吗记忆库会不会无限增长这是我最早担心的问题。毕竟每天都往里面写时间长了文件越来越大查询时向量相似度计算也可能变慢。实测下来单个项目一天大概产生 100 到 300 条记忆每条记忆的文本加上向量平均占 1KB 左右。也就是说高强度使用一年数据库文件大小大概在 50MB 上下。这个体量对 SQLite 来说完全谈不上压力查询速度依然毫秒级。真正需要留意的是那些每条记忆都带着大段代码片段的情况比如让 claude-mem 把整个函数实现都存进去那一条记忆可能就几十 KB积少成多数据库就会明显变大。我的处理方式是每个月手动跑一次清理把三个多月前的、相似度过高的重复记忆删除掉。claude-mem 提供一个清理命令按时间范围过滤删除操作很直接。不用太担心删错被反复引用过的关键记忆通常都会在最近的会话里再次被写入旧版本删了也无所谓。5.2 每次对话都要付的 embedding 费用claude-mem 不是免费的这一点很少有人提但确实存在。每次写入记忆要调用一次向量化接口每次检索也要调用一次咱们按 token 计费。单次调用费用其实非常低几乎可以忽略不计但如果你把它当默认工具天天高强度使用一个月下来也够买两杯咖啡了。我用了一个月粗算了一下每天约 20 个会话每个会话大约产生 10 次写入和 20 次检索总共 30 次向量化调用。每次调用输入输出都是短文本平均 1000 token 左右。一个月下来约 9 万次调用折合费用在几美元级别。这个成本在我看来完全可以接受换来的是每天省掉大量重新交代上下文的精力。但如果你有预算洁癖可以通过调低CLAUDE_MEM_TOP_K减少检索次数或者把写入频率降下来只保留关键节点的记录。5.3 明文存储与敏感信息防火墙最后说一个很多人忽略的问题SQLite 文件是明文存储的。我的记忆库里曾经记录过一段数据库连接串虽然是测试环境的但它里面明确写了用户名和密码。这意味着任何能读到那个文件的人或程序都能直接看到这些敏感信息。我的建议是给 claude-mem 立三条规矩。第一不记录密钥类内容你可以在配置里加一个敏感词过滤把api_key、password、secret这类字段对应的记忆排除掉。第二生产环境的信息不要和本地开发混在一个记忆库里单独拉一个库或者干脆不记录。第三如果机器的磁盘本身就是加密的那这个风险基本可以忽略如果机器可能被其他人登录记得把记忆库文件权限设成仅当前用户可读写。这些措施不需要一次做完但应该在第一次使用前就有意识。记忆工具本来就是越用越有价值的东西数据越积越多隐私边界问题就会越来越突出提前划一条线比事后补救省心得多。6. 从个人习惯到团队资产claude-mem 的高级玩法6.1 按项目建独立记忆库前面提到多项目串味的时候我说了用不同环境变量指向不同库文件的办法。这个思路再往前一步就是把它当项目资产来管理。我现在给每一个进行中的项目在项目根目录放一个.claude-mem.env文件里面写好这个项目专用的记忆库路径。项目开始前source一下这个文件整个项目的记忆就自动归到独立的库里。配合 Git记忆库文件也可以纳入版本管理——这样团队成员拉下代码的同时就拿到了全套的项目上下文。不过有一点要提醒记忆库里可能包含个人化的思考过程不一定适合全员共享。我目前的做法是只把项目级的技术决策和约定纳入共享把个人偏好、实验性的想法留在本地库。这个取舍标准自己定但一定要定义清楚否则容易把个人笔记和团队资产混成一锅粥。6.2 用定时任务让记忆自动归档claude-mem 默认的写入时机是会话相关事件但如果你想让它更主动地沉淀记忆可以加一个定时任务。我写过一个简单的脚本每天凌晨把当天所有会话记录里超过一定相似度聚类的记忆合并归档减少冗余。用 cron 跑一个命令就能实现比如0 2 * * * claude-mem archive --merge --older-than 1d这样每天凌晨两点前一天的记忆会被自动合并、去重、归档长期下来记忆库会保持清爽。这类归档 合并操作属于维护性质不用盯着它让它自动跑就行。我跑了俩月记忆库的增量明显比之前平滑检索结果也更干净了。6.3 与其他记忆方案对比后的取舍建议聊到这儿顺便说一下 claude-mem 和其他记忆方案的取舍。我见过有人用 LangChain 一类框架里的 Memory 模块也有人自己写一个把历史对话塞进每次请求的脚本还有直接用向量数据库做 RAG 的。这些方案各自的适用场景不太一样。自己写脚本把所有历史塞进去最直接但由于窗口长度限制很难扩展RAG 式向量库方案性能最强但要搭一套外部服务维护成本高claude-mem 胜在轻、无侵入、和 Claude Code 结合紧密。它不是万能的用在高强度、多会话、需要长期上下文的项目上收益最大如果只是随手问几个一次性问题没必要装它。我的个人建议是如果你的工作流里 Claude Code 已经是常态工具而且你有跨会话维护上下文的需求claude-mem 值得一试。装好、配好、用一周再决定是否留下。我第一次用的时候觉得它像是给 Claude 装了一块外置硬盘用到现在这块硬盘已经变成了我项目的一部分——新开一个会话不用重新自我介绍直接说继续它就知道我在讲什么。这份默契值得你花一个下午折腾出来。 
长河君 · 2026/10/26 9:05:01 · 阅读 1.2k claude-mem：为Claude Code装上外置记忆，告别跨会话失忆
如果你用 Claude Code 干过超过一个星期的正经项目大概都有过这种体验昨天刚和它敲定的技术选型今天新开一个会话它像失忆一样重新问你一遍这个项目打算怎么做。不是模型变笨了而是默认状态下每次新会话对 Claude 来说都是一次格式化重启。上下文窗口再大也管不到上一场对话。claude-mem 这个开源工具就是冲着这个痛点来的把对话里真正值得记住的信息抽出来存进本地 SQLite再用向量检索的方式在后续会话里自动想起来。我把这个工具从装到用仔细折腾了一遍这篇文章不打算复述 README而是把记忆机制的底层原理、两条接入路径、一周实测下来的真实表现还有数据库膨胀、API 费用、明文隐私这几个绕不过去的坑一次讲清楚。适合已经把 Claude Code 当日常生产力工具、却被每次都要重新交代背景折磨得不轻的人。1. 每次对话都失忆的 Claude到底缺了什么1.1 无状态 LLM 与真实开发需求之间的鸿沟要理解 claude-mem 的价值先得搞清楚 Claude 为什么记不住事。大语言模型的本质是一个无状态的函数你给它一段输入它根据训练时学到的参数分布生成输出整个过程不保留任何记忆。所谓的多轮对话能力靠的是把前几轮的消息重新拼进输入里一次一次地带着历史往前走。这就像两个人聊天时每个人都得把之前说过的每一句话贴在脑门上说一句贴一句窗口满了就把最早的话丢掉。日常开发恰恰是长周期、多会话、强上下文依赖的活儿。一个功能从设计到上线往往跨好几天期间会有大量讨论、试错、决策变更。你在第一个会话里确定了用 PostgreSQL 而不是 MySQL因为要用 JSONB 做模糊检索第二个会话里让 Claude 写建表 SQL它根本不知道这个决策可能又提了一堆 MySQL 方案。你只能手动把结论粘回去然后祈祷它别忘。这还不算最难受的。更常见的是你在两个终端窗口同时开两个会话一个写后端接口一个调前端样式。两个会话各自为政项目背景、代码约定、命名规范都得分别教一遍。一个人带着一个项目反复当复读机这种体感时间久了真的很消耗耐心。claude-mem 的思路就是在这条鸿沟上搭一座桥会话结束后把关键信息沉淀下来下次需要时自动取回来。1.2 为什么我不建议把记忆塞进 system prompt有人会说记忆问题不是可以用 system prompt 解决吗把项目背景、关键决策、待办事项全部写进去每次新会话开头先读一遍。这个思路方向对但实际操作里有三个硬伤。第一system prompt 有长度上限而且非常珍贵。Claude 的上下文窗口要留给代码、报错信息、工具返回结果这些正在发生的事情你把历史背景占掉一大块留给当轮任务的容量就小了。项目越复杂背景说明越长最后你会发现自己陷入一种诡异的循环写 prompt 的时间比写代码的时间还长。第二手动维护 system prompt 是反人性的。今天改了架构决策明天新增了模块你得记得同步改那份项目说明书一旦忘记Claude 就会基于过时信息给你建议比没有记忆更糟。所有需要人主动维护的方案最终都会因为人的惰性而失效。第三静态文本没有检索能力。你写上十条历史决策Claude 读的时候只能全盘接收没法在当前问题里精准判断哪一条历史信息与此刻最相关——除非你自己指出来。而 claude-mem 这类工具做的正是动态检索不是把记忆全部倒给模型而是根据当前的问题挑出最相关的几条记忆给 Claude 看。这才是记忆和资料堆的本质区别。2. claude-mem 的记忆机制拆解SQLite 存事实Embedding 做召回2.1 记录什么从原始会话里提取值得记的内容第一次把 claude-mem 接进 Claude Code 后我最好奇的一件事是它到底怎么判断什么东西值得记总不可能把每句对话都原封不动存下来吧那样过两天数据库就炸了。实际跑起来就明白了。claude-mem 不是把会话当录音机而是当会议纪要员。它监听会话过程中的关键节点比如 Claude 给出了一个明确的技术选型理由、你拍板了一个接口设计、排查完了一个 bug、定下了一个命名规范这些内容会被抽出来压缩成一条条独立的记忆记录。每条记录包含正文内容、所属项目、创建时间、以及对应的向量表示。我在实际使用里观察到的规律是凡是结论性的、未来还可能被引用的内容基本都会被收进去而那种临时性的、一次性的闲聊会被过滤掉。这个过程涉及一次精炼提取调用一次模型把原始对话浓缩成结构化记忆。数据量上比直接存原文小得多语义上反而更干净。你会发现 claude-mem 记下来的东西往往恰好是你在新会话里最想重新告诉 Claude 的那几句话。2.2 存到哪里单文件 SQLite 和它的向量表存储层claude-mem 选的是 SQLite不是 PostgreSQL更不是专门的向量数据库。这一点我一开始不理解后来想明白了这个选择极其务实。SQLite 是一个单文件数据库整个记忆库就是一个.db文件默认放在用户目录下。对个人开发场景来说这有几个天然好处零运维不用装服务、不用管端口备份即拷贝把那个文件复制走记忆就全带走了查询性能对个人项目的数据量绰绰有余你一天产生几百条记忆一年也就几万条SQLite 处理这点数据毫无压力。向量检索的部分claude-mem 用了 SQLite 的向量扩展能力把每条记忆的 embedding 向量直接存在表里查询时用余弦相似度去匹配。整个方案在够用和轻量之间取了一个很舒服的平衡点。如果你用过专门的向量数据库会发现那个东西确实性能强但为了记录个人项目的对话记忆去部署一套 Milvus 或者 Qdrant完全是杀鸡用牛刀而且平白多了一个需要维护的依赖。2.3 如何想起来查询关键词的向量化召回链路claude-mem 的召回机制是我觉得最值得讲的部分。它不是一个简单的 LIKE 模糊搜索而是完整的向量语义检索。当你在新会话里向 Claude 提问或者 Claude 在处理某个任务时claude-mem 会把当前上下文的关键内容做一次向量化然后在 SQLite 的记忆表里算出每条历史记忆与当前上下文的相似度按分数排序把超过阈值的前 N 条记忆返回给 Claude。在这个过程中相似不是字面上的关键词相同而是语义相近。举个例子。假设你之前记录过一条支付模块的幂等键用了订单号用户ID组合后来你在新会话里问怎么防止用户重复提交订单这两个问题的字面关键词完全对不上但语义上是高度相关的。向量检索就能把它们关联起来。这是 claude-mem 最核心的价值所在——它让 Claude 真的能想起来而不是搜到。完整的链路是三段式写入阶段记忆被提取、向量化、存入 SQLite查询阶段当前上下文被向量化、与存量记忆算相似度、取 Top-N使用阶段召回的记忆以格式化文本的形式注入到 Claude 的对话上下文中提醒它这些历史信息可能对当前问题有用。3. 把 claude-mem 装进 Claude Code两条接线的完整配置3.1 前置条件Node 环境与 API Key先说环境要求。claude-mem 是用 Node.js 写的安装之前你得保证机器上有可用的 Node 运行时版本建议 18 以上。我在 macOS 上装的时候用的是系统自带的 node版本刚好满足要求在 Linux 服务器上装则碰到过 node 版本过老的问题用 nvm 切到 LTS 版本就顺畅了。其次是要有一个可用的 Anthropic API Key。claude-mem 做记忆提取和向量化都要调用模型接口所以这个 Key 是刚需不是可选项。如果你已经在用 Claude Code那这个 Key 应该已经有了直接在环境变量里暴露给它就行。安装本身很简单一条 npm 全局命令的事npm install -g claude-mem装完可以跑一下claude-mem --version确认安装成功。如果公司网络有代理限制npm 源可能拉不动记得先配好镜像源。我第一次装的时候卡在这一步换了 npm 镜像之后秒下完。3.2 接入方式一以 MCP Server 形式挂在工具链上claude-mem 最常见的接入方式是通过 MCP。MCP 全称是 Model Context Protocol你可以把它理解成 AI 应用的USB 接口——Claude Code 通过这些接口去调用外部工具获取上下文。claude-mem 把自己实现成一个 MCP ServerClaude 就能在对话过程中实时调用它的记忆读写能力了。以 Claude Code 为例接入命令大概长这样claude mcp add claude-mem -- npx claude-mem跑完这条命令Claude Code 的 MCP 配置里就多了一个 claude-mem 服务。之后你新建会话Claude 会自动发现这个服务并在合适的时机调用它的工具检索历史记忆、写入新的记忆、更新已存在的记忆条目。这种方式的优势是让 Claude 自己决定什么时候该回忆。你不必手动触发Claude 在对话中如果觉得当前问题和以往记忆可能有关系就会主动调用检索。实际用下来整个体验很接近这个助手真的知道我上次交代过什么而不是一个被动的搜索插件。3.3 接入方式二用 hooks 自动记录每次会话MCP 方式解决了读取记忆的问题但写入记忆这件事我发现有时候会漏。Claude 不会每一次对话都主动把结论存下来这其实挺考验它的主动性判断。为了不依赖这种判断我额外接了一条路径Claude Code 的 hooks 机制。hooks 是 Claude Code 提供的事件钩子可以在工具调用、会话结束等节点自动执行命令。我在配置里加了一个 PostToolUse 的 hook让每次工具调用结束后把当前会话的上下文自动送给 claude-mem 做记录。配置文件大致长这样{ hooks: { PostToolUse: [ { matcher: .*, hooks: [ { type: command, command: claude-mem record --from-hook } ] } ] } }这样写的好处是逢事必记每次关键操作都自动沉淀一条记忆不依赖 Claude 的自觉。缺点是记忆量会比 MCP 方式大不少后续的清洗成本高一丢丢。我现在是两条路径同时开着hooks 负责全量记录MCP 负责按需召回配合下来覆盖得比较完整。提示如果你和我一样同时开两条路径注意看下有没有重复写入。我在一开始配置的时候出现过同一条记忆被记了两遍的情况后来在 claude-mem 的配置项里开了去重问题就消失了。3.4 关键环境变量与权限检查清单配置环境变量是接入过程里最容易出问题的环节我把常用变量整理成了表照着检查基本不会踩坑变量名作用我的建议值ANTHROPIC_API_KEY模型调用凭证记忆提取与向量化都靠它换成你自己的 Key注意别写进公共配置CLAUDE_MEM_SQLITE_DB_PATH记忆库文件位置默认挺好多项目并存时建议显式指定CLAUDE_MEM_MODEL向量化用的模型默认即可追求中文效果可换文本模型CLAUDE_MEM_TOP_K每次召回多少条记忆5 到 10 之间比较稳太多会冲淡重点CLAUDE_MEM_SIMILARITY_THRESHOLD召回相似度阈值0.7 左右太低会带回一堆无关历史权限方面有一个很隐蔽的坑如果你用 hooks 方式接入而 Claude Code 是以某个特定用户身份跑的那 claude-mem 写入 SQLite 文件时需要这个用户对该路径有写权限。我在一台 Linux 服务器上遇到过看起来装好了但记忆永远写不进去的情况排查半天最后发现是数据库文件的所有者和运行用户不一致chown一下就好了。4. 一周实测记忆回填的真实效果和边界4.1 跨会话重提旧事的质量配置完成之后我拿一个真实的项目试了一周。那个项目前后持续五天横跨了十几个会话涉及接口设计、数据库表结构调整、前端组件方案选型。以前这种项目最痛苦的就是每天开工第一件事把昨天的结论重新复制给 Claude。装上 claude-mem 之后第二天新开会话我故意只丢了一句继续昨天的接口改造Claude 居然能说出昨天确定的字段命名和分页方案还追问了一句是否需要沿用之前排除的 Elasticsearch 方案那一瞬间确实有点震撼。回看记录Claude 之所以能答上来是因为它先调用了 claude-mem 的检索工具拿到了几条高度相关的历史记忆包括我之前拍板用 PostgreSQL 做全文检索的决策、接口返回结构的约定、以及当前版本不做 ES这条排除性结论。这些都是我在前一天的对话里随口说过的内容人类记不住但 claude-mem 记住了。跨会话召回的质量我用一句话总结结论性内容召回准确率很高过程性细节会有遗漏。凡是我们决定 X这种句式基本都能被完整捞回来但之前那个函数里有个边界条件需要注意这种只有代码里才看得到的信息得靠代码本身去提醒记忆库帮不上太多忙。4.2 误召回、旧信息覆盖与新事实写入随着记忆库里的条目越来越多新的问题也出现了误召回。第三条项目里有一个模块叫 payment另外一条记忆里恰好记录了页面支付按钮的颜色从绿色改成蓝色按理说这两件事属于业务逻辑和UI 样式两个维度但语义向量计算相似度时它们因为都涉及支付字样被一起召回了。Claude 拿到这条不相干的 UI 记忆后在讨论支付幂等性时突然冒出一句顺便说支付按钮现在是蓝色有点哭笑不得。这类问题的根源在于向量检索只看语义相似度不区分话题领域。我的缓解办法是调整召回阈值把CLAUDE_MEM_SIMILARITY_THRESHOLD从默认值往上提宁可少召回几条也不引入噪音。另外当一条记忆明显是被后续对话推翻了比如之前定了 A 方案后来你明确说还是用 Bclaude-mem 会更新旧记忆而不是追加新记忆。这个机制很重要不然 Claude 会同时看到两条互相矛盾的方案然后陷入纠结。我还专门测了事后更正的场景第一天说缓存用 Redis第二天改成其实直接内存缓存就够了。新会话里问 Claude 用的什么缓存方案它回答的是内存缓存而不是把 Redis 和内存缓存并列列出。这说明 claude-mem 的覆盖更新逻辑是生效的旧的过期结论没有继续干扰。4.3 多项目混用的串味问题我同时维护两个项目的时候发现了一个必须提前处理的点记忆串味。默认情况下所有会话的记忆都写进同一个 SQLite 文件。项目 A 的接口设计和项目 B 的错误排查会出现在同一次检索里。虽然向量相似度会让他们大概率分得开但总一些边缘情况比如两个项目都用到了登录鉴权这个词结果 Claude 在项目 A 里查登录问题的时候把项目 B 的登录实现也捞了出来给出了一段完全不适用的建议。解决方式很简单为每个项目指定独立的记忆库文件。启动每个项目的会话之前把CLAUDE_MEM_SQLITE_DB_PATH指到对应的路径上。我在.zshrc里为两个项目写了两个 alias一个切到 project-a 的记忆库一个切到 project-b 的。用起来没有任何额外成本但彻底避免了串味问题。5. 踩坑记录数据库膨胀、API 费用与数据安全5.1 SQLite 会无限变大吗记忆库会不会无限增长这是我最早担心的问题。毕竟每天都往里面写时间长了文件越来越大查询时向量相似度计算也可能变慢。实测下来单个项目一天大概产生 100 到 300 条记忆每条记忆的文本加上向量平均占 1KB 左右。也就是说高强度使用一年数据库文件大小大概在 50MB 上下。这个体量对 SQLite 来说完全谈不上压力查询速度依然毫秒级。真正需要留意的是那些每条记忆都带着大段代码片段的情况比如让 claude-mem 把整个函数实现都存进去那一条记忆可能就几十 KB积少成多数据库就会明显变大。我的处理方式是每个月手动跑一次清理把三个多月前的、相似度过高的重复记忆删除掉。claude-mem 提供一个清理命令按时间范围过滤删除操作很直接。不用太担心删错被反复引用过的关键记忆通常都会在最近的会话里再次被写入旧版本删了也无所谓。5.2 每次对话都要付的 embedding 费用claude-mem 不是免费的这一点很少有人提但确实存在。每次写入记忆要调用一次向量化接口每次检索也要调用一次咱们按 token 计费。单次调用费用其实非常低几乎可以忽略不计但如果你把它当默认工具天天高强度使用一个月下来也够买两杯咖啡了。我用了一个月粗算了一下每天约 20 个会话每个会话大约产生 10 次写入和 20 次检索总共 30 次向量化调用。每次调用输入输出都是短文本平均 1000 token 左右。一个月下来约 9 万次调用折合费用在几美元级别。这个成本在我看来完全可以接受换来的是每天省掉大量重新交代上下文的精力。但如果你有预算洁癖可以通过调低CLAUDE_MEM_TOP_K减少检索次数或者把写入频率降下来只保留关键节点的记录。5.3 明文存储与敏感信息防火墙最后说一个很多人忽略的问题SQLite 文件是明文存储的。我的记忆库里曾经记录过一段数据库连接串虽然是测试环境的但它里面明确写了用户名和密码。这意味着任何能读到那个文件的人或程序都能直接看到这些敏感信息。我的建议是给 claude-mem 立三条规矩。第一不记录密钥类内容你可以在配置里加一个敏感词过滤把api_key、password、secret这类字段对应的记忆排除掉。第二生产环境的信息不要和本地开发混在一个记忆库里单独拉一个库或者干脆不记录。第三如果机器的磁盘本身就是加密的那这个风险基本可以忽略如果机器可能被其他人登录记得把记忆库文件权限设成仅当前用户可读写。这些措施不需要一次做完但应该在第一次使用前就有意识。记忆工具本来就是越用越有价值的东西数据越积越多隐私边界问题就会越来越突出提前划一条线比事后补救省心得多。6. 从个人习惯到团队资产claude-mem 的高级玩法6.1 按项目建独立记忆库前面提到多项目串味的时候我说了用不同环境变量指向不同库文件的办法。这个思路再往前一步就是把它当项目资产来管理。我现在给每一个进行中的项目在项目根目录放一个.claude-mem.env文件里面写好这个项目专用的记忆库路径。项目开始前source一下这个文件整个项目的记忆就自动归到独立的库里。配合 Git记忆库文件也可以纳入版本管理——这样团队成员拉下代码的同时就拿到了全套的项目上下文。不过有一点要提醒记忆库里可能包含个人化的思考过程不一定适合全员共享。我目前的做法是只把项目级的技术决策和约定纳入共享把个人偏好、实验性的想法留在本地库。这个取舍标准自己定但一定要定义清楚否则容易把个人笔记和团队资产混成一锅粥。6.2 用定时任务让记忆自动归档claude-mem 默认的写入时机是会话相关事件但如果你想让它更主动地沉淀记忆可以加一个定时任务。我写过一个简单的脚本每天凌晨把当天所有会话记录里超过一定相似度聚类的记忆合并归档减少冗余。用 cron 跑一个命令就能实现比如0 2 * * * claude-mem archive --merge --older-than 1d这样每天凌晨两点前一天的记忆会被自动合并、去重、归档长期下来记忆库会保持清爽。这类归档 合并操作属于维护性质不用盯着它让它自动跑就行。我跑了俩月记忆库的增量明显比之前平滑检索结果也更干净了。6.3 与其他记忆方案对比后的取舍建议聊到这儿顺便说一下 claude-mem 和其他记忆方案的取舍。我见过有人用 LangChain 一类框架里的 Memory 模块也有人自己写一个把历史对话塞进每次请求的脚本还有直接用向量数据库做 RAG 的。这些方案各自的适用场景不太一样。自己写脚本把所有历史塞进去最直接但由于窗口长度限制很难扩展RAG 式向量库方案性能最强但要搭一套外部服务维护成本高claude-mem 胜在轻、无侵入、和 Claude Code 结合紧密。它不是万能的用在高强度、多会话、需要长期上下文的项目上收益最大如果只是随手问几个一次性问题没必要装它。我的个人建议是如果你的工作流里 Claude Code 已经是常态工具而且你有跨会话维护上下文的需求claude-mem 值得一试。装好、配好、用一周再决定是否留下。我第一次用的时候觉得它像是给 Claude 装了一块外置硬盘用到现在这块硬盘已经变成了我项目的一部分——新开一个会话不用重新自我介绍直接说继续它就知道我在讲什么。这份默契值得你花一个下午折腾出来。