Claude-Mem：为 Claude Code 赋予跨会话长期记忆能力

这些钩子有几个特点：对用户来说几乎是'隐形'的，不需要改变现有使用习惯；重点记录的是'工具使用带来的变化'，比如改了哪些文件、执行了什么命令，而不是一股脑儿把所有聊天记录都存下来；把这些东西统称为'观察记录'（Observations），类似一个时间序列的项目事件日志。

这一步解决的是：怎么把人机协作过程变成结构化、可追溯的历史，而不是散落一地的对话记录。

4.2 本地混合存储：结构化 + 全文 + 语义

Claude-Mem 的存储设计也比较'务实'：

• 使用 SQLite + FTS5：存结构化数据（会话 ID、文件路径、时间戳、操作类型等）；做全文检索（像搜索日志一样搜关键词）。
• 使用 Chroma 向量库：把摘要、重要片段向量化，用来做语义检索；适合处理'模糊问题'，比如'上周讨论的那个支付风控策略'。

所有数据统一存放在用户本地目录 ~/.claude-mem/ 下，不走云端服务，这点对隐私敏感行业（金融、医疗）比较重要。

从工程角度看，这套组合有几个优势：部署成本低，不需要额外起一套服务；查询灵活，结构化筛选 + 全文 + 语义，可以随场景组合；用户可见可控，目录是本地的，想备份、加密、甚至手动清理都可以。

4.3 记忆压缩：别把'原始流水账'端给模型看

只存是第一步，更关键的是：会话结束时，要把大量零散的观察记录压成模型看得懂、又不费 Token 的摘要。

Claude-Mem 在 SessionEnd 阶段会调用 Claude Agent SDK，把会话中累计的 Observations 汇总成结构化摘要，典型包含四块：调研内容、学习成果、已完成工作、后续步骤。

这一步的关键是：不再把完整的原始历史直接塞进上下文，而是只注入高度浓缩后的'记忆索引 + 摘要'。它为后面的'渐进式披露'打好了基础。

五、三层渐进式披露：Token 成本怎么砍到 95%？

Claude-Mem 的核心创新，总结为'三层渐进式披露'（progressive disclosure）。简单理解：不是一开始就把所有历史端给模型，而是分三层，按需解锁。

5.1 三层结构长什么样？

大致流程可以想象成这样：

1. 用户在新会话发起问题，比如'接着上周的支付风控策略，帮我补充风控规则'。
2. 插件先在本地做 Search，找出最相关的一些历史摘要（这一步开销很小）。
3. 如果当前任务需要更多上下文，再拉对应时间段的 timeline，看看前后做了什么。
4. 若还不够，最后才会调用 Get_Observations，把当时的具体操作记录（文件改动、命令输出等）拉进上下文。

5.2 为什么这种设计能大幅省 Token？

如果没有这三层，常规做法有几种：暴力法，直接把过去几天的对话和改动全扔给模型看，Token 爆炸；手动挑，开发者自己翻历史，复制粘贴上下文 —— 太累，而且容易漏。

三层渐进式披露，本质上是把'召回'和'注入'这两步拆开，优先只注入压缩后的高价值摘要。

• 常规使用场景下，大约可以节省 90% 左右的 Token。
• 在'无尽模式'（项目持续很久、记忆特别多）下，最高可以节省 95%。
• 因为 Token 压力下降，工具调用上限也可以放宽到原来的 20 倍量级。

对开发者来说，体感上就变成：同样的预算，AI 可以陪你做更长时间的活，而且不会越用越'傻'。

六、实战效果：在不同场景里能带来什么变化？

几个实测和反馈场景，我们可以按使用者身份来拆开看。

6.1 企业团队：复杂项目里的'团队记忆库'

在大型代码库、多团队协作的企业场景，Claude-Mem 能做的事包括：持续记录模块设计的演变过程，知道为什么当时选了方案 A 而不是方案 B；跟踪缺陷修复：这个 Bug 曾经怎么排查、怎样验证过；给新同事一个'可查询'的历史上下文，而不是光靠问人。

有团队反馈过这样的数字：新人上手时间缩短约 40%；代码评审效率提升约 25%。

对于动辄数月、多人接力的企业项目来说，这种提升是实实在在的：记忆系统不是多一个'功能点'，而是让 AI 真正融入现有协作流程。

6.2 个人开发者：长线 side project 的'自动笔记助手'

对一个长期在搞 side project 的个人开发者，Claude-Mem 带来的变化会更直接一些：你可以用自然语言直接问之前的决策，比如：'上周我重新设计过登录流程，当时用了什么鉴权策略？'；插件可以帮你回溯出当时讨论过的选项、最终采用的方案，以及改动的代码范围；打开本地 Web 界面（默认是 http://localhost:37777），能实时看到记忆流和会话摘要，类似'项目日记自动生成版'。

这对很多'间歇性推进'的个人项目尤其友好 —— 哪怕你中间停了两周，回来之后不会全靠自己翻 Git commit 和脑补。

6.3 隐私敏感行业：合规边界怎么守？

在金融、医疗这类对隐私特别敏感的行业，大家最担心的是：'这些数据会不会上传到云端？'、'有没有可能误把敏感信息存进记忆里？'

Claude-Mem 的做法主要有两点：数据全部本地存储，而且目录可见、可控；支持标签机制，可以给某些内容打上'不要记录'类标签，阻止敏感信息被纳入记忆。

这意味着你可以根据项目和合规要求，自定义'能记什么、不能记什么'，而不是一刀切地'要么全记，要么全不记'。

七、安装与使用体验

/plugin marketplace add thedotmack/claude-mem /plugin install claude-mem

执行完插件安装后，重启 Claude Code，大部分功能就能直接用上。

对普通开发者来说，有几点体验上的好处：无需改动现有工作流，不用写额外脚本；无需部署额外服务，不用自己搭一套后端；多数配置有合理默认值，用起来更像'开关一个功能'，而不是做系统集成。

当然，如果你想进一步定制（比如不同项目用不同记忆策略），就需要了解一些配置项和阈值设定，这对高级用户来说也是可控的工程成本。

八、和其他方案对比：它到底好在哪儿？

几个常见的'替代方案'，我们可以稍微整理成一张表：

从工程折中来看，Claude-Mem 走的是一条'中等复杂度'的路线：比简单注入和手动复制强得多，有检索、有结构化、有自动摘要；又比全自研 RAG 系统轻量很多，不用搭服务、不用管集群和运维。

这也是为什么很多人把它称为：在 IDE 内部实用层面，目前最接地气的一种长期记忆方案。

九、局限与风险：它不是'万能记忆药丸'

Claude-Mem 的几个局限，展开讲一下，方便评估是否适合自己的场景。

9.1 摘要质量取决于底层模型

记忆压缩是靠 Claude Agent SDK 来做的。这意味着，在极端复杂场景下（比如几十个相关模块、跨多团队改动），摘要可能会出现信息遗漏或侧重点不太符合预期的问题。

所以在一些关键决策类项目中，仍然有必要保留人类写的设计文档和决策记录，不能完全依赖自动摘要当'唯一真相来源'。

9.2 对版本和生态有一定依赖

因为它是为 Claude Code 量身定制的插件，所以需要较新的 Claude Code 版本支持对应插件机制；IDE 和插件生态更新时，可能会遇到兼容性问题，需要跟进升级。

这对走企业大规模部署的团队来说，需要在内部有一套插件版本管理和回滚机制，不然遇到版本冲突会比较头疼。

9.3 需要一点'调参意识'

虽然默认配置可以直接用，但要在复杂项目里用得顺手，多少需要调一下参数，比如：检索阈值（相关度多少以上的记忆才注入）、注入上限（一次允许带入多少条历史）、不同项目是否需要单独命名空间或标签。

这些都关系到：既要让 AI 记得你，又不要记得太多，把上下文弄成'信息垃圾场'。

十、从工程视角看：为什么说这是 'Agent 时代的标配能力雏形'？

把 Claude-Mem 放在一个更大的背景里：AI Agent 时代，记忆将从加分项变成标配。

如果你正在做 Agent / 工具链 / 多模态协作之类的项目，可以从 Claude-Mem 身上借鉴几个思路：

10.1 记忆应该是'分层的'

• 第一层：轻量索引和摘要，适合高频调用。
• 第二层：带时间序的上下文，用来理解事件过程。
• 第三层：完整细节，用于审计、还原现场、精细推理。

这逻辑其实跟人脑挺像：先想大概、再回忆过程、最后才是翻日记和聊天记录。

10.2 本地优先 + 可控隐私，是很多行业的硬需求

不是什么东西都能放到云上跑：有些国家/地区的监管要求数据必须留在本地；有些企业不接受把源代码、业务日志交给第三方服务。

Claude-Mem 采用'本地数据库 + 本地向量库'的实践，证明在很多 IDE AI 场景下，这条路是可行的，不一定非要上云端'重炮'。

10.3 社区驱动的插件生态，会放大基础模型的价值

从 Claude-Mem 的成长轨迹可以看到：模型厂商提供了足够开放的插件能力和工具调用接口；社区开发者能在这个基础上做出高价值的增强功能；最终是整个生态受益，用户会更愿意深度绑定这个工具链。

对正在做大模型平台或 IDE 集成的团队来说，这是个很重要的信号：开放能力 + 激励社区，比自己闭门造车，往往走得更远。

十一、实用建议

如果你现在就在用 Claude Code，可以怎么落地？结合上面的分析，如果你是目标用户，基本可以按下面几步来实践。

11.1 先从一个真实项目开始，而不是 Demo

不要拿一个'demo 仓库'测感受，建议直接选一个开发周期至少一周以上、有明确的功能演进和多次历史改动、你个人或团队都已经比较熟悉的项目。

在这个项目上开启 Claude-Mem，正常工作一段时间，然后观察：是否减少了重复解释的时间？AI 是否能更准确理解你当前任务所处的上下文？旧问题的重现和定位是否更快？

11.2 刻意用几次'带检索'的提问方式

比如尝试下面这类问法：

• '帮我接着上次我们讨论用户权限系统的地方继续完善表结构。'
• '列一下过去三天我们在支付模块里改过哪些东西。'
• '总结一下之前为解决超时问题，试过哪些优化手段，哪种被保留下来了。'

这些问题能很好地'压测'记忆系统的检索与注入效果，看它是不是真的理解了你的'长期上下文'。

11.3 对团队：把记忆系统写进开发规范

如果你是团队里的技术负责人，可以考虑几件事：统一在某些关键项目上启用 Claude-Mem，并把使用方式写进内部开发规范；约定一些'可检索问题模版'，比如'总结最近一次上线前的回归重点'等；定期 review 记忆摘要质量，看是否需要调整阈值、过滤规则或标签策略。

这样，Claude-Mem 不只是'某个工程师自己安装的插件'，而是变成团队协作流程的一部分。

十二、结语：Claude-Mem 值得怎么被看待？

Claude-Mem 做的事情不神秘，也谈不上'黑科技'，但很扎实：把真实痛点抓得很准，跨会话失忆 + Token 成本高；用的是现成、可靠的工程手段，事件钩子、本地数据库、向量检索；设计上有'节制感'，不追求'什么都记'，而是按层、按需披露；社区热度和使用反馈也说明，它确实改善了不少人的日常开发体验。

如果你正在做 AI 编程助手、Agent、开发工具类产品，Claude-Mem 值得被认真拆一遍，不只是'抄功能'，而是思考：自己的场景里，什么才是真正有价值的长期记忆？这些记忆应该以什么粒度、什么形式，被保存与调用？在成本、隐私和体验之间，怎么找到合适的平衡点？

某种意义上，Claude-Mem 只是一个开始。未来几年，'让 AI 真正记住你'和'让 AI 在正确的时机想起正确的事'，会变成所有智能工具绕不过去的基础能力。Claude-Mem 做的，是帮我们先给这块拼图，拼了一个还不错的第一版样子。