最近围绕 Claude Code 记忆系统的几篇文章，让我重新认真想了一遍一个其实已经被说滥、但直到今天仍然没有被真正说清的问题：大模型为什么需要记忆？
表面看，这像一个早就有标准答案的问题。模型上下文有限，所以要把过去的信息存起来；用户会重复表达偏好，所以系统要记住；Agent 要跨会话持续工作，所以需要长期知识。于是大家很自然地说：给模型加 memory，问题就解决了。
但真正做过 Agent、做过编程助手、做过长期协作系统的人，通常都会很快撞上一堵墙：记忆并不是一个统一的东西。
把聊天记录存下来，和把经验沉淀成知识，不是一回事；把知识提炼出来，和让系统下次真的按这个知识行动，也不是一回事。很多系统看起来“有记忆”，但它们真正拥有的，往往只是一个能够回捞历史文本的仓库。仓库不是没价值，但仓库本身并不会自动变成经验，更不会自动长成判断。
所以我想讨论的，并不是 Claude Code 泄露本身，而是那几篇文章共同碰到的那个更本质的问题：为什么大模型系统不能再把记忆当成一个统一概念处理，而必须走向分类记忆。
一、真正的问题不是“能不能记住”，而是“到底记住了什么”
今天很多关于 AI 记忆的讨论，最大的问题不是方向错了，而是概念太糊。大家都在说 memory，但说的其实完全不是同一个东西。
有的人说的是 transcript，也就是会话原文；有的人说的是向量检索；有的人说的是用户画像；有的人说的是偏好规则；有的人说的是任务状态；还有的人说的是一种更难描述的东西：系统在反复做事之后慢慢形成的“做法”。这些内容都能被持久化，但它们在功能上根本不是同一类对象。
如果不把这些层拆开，后面很多工程判断都会越来越乱。因为系统会同时面临几个互相冲突的要求：
- 它既要保留原始经历，方便追溯；
- 又要压缩和抽象，避免上下文爆炸；
- 既要知道事实和规则；
- 又要在未来真的改变行动方式；
- 既要长期保留稳定信息；
- 又要让大量临时噪声自然过期。
把所有这些责任都塞给一个叫 memory 的大抽屉，听起来简洁，实际上只是把复杂性藏了起来。最终系统会变成一种很熟悉的样子：什么都存了一点，什么也没真正管好。
这也是为什么我越来越觉得，今天讨论大模型记忆，最该先做的不是选数据库，不是选 embedding，不是选图谱，而是先把一句话说清楚：记忆在系统里到底承担哪些不同职责。
二、Claude Code 的启发，不在于它“记忆很强”，而在于它很克制
围绕 Claude Code 的那几篇分析稿，写法虽然不同，但隐含着一个很一致的判断：它的记忆设计并不花哨，甚至从某些角度看显得有点朴素，但它抓住了一个今天很多系统反而会忽略的重点——记忆要服务执行。
这句话听上去不新鲜，但其实很少有人真按这个原则设计系统。因为一谈记忆，大家天然会想做“大”：更多存储、更强召回、更复杂检索、更完整的知识底座、更细的画像层次。可 Claude Code 这条路线更像是在反过来问：对于一个真正要长期写代码、查文件、跑命令、修问题的 Agent 来说，记忆最先要解决的到底是什么？
答案未必是“拥有一个尽可能完整的人生档案馆”。更现实的答案常常是：
- 当前项目约定别丢；
- 用户刚纠正过的偏好别丢；
- 已经踩过的坑别丢；
- 已经验证过的做法别丢；
- 连续执行中的理解不要蒸发。
换句话说，它优先解决的是防漂移，而不是先解决“全知”。这两种路线差别非常大。
很多人一说长期记忆，就默认目标是建立一个宏大、完备、可跨很长时间统一召回的知识系统。这个目标当然很有吸引力，也确实在很多场景下值得追求。但 coding agent 的现实工作流，很多时候并不是“先把世界建模完整，再开始行动”，而是“我现在就要去做事，理解会在做事过程中逐渐形成”。在这种情境里，记忆系统最重要的职责，不是替系统营造一种虚假的全貌，而是确保那些在行动中形成的关键理解不会在几轮交互后消失。
这就是 Claude Code 路线最值得重视的地方：它不是在证明“轻记忆一定优于重记忆”，而是在提醒我们，记忆设计的好坏必须放回任务场景里讨论。
三、为什么我越来越确信，大模型必须走向分类记忆
我现在基本不再相信“统一 memory 模块”这套想法了。不是因为它在理论上不够优雅，而是因为它在工程上很容易变成一种含混。
如果硬要把今天 Agent 系统里的记忆压成几个最有意义的维度，我会更倾向于这样拆：
- 记录发生过什么的记忆
- 沉淀知道什么的记忆
- 影响以后怎么做的记忆
这三种东西都可以叫记忆，但它们的写入时机、保留周期、可靠性要求、读取方式、对未来动作的影响路径都完全不同。
1. 记录“发生过什么”的，是情境层
这类记忆最容易理解，因为它最像日志。
对话原文、工具调用、报错、尝试过的命令、用户当时给出的纠正、某次失败是怎么发生的，这些都属于“发生过什么”的痕迹。它们的价值在于保留现场。没有这层原始材料，系统后面就很难做更稳的抽取、更可靠的复盘、更准确的责任划分。
但这层内容同时也最危险，因为它天然冗余、天然嘈杂、天然容易膨胀。一次长 session 里，大量中间猜测和错误分支都只是过程噪声。如果系统把这层内容直接等同于长期知识，就等于把原始流水账当成了结论。
所以情境层最重要的不是“永远可见”，而是保留证据，供后续提炼。它像原材料，而不是最终产品。
2. 沉淀“知道什么”的，是语义层
系统不是只需要知道某次会话里用户说过一句什么话，它更需要知道：从很多具体经历里，已经能够稳定抽出来哪些知识和规律。
比如：
- 这个项目默认使用 pnpm，不用 npm；
- 这个目录下是 API handler，不是业务逻辑；
- 这个用户不喜欢在低风险内部动作上反复确认；
- 这个团队习惯先给 plan，再改代码；
- 这个仓库的测试入口是什么；
- 某条接口约定已经在前几轮任务里被反复验证过。
这些内容已经脱离了某次具体会话，变成了可复用知识。它们更像笔记、约定、模式和事实，而不是原始现场。
语义层最重要的要求有两个：第一，要足够稳定，不要把一次临时猜测写成长期真理；第二，要尽量可读、可审计、可修正。后者其实非常关键。工程师不喜欢一个完全黑箱的长期记忆层，因为黑箱很难建立信任。Markdown、结构化笔记、主题文件、索引式入口这些做法，看起来不够“先进”，但它们有一个非常强的优点：人可以直接理解它们。
3. 影响“以后怎么做”的，是程序层
真正最难的，其实是这一层。
很多系统会说自己记住了用户偏好，但严格来说，它们记住的往往只是一段文本，而不是一种行为倾向。文本被放进 prompt，并不自动等于系统形成了“下次默认怎么做”的稳定路径。
程序层关心的不是系统知不知道一条规则，而是它在未来面对类似情境时，会不会更自然地走向某种成熟做法。
这层记忆更像：
- 遇到多步任务时先写计划；
- 碰到高风险外部动作先确认；
- 对低风险内部执行直接推进；
- 遇到飞书相关操作先走 lark-cli，而不是浏览器；
- 被用户明确纠正过的坏习惯不要反复犯；
- 被用户认可过的好做法要逐渐变成默认手感。
你会发现，这里已经不是“知识存储”那么简单了，而是在谈一种接近技能和工作风格的沉淀。这类记忆的价值不在于它能不能被搜索到，而在于它是否真的会改变未来的行为。
这也是为什么我非常认同那几篇文章里一个共同判断：如果一个系统只记录负反馈——也就是只知道什么不能做——它最终很可能越来越保守。因为它只学会了避错，却没学会什么是对的。一个成熟的程序层记忆，必须同时包含：
- 错误边界
- 成功路径
只有这样，它才不会越学越胆小，而是越学越稳。
四、分类记忆不是理论洁癖，而是工程现实
一旦把这三层分开看，很多工程问题就变得特别清楚。
为什么不能把 transcript 和长期知识混成一层？因为原始经历里噪声太多，直接长期化只会污染系统。
为什么不能把事实知识和行为规则混成一层？因为“知道什么”不等于“怎么做”，前者主要影响判断，后者直接影响执行流程。
为什么短期任务状态和长期用户偏好不能混成一层？因为它们的保鲜期完全不同。一个是今天就会失效的上下文，一个是长期有效的协作模式。
为什么统一记忆层很难设计合理的遗忘机制？因为不同信息压根不该按同一种生命周期管理。有些东西应该很快过期，有些应该长久保留，有些则应该在多次重复后被强化。
所以“分类记忆”并不是为了把认知科学的名词搬进产品，而是因为如果不分类，系统根本没法决定什么该怎么存、什么时候读、什么时候忘、什么时候巩固、什么时候改变行为。
换句话说，分类记忆本质上解决的是治理问题，而不是命名问题。
五、为什么“轻记忆、重执行”是一个被低估的方向
很多人看到 Claude Code 这种路线，会本能觉得它不够宏大。没有特别重的长期知识图谱，没有特别炫的全局语义召回，没有一种“我拥有完整记忆操作系统”的雄心。但如果回到编程 Agent 的现实场景，我反而觉得它抓住了一种特别容易被忽略的价值：低摩擦。
所谓低摩擦，不只是实现轻，而是记忆能够很自然地嵌进执行循环，不把自己变成另一套沉重的系统负担。
对于真正长期干活的 Agent 来说，这一点太重要了。因为执行不是论文里的静态任务，而是一连串动态动作：读文件、搜索、推理、修改、跑测试、读报错、再改、再验证。理解并不是先验给定的，而是在这个过程中不断生长出来的。那记忆系统最应该做的，就是把这些在行动中形成的关键理解留住，而不是逼系统在每次行动前都先通过一整套重型基础设施才能“想起来自己是谁”。
这也是为什么我越来越觉得，未来好的 coding agent 记忆系统，很可能都不会是那种单一的大一统记忆仓。它们更可能是：
- 底层保留原始经历；
- 中层沉淀稳定知识；
- 上层塑造行动规则；
- 需要时按作用域和时机把合适的部分拉进来。
这套体系看起来没那么性感，但它非常符合真实工作的节奏。
六、重型记忆路线也重要，但它解决的是另一类问题
这并不是说 LangMem、Mem0、Zep、MemOS、EverMemOS 这些更重型的记忆路线不重要。恰恰相反，我认为它们代表的是另一个同样非常关键的方向：让 memory 从一个附属能力升级成一种系统级资源。
比如有的框架很强调作用域分层，关注 session、user、organization 各自应该记什么；有的框架很强调知识图谱与 Graph RAG，希望把长期事实和关系组织得更细；有的框架干脆就是在重新定义 memory runtime，希望记忆的存储、更新、召回、遗忘都变成一种可编排、可治理的基础设施。
这些方向当然非常重要，尤其适合那类目标更宏大的系统：长期陪伴型助手、跨场景连续工作的代理、多模态个人档案系统、企业知识中台式 Agent 等等。
但如果回到 Claude Code 这类工具，我们就会发现：它不是在和这些系统竞争“谁更完整”，而是在做另一种取舍。它接受自己的主要战场是“连续执行”，所以它让记忆围绕执行收敛，而不是让执行围绕记忆让路。
这并不是保守，而是非常明确的场景判断。
七、OpenClaw 给我的另一个提醒：记忆的关键不只是存什么，还有什么时候用
看完这些讨论后，我另一个更强的感受反而来自对 OpenClaw 这类系统的再理解。它们提醒我，记忆设计里还有一件经常被忽略的事：调用时机。
很多人谈 memory 时，会默认最理想的状态是“系统自动把一切相关内容都提前装进上下文”。但真实工作里，人并不是这样用记忆的。我们也不是时时刻刻背着所有经验，而是在具体问题冒出来时，调动合适层级的过去。
如果系统没有这个“按时机调用”的能力，即使你把一大堆东西都存好了，也很可能只是制造新的噪声。它会在不需要的时候回忆太多，在真正需要的时候又抓不到重点。
所以记忆系统成熟与否，不只是看它能存多少、检多少，还要看它能不能回答：
- 什么时候应该调用原始经历？
- 什么时候应该调用稳定知识？
- 什么时候应该调用行为规则？
- 当前任务只需要局部记忆，还是需要更长期的背景？
这其实再次证明了，记忆如果不分类，就连“何时调用”都无法被好好设计。
八、最终我真正认同的一句话是：记忆不是仓库，而是转化机制
如果让我把这些天看下来的所有文章、所有分析、所有比较压成一句最值得保留的话，那会是：记忆最重要的不是存储，而是转化。
经历如何变成知识，知识如何变成行动倾向，行动又如何在下一轮经历里继续修正自己——这才是记忆系统的核心闭环。
如果只存 transcript，没有抽象，那你得到的是噪声仓库；
如果只存事实，没有行为反馈，那你得到的是一个客服知识库；
如果只存纠错，不存成功路径，那你得到的是一个越来越保守、越来越会犹豫的代理；
如果只想做最宏大的长期知识底座，却忽略执行循环中的低摩擦需求，那你可能会做出一个论文上很漂亮、产品上却很难真正好用的系统。
Claude Code 这次引发讨论的价值，不在于它是不是“最强记忆系统”，而在于它逼我们重新面对一个已经被大量空话淹没的问题：记忆到底是用来干什么的。
我的答案是：不是为了显得系统“有连续性”，而是为了让这种连续性真的在下一轮行动中产生作用。
也正因为如此，我越来越确信，大模型最终一定会走向分类记忆。因为只有分类，系统才能真正区分：
- 什么是现场，什么是知识；
- 什么是知识，什么是技能；
- 什么该快速遗忘，什么该长期保留；
- 什么该在会后抽取，什么该在后台巩固；
- 什么只是能被找到，什么必须真的改变做法。
这才是记忆从“仓库”变成“能力”的分水岭。
说到底，一个真正成熟的系统，不该只是比别人存得更多，而应该比别人更知道：哪一段过去，应该在什么时候，以什么形式，回来影响现在。
这才是分类记忆真正值得认真讨论的地方。