说实话我第一次用Claude Code的时候印象最深的就是它能记住当前窗口里的对话状态保持得很好。但一旦关掉终端第二天重新打开它就像失忆了一样之前聊的技术决策、写好的接口规范、约定好的目录结构全得重新讲一遍。短一点的项目还好忍忍就过去了稍微长线的项目每天光重复说明上下文就占了大半窗口。后来我找到了claude-mem一个给Claude Code增加长期记忆的MCP工具。折腾了两天现在基本离不开它了。这篇文章我不打算写成官方文档的翻译就从一个实际使用者的角度把我配置的过程、理解的核心机制、踩过的坑和现在的工作流完整梳理一遍。1. 为什么Claude Code会用着用着失忆claude-mem要解决的痛点1.1 上下文窗口再大也装不下跨会话的长期记忆先讲清楚问题的本质。Claude Code这类AI编程工具能力再强工作模式也是当前会话有效。它能看到的内容只有当前上下文窗口里排进去的对话历史、文件内容和工具返回结果。窗口一旦关闭这些内容就没了。这就好比一个记忆力正常但每次上班都会失忆的同事——你昨天和他对齐的需求今天他完全不记得了。有人可能会说那我把需求都写进项目里的README或者docs文档不就行了这也是一种办法但有两个问题第一写文档本身是负担。开发节奏快的时候谁有空把每个决策都整理成文很多时候对话里说清楚了脑子也记住了但文字没有沉淀下来。第二就算写了文档AI也不会主动去读。除非你在会话里明确把文档路径告诉它或者它觉得有必要才去翻。实际用下来Claude Code更倾向于直接读代码文件很少主动去翻你的历史文档。1.2 claude-mem是个什么东西claude-mem本质上是给Claude Code装了一块外接硬盘。它通过MCPModel Context Protocol模型上下文协议把过去对话里的内容存下来然后在合适的时机重新注入Claude的上下文里。我理解它的核心思路就三步每次对话过程中把值得记的东西提前存下来比如标识符、命令、项目偏好。对话结束后把完整对话提炼成记忆条目落盘成一个JSONL文件。新会话开始时基于你当前说的内容做相关度匹配把相关的历史记忆调出来塞进上下文。这么一来Claude Code就不只是当前会话容器了它背后多了一个会翻历史记录的助手。我第二天把它喊起来的时候它会隐约记得我们昨天聊过什么。1.3 适合谁来用我身边用这个工具比较多的人一般就三类长期项目开发者一个项目跨几周甚至几个月中间有大量之前说好的这种隐性约定。做多项目并行的人好几个仓库来回切每个项目都有自己的技术和风格偏好单靠脑子记容易串。重度依赖AI编程、但希望质量稳定的人AI有记忆之后写出来的代码更连贯不用每轮重新解释背景。如果你只是偶尔用Claude Code写个一次性脚本那claude-mem对你的价值有限。但只要你连续几天在同一个仓库里干活你早晚会遇到它怎么又忘了的瞬间。2. 安装与配置让记忆功能在一小时内跑起来2.1 环境准备和安装方式claude-mem对运行环境要求很宽松只要有Node.js和Claude Code就能跑。Node版本我用的2018应该都没问题。安装方式有两种一种是通过Smithery安装一套命令自动配好另一种是手动加MCP服务器配置灵活度更高也方便排错。我用的是Smithery方式因为它会把MCP配置直接写进Claude Code的配置文件里省掉了手动查路径的麻烦npx -y smithery/cli install claude-mem --client claude-code --interactive之后按提示指定项目的源目录路径就行。这里的源目录路径是指你希望claude-mem去扫描哪里的对话如果你是按项目隔离的填当前项目根目录最合适。安装完后Smithery会在你的~/.claude.json里加一条claude-mem的配置。如果你不想借助Smithery手动配置也完全不麻烦。先在项目里装依赖npm install -g claude-mem然后在Claude Code的MCP配置文件里注册这个服务器。配置内容大致是{ mcpServers: { claude-mem: { command: claude-mem, args: [--source, /path/to/your/project/history], cwd: /path/to/your/project } } }注意--source指向的是Claude Code存储会话历史的位置一般是~/.claude/projects/目录也可以指定到具体的项目子目录。如果你只需要记忆某一个项目就把路径收窄一点。2.2 配置MCP服务器时的几个细节配置MCP服务器有几个小坑我第一天就踩了两个。第一个是Windows环境下的路径问题。claude-mem命令在Windows上需要通过cmd /c claude-mem才能正常被Claude Code唤起直接写命令名有时候会报找不到。Smithery安装时它自己处理了这点手动配置的话要留意。第二个是MCP服务器的启动时机。Claude Code启动时会自动拉起注册好的MCP服务器claude-mem会自动运行并开始加载记忆。如果你配置完没生效多半是Claude Code没重启旧的MCP连接还留着。重启一下会话就能看到效果。2.3 验证是否配置成功配置完成后在Claude Code里输入/mcp回车会列出已加载的MCP服务器列表。能看到claude-mem状态为connected就说明配置成功了。更直接的验证方法是问Claude一句根据你的记忆我们昨天关于数据库表结构是怎么定的如果它能从claude-mem捞到历史记录就说明整条链路已经通了。我第一次配置完问它这个问题它回了一段我们三天前讨论过的索引设计内容那一刻是有被惊喜到的。3. 记忆库的核心架构llm_command、tool_use这些表到底在干什么3.1 记忆存储方式和检索逻辑claude-mem不是把记忆存在云端的它在本地维护了一套SQLite数据库。每个来源目录对应一套记忆库里面的表结构是设计好的不是简单的对话日志堆一起。为什么用SQLite而不是直接搜文本文件我理解核心原因是需要快速做相关度匹配。新的大型语言模型提示进来的时候claude-mem需要快速找出与此前哪一段记忆最相关纯文本逐行扫效率太低SQLite里预计算好向量和关键词索引查起来快得多。这里的关键机制是每条记忆除了原文还会存储对应的嵌入向量。新会话里用户说的话会先被转成向量然后用相似度算法典型的是余弦相似度在记忆库里检索挑出最相关的那几条注入上下文。这个逻辑跟RAG检索增强生成的常规套路是一致的。3.2 核心表清单和各自职责我看它的源码和实际使用后的理解核心表大概是这么几张llm_command每次用户输入的指令经过规范化后的记录。它存的是用户说了什么的标准形态是检索的主入口表。monologueClaude在思考过程中的长段推理记录。AI的工作流里有大量内心戏这部分被单独沉淀下来后续可以复用思考路径。evidence与每条monologue对应的具体证据例如它得出某个结论时的代码片段、输出结果片段等。这相当于AI做出判断的依据。tool_use每一次工具调用的JSON快照。Claude Code会频繁调用各类工具读文件、执行命令、搜索等这些调用记录都会被记下来。output每次工具调用的输出结果以及对应的token计数。token计数很重要它能让claude-mem在注入上下文的时候知道这条记忆有多大。related_queries用户问的不同问题之间的关联关系。比如你第一天问了怎么处理超时重试后来又问请求总是超时怎么办这两个query会被关联起来。user_query用户的历史查询记录用于还原对话场景。我一开始看这个表设计会觉得很复杂后来想明白了它本质上是把一次完整的AI交互过程切成了输入→思考→行动→结果四层每一层都会被记录下来。这样后续找回的不只是一个结论而是当时为了解决这个问题AI思考了什么、调了什么工具、得到了什么输出的完整链条。3.3 为什么这套设计比单纯记聊天记录更实用直接记录聊天记录不是更好我也想过这个问题后来发现在AI编程场景里聊天记录本身的信息密度不够。比如你问它帮我优化一下登录鉴权它回复一长段思路然后调了三个工具改了四个文件。如果你只存聊天内容那当时它具体改了哪些文件、改了什么、哪个文件出错被它纠正了全都没有记录。可恰恰是这些工具调用和输出结果才是后续最有价值的记忆。claude-mem把工具调用和输入输出都落表意味着下次你提到登录鉴权时它能从tool_use和output表里捞到上次改过的文件清单和改动要点这就能非常具体地告诉Claude上次我们改的是auth模块的这两个文件方向是把token快过期时的续期逻辑提前。这种级别的记忆单纯存聊天记录是给不了的。4. 日常使用指南从回忆对话到主动存档的完整命令流4.1 discover搜索你的历史对话claude-mem discover有几个不同层级的用法。最简单的直接列出所有历史对话骨架claude-mem discover输出是一份按时间分组的对话摘要列表包含时间戳、话题标题和关键点。这样你能快速看到过去几周里和Claude聊过哪些主题。想深入看某一个主题时加上主题参数就能看到那次对话的完整内容。比如我们之前讨论过Oracle数据库相关的问题我用claude-mem discover oracle它立刻把涉及oracle的几轮对话摘出来还标注了大致日期。这个命令适合做复盘项目中期想回看这个方案当时是怎么定下来的用它一查就有。4.2 remember主动让Claude记住重要信息discover是检索已有的记忆remember则是主动写入记忆。这个命令非常有意思它的用法不是你自己输入而是让Claude调用工具来执行。正常流程是当Claude Code的对话里出现值得长期保留的内容时你可以对它说记住这一点claude-mem就会自动把当前讨论的重点提炼成一条记忆条目。我在实际使用中会主动让Claude记住以下几类信息项目约定比如后端统一用FastAPI不要引入Django。部署细节比如线上环境的数据库连接字符串放在.env.production里不要硬编码。代码风格约束比如工具函数统一放在lib/utils目录。要说明的是这里的记住不是简单把这句话存进去而是会结合当时对话的上下文提炼出一条结构化记忆。后续注入上下文时这条记忆会以更紧凑的形态参与匹配。4.3 forget忘掉不该记住的东西记忆太多也不全是好事forget就是用来做清理的claude-mem forget 记忆内容或ID它会先从记忆库里搜索出与该内容相关的记忆条目然后你选择要删除哪条。删除是直接从数据库里移除不是打标记所以删除前最好确认一下。我一般在以下情况用它临时调试时的方案被我当成长期约定存进去了换了技术方向后旧的规定不再适用以及有些敏感信息不小心存进记忆需要彻底清除。4.4 archive归档而不是删除archive对我来说是比forget更常用的命令。它会把指定记忆标记为归档状态不参与常规检索但还留在数据库里需要时仍可翻查。比如一个项目已经结项了但它的一些技术约定未来可能还用得上归档就很合适。这样新项目启动时不会被旧记忆干扰万一回头再查旧项目的方案数据都还在。我理解这个命令的设计动机AI的记忆不是越多越好相关度高、时效性强的记忆才有价值。归档就是做降噪让那些曾经重要但现在并不活跃的信息退居二线。4.5 记忆自动注入上下文的工作流程claude-mem最优雅的一点是日常使用中你不需要频繁手动调用命令。当你在Claude Code里开始新的对话时claude-mem会自动读取你当前输入的内容。在记忆库里做相似度检索。挑出相关度最高、且时间上比较近的记忆。在后台把这几条记忆以内部上下文的形式注入给Claude。所以你第二天的对话一开始Claude就带着前几天的记忆上线了。这种自动关联的效果比每次手动在对话开头补一句背景描述要顺畅得多。但要注意自动注入不是全量注入它是有选择性的。相关性越低或者时间越久的记忆被带出来的概率就越小。这其实是一个很合理的策略——只带最相关的内容避免上下文被大量历史信息污染。5. 实战场景拆解跨会话开发一个项目时记忆如何真正派上用场5.1 场景一中断三天之后继续开发我在做一个内部管理系统的时候前端页面结构、后端接口风格、数据模型都已经和Claude对齐好几天了。中间获得了一个新的需求我停下手头的开发去处理三天后回来继续。如果没有claude-mem打开Claude Code那一刻它只会看到当前目录下的文件完全不知道我们之前在聊什么。我大概率要花很长时间把之前定下的方案重新说一遍目录结构、命名规范、状态管理方式、后端接口的返回格式等等。有claude-mem之后我只需要在Claude Code里输入继续之前的工作先看一下我们之前定的前后端接口规范。它会立刻从我历史对话里找到相关条目不仅回忆起接口规范可能连当时设计的请求响应结构、错误处理方式都带出来了。这节省的不仅仅是重述时间更重要的是避免了两次叙述不一致造成的信息损耗。5.2 场景二多个项目间切换时防止串味我同时维护两个项目一个是Python写的后端服务另一个是Node.js写的工具链。如果这两者的技术偏好都被塞进同一个记忆库那Claude在Python项目里写Node代码还自以为是正常的。claude-mem的思路是通过--source指定不同的路径来隔离记忆库。不同项目配不同的MCP服务器实例记忆不会混到一起。我是这样做的给两个项目分别配了不同的source路径用同一个claude-mem服务器但指定不同参数。这样在A项目里聊的约定完全不会渗透到B项目。5.3 场景三把当时为什么这么做找回来开发过程中最容易被遗忘的其实是决策动机。代码文件还在但当时为什么选择用消息队列而不是直接HTTP调用、为什么把某个字段设计成冗余存储这些决策过程只存在于对话里。claude-mem的monologue和evidence表恰好能把这类上下文保留下来。有一次我在改一个旧模块看到一段让人困惑的代码就问了Claude一句这段逻辑为什么这么写是我们之前讨论过的吗它通过相关记忆检索翻出了我们一周前讨论过的场景——当时是为了处理某个边界条件才引入的这段逻辑。这个回忆过程帮我省下了大量逆向推理的时间。5.4 使用中的效率对比这是我个人体感上的对比没有严格量化但很有参考价值之前开启新会话平均需要花10到20分钟重新同步项目上下文。使用claude-mem后同步时间压缩到2分钟内前提是历史对话确实把关键信息聊到位了。中间切换项目的恢复速度从重新讲一遍变成了输入一句继续它就懂了。如果你也在做长周期项目这几个场景应该很有共鸣。6. 我用下来的踩坑记录与几点使用建议6.1 记忆不生效先检查这几处最影响体验的问题就是配好了但感觉它没记忆。我总结过排查顺序第一检查MCP服务器状态。在Claude Code里输入/mcp确认claude-mem是connected而不是failed。如果failed大部分情况是路径配置有问题或者Node版本不兼容。第二检查source目录是否正确。如果source指错了目录它读取到的历史对话就是空的自然什么也记不住。可以用claude-mem discover直接测试能否搜出内容。第三确认Claude是否主动调用了claude-mem的工具。早期版本里自动注入的触发条件没有那么灵敏需要用户在对话中明确提出查看记忆的要求。如果你发现完全没有任何自动记忆的迹象可以主动说查看你的记忆库看它是否开始调用claude-mem相关工具。6.2 记忆库膨胀之后怎么办我跑了大概三周后记忆库已经不小了。最直接的表现不是慢而是自动注入时相关记忆太多上下文被撑得很长反而稀释了重点信息。Claude有时候会从记忆里挑出好几条看似相关但实际帮助不大的内容。这个问题我现在的处理方式是定期归档。每周抽5分钟把已经完成的任务、不再活跃的话题归档掉。核心目标是让检索范围里只保留最近活跃且仍然重要的记忆。另外在对话里也要注意清理。有时候对话里产生了临时性的调试方案我明确会说这个不要记住。比起事后清理控制来源更省力。6.3 结合个人工作流的几点使用建议根据我自己的实际体验有几条建议可能对第一次用的人有价值第一主动喂记忆要尽早习惯。很多人在用claude-mem时只依赖自动记录但自动记录是广撒网难免漏掉一些隐含约定。凡是你在对话中明确做出的决策我都建议补一句记住这个。第二不要等积攒了太多再整理记忆。两三天整理一次是合理的节奏主要是清理临时性内容、归档已完成话题。积攒太久之后连你自己都分不清哪些还有价值。第三给不同项目做隔离。多项目开发者一定要用不同的source路径隔离记忆。临时混用会让你在写A项目时被B项目的历史干扰那种串味的体感很糟糕。第四善用discover做项目复盘。它是很好的周报素材来源。我每次周报都能从里面翻出来这周和Claude讨论过的所有问题密密麻麻列一串基本不用额外记日志。6.4 关于记忆与隐私的边界claude-mem默认把记忆存在本地SQLite数据库里对话内容不会上传到第三方服务器。对于内部项目来说这个设计比较稳妥。但有一点要提醒如果某个对话里包含密钥、密码、个人敏感信息尽量别让它进入记忆库。就算存了也要记得用forget彻底删除。我的一般做法是凡是涉及生产环境密钥的讨论从来不在Claude Code里展开哪怕它会自动记住。最后再分享一个小技巧claude-mem在保存记忆文件时附带的ASCII艺术作品还挺有意思的你可以留意一下~/.claude-mem/目录下的内容偶尔翻翻也算另一种形式的项目日志了。