做了 3 个月 AI 产品才明白：记忆分三层，最难的那层叫遗忘-拓冰建站

我有一段时间特别不理解一件事

为什么我每次在 AI 对话工具里新建一个窗口，它就完全不认识我了？上一个对话里我刚告诉它我是做 AI 产品的、我喜欢用什么写作风格、我的项目背景是什么。切到新窗口，全没了。它会用一种礼貌但陌生的语气跟我打招呼，就像我们从来没见过

直到我去深度调研了一个叫 Elys 的 AI 社交产品

Elys 做了一件很前卫的事：它让用户创建一个 AI 分身，这个分身会学习你的说话方式、你的偏好、你的价值观。学完之后 24 小时替你在社交平台上浏览、点赞、评论、筛选连接。听起来很酷，AI 替你社交，你只在关键时刻接手

它在记忆上投入了巨大的精力。从 128 个动态记忆槽位到多维 graphRAG，技术迭代做了好几代。内测首日 50 万注册，邀请码在闲鱼被炒到 100 块一个

可四个月后，App Store 的评分从 3.8 掉到了 3.24

用户反馈里最有杀伤力的一条差评是这么写的：分身对话几百句之后变成了复读机，拿着关键词不分语境到处评论，我反而想撤回它说的话。“既然我都想撤回了，那这个'代我社交'的出发点就矛盾了”

你看，记住你不等于理解你。AI 有了记忆之后，做错事的成本反而更高了。因为它不是“不知道”你是谁，它是“以为自己知道”你是谁，用一种自信但跑偏的方式替你行动

这让我意识到一个很多人都没想清楚的事情：Memory 不是一个功能开关，打开就升级，关掉就降级。它是一套系统工程，设计得好是护城河，设计得不好是定时炸弹

这篇文章想做的事情就一件：把 Memory 这个被说烂了但其实大部分人都没真正理解的东西拆清楚。我会从最底层讲起：Memory 到底是什么，它跟你以为的“聊天记录存下来”有什么本质区别，为什么记住所有东西反而是最差的策略，以及为什么“遗忘”才是 Memory 系统里最难设计的那个能力

如果你正在做 AI 产品、或者你在考虑怎么给自己的产品加上记忆能力，这篇文章应该能帮你少踩一些坑

第一章：Memory 是什么

很多人对 AI 的 Memory 有一个直觉理解：就是把聊天记录存下来，下次能调出来用

这个理解不能说错，但它跟真正的 Memory 系统之间的差距，大概相当于“我有个记事本”和“我有一个能自己整理、筛选、更新、甚至主动遗忘的大脑”之间的差距

想理解 Memory，最好的类比对象不是硬盘，是人脑

硬盘做的事情很简单：你存什么它就放什么，存了不变，调出来原封不动。100G 的文件存进去，十年后拿出来还是那 100G，一个字节都不差

人脑完全不是这样。你昨天中午吃了什么？你可能要想一下才能回忆起来。你三个月前某个周二中午吃了什么？大概率你完全不记得了。但你初恋跟你说的第一句话是什么？你可能记得清清楚楚

这说明人脑的记忆不是“存储”，是“管理”。它在不断地做筛选：什么该留、什么该扔、什么该从短期转入长期。这套筛选机制不是你主动控制的，是你的大脑在后台自动运行的

好的 AI Memory 系统在做的事情，本质上就是在模拟人脑的这套机制

Memory概念

说得再直接一点。在 AI 的语境里，Memory 指的是一套让模型能够跨对话、跨时间段保留和使用信息的完整系统。它至少包含四个核心能力：存储（信息放在哪里）、检索（怎么在需要的时候找出来）、更新（新信息进来了怎么处理旧的）、清理（什么时候该把过时的信息扔掉）。这四个能力缺一个，Memory 都跑不起来

这里要区分一个容易混淆的概念。你跟 AI 聊天的时候，它在当前这一轮对话里是“记得”你前面说过什么的，这靠的是上下文窗口，本质上就是一个短期缓冲区，对话结束就清空了。真正的 Memory 是跨越对话边界的持久化能力，是你关掉窗口、过了三天再回来，AI 还知道你是谁、你上次在干什么

大部分 AI 模型在默认状态下是没有跨对话记忆的，就是每次对话完就清零的那种。它们是怎么工作的？每次对话就是一次完整的输入→处理→输出的循环。你说一句话，它根据这句话（加上本次对话里之前的几句话）给你一个回应。对话结束，一切归零。下一次对话，它对你一无所知

这就是为什么你每次开新窗口它都要重新认识你。它根本不知道有过“上一次”

有 Memory 的 AI 则不一样。它有了“上下文的延续感”，它知道你上次提到过什么项目、你喜欢什么风格、你讨厌什么表达方式。这种延续感让 AI 从一个“每次都从头来的工具”变成了一个“越用越懂你的助手”

这个区别听起来简单，但背后的设计决策一点都不简单：存什么？怎么调出来？什么时候该清理？这些问题的答案，决定了一个 Memory 系统是好用还是灾难

这些问题其实一直都在。过去几年行业里有一种乐观的想法：上下文窗口越做越大，从 4K 到 128K 到 200K，总有一天大到可以把所有历史都塞进去，Memory 问题自然就解决了。可2026 年大家发现这条路走不通。

为什么？两个原因

窗口确实变大了，但问题反而更严重了。因为窗口越大，你往里面塞的垃圾信息就越多，每次推理的 Token 成本就越高。上下文窗口不是记忆，它更像你的工作台。桌面越大不代表你工作效率越高，如果桌面上堆满了无关的东西，你反而更难找到你真正需要的那份文件

另一个是 2026 年 AI Agent 产品集中爆发。Agent 跟传统的对话式 AI 有一个根本区别：它需要持续运行、持续学习、持续跟环境交互。一个对话机器人可以每次对话完就失忆，但一个替你管理项目、替你写代码的 Agent，每次启动都从零开始的话，它永远停在“我是谁、我在哪、我该干嘛”的阶段

这就是为什么 Memory 突然从一个“锦上添花的功能”变成了“决定产品生死的基础设施”

但大部分人对 Memory 的理解，还停留在最表层。我把它拆成了三层认知，接下来一层一层讲。你可以对照着看自己在哪一层，以及你的产品在哪一层

第二章：第一层认知：“记住”

这是大部分人对 Memory 的理解。包括很多正在做 AI 产品的产品经理

这一层的核心假设是：记住 = 存下来 = 有用

实现方式通常也很直觉。最简单的做法是消息过滤，只保留最近 N 条消息在上下文里，太老的直接丢掉。稍微进阶一点的做法是消息摘要，对话太长了就用 LLM 跑一遍生成一段摘要，把原始消息删掉，用摘要替代。再往前走一步就是持久化，把用户说过的一些信息存到一个键值对或者数据库里，下次对话的时候把相关的信息捞出来塞进上下文

LangChain 的 checkpointer 机制就是这一层的典型代表。它的做法是每个对话线程维护自己的状态，checkpointer 负责保存和恢复这个状态。你可以按消息数量筛选、按 Token 数量筛选、按消息类型筛选（比如优先保留人类和 AI 的消息，丢掉工具调用的消息）。这些都属于“第一层认知”的实现方式

这一层有没有价值？当然有。它解决了最基础的“金鱼脑”问题。你不需要每次对话都重新介绍自己，AI 至少知道你上次说了什么。对于简单的场景，比如一个客服机器人需要记住本次对话用户提的问题，这一层完全够用

但这一层的局限非常明显

第一个问题是成本

让模型全部记住是要花钱的。每次对话把全量历史塞进上下文，Token 成本是线性增长的。一个活跃用户每天跟 AI 聊 20 轮，连续用两周，你攒下来的对话历史可能有好几万 Token。每次新的对话都要把这些全部传进去，光上下文的 Token 消耗就可能吃掉你大部分的推理预算。而这些 Token 里面有多少是真正对当前对话有用的？可能 10% 都不到

第二个问题是污染

所有信息被一视同仁地塞进上下文，不分轻重、不分新旧。你三个月前说“我最近在看 React”，现在你已经转去做后端了，但那条信息还在。AI 可能会基于过时的信息给你推荐 React 的学习资源，它不知道这条记忆已经过期了，因为在它眼里所有记忆的权重是一样的

第三个问题是没有体系

这一层的 Memory 就像一个什么都往家里搬的囤积症患者。家里东西越来越多，但你找不到任何一样你真正需要的东西。而且你越堆越多，找东西的成本越来越高，最后你可能花在“翻找”上的时间比花在“使用”上的时间还长

这里有一个很关键的认知需要刷新

LangChain 团队，也就是目前最流行的 AI Agent 框架的开发者，在分享他们构建 LangGraph 的经验时说了一句很有分量的话：“我们并不看好通用记忆抽象或服务的想法”

这句话打中了很多产品经理的一个幻想：找一个通用的 Memory 中间件接进自己的产品，开箱即用，问题就解决了

LangChain 的判断是相反的。他们认为记忆必须是应用特定的：“它需要针对你试图做的事情和你可能想记住的东西来定制，因为这才是让你的应用变得更好的关键”。不存在一个万能的记忆方案能同时适用于客服机器人、编程助手和社交产品

为什么？因为不同场景下“什么值得记”的定义完全不同。一个编程助手需要记住你的代码风格偏好，但不需要记住你每次修改了哪一行代码（这可以从 Git 历史里看到）。一个社交产品需要记住你的兴趣标签，但不需要记住你每次刷了哪些帖子。如果你不分场景地把所有信息都存进去，你得到的只会是一个更贵、更乱的 AI

再看一个具体的成本数据。Mem0 是目前最成熟的开源记忆中间件之一，支持 17 家 LLM 提供商、11 种 embedding 模型、22 种向量数据库，生态很完善。但它有一个问题：每次 add 操作（也就是存入一条新记忆）需要调用 2-5 次 LLM。如果你的产品是高频交互场景，每轮对话都想存点什么，这个成本会非常可观。“记住”不是免费的，每多记一条，你就多付一笔账单

这就是第一层认知的天花板。它能让 AI 不再是金鱼脑，但它解决不了“记了一堆没用的东西导致成本飙升”的问题，也解决不了“旧信息污染新推理”的问题

那怎么办？你得学会分类。不是所有信息都值得被同等对待

第三章：第二层认知：“断舍离”

从这一层开始，Memory 的设计哲学发生了一个根本性的转变

第一层的思维方式是“怎么记更多”，第二层的思维方式是“怎么把不同的东西放在不同的地方”

有一句话我在研究 Memory 架构的过程中反复看到，出处是对 Hermes 这个 AI Agent 框架的深度分析：“它追求的从来都不是什么都记住。它追求的是把不同类型的记忆放进不同层次，用合适的生命周期和成本模型去管理它们”

这句话基本上就是第二层认知的一句话总结

那具体怎么分？我拆了两个最有代表性的架构给你看：Claude Code 和 Hermes。它们的分法不一样，但底层逻辑高度一致

Claude Code：六层记忆体系

Claude Code 是 Anthropic 推出的 AI 编程助手，它的记忆系统在同类工具里设计得最完整。它把记忆分成六层，每一层的存储位置、生命周期和触发条件都不一样：

指令记忆：基于配置文件（CLAUDE.md）的多层加载系统。从全局到本地有明确的优先级，最后加载的覆盖先加载的。这一层存的是“规则”，你希望 AI 在所有项目里都遵守的习惯、某个特定项目的特殊要求

短期记忆：当前会话的完整对话历史，就是你这次聊了什么。不压缩地存在内存里，对话结束就没了

工作记忆：当前任务的进度、状态。比如你让它改一个文件，改到哪一步了、中间遇到了什么问题。任务结束就清除

长期记忆：这是最核心的一层。基于磁盘上的 Markdown 文件做分层知识库。但最反直觉的设计在这里：它严格规定了只有四种信息值得被长期记住：用户画像、行为反馈（包括正面和负面的）、项目上下文、外部引用

代码模式、架构分析、文件路径呢？全都不存

为什么？因为这些信息可以从代码本身推导出来。你存了一份“这个项目用的是 TypeScript + Next.js”的记忆，三个月后项目迁移到了 Python，这条记忆就变成了污染源。而如果你不存它，AI 每次直接看代码就知道现在用的是什么语言。可推导的信息不该占记忆资源。这是一个很容易被忽视但极其重要的原则

而且这条原则背后还有一层成本逻辑：你多存一条无用的记忆，它就会在之后的每一次推理里都占一份 Token 的位置。长期记忆的索引被限制在 200 行以内、每行不超过 150 字符、总大小不超过 25KB。这些数字都是刻意设定的，目的就是用硬上限防止记忆膨胀带来的成本失控

摘要记忆：对话过程中持续维护一份会话笔记，不是等到要压缩的时候才临时生成摘要。它包含对话标题、工作状态、关键文件、错误修正等信息。这样即使对话被压缩了，核心脉络还在

休眠重塑记忆：这个后面第四章会详细讲，这里先知道有这一层就行

你看，六层记忆的重点在于“六种不同的生命周期管理策略”。有的信息只活一次对话，有的信息永久保留但要严格筛选入场资格，有的信息在后台被定期重组。这才是“分层治理”的意思

还有一个设计细节值得单独拎出来说。Claude Code 做了一个“双轨注入”的设计：指令记忆通过对话消息通道注入，行为规范通过 System Prompt 通道注入。两者独立管理缓存和 Token 预算，互不干扰。这意味着你更新了一条指令记忆，不会导致行为规范的缓存失效，也就不会触发额外的 Token 消耗。这种级别的工程细节，如果你不拆源码很难看到，但恰恰是这些细节决定了一个 Memory 系统在大规模使用时能不能控制住成本

Hermes：四层记忆 + 两个反直觉的设计决策

Hermes 是另一个开源的 AI Agent 框架。它的分层比 Claude Code 简洁，四层：工作记忆、内建长期记忆、完整历史、外部 Memory Provider

分层方式不用细说了，逻辑跟 Claude Code 类似。我想重点讲 Hermes 做了两个让人一开始觉得“这是不是搞错了”但想明白之后会觉得“真聪明”的设计决策

第一个：写入与生效分离

在 Hermes 的架构里，当你告诉 AI 一条新信息，比如“我换工作了，现在在做后端”，这条信息会立刻被写入硬盘。落盘成功了，存下来了

但它不会立刻在当前会话里生效

什么意思？就是你告诉 AI “我现在做后端了”，它说“好的记住了”，但它接下来跟你聊天的时候，用的还是旧的上下文（可能还以为你在做前端）。你新写入的这条记忆，要等到你开一次新会话才会被加载进来

这听起来像 bug 对不对？但这是一个刻意的设计

原因是System Prompt 在会话启动的时候会被冻结成一个快照，整个会话期间复用这个快照。对于支持 Prefix Cache 的模型（Claude 和 GPT-5 都支持），如果 System Prompt 在会话中途变了，前缀缓存就会失效，需要重新计算。这意味着每次你往长期记忆里写入一条新信息，如果立刻刷新 System Prompt，就等于放弃了之前所有的缓存优势。推理成本和延迟都会上升

Hermes 的选择是：宁可牺牲“立刻生效”的体感，也要保住前缀缓存的成本优势。这是一个典型的“用一点用户体验换一大块运营成本”的产品决策。做 AI 产品的人看到这里应该深有体会，谁都想做到完美，但成本不允许

第二个：稳定事实与事件流的刻意分离

Hermes 明确区分了两类信息，而且拒绝把它们混在一起：

稳定事实：你的名字、你的编程语言偏好、你团队的技术栈约定。这些信息不太变化，变了也是低频的。它们被存在精选记忆里（Memory.md 和 User.md），有严格的字符预算：Memory.md 默认 2200 字符，User.md 默认 1375 字符。超了就不让存了，硬上限

事件流：你上次改了哪些函数、试过哪些失败的方案、跑了哪些测试命令。这些信息是高频变化的，而且大部分只在特定时间段内有用。它们被保留在完整历史数据库里（state.db），支持全文搜索，但不会被塞进 System Prompt

这两者的查询方式完全不同。稳定事实在每次开新对话的时候会自动带上，成本固定、位置固定。事件流通过 Session Search 按需检索，先用关键词搜到相关的 Session，再交给辅助模型做定向摘要。而且它有个很聪明的设计：搜索的时候会排除当前 Session 的历史，避免“自我污染”。不会因为当前对话里反复提到某个关键词，就错误地认为这个信息很重要

很多 AI 系统最后输就输在上下文层次混了、历史污染了、Session 边界不清楚。这句话是对 Hermes 架构分析里最有分量的判断之一。它也解释了为什么“分层”绝对不是锦上添花。不分层的代价是系统级的混乱

人脑最被低估的能力

讲到这里你可能会问：这些 AI 系统为什么要搞得这么复杂？为什么不能像硬盘一样全存下来、需要的时候搜一下就行？

因为人脑也不是这么工作的。而 AI 的 Memory 系统如果不学人脑，最终都会撞上同样的墙

艾宾浩斯遗忘曲线是心理学里的常识，新学的东西如果不复习，20 分钟后忘 40%，一天后忘 70%，一个月后基本只剩下一点碎片。大部分人把这个曲线当成“人脑的缺陷”来看，为什么我记不住东西啊，好烦

但换一个角度想：如果你什么都记得呢？

有一种罕见的状况叫超忆症（Hyperthymesia），患者可以记住人生中每一天的几乎每一个细节。听起来像超能力，但实际上这些人的生活非常痛苦。因为他们无法从海量的记忆中筛选出当下真正需要的信息。每一个负面的记忆都像昨天刚发生一样清晰，每一次决策都被无数个互相矛盾的过往经验拖住

遗忘不是 bug，遗忘是 feature

人脑的海马体每天都在做一件事：筛选。什么信息值得从短期记忆转入长期记忆？什么信息可以让它自然衰减？什么信息需要在睡眠时重新整理和巩固？这套筛选机制跟上面讲的 AI Memory 系统做的事情几乎一模一样：分层、筛选、有预算限制、有生命周期管理

Claude Code 限制长期记忆索引 200 行，本质上就是给 AI 的“长期记忆区”设定了容量上限，跟人脑的海马体筛选机制异曲同工。Hermes 区分稳定事实和事件流，本质上就是模拟人脑对“核心记忆”和“日常琐事”的不同处理方式

到这里可以回头看一下 Elys 的问题。Elys 的记忆飞轮在设计方向上是对的，用户每投喂一条 context，分身就更像你，分身再从网络上带回更好的连接，形成正循环。这个设计对应的正是“持续积累用户的高维上下文”

但冷启动阶段出了问题。记忆飞轮的逻辑是“用得越久越像你”，这意味着新用户必须先熬过一段分身质量很差的低谷期。分身在没有足够 context 的时候，只能退化成通用 LLM 的礼貌回复模式，什么都能说两句但什么都不像你。App Store 评分从 3.8 跌到 3.24，本质上就是飞轮还没转起来的时候，用户已经失去耐心走了

这是一个产品设计层面的记忆初始化问题。如果你的 Memory 系统需要大量数据才能展现价值，那你必须设计一套“冷启动校准”机制，让用户在第一天就能感受到“这个 AI 有点懂我”。不能等飞轮慢慢转，因为用户的留存窗口可能只有几分钟

好，第二层认知讲到这里。总结一下这一层的核心收获：

不是所有信息都值得被同等对待。好的 Memory 系统会把不同类型的信息放进不同的层次，用合适的生命周期和成本模型去管理它们。可推导的不存、过时的该清、高频变化的和低频稳定的分开放、注入方式和缓存策略独立管理

这已经比第一层认知高了一个量级。但这里有一个前提：所有这些规则都是人提前定好的

什么信息存、什么不存、存多久。这些都是产品经理和工程师在设计阶段就决定好的。系统按照这些规则执行，不多做也不少做

那问题来了：如果环境变了呢？用户的偏好变了、项目换了方向、旧的记忆跟新的事实产生了矛盾，谁来更新？谁来清理？靠用户自己手动删除过时的记忆？在 Agent 场景下，这根本不现实

这就是第三层认知要解决的问题：系统得自己学会：什么该留，什么该丢

第四章：第三层认知：“遗忘”

前两层讲的都是“怎么记”。这一层讲的是一个更高阶的能力：让 AI 自己学会整理、学会遗忘、学会在你不在的时候自己进化

Letta 的联合创始人 Charles 说过一句话，让我印象很深：“我认为学习实际上是当今 LM 驱动 AI 中根本缺失的部分。我们构建的很多代理实际上没有学习能力”

他说的“学习”跟微调模型没关系。他指的是 Agent 能不能从过去的交互中提取经验、更新自己的记忆、纠正错误的认知、丢弃过时的信息。大部分 Agent 做不到这件事。它们在用户离开之后就完全休眠了，错失了在后台学习和整理的机会

第三层认知的核心，就是打破这种“用户不在就停工”的模式

睡眠时间计算

这个概念也是 Charles 提出来的，他把它叫做“Sleep-time Compute”（睡眠时间计算）

大家可能听说过“Test-time Compute”（测试时间计算），就是 o1 模型那种在回答问题之前多想一会儿的能力。你问一个复杂问题，模型不急着回答，先在内部推理一阵子，最后给你一个更高质量的回答。这已经被证明非常有效

睡眠时间计算是这个思路的极限延伸，不仅在用户提问时运行更久，而是尽可能一直运行。用户上传了一份文档，AI 不等你问，自动在后台分析内容、生成记忆摘要。编码代理在等待你下一条指令的时候，自动去索引代码库、爬取项目的 Issue 列表。游戏代理在对话间隙，自动整理用户偏好、合并冗余记忆

这种异步、持续的计算模式，让 Memory 从“被动存储”变成了“主动进化”。AI 不再是一个等你投喂信息的容器，而是一个能自己消化信息、自己成长的智能体

Claude Code 的 AutoDream

如果“睡眠时间计算”是一个概念，那 Claude Code 的 AutoDream 就是这个概念最完整的工程实现

AutoDream 的名字本身就很有意思，Auto Dream，自动做梦。你睡觉的时候大脑也没闲着，它在整理白天接收的信息、巩固重要的记忆、清理不需要的碎片。AutoDream 做的是同一件事，只不过对象是 AI 的记忆库

它的触发条件是双重门控：至少过了 24 小时，而且有 5 个不同的会话产生了新的记忆。两个条件都满足才会启动。这个设计避免了两种极端：不会因为一次对话就疯狂整理（太频繁了，浪费算力），也不会积累了几百条记忆还不整理（太迟了，质量劣化）

启动之后走四个阶段：

Orient（定向）：先浏览一遍记忆库的目录结构，知道现在有什么

Gather（收集）：查看最近的记忆日志，检查有没有互相矛盾的记忆。比如你三个月前说“我用 React”，上周说“我现在转到 Vue 了”，这两条记忆是矛盾的

Consolidate（合并）：把新记忆合并到已有的主题下面，删除被推翻的旧事实。“用 React”这条会被删掉，“用 Vue”会被归入技术栈主题

Prune and Index（修剪和索引）：修剪索引，确保保持在 200 行以内

最关键的是第三步和第四步。过时的事实被删除，冗余的记忆被合并，索引被压缩。这不是数据丢失，这是知识蒸馏，把一堆零散的、可能互相矛盾的原始记忆，蒸馏成一份干净的、一致的、紧凑的知识库

而且这个过程有锁机制，防止多个实例同时整理导致冲突。还支持回滚。如果某次整理出了问题，可以回退到上一个版本。这种级别的工程考虑，说明这已经是一个被认真设计过的生产级系统

从成本角度看，Prune 步骤的意义不仅是“更干净”。索引被控制在 200 行以内，意味着每次记忆召回时的计算量也被控制住了。如果你的记忆索引膨胀到 2000 行，每次推理时光是“从记忆库里找出最相关的几条”这个步骤就会消耗大量的 Token 和时间

Hermes 的“临终遗言”

Hermes 在第三层认知上做了另一个很精妙的设计：Flush Memories，在上下文快要丢失的时候主动抢救值得保留的知识

什么时候上下文会丢失？最常见的场景是上下文压缩：对话太长了，Token 快要超限了，系统需要压缩或截断旧的对话。在传统的实现里，这些旧对话就直接被扔了，里面的信息一起消失

Hermes 的做法不一样。在压缩发生之前，它会先在消息列表末尾追加一条系统风格的消息，提醒 AI：“你的上下文马上要被压缩了，赶紧把值得长期记住的信息存下来。”AI 收到这条消息后，会发起一次只开放 Memory 工具的模型调用，也就是说它在这一轮只能做一件事：往长期记忆里写东西

写完之后，这条临时的提醒消息和写入的痕迹会从消息列表里被删除，确保完整历史不被污染。而且压缩不会直接覆盖旧的对话。它会结束旧 Session、创建一个新的 Continuation Session，旧的完整记录仍然保留在数据库里，随时可以回溯

这个设计的本质是：不是所有东西都要留，在要丢之前先把值钱的捞出来

另外 Hermes 还有一套 Background Review 机制作为兜底。系统不信任主代理每次都会自觉地把该记的东西记下来。说白了 AI 在执行任务的时候注意力都在任务本身，很容易忽略“顺便记住这个信息”。Hermes 怎么做的呢？后台维护一个计数器，如果连续 10 轮对话都没有调用 Memory 工具，就 fork 一个轻量的 review agent。这个 agent 会在用户收到最终回复之后异步检查：有没有什么本该记住但没记下来的事实

前台执行 + 后台复盘。这构成了一个双重保险

有一个数据可以从侧面说明 Memory 系统做到这一层之后能产生多大的差距。Rimi 这个框架做过一个测试：Qwen3-8B（一个相对小的模型）加上 Rimi 的记忆系统，在复杂任务中的表现超过了没有记忆的 Qwen3-14B。一个好的记忆系统，真的能让小模型越级打大模型。记忆系统的价值可以大到超越模型本身的能力差距

不投喂就不进化

我在调研 Elys 的过程中发现一个很有意思的现象

我在最初几天给分身投喂了大量的 context，包括我的职业背景、我对技术的看法、我喜欢的说话风格。那段时间分身确实在变好，评论质量有明显的提升

但后来我忙了一阵子没怎么用。再打开的时候发现，分身还停在我上次投喂的那天。它记得的还是几周前的我，没有任何更新、没有任何进化。它不会主动去看我在别的平台发了什么、不会根据时间推移调整对我的理解、不会自己发现“这个人最近的兴趣好像从 A 转向了 B”

这就是一个典型的“有第一层和第二层，但没有第三层”的状态。它记住了你，也做了分层管理，但它不具备主动学习和自我更新的能力。它是一个忠实但僵化的快照，而不是一个活的、会成长的记忆系统

这也是为什么 Charles 会说“代理的寿命比模型的寿命更长。记忆和上下文比模型本身更有价值”

模型可以每季度升级一次，从 GPT-4 换到 GPT-5，从 Claude 3 换到 Claude 4。但如果你的 Agent 运行了两年，它积累的关于你的记忆、关于你项目的理解、关于你团队协作习惯的洞察，这些东西换一个模型也应该能继续用。记忆层必须跟模型层解耦

而且这个记忆层不能只是一个被动的存储，它必须拥有自我进化的能力：自己整理、自己合并、自己发现矛盾、自己清理过时的信息、自己在你不在的时候变得更好

包括——自己学会遗忘

第五章：用户到底希望 AI 记住什么

前面四章都是从设计者和开发者的视角在讲 Memory 怎么做。但有一个视角一直缺席：作为用户，你希望 AI 记住你什么？不记住你什么？

这不是一个技术问题。这是一个产品设计问题，也是一个信任问题

一方面，用户是渴望被记住的

你跟 AI 说了三次“我不喜欢用表情符号”，第四次它还在给你的文案里加 emoji，这种体验让人崩溃。你切换了技术栈从 React 转到了 Vue，每次开新对话还得重新说一遍，这种重复劳动让人疲惫。“被记住”本身就是一种产品价值：它传达的潜台词是“你对我来说很重要，我在意你说过的每一件事”

Elys 的用户反馈里有一条好评把这种感觉说得很精确：“你不必在意发的内容会不会很白痴，会不会没人观看。你需要的只是表达。” 分身记住了你的偏好和表达方式，降低了社交的心理门槛，创造了一种“被接纳”的归属感。每一条内容都有回应、每一个想法都被认真对待。这是人类最基本的社交需求，AI 的记忆系统让它变成了可扩展的

另一方面，用户是害怕被窥视的

“你怎么知道我上周跟谁吃饭了？”“我只是随口提了一句我最近在看心理医生，你别给我记下来。”“我还没感受到这个产品的价值，你就让我交出性别、职业、MBTI、说话习惯，你凭什么？”

Elys 的差评和社媒舆情里有一个反复出现的焦虑：还没体验到分身的用处，就被要求交出大量个人隐私。12 步的 onboarding 流程里从职业到 MBTI 到语音录制，信息收集量确实不小。对于信任还没建立起来的新用户，这种“先交出一切、再体验价值”的模式会制造抵触情绪

记忆越强大，这种不安感越强。当 AI 真的能记住你说过的每一句话、你的每一个偏好、你在什么时间段情绪低落，它和一个“监控系统”之间的界限在哪里？

这个问题的解法不在技术层面，在产品设计层面

Rimi 这个框架提供了一个很值得借鉴的思路：把记忆直接写成用户可以看到、可以编辑的Markdown文件。你可以打开文件看 AI 记住了你什么，你觉得不对的可以直接改，你不想被记住的可以删掉。用户甚至可以用 Git 给自己的记忆做版本控制，回滚到上个月的记忆状态

有一句对 Rimi 的评价说得很好：“把记忆的控制权和透明度，完完全全还给了用户”

而且 Rimi 的这个设计还有一个意外的技术收益。它做了增量监控，文件如果是追加内容，就只对新增的部分做 embedding，不用重新处理整个文件。这一个优化节省了 92% 的 API 调用成本。透明度和效率在这里居然不矛盾

对产品经理来说，这里有一个核心的设计原则值得记住：最好的 Memory 设计，是让用户清楚地知道你记了什么、为什么记、怎么改、怎么删

你可以把它做得很轻，比如在设置页面加一个“AI 记住了关于你的这些信息”的展示区，让用户随时可以查看和编辑。你也可以做得更重，像 Rimi 一样直接把记忆文件暴露给用户。具体怎么做取决于你的产品形态，但“透明度”这个方向是确定的

还有一点容易被忽视：有时候“没有上下文”本身就是用户的选择

不是所有对话用户都想被记住。有些问题用户就是想匿名地、一次性地问完就走。如果你的 AI 不分场合地把每次对话都往记忆库里塞，用户反而会觉得不自在。这就像你跟朋友吐槽了一句“我老板真烦”，你朋友心领神会笑一下就过去了。但如果一个月后你朋友突然说“你不是说你老板很烦吗，你考虑辞职了吗”，你会觉得“嗯？你还记得这个？我只是随口说说的”

AI 需要学会判断哪些信息用户真的希望被记住，哪些只是随口一说的情绪。这可能是 Memory 产品化的最后一公里，也是最难的一公里