我先说一个很现实的问题哪怕你天天在用 Claude Code它也记不住你昨天让它改过的代码。每次新开一个会话它都像第一次见到你一样客客气气问“请问你想让我做什么”。对一次性提问没影响但对跨天的项目、连续的调试、长期的技术方案来说这个“失忆”真的能把人逼疯。我在 GitHub 上看到 claude-mem 这个开源项目的时候第一反应是终于有人把这件事做成正经工具了。claude-mem 是一个给 Claude 提供持久记忆的 MCP 服务器底层用 SQLite 存数据Claude 可以在会话过程中主动往“记忆库”里写东西下次新会话再把这些内容捞回来用。它解决的不是“多轮对话里能不能记住上文”而是“跨会话、跨项目、跨时间Claude 能不能像老同事一样记得你的偏好和项目脉络”。这篇文章我会把它的原理、安装配置、实际使用中的坑以及我对它边界的真实感受都写一遍适合正在用 Claude Code、或者想把 Claude 用在长期项目里的朋友参考。1. Claude 没有记忆不是简单的“忘了”1.1 三个让我崩溃的真实场景先具体说一下被“失忆”折磨的过程。第一个场景发生在一次 API 服务重构里。我第一天下午让 Claude Code 把某个模块从 Flask 改成 FastAPI并且把路由风格统一成 RESTful 规范当时它做得挺好。第二天早上我想让它接着改下一个模块于是新开了一个会话结果它来了一句“我没有看到你之前改过的代码请告诉我哪个文件需要处理。”我不得不把整个项目结构、改动范围、第一天定下的规范重新贴一遍。等于第一天下午讨论出来的东西第二天全清零。第二个场景跟个人偏好有关。我写 Python 的时候有一个非常具体的习惯import 必须按 stdlib、第三方、本地模块分组类注释写特定格式异常处理宁可多写一个 logger 也不静默吞掉。这种偏好我几乎每隔几天就要重新跟 Claude 解释一次。一次两次还能忍时间长了真的烦躁。明明这些规则完全具备“沉淀”的条件但每个新会话都是白纸一张。第三个场景最坑是跨会话的技术决策反复。一个项目进行到中期我让 Claude 在前端技术选型上给个结论。第一天它建议用状态管理库 A第二天我发现库 A 的学习成本太高让它换库 B到了第三天它又建议回到 A因为它根本不知道第二天我们已经推翻过 A。这种“忘记自己在上一轮已经拍板过什么”的问题会让项目在同一个坑里反复横跳个别情况下还会越改越乱。这三个场景是 claude-mem 诞生的最直接动机Claude 本身是强大的工程师但它没有“项目记忆”。你给它上下文它就能干活你不给它就只能靠猜。1.2 把提示词塞满 System Prompt是条死路有人可能会说既然它记不住那我每次把规则写进 System Prompt 不就行了我确实试过而且试了很久这条路本质上走不通。第一是成本问题。System Prompt 每轮对话都要作为输入 token 被计算你塞 2000 字进去短时间看着没事连续聊几十轮之后那是一笔很实在的开销。第二是稀释效应。当 System Prompt 里的背景信息越来越多真正关键的任务指令就会藏在一堆冗长的偏好描述里模型对相关信息的注意力反而不集中回答质量会下降。第三是硬上限。Claude 的上下文窗口再大也是有限的规矩、背景、示例、历史结论全堆在里面迟早有爆的一天。到了那时候最先被挤掉的反而是最重要的早期决策记录。所以结论很清楚把记忆硬塞进“对话上下文”不是可持续的方案。真正的记忆应该独立存在需要的时候拿一部分出来用用完了再放回去而不是全程占着地方。1.3 记忆不该放在“提示词”里而该放在“记忆库”里想明白这点之后思路就变了。Claude 需要的不只是更长的上下文而是一个可以在会话之外持续写入、持续读取的“外部存储”。这个外部存储要能满足几个条件Claude 在会话过程中能主动把重要信息写进去新会话启动时能快速检索到相关内容不会因为对话结束而丢失读写成本足够低不会严重影响对话效率。这就是 MCPModel Context Protocol服务器最合适的用武之地。MCP 可以理解成一个标准化的“外部工具接口”Claude 这种模型客户端不需要知道记忆具体存在哪里只需要通过协议调用工具就能完成“存一条记忆”“查一批记忆”的操作。claude-mem 正是以 MCP 服务器的形态出现的这也是它在设计上最聪明的地方——它不尝试改造模型本身而是给 Claude 接了一个独立于会话的“外脑”。2. claude-mem 的“记忆”到底是怎么实现的2.1 它不是一个聊天框是一个 MCP 服务器很多第一次接触这个工具的人会误解以为 claude-mem 是个聊天界面或者插件。它不是。它是一个独立运行的进程通过 MCP 协议和 Claude Code 这类客户端进行通信。你可以把 MCP 想象成 USB-C 接口设备只需要遵循同一个标准就可以接上各种不同的外设。Claude Code 是设备claude-mem 就是接上去的“记忆外设”。Claude 在对话中会收到一组额外的工具比如“保存记忆”“搜索记忆”“获取记忆概览”当它判断当前信息值得记住时就会主动调用这些工具写入数据库当它需要回顾过去的上下文时就通过搜索工具把相关记录拉回来。这个设计有个直接好处记忆的读写是和具体对话解耦的。你在会话 A 里写入的内容会话 B 完全可以读到因为它们共用同一个 SQLite 数据库而不是共享同一段上下文。2.2 记忆库里到底存了哪几类东西我实际用过之后发现 claude-mem 的记忆组织方式可以大致分成几类用户偏好比如代码风格、命名习惯、常用工具链、回答问题的语气。这类信息通常具有全局性任何项目都能用。项目事实比如某项目采用了什么架构、模块之间怎么依赖、哪些目录是核心代码。这类信息服务于特定项目的长期维护。会话摘要每个会话结束或被触发时系统会生成一段摘要记录这个会话里完成了什么、决定了什么、遗留了什么。这些内容不是混成一团的而是按一定的结构和标记存进 SQLite方便后续搜索和过滤。从使用体验上说Claude 在收到一个跨会话任务时会先去查项目事实和用户偏好而不是一股脑把所有历史消息翻出来。2.3 写入和读取的完整链路我跑起来之后观察它的行为整个过程大概是这样的在会话过程中Claude 如果确认了一条值得长期保存的信息比如“项目使用 pnpm 作为包管理器”它会调用一个类似“记忆保存”的工具把这条信息写入数据库。这个写入动作不是存储整段对话文本而是存储经过提炼的内容。这也是 claude-mem 区别于简单“聊天记录回放”的地方。新会话开始后Claude 会根据当前项目目录、用户身份等信息主动读取一部分记忆概览再把与当前任务相关的记忆通过搜索工具捞回来。这里面的搜索逻辑很关键——它不是拉全部记忆而是按 relevance相关度挑有用的。有一次我让它继续处理一个三天前的任务我只是说了句“继续我们之前讨论的方案”它竟然直接把我三天前记录的“API 版本兼容策略”写进了回答里。那一刻你会明显感觉到多个会话之间的信息终于串起来了。2.4 为什么用 SQLite 而不是一个 JSON 文件有人会问记一点东西而已直接存成 JSON 文件不也行吗我从实际使用角度来说SQLite 的优势非常明显。首先是搜索效率。记忆量一旦过百条线性扫描 JSON 文件和数据库索引检索的差距是可怕的。其次是并发安全。Claude Code 可能有多个会话同时运行如果都往同一个 JSON 文件里写极容易出现互相覆盖的问题。SQLite 对并发写有成熟的处理机制不容易写坏。还有一个很多人想不到的好处SQLite 文件可以直接用sqlite3命令行打开。想查库里到底存了什么、有没有存错把表数据拉出来看一清二楚不用专门写管理界面。这对一个开发者工具来说是很有价值的可观察性。3. 从零跑起来安装、配置、首次落库3.1 安装之前的准备在装 claude-mem 之前我建议你先确认两件事。第一你已经安装了 Claude Code CLI 并且登录了账号毕竟工具是给 Claude 客户端用的没有客户端装好也无从验证。第二本机有 Python 环境因为 claude-mem 本身是用 Python 写的官方推荐的启动方式是uvx。如果你之前完全没装过 uv可以先装一下它本质上是一个 Python 包管理器用来快速运行 claude-mem 这个命令。准备好之后最直接的方式是通过 Claude Code 自带的 MCP 注册命令把服务器加进去。大致命令就是claude mcp add claude-mem -- uvx claude-mem这条命令的含义是让 Claude Code 知道有一个叫 claude-mem 的 MCP 服务器启动方式是用uvx运行claude-mem。如果你本机的uvx不在 PATH 里注册之前最好先跑一下which uvx确认能找到不然后面会出一堆莫名其妙的问题。3.2 项目级配置还是全局配置要提前想清楚claude-mem 支持按项目注册也可以做全局配置。这一步很多人一开始没在意后面才来后悔。如果你希望每个项目都有独立的记忆库那就在进入项目目录之后再执行注册命令这样配置会被写入当前项目的.mcp.json文件只在当前项目里生效。如果你希望所有项目共享一套偏好比如代码风格、工具链偏好那就在用户配置层面注册这样任何项目都能读到全局记忆。我的建议是偏好类信息走全局项目事实走项目级。这样既能享受记忆带来的连续性又不会出现“项目 A 的架构信息出现在项目 B 的对话里”这种串味情况。这个决定后续改起来稍微有点麻烦但也不是不能改关键是先想清楚。3.3 非 Claude Code 客户端的配置写法如果你用的不是 Claude Code而是 Claude Desktop 或者其他支持 MCP 的客户端配置方式也类似只是改配置文件而已。Claude Desktop 的配置一般在一个叫claude_desktop_config.json的文件里需要把 mcpServers 这一段加进去{ mcpServers: { claude-mem: { command: uvx, args: [claude-mem] } } }这段配置的意思是告诉客户端遇到 claude-mem 这个服务器时就用uvx claude-mem把它启动起来。不同客户端加载配置的位置不太一样但结构基本都是这个模式。配置完记得完全退出客户端再重启因为 MCP 服务器的加载发生在启动阶段。3.4 第一次写入记忆验证工具真的在工作配置好之后别急着干嘛先做一个验证测试。运行一个简单的任务例如让 Claude 记住一个事实“我的项目使用 Rust 编写模块划分遵循 Cargo workspace 规范。”等它执行完我们去数据库里看看有没有真的写进去。claude-mem 的数据库位置一般在用户目录下的.claude-mem目录里也就是~/.claude-mem。打开终端执行sqlite3 ~/.claude-mem/memories.db .tables sqlite3 ~/.claude-mem/memories.db SELECT * FROM memories;如果能看到刚才让 Claude 记住的内容说明整条链路已经通了。然后你新开一个会话不用重复任何背景直接问它“我们项目的模块划分是什么样的”它如果能答出来那就说明 claude-mem 真正起作用了。4. 跑了两个月之后我踩过的配置坑4.1 MCP 工具没暴露Claude 完全不接茬第一次安装完我以为配好就完事了结果新会话里 Claude 就是不用记忆功能。我让它“查一下之前记录的项目偏好”它回了一句“我之前没有和你聊过这个话题”。后来排查发现问题出在运行中的会话没有重新加载 MCP 配置。Claude Code 的 MCP 服务器是在会话启动时被加载的我是在会话中途注册的 claude-mem当前会话压根不知道有这个工具。解决方式很简单完全退出 Claude Code再重新启动然后在对话里输入命令看看工具列表里有没有 claude-mem 相关的工具。如果你用的是 Claude Desktop同样要彻底退出再重进。这个坑非常典型不是 claude-mem 的问题而是 MCP 这套机制的工作方式问题。遇到“配置了但没用上”的情况第一件事永远是重启客户端不是怀疑配置写错了。4.2 uv 环境路径问题让服务器启动失败另一个高频问题出在uvx命令。Claude Code 通过配置文件启动 MCP 服务器时它继承的 PATH 不一定跟你终端里一样很多时候 GUI 应用或某个服务进程的 PATH 特别精简根本找不到uvx在哪里。表现就是配置看起来没毛病但 claude-mem 一直启动失败日志里提示找不到uvx或类似的可执行文件。我当时的解决办法是先执行which uvx拿到它的完整路径然后把它写进配置文件的 command 字段里也就是{ mcpServers: { claude-mem: { command: /Users/你的用户名/.local/bin/uvx, args: [claude-mem] } } }这样客户端就不依赖 PATH直接按绝对路径启动。这个问题在 Linux 和 macOS 上都很常见Windows 大概率的坑点也类似建议直接用绝对路径省得后续反复排查。4.3 多个项目共用一个记忆库信息串味了全局注册用了一阵子之后我发现“串味”问题很严重。我在项目 A 里让 Claude 记住了“数据库表结构是 X”结果跑到项目 B 里问它任何问题它也会莫名参考这些跟 B 毫无关系的信息回答甚至被带偏。说到底Claude 自己在判断相关度时并不能保证 100% 区分清楚哪些记忆属于哪个项目。这个问题的本质是记忆库应该按上下文隔离。我现在用的方式是项目事实尽量在项目目录下做配置让每个项目有独立的记忆库用户偏好这种没有冲突风险的才放到全局库。如果你想偷懒也可以做多套 MCP 配置按项目切换只是稍微麻烦一点。空间隔离不是什么高深概念但真的很重要。记忆串了味比没有记忆更让人难受。4.4 自动生成的摘要太啰嗦信息密度反而下降claude-mem 会在会话结束或者关键节点生成摘要这个功能听起来很智能实际用的时候需要注意控制粒度。我早期遇到过它把一次简单的“改了几行配置”的对话生成了几百字的摘要里面全是我当时讨论过程留下的细枝末节。等下次查询时Claude 把这种低质量摘要当线索用结果不仅没帮助还把真正重要的决策记录给淹没了。后来我调整了使用方式不是让它随意记录所有对话而是只让它记录明确的决策和结论。我会在对话中主动说类似“把这条保存下来我们决定用 PostgreSQL 而不是 MySQL”这样的指令把它当成一个需要显式调用的记忆接口来用。这样落库的内容精准很多搜索召回的质量也明显提升。任何记忆工具都需要有人替它判断什么值得记。这个判断目前还不能完全交给模型该手动的时候别偷懒。4.5 隐私和敏感信息千万别写进记忆库这一点我要单独拿出来提。记忆库是明文的 SQLite 文件位置就在你本地目录下。虽然比云端存储安全但也意味着所有能访问你机器的人都读得到。密钥、内部 IP、用户身份证这类敏感信息绝对不要让 Claude 存进记忆库。有一次我不小心让 Claude 记住了一条包含了内部服务端口和调试账号的信息事后清理时费了不少劲。从那以后我的做法就两条第一在对话里明确说“不要保存敏感信息”第二定期打开数据库文件看一眼发现问题立刻删除对应记录。工具本身不会替你判断哪些内容敏感这个责任只能自己扛。5. 实际工作流中我是这样用它的5.1 把架构决策记录“喂”给记忆库现在我在每个长期项目里都会刻意让 Claude 把关键决策记下来。比如“为什么这个模块不用消息队列而用 HTTP 轮询”“为什么接口采用版本号前缀而不是 header 传递”这些决策背后的原因如果脱离了上下文隔两周再看可能完全看不懂。我现在会让 Claude 在讨论出结论后顺手执行一条保存操作把结论和理由存进项目记忆库。这个做法的效果是一个多月后我再开新会话处理同类问题时Claude 能直接引用当初的决策依据而不是又把方案从头推演一遍。这个体验真的是“老同事”级别的体验。5.2 写作场景术语表和语气偏好我除了写代码平时也会让 Claude 帮忙做技术写作和文档润色。这个场景对“记住偏好”的需求同样强烈。比如我的写作风格要求中文技术文档尽量用短句不堆名词术语第一次出现要加英文缩写语气偏克制不夸张。以前每写一篇新文档我都要重新复制粘贴一遍风格要求。现在只需要第一次写清楚然后让它保存为偏好之后所有写作任务都会自动带上这个约束。对于固定团队的文档这个功能还能解决风格统一问题。团队里只要有人把风格规范导入了记忆库后续成员用同一个库时写出来的文档就不会出现风格漂移。5.3 让代码规范从“贴进提示词”变成“查记忆库”在团队项目里代码规范通常写在文档里但 Claude 不会自己去看文档。以前的做法是把规范粘贴进对话上下文既占 token又容易因为太长让模型抓不到重点。现在我会把代码规范拆成一条一条的“记忆条目”让 Claude 记住。比如项目错误处理统一使用全局异常类service 层禁止直接操作数据库所有 API 响应结构统一为{ code, message, data }。新会话一启动Claude 不需要我重新贴规则它会主动查项目记忆来对齐这些约束。有一次我让它写一个新的 service 类它居然自己引用了“service 层禁止直接操作数据库”这条记忆来设计方案那一刻我确实觉得这工具值回票价了。5.4 记忆库也是会过期的定期要清很多人以为记忆库是“永久有效的”实际不是。项目会迭代技术方案会调整偏好也会变化。如果库里存着一堆三个月前的过时信息Claude 查询时可能优先拿旧信息当依据反而帮倒忙。我现在每隔一段时间会打开~/.claude-mem/memories.db看一眼把明显过时的记录删掉或更新。这个习惯一开始觉得繁琐时间久了你会发现这是整个记忆系统保持有效性的关键。记忆不是越全越好而是越准确越好。6. token 成本、性能和它的边界这里有个真实账6.1 prompt 缓存确实帮了大忙我刚开始担心一个问题有了记忆库之后Claude 每次启动新会话都要读一堆记忆token 消耗会不会爆炸实际跑下来情况还好原因是 claude-mem 上了 prompt caching 的思路。记忆内容会命中缓存不会像普通系统提示词那样每轮都全额计费。加上它有摘要机制不会把几十条原始记录全部塞进上下文而是先按需搜索再注入所以单次消耗整体可控。我自己的经验是会话启动时它会拉一批概览信息这部分是固定开销真正动态消耗在于搜索动作命中了多少条记忆而这个数量是可控的。6.2 记忆条目不是越长越好300 字是一个好上限用了一段时间之后我自己总结出一个铁律单条记忆尽量控制在 300 字以内。原因很简单Claude 搜索记忆时是按照相关度召回若干条如果每条记忆都写得又长又啰嗦召回少量条目就把上下文塞满了反而装不下更有用的信息。真正高质量的记忆条目像便利贴一样短一句结论一个原因就够了。比如与其让 Claude 记住“我们讨论了三天最终决定在订单服务中使用 PostgreSQL因为团队最熟悉它且运维成本低”不如直接记“订单服务使用 PostgreSQL理由团队熟悉、运维成本低”。信息量几乎一样但后者占的空间小太多。6.3 什么样的人不适合用 claude-mem说了这么多好处我也得说点实话这个工具不适合所有人。如果你的 Claude 场景是“问一次就不用了”的零散问题比如临时翻译一段文字、写个一次性脚本那确实没必要上记忆功能配置成本大于收益。记忆工具是为“长期、重复、有上下文依赖”的使用模式设计的把单次任务硬套上记忆属于画蛇添足。另外如果你的使用环境对数据安全要求极高比如禁止任何形式的本地持久化存储那 claude-mem 默认的“明文 SQLite 落盘”机制显然不合适。这种场景不是工具不好而是场景不匹配没必要硬上。我个人对 claude-mem 的真实评价是它把 Claude 从“每次都是陌生人”变成了“记得你习惯的老队友”。它不是能帮你解决所有问题的银弹但对于长期项目和持续创作的人它能消除的重复沟通成本远大于配置它花掉的那点时间。最后再分享一个小习惯我每个周末会花五分钟把 claude-mem 记忆库里这一周的记录扫一遍删掉过时的、修正错误的、合并重复的。这个习惯看着很小但效果非常明显——它能让记忆库保持“高效且可信”而这恰恰是任何外部记忆系统最核心的价值。