claude-mem 能解决 Claude Code 失忆吗？

claude-mem 能缓解 Claude Code 的跨会话失忆，但它保存的是经 AI 压缩、可检索的外部记忆，而不是把每次对话无损续接。它的核心价值在于把原本局限在单次会话里的项目决策、排错结论和开发进度，转换为下一次可以按需召回的信息。

这一机制并非简单扩大模型的上下文窗口，而是在模型外部依托一个“捕获—压缩—存储—检索—注入”记忆层运作。claude-mem 因针对 Claude Code 重启后需要重复解释项目背景这一场景而进入 GitHub Trending；不过榜单、Star 数和版本都在变化，发布文章时仍应重新核对仓库，不应长期沿用二手资料中的热度数字。

现有资料没有提供一套完整、可复核的终端日志，因此本文不会虚构命中率、Token 降幅或安装结果。本文采用更稳妥的双会话验证方式：先在同一非敏感仓库中建立一条架构决策和一条排错结论，关闭终端后重新提问，再与未启用记忆的基线流程对照。重点不在于界面里是否多了一条记录，而在于 Claude Code 能否在未获提醒的情况下稳定召回正确信息。

Claude Code 会话关闭后，架构方案、调试结论、代码约定和接口逻辑未必能自然延续，开发者往往需要重新介绍技术栈、项目进度和已经排除过的错误方向，既消耗 Token，也打断开发节奏。claude-mem 通过持久化存储与检索机制弥补会话隔离带来的信息缺口，并不修改模型本身。

从事件顺序看，claude-mem 会利用 Claude Code 的生命周期钩子介入工作流。SessionStart 负责在会话启动时注入历史记忆，UserPromptSubmit 记录用户问题和上下文，PostToolUse 捕获 Read、Write、Edit 以及命令执行等操作，SessionEnd 则触发会话摘要和压缩处理。这些资料说明，记忆并非只来自用户手动输入的一句话，而是可以从一次真实的开发过程中逐步形成。

会话结束后，系统会尝试提取技术决策、项目背景、用户偏好和排错结论，经 AI 压缩后写入本地记忆库；其中 SQLite 用于保存事实信息。下一次会话再根据当前任务匹配相关内容，而不是默认把所有历史都塞进提示词。资料提到的分层检索、渐进式披露和 Token 成本可见性，用于控制注入规模；需要查找较久远的信息时，还可以使用 mem-search 技能主动检索项目历史。

判断一次召回是否真实有效，必须区分两种路径。其一是自动注入，即由 SessionStart 在新会话中带入相关记忆；其二是手动检索，由 mem-search 查回某条历史记录。只有前者才能说明“模型自然地记住了”，后者则只能证明记忆库里存在相关信息。claude-mem 提供本地 Web 查看器和观察 ID，可通过 http://localhost:37777 查看记忆流，也能利用 http://localhost:37777/api/observation/{id} 回溯具体记录。

现有记忆方式解决的问题并不相同：

CLAUDE.md 的问题不是没有用，而是需要人工持续维护，容易和真实开发进度脱节。Anthropic 官方页面确认 Claude 产品提供“Memory across conversations”，但现有官方资料不足以证明它与 claude-mem 在 Claude Code 项目级、本地存储和语义检索方面采用相同机制，这两者不应混为一谈。

在部署方面，应以 GitHub 仓库当前 README 为唯一安装依据。二手资料将其概括为“一行命令部署”，但钩子名称、安装入口和数据目录都可能随版本变化。开始安装前，先记录本机环境和当前版本：

claude --version
git --version
uname -a

随后打开 https://github.com/thedotmack/claude-mem，在 README 的 Installation 部分执行当前版本给出的命令，不从旧文章复制未经核对的安装语句。安装完成后，需要依次检查三件事：Claude Code 是否识别到插件或生命周期钩子，本地记忆服务是否正常运行，以及 Web 查看器能否访问。最小连通性检查可使用以下命令：

curl -sS -o /dev/null -w '%{http_code}\n' http://localhost:37777

返回结果应表明本地服务可以响应。具体状态检查、钩子注册和数据目录均以当前 README 为准，不应凭经验猜测配置路径。

第一次测试不要拿真实业务仓库试错。先选一个不包含客户数据、访问令牌和生产凭据的仓库，并准备两个内容相近的会话。会话 A 的任务应当包含文件读取、命令执行和可验证结论，否则即使界面出现一条摘要，也无法说明工具调用是否真的被捕获。

可以使用下面的提示词模板，并替换其中的文件路径：

请读取 [目标源文件] 和 [相关测试文件]，运行最小相关测试并定位失败原因。
暂时不要修改代码，只给出：
1. 一条可执行的修复建议；
2. 一条本次应保留的架构决策；
3. 一条已经排除的错误方向；
4. 最后用不超过五条列出需要进入项目记忆的决策、进度和排错结论。

完成操作后正常结束会话，而不是直接关闭终端或强制结束进程。重点检查正常退出是否触发了 SessionEnd。随后进入 Web 查看器，确认至少能看到本次会话产生的相关记录，包括工具操作、摘要或可检索观察；再复制一个观察 ID，访问对应地址核对正文，避免只凭列表标题判断捕获成功。

如果查看器里没有记录，第一检查项是钩子是否注册，第二是会话是否完整触发结束事件，第三才是索引或服务状态。只看到一条摘要也不能直接判定成功：摘要可能抓住了任务类型，却没有保留关键决策和排错结论。

会话 B 要验证的是自然召回，而不是用户提示词写得足够详细。关闭终端后重新启动 Claude Code，不主动复述旧结论，也不要先要求它读取相同文件，直接提出依赖旧信息的续作任务：

继续上次的 [具体任务]，先不要重新扫描整个仓库。
请回答：
1. 上次确定的架构原则是什么？
2. 上次失败的根因是什么？
3. 基于这两个结论，下一步应该改哪里？

此时应分别记录三类结果：会话启动时自动注入了什么，Claude 的首次回答命中了哪些旧结论，以及哪些信息仍然需要用户重复解释。如果首次回答不稳定，再用 mem-search 手动查找“架构决策”“失败根因”等关键词；手动检索命中而自动注入未命中，则表明存储链路可能正常，但仍需检查相关性排序或自动注入策略。

为了避免把模型偶然答对当成记忆能力，还应运行一次无记忆基线。一种做法是使用同一仓库的另一份干净副本，在未启用 claude-mem 的情况下重复会话 A 和会话 B，再把两轮结果放在同一张表里比较：

“最高节省九成 Token”来自二手资料中的宣传口径，可以作为待验证指标，不能写成所有项目都能稳定获得的结果。不同仓库长度、历史记忆规模、检索命中质量和任务类型都会改变收益；一个只输出项目背景的问题，与一个需要遍历大量代码的任务，也无法使用同一标准衡量。

测试中出现问题时，可以按症状定位，而不是反复重装：

升级前应固定当前版本，并备份 README 指定的本地记忆数据和配置；升级后重新执行双会话测试，不能因为界面可以打开就认定迁移成功。卸载时也应按当前 README 清理钩子、查看器进程和对应数据，再启动一次普通 Claude Code 会话，确认没有残留注入行为。

当记忆库逐渐变大，问题会从“记不住”转向“记得太多”。实际目标应是让 Claude Code 只获得与当前任务有关的决策、进度和排错线索，并不追求把全部历史全量回填。评估时应分别统计自动注入量、手动检索量、无关内容比例、重复记忆比例、首次命中率和总 Token，而不是只看某次回答是否“像是记得”。

维护上，可以按项目、任务类型和关键决策整理标签，并定期删除已经失效的结论。AI 摘要适合充当导航线索，不应成为唯一事实来源；凡是仍然影响代码的规则，仍应以测试、提交记录和正式文档为准。对于多个并行仓库，应分别运行会话并检查是否发生项目间串记；如果标签和数据目录无法提供足够隔离，就应关闭自动注入，改为明确检索。

隐私方面，资料建议使用 <private> 标签排除不应保存的敏感内容。但标签机制不应成为输入密码、令牌和客户数据的理由。更重要的是，“数据本地保存”只是持久化层的属性，不等于整个链路不存在模型调用、日志或配置泄露风险；资料还提到会话结束会调用 Claude Agent SDK 进行压缩，因此需要把压缩链路也纳入安全评估。

部署范围同样需要保持克制。现有资料重点描述的是个人本地安装，以及通过 http://localhost:37777 使用的本地查看器。在 README 没有明确提供远程访问、多用户协作、权限隔离或高可用方案之前，不应把它包装成团队级记忆服务；它面向其他 Agent 的扩展能力也需要逐个平台验证，不能由 Claude Code 的结果直接外推。

采用标准可归纳为四点：关键决策能够稳定召回，无关注入可以控制，敏感内容能够排除，升级与清理路径明确。满足这些条件后，再逐步扩大到真实项目；若出现记忆遗漏或噪声，优先调整标签、检索和上下文配置，而不是直接扩大自动注入范围。

下一步可以先固定 claude-mem 的当前版本，在一个非敏感仓库里完成“会话 A 建立结论—正常退出—会话 B 追问”的最小测试，再通过 Web 查看器和观察 ID 核对原始记录。随后记录首次命中率、重复说明次数和 Token 变化；只有结果稳定，才值得把它接入长期项目。