玩 Claude Code 的人,基本都经历过那种"对话失忆"的崩溃时刻。上周还在一个会话里和 Claude 敲定了整个项目的数据库表结构、目录规范和 API 设计,这周新开一个终端,它一脸茫然地反问你:这个项目到底用不用 PostgreSQL?你只能把之前的代码注释、设计文档甚至聊天记录翻出来,一段段再贴回去。这种重复劳动我忍了很久,直到开始用 claude-mem。
简单说,claude-mem 是一个开源工具,专门给 Claude Code 加一层"长期记忆"。它会把 Claude Code 在终端会话中真实产生过的对话、决策、Markdown 文档自动提取出来,存进本地 SQLite 数据库,再通过 MCP(Model Context Protocol)暴露给 Claude Code 调用。你可以在新会话里直接问 Claude 之前做过什么决定、当时的思路是什么,它基于这些真实记录回答,不再凭空现编。适合谁?只要你是 Claude Code 的重度使用者,或者在跑一个跨多天的中大型项目,又或者想让 AI 辅助开发的过程沉淀成可追溯的项目资产,这套工具都值得花半小时配置上。
下面我从设计思路、原理拆解、实际配置到最后的问题排查,完整过一遍。
1. 这个项目到底解决了什么痛点
1.1 Claude Code 的会话失忆问题
先聊清楚背景。Claude Code 的上下文主要在单个进程内生效,你开一个会话,它会在活跃的 Context 里记住前面的对话,持续几小时到一整天都没问题。但只要你关闭终端,或者新开一个claude会话,之前聊过的内容就基本不在了,除非你引入了外部记忆机制。
这带来的连锁反应很现实:每个新会话你都得重新交代项目背景,重新解释架构决策的来龙去脉,反复粘贴同样的需求文档。更麻烦的是,同一个项目里如果你开了多个终端窗口,A 窗口里讨论的方案,B 窗口的 Claude 完全不知道,两边很容易改出互相冲突的代码。有人会选择把整个项目塞进一个超长会话里硬扛,结果窗口越长,Token 消耗越离谱,回答也越容易飘,因为上下文一长,模型对细节的注意力就会下降。
所以问题的本质是,Claude Code 本身缺少一个"显式、可查询、跨会话"的记忆层。你不去看看,它就丢了;你想找回来,只能靠人工搬运。claude-mem 就是在这个缺口上长出来的工具。
1.2 claude-mem 在记忆工具链里的定位
现在 AI 记忆方向的工具其实不少,比如 Mem0、Letta(原 MemGPT)、OpenMemory 这些。它们大多是通用型的,思路是给大模型加一个"外挂大脑",服务各种 chat 应用和 agent 框架。claude-mem 的定位更窄,也更专——它只围绕 Claude Code 这一个生态来解决问题。
claude-mem 做对了几件事。第一,数据源是"真实发生过的东西",它读取 Claude Code 在本地留下的会话缓存和生成过的 Markdown 文档,而不是让模型凭空"描述记忆",所以提取出来的信息可信度高。第二,存储设计成本地优先,一条记忆写成一行记录放进 SQLite,没有后端服务,不需要 Redis 或者云数据库。第三,提供 MCP server 作为桥接层,Claude Code 原生支持 MCP,接入后 Claude 可以主动调用记忆查询工具,不需要手动切出去搜文件。
这种"会话记录 → 结构化提取 → 本地落库 → MCP 暴露"的链路,本质上是把 AI 编程工具产生的过程资产沉淀下来,变成可复用的长期记忆。它不是让 Claude 变聪明,而是让你的项目经验不再随着终端关闭而蒸发。
2. 核心设计拆解:记忆怎么存、怎么取
2.1 MCP 桥接:给 Claude Code 插上外接记忆
MCP 这套协议,很多人第一次听觉得玄乎,其实类比成"USB 接口"就好懂了。Claude Code 是主机,MCP server 就是外设。你想给它插个记忆硬盘、插个文件浏览器、插个数据库客户端,只要外设实现了 MCP 协议,主机就能直接调用它的能力。
claude-mem 把自己实现成一个 MCP server,启动方式是claude-mem --mcp,然后通过标准输入输出和 Claude Code 通信。在 Claude Code 这边,它相当于多了一组工具,常见的有搜索记忆、插入记忆、列出记忆、删除记忆等。你在对话里说"查一下我们上周定的错误码规范",Claude 收到指令后会调用搜索工具,把 SQLite 里命中的记忆取回来,再结合当前上下文回答你。
为什么走 MCP 而不是直接用脚本切片?因为 MCP 让记忆变成了"可被对话自然触发的能力"。你不需要记住一串 CLI 命令,也不需要复制粘贴文件内容,记忆查询这件事被融入到了和 Claude 的日常协作里。这也是 claude-mem 体验上最顺滑的地方。
2.2 本地优先的 SQLite 存储
选 SQLite 做存储,我是举双手支持的。深度学习场景不需要高并发,就是自己一个人或一个小团队在本地跑,SQLite 单文件、零运维、还支持 SQL 查询,比什么 MySQL 后端起一个服务要轻太多了。
表结构大概围绕"记忆条目"来组织,一个典型字段会包含记忆内容、来源(哪个项目、哪个会话、什么时间)、类型(对话摘要、Markdown 文档、决策记录等)。我实际用下来的感觉是,它更像一个"结构化的日志仓库",每一条记录都带着来源上下文,而不是把对话原文一骨碌倒进去。这样做有一个额外好处,就是当你需要回溯某条决策的来龙去脉时,可以直接回到来源会话或者源文件去确认,这对技术审计很有价值。
2.3 语义检索与关键词检索的取舍
记忆存了就得能找回来。claude-mem 在搜索上做的是语义检索,核心思路是给每一条记忆生成向量(embedding),查询的时候把用户问题也转成查询向量,然后算相似度,找出最相关的几条。这里用到的 embedding 能力可以来自 OpenAI 的 API,所以在环境变量里配置OPENAI_API_KEY。
为什么不用普通 SQL 的LIKE '%关键词%'全文匹配?因为关键词匹配只能命中字面一样的词汇。举个例子,你之前写过"会议纪要里记录了容灾切换的 RTO 要求",过几天你问的是"故障恢复时间目标是多少",字面上完全对不上,但语义上其实是一回事。向量检索的好处就在于它理解意思相近的表达,哪怕用词不同,也能把那条记忆捞出来。
代价也很明显,就是每次搜索或者每次新增记忆都要调用一次 embedding API,会有 Token 消耗和网络延迟。后面讲排查问题时,我还会专门说这个环节容易踩的坑。
3. 实操:从安装到接入 Claude Code
3.1 前置环境要求
先说环境,免得你装到一半卡壳。
claude-mem 主体是 Node.js 写成的,通过 npm 全局安装,所以我建议你先把 Node.js 升到 18 以上,老版本跑起来容易报各种奇怪的兼容性错误。部分功能会用到 Python 脚本处理 Markdown 解析,Python 3.9 以上的环境建议备好。还有一个硬性条件是OPENAI_API_KEY,因为记忆的向量化依赖它。你提前检查好这三样,后面基本一路畅通。
3.2 安装与 MCP 接入的两种方式
安装本身很简单,一句话:
npm install -g claude-mem装完以后,关键是把它注册成 Claude Code 的 MCP server。这里有两个路径,一个是用项目提供的一键注册脚本,实际执行时会自动帮你在 Claude Code 配置文件里写 MCP 条目,命令类似:
claude_mcp_add claude-mem另一个是手动加,你打开 Claude Code 的 MCP 配置文件(项目里的.mcp.json或者用户级配置文件,具体取决于你用哪种方式管理配置),加入这样一段:
{ "mcpServers": { "claude-mem": { "command": "claude-mem", "args": ["--mcp"] } } }我个人的建议是,如果版本支持手动配置,优先手动写,因为你能清楚地看到 Closde Code 到底加载了什么命令,排查问题也方便。用一键脚本省事,但有时候你没注意到 Node 全局路径没进环境变量,后面 MCP server 就会一直启动失败,比手动配置更让人头大。具体命令以你当前安装版本仓库里的 README 为准,不同小版本可能有差异。
3.3 功能验证与基础命令
配置完之后,重开一个 Claude Code 会话,输入以下命令确认 MCP 工具已经挂上:
claude mcp list如果列表里能看到 claude-mem,说明桥接成功。这时候你在对话里试探一句"试试搜索记忆里的 RTO 相关记录",Claude 如果能调用工具,说明检索链路已经通了。
命令行里也有一套手动管理命令。claude-mem init用来初始化数据库和数据目录,claude-mem search "你想找的内容"可以在终端直接搜索记忆,不需要打开 Claude。claude-mem list列出全部记忆条目,claude-mem delete指定 ID 删除某条记录。这些命令配合起来,基本上可以做到不进 Claude Code 就能对记忆库做全量管理。
4. 数据从哪来:Claude Code 会话的自动提取
4.1 解析 cached_sessions 与 Markdown 记录
claude-mem 的一个特点,是它不需要你手动开启记录,它会自动去读 Claude Code 留在本地的会话缓存。
Claude Code 每次运行的时候,默认会在用户目录下的.claude相关目录里按项目保存会话历史,典型的路径像~/.claude/projects/<项目名>/,里面会有会话记录文件以及 Claude 在过程中生成的各种 Markdown 输出。claude-mem 会定期扫描这些目录,把其中的关键内容提取出来,拆成一条条记忆入库。这个机制相当于"事后复盘":你正常干活,它默默在旁边做笔记,然后整成结构化的记忆。
这里我要提醒一句,它的数据源是真实记录,不是模型脑补出来的回忆。所以如果你发现某条记忆内容和你当时实际做的决定有出入,多数情况是提取逻辑把长文中不重要的句子也收进去了,你可以直接删掉那条记忆,不要让错误信息残留太久,否则后面对话 Claude 会基于错误记忆给你建议。记忆的质量要自己把控。
4.2 手动触发与增量管理
扫描提取通常是自动触发的,间隔也会有一些限制。如果你刚结束一个高强度会话,想让新的决策立刻进入记忆库,可以手动跑一次更新命令触发增量提取,不用傻等下一次自动触发。
增量管理这块,我比较推荐你每周花几分钟过一遍记忆列表。因为数量多了之后,你会发现有些记忆其实是过期的,比如依赖版本升级了、表结构改了、旧的决策被推翻了。这时候及时删除或标记过期,能避免 Claude 在推荐方案时拿旧闻当新闻。删除就用claude-mem delete <id>处理即可。
5. 常见问题与排查实录
5.1 MCP 连接不上或搜不到记录
这是我遇到最多的一个问题。MCP server 启动失败,十有八九是 Node 全局安装路径没进 PATH。npm 全局命令默认装到%APPDATA%\npm(Windows)或/usr/local/bin(macOS)这类目录,gz 全局路径设置不当时,Claude Code 里启动claude-mem --mcp会直接找不到命令。
排查顺序是:先在终端手动执行claude-mem --mcp看能不能跑起来,如果终端能运行而 Claude Code 里不行,基本是 PATH 问题;如果终端里也报错,就去看 Node 版本和依赖有没有装干净。另一个容易漏的点是,修改配置后必须重启 Claude Code 会话,否则 MCP 不会重新加载。
5.2 embedding API 配额与网络问题
语义搜索依赖 OpenAI API,那问题就跟着来了。如果你账号是新号,并发额度比较低,一次性写入大量记忆时,embedding 请求会撞上限流,轻则变慢,重则写入失败。
我的应对方法有两条。第一,控制单次写入的规模,不要一次性导入超大量历史记录,分批跑更稳。第二,给环境变量配上更宽松的超时时间,网络不稳定时不要立刻失败重连。另外,公司网络如果访问 API 受限,这一类环境问题会直接影响搜索功能,建议自查网络连通性再排查逻辑。
5.3 查询出来的记忆不相关
搜索质量不好,别急着怪工具,先反思你的提问方式。语义检索不是关键词匹配,问题描述得越具体,结果越准。比如你搜"数据库"可能返回一大堆泛泛的记录,但搜"订单表的分库分键方案"就精准很多。
另外,很多记忆条目是从长对话里切出来的,可能本身就带了不少上下文噪音,这时候筛选重点就很重要。如果某类记忆频繁出现、长期有效,建议你在 Claude Code 里把核心决策单独整理成一份 Markdown 文档,claude-mem 会扫描这类文档,它们往往是搜索结果里最干净、最有用的一部分。
5.4 数据膨胀与隐私清理
随着项目越做越大,SQLite 文件会膨胀,检索性能也会缓慢下降。别担心到爆炸,定期用删除命令清理过期条目就行,你还可以把某段时间之前的记录一锅端掉。说句实话,很多人担心所谓隐私问题,我更关心的是不要把敏感的生产密钥或内部系统地址写进对话里。claude-mem 存储是在本地,但一旦你让它提取记忆并汇入公共仓库或上传到云端备份,风险就变大了。最好的习惯是,如果你在对话里提了敏感的 token 内容,结束后立刻删掉对应的记忆记录,别留隐患。
6. 个人使用心得与项目沉淀建议
用 claude-mem 这段时间,我最大的体会是它把"和 AI 协作开发"这件事从单次会话的即时体验延伸成了一个长期资产库。以前我做一个跨周项目,需要维护一份长篇 README 记录各种决策,现在 README 照写,但 Claude 自己能记住的东西变多了,很多重复解释的环节被省掉,效率提升是很直接的。
最后再分享一个小技巧:如果你在团队里协作,记得让每个成员都接入同一个存储目录(把数据目录指向共享位置),大家就能共享同一份项目记忆。跨设备场景下也可以实现类似效果。不过要提醒,共享记忆的前提是项目本身允许这种数据沉淀方式,涉及敏感信息的项目建议谨慎开启共享。反正这套工具是个开源生态,可定制空间很大,你可以按团队规范来调,重点是先把它跑起来,让记忆开始流动。