Claude Code 现在已经有两层内建记忆：CLAUDE.md 负责显式规则，auto memory 负责从反复纠正中学习模式。所谓 Claude Memory MCP，说的是另一层东西：把记忆放到 Claude Code 内建、machine-local 边界之外的外部 MCP server。
这层拆分一清楚，建议就会立刻跟着变。假如你要解决的还是仓库规则、启动说明、反复出现的个人偏好，或者单机上的工作习惯，那内建层仍然是第一站。只有当你要解决的是 /compact 之后还能找回、跨工具检索、跨机器连续性，或者团队共享同一份外部记忆时，外部 memory MCP 才开始真正成立。
Anthropic 现在的 Claude Code memory docs 和 MCP docs 仍然把这两层写成不同表面：CLAUDE.md 与 auto memory 属于 Claude Code 的内建行为，MCP server 则是外部工具与数据接入面，带着自己的 approval、作用域和第三方风险。真正有用的问题，不只是“哪家工具更强”，而是哪一层应该先拥有这段上下文。
| 如果你真正的问题是…… | 先走哪条路 | 为什么这条路应该更早出现 |
|---|---|---|
| 仓库规则、启动时就要生效的说明、危险操作边界 | CLAUDE.md | 这是 Claude 一开始就该看到的显式规则层 |
| 反复纠正出来的习惯、单机环境里的偏好 | auto memory | 这是内建学习层，不是自动跨机器同步的共享库 |
/compact 后的上下文延续、跨工具检索、跨机器连续性、团队共享 | 外部 memory MCP | 这才是真正越过内建边界的外部连续性问题 |
如果前两列已经能准确描述你的痛点，就先不要加 server。外部 memory 真正值得出现的时刻，是第三列已经明确变成你的主问题，而不是因为“persistent memory”听起来很诱人。
在你加任何外部层之前，Claude Code 已经会记住什么
很多人太早想上 external memory，不是因为需求真的复杂，而是因为“memory”这个词听起来像一个整体功能。实际上，Claude Code 的内建记忆已经分成了不同职责。
CLAUDE.md 是显式规则层。测试命令、review 预期、危险操作边界、目录约束、版本发布规则，这些只要你不希望每次都重新解释，就应该写进这里。它的价值不在“神奇”，而在“明确而且从会话开始就在场”。
auto memory 承担的是学习层。某些东西不一定要你显式写成制度，但会在长期合作中反复出现，比如你习惯先跑哪条命令、项目里某个缩写是什么意思、哪类文件通常不应该直接动。这类模式可以让 Claude 从重复纠正里学会。不过它仍然是有边界的：官方文档写得很清楚，这不是一个默认跨机器、跨团队同步的永久 store。
所以更有价值的问题不是“Claude 会不会记住”，而是“该由哪一层记住什么”。如果答案是“仓库规则和必须持久的工作约束”，那就回到 CLAUDE.md；如果答案是“重复习惯和局部偏好”，那交给 auto memory；如果答案已经变成“我要跨工具、跨机器、跨团队维持同一份检索与记忆面”，那才是外部 memory MCP 的工作。
这里也别跳过 /memory 和 /context。很多人以为自己需要 external memory，最后真正的问题只是：内建规则没写清楚、实际加载的层和自己想象的不一样，或者上下文本身已经膨胀得太乱。如果你想看 Claude Code 内建记忆的完整拆解，包括启动加载、路径和 /compact 排障，可以接着看我们的 Claude Code Memory 指南。这里更关心的边界更简单：显式规则和习惯留在内建层，只有连续性必须活在机器外面时，才升级到外部层。
外部 memory MCP 真正解决的，到底是哪几种问题
外部 memory MCP 不是抽象意义上的“更强记忆”。它有价值，只发生在你的连续性问题已经超出内建 Claude Code memory 该负责的范围之后。
第一种门槛是 compaction survival。如果重要工作上下文在 /compact 之后总是失踪，而你又不可能每次都靠聊天内容重建，那么问题就不再只是“我该把规则写在哪”。你开始需要一个位于对话之外的持久表面。
第二种门槛是 跨工具检索。Claude 需要的东西不一定都属于 repo 规则，也不一定是从重复纠正中学出来的习惯。有些信息本来就在 notes、issue 历史、共享文档或别的工具里。到这里，你要解决的已经是 retrieval，而不是把 Claude Code 自己的 memory 再抹厚一层。
第三种门槛是 跨机器连续性。内建 Claude Code memory 目前仍然是 machine-local。如果你经常在多台电脑、远程环境或不同 runtime 之间切换，又希望同一套记忆表面跟着走，那么你碰到的就不是内建层的正常使用问题，而是边界问题。
第四种门槛是 团队共享。这也是最容易被说服升级、但同样最容易被滥用的一档。团队共享只有在大家真的需要共同的笔记、共同的回忆面、共同的外部检索时才成立。不是因为“几个人都在用 Claude Code”，就自然应该立刻共享一层外部 memory。
现在市场上的 memory-MCP 页面，卖点通常也集中在这几类：跨会话延续、压缩后还能找回、跨工具共享、团队记忆集中化。它们的价值在于帮你识别“什么算外部层的问题”。它们的风险在于，很容易让人误以为 Claude Code 默认就缺了这块功能。更安全的读法是：这些是外部产品在解决的特定问题，不是 Claude Code 官方内建能力的缺口清单。
插件、remote MCP，还是 project-shared？
一旦你确认外部 memory 的门槛是真的，下一步也不是先挑产品，而是先决定这层能力应该由谁拥有。
最安全的默认答案仍然是 先个人、再共享。如果还只是一个人验证这条流程，就让它保持个人可控。你可以用插件式体验，也可以连一个只在自己环境里启用的 remote MCP。关键不是“哪种看起来更高级”，而是先证明这份外部 memory 的确在解决一个明确且反复出现的问题。
Remote MCP 更适合真正需要外部检索或外部持久化的时候。但 remote 的代价也很明确：你要额外相信 operator、接受服务可用性问题、处理新的依赖边界。如果它吸引你的理由只是宣传语很猛，那先别装；如果它能精确解决你已经说得清楚的连续性故障，再开始评估才合理。
Project-shared 则应该更晚。Anthropic 的 MCP 体系本来就把 local、project、user 这些作用域分开，因为“谁来拥有这个接入面”本身就是 recommendation 的一部分。如果 repo 真的要把 memory integration 收进来，那应该是因为工作流已经稳定、共享收益已经明确，而不是因为“看起来专业”。
如果你的问题已经扩大成“Claude Code 还有哪些外部集成值得先装”，那更适合读我们的 Claude Code 最佳 MCP 指南。如果问题仍然只和 memory 有关，就先守住最轻的接入面，等连续性问题自己证明它值得更重的基础设施。顺序也很简单：先个人验证，再 remote，最后才 project-shared。你一旦反过来做，通常就是先上基础设施、后找场景。
怎么识别 memory-MCP 宣传是不是在放大词
external memory 市场是真实存在的，但不能把它当官方产品真相来读。Anthropic 官方文档只负责说明 Claude Code 默认已经做了什么；第三方产品页面只说明市场正在试图解决什么。
最快的判断方法，是把每个宣传词都翻译成一个可操作的问题：
Persistent memory：到底持久到哪里？是/compact后还在、跨工具还在、跨机器还在，还是团队都能读到？Works with Claude：它是在通过 MCP 扩展 Claude，还是文案在暗示它属于 Claude 默认内建能力？Shared memory：谁拥有数据、谁能写、谁要为脏上下文和 prompt injection 负责？Easy setup：是对一个开发者来说简单，还是对整个 repo 而言也可维护？
这些问题重要，是因为错误升级的代价不只是“没帮上忙”。它还可能把低可信、过宽泛、已经过时的外部内容再送回模型。正确顺序应该是：先相信官方文档给出的 built-in 基线，再根据精确收益、所有权模型和维护成本去评估外层值不值得加。
很多人现在最该做的，其实是什么都别加
对不少读者来说，看完之后最好的动作仍然是不安装任何 memory MCP。这不是保守过头，而是更高价值的建议。
如果你现在的问题仍然符合下面这些情况，就先不要加外层：
CLAUDE.md里的仓库规则还没写清楚- auto memory 已经很脏，或者在做本该由显式规则承担的事
- 你还没跑过
/memory，不知道当前到底加载了什么 - 真正的痛点更像上下文膨胀，而不是连续性缺口
- 你仍然只在单机、单仓库工作流里工作
在这些场景里，再加一层 memory server 大多是在掩盖问题，而不是解决问题。还有一种常见误判也要避免：有时你缺的根本不是 memory，而是更强的 repo 内工作流约束，或者更广泛的外部工具接入。前者更像 instruction/skills 问题，后者才是更宽的 MCP 选择问题。把“先别加”放进决策本身，通常比把它留到最后更有价值。
FAQ
Claude Code 默认就需要 memory MCP 吗？
通常不需要。只要问题还停留在仓库规则、学习习惯、单机连续性这些层面，先把 CLAUDE.md 和 auto memory 用对，比外接一层更值。
Claude Code 默认已经会记住什么？
它已经通过 CLAUDE.md 提供显式规则层，通过 auto memory 提供学习层。但这两层都是有边界的，不等于一个普适共享记忆库。
什么情况下 /compact 才算真的把你推向外部层？
当关键上下文反复在 /compact 之后消失，而且它需要活在聊天之外时，外部层才开始合理。如果只是规则从来没写进 CLAUDE.md，那先修内建层。
应该先装插件，还是直接连 remote MCP？
先选最轻的个人接入面，把问题验证清楚。只有外部检索或外部持久化本身就是核心价值时，remote MCP 才值得更早出现；project-shared 还要再晚一步。
什么时候最该什么都别加？
当你还没有理清 CLAUDE.md、auto memory、/memory 和上下文边界的时候。那时更好的内建记忆卫生，通常比新增一个外部 dependency 更有用。