Claude Code 记忆扩展该如何选

给 Claude Code 加记忆插件之前，先分清它忘了什么：你的个人偏好、上次排查到哪一步，还是团队已经拍板的产品规则。这篇文章的结论很明确：这些信息需要不同的保存和更新方式，不能靠多装一层记忆统一解决。

作者比较了原生能力和六款工具，但没有做实验室排名。它值得读的地方，是把选型问题从「谁记得更多」转向「谁该看到、凭什么生效、过期后怎么办」。对经常跨会话写代码的程序员，这比召回率更接近实际需求。

原生记忆够用时，为什么还要增加维护成本

Claude Code 已经有两套互补机制：开发者维护的指令文件，以及 Claude 根据纠正和偏好写入的 auto memory。

稳定的项目约定适合放进简短的 CLAUDE.md 或 AGENTS.md，通过版本控制共享和审查。个人偏好则可以先交给 auto memory。后者保存在本机，同一仓库的多个 worktree 共用一个记忆目录，但不会自动同步给另一台机器上的同事。

这条边界很有用。你喜欢小步提交，不必变成全公司的规定；客户数据导出时必须排除某个字段，也不该只存在你的个人记忆里。

先给信息确定归属，再决定是否需要插件。

额外工具会增加安装、检索、数据保留和日常维护的选择。如果问题只是反复告诉 Claude 使用哪个测试命令，原生能力可能已经足够。只有跨会话续接、跨工具共享或团队决策留存存在明确缺口时，新增一层才有理由。

自动记住历史，能否接上下一次工作

Supermemory 和 claude-mem 都涉及会话延续，但记录和取回信息的侧重点不同。

Supermemory 的 Claude Code 插件通过 hooks 捕获新的对话内容，并在实质性提示前检索相关记忆。集成既支持托管服务，也支持自托管 Supermemory 的自定义 endpoint。需要跨会话、跨工具找回过去工作时，它值得评估。

共享范围却不能靠猜。存在仓库容器，不代表每位同事都能读取所有捕获内容，还要检查组织、作用域和访问规则。

费用也有边界。按作者在 2026 年 10 月 29 日核对的信息，插件可用于 Free 计划，但 API 使用会消耗额度：Free 每月含 $5 额度和 1 个席位；Pro 每月 $19，含 $20 额度和 3 个席位。免费安装不等于无限使用。

claude-mem 则捕获工具使用过程中的观察记录，生成摘要，再向后续会话提供相关上下文。它适合保存「查过什么、试过什么、哪里失败、接下来做什么」。文档还描述了可选 cloud sync 和 TeamBrain，因此不能简单称它为纯本地或纯个人工具。

安装时也要区分库与实际集成。原文没有给出安装命令，只提醒读者：不要以为全局 npm 安装就自动配置好了 hooks，应以当前 README 为准。

两者都绕不开一个问题：记住了讨论，不等于确认了结论。一次失败实验、一个待定方案和一条正式约束，可能出现在同一段历史里。摘要能帮助续接工作，却不能单凭自身证明哪条规则已经获批。

本地存储、共享知识与正式决策，分别补什么缺口

Hippo 适合重视可检查存储的人。它用 SQLite 保存记忆，同时生成可读的 Markdown 镜像；默认 BM25 搜索不需要 embedding 模型，启用可选 embeddings 等检索能力则会改变配置。

但 local-first 不代表所有操作都离线。按 README 的描述，设置 Anthropic API key 后，consolidation，也就是记忆整理步骤，会把记忆文本发给 Anthropic。可选 API embedders 和 rerankers 也可能联网。安装还可能加入 hooks 和每日定时任务，需要一并检查。

Basic Memory 更偏向人和 agent 共用的知识库，通过 MCP 访问结构化笔记、链接和知识图谱。Claude Code 插件还包含 briefing 和 checkpoint 行为，用于提供简报、记录阶段状态。

它的本地版运行在个人电脑上，不含团队功能；Teams 提供共享云端知识库，按席位收费。好处是人可以阅读和维护 agent 检索的内容，但共享只解决可见性，笔记仍需要负责人和审查，提案不会因为人人可读就自动成为规则。

MemoryLake 描述了通过 MCP 提供项目记忆、跨成员共享和基于角色的权限，集成页面区分免费个人使用与付费团队协作。不过，它把 Claude Code 描述成无状态产品的营销前提，与原生 auto memory 的文档不符。该比较没有独立测试其捕获时机、新会话加载、权限执行或决策替换行为，实际增益仍需验证。

Lockstep 关注的是另一件事：已经接受的产品与工程决策，如何传到后续执行者手里。比如产品和工程负责人已同意导出时排除敏感字段，新会话却看见一个包含该字段的旧原型。此时缺少的是哪条规则生效、为何成立、谁负责以及是否仍然适用。

作者披露 Lockstep 是自家产品。其已发布 CLI 包含决策提案、上下文、会话简报，以及考虑用户同意状态的建议性检查。但检查不完整或不可用，不能当成检查通过；出现建议性发现，也不保证冲突代码无法上线。

它当前的个人接入路径是 Claude Code pilot，仓库与网站存在部分发布状态差异，作者也没验证一次全新的、经过身份认证的托管接入流程。合理做法是先在一个仓库验证。其他工具同样可以存决策，比较重点应是审查、替换和来源追溯流程。

我的判断

我赞同作者按信息用途选工具。实际协作中，「找回旧内容」和「确认当前规则」是两个问题。历史越多，越需要区分草稿、实验结果和正式决策，否则检索得越积极，越可能把旧结论带进新代码。

不过，这篇文章提供的是基于文档的选型框架，没有给出召回质量、延迟、上下文占用或团队收益的对照数据。末尾的验收方法也只是建议，并非已经完成的实验。因此，不能据此判断哪款工具效果最好，或一定比仓库里的 Markdown 文件更省事。

短指令文件的优势是容易审查、能随代码版本演进；自动捕获工具能减少手工整理；共享知识库方便多人维护；决策记录工具则强调规则的接受与替换流程。这些优势能否兑现，还取决于团队是否愿意维护内容，以及工具是否真能正确处理权限和失效信息。

对 Lockstep 尤其要保留这个尺度：作者主动披露自家产品和验证缺口，有助于读者判断，但这些说明不能替代实测。

能拿来做什么

• 先整理当前反复补给 Claude Code 的信息。把稳定项目约定放进简短的 CLAUDE.md 或 AGENTS.md，把个人偏好交给 auto memory，再判断缺的是历史续接还是团队共享。
• 用一条真实规则做小规模验收。例如记录「导出时排除某个敏感字段」、原因及被否决的方案，关闭会话后重新询问；随后替换规则，检查旧版本是否还被当作当前建议。
• 如果需要团队共享，就用第二个账号或另一款工具，按实际权限重复测试。不要共用一个管理员身份，否则无法验证成员能看到什么、哪些内容应被隔离。
• 在接入项目上下文前，检查 hooks 捕获内容、删除行为、网络请求和注入上下文的数量。对前端或 Node 仓库，既要确认私有代码去了哪里，也要看无关历史是否挤占当前任务。