上一篇文章《为什么 AI Agent 的长期记忆几乎都是错的？》讨论的是一个更表层、但也更常见的问题：为什么很多 AI Agent 的长期记忆经常出错。
结论并不复杂。问题通常不在模型"记不住"，而在系统"不会记"。历史对话被切成碎片，检索出来一些相关内容，再拼回上下文，看起来像是有了记忆，但一旦进入跨时间、多条件、状态变化这些场景，错误就会很快暴露出来。
继续往下追问，一个更关键的问题就来了：
如果"聊天记录 + 检索"不等于长期记忆，那么一套真正可用的记忆系统，到底应该长什么样？
这篇文章想回答的，就是这个问题。
这不是一篇论文综述，也不是一篇框架说明书。更准确地说，这是一篇系统定义篇：试着把"长期记忆系统"这件事，从一个模糊概念，拆成几个真正可落地的工程层次。
一、从"记不住"到"不会记"，问题要继续往下拆
很多团队第一次给 Agent 做长期记忆，通常会先想到两个方向：
一是把上下文拉长。 二是把历史存进向量库。
这两个方向都合理，也都能解决一部分问题。但它们解决的，本质上还是"怎么把更多历史留住"，而不是"怎么把历史变成真正可用的记忆"。EverMemOS 论文就明确指出，很多现有 memory 方法把记忆当成扁平的、分散的记录集合，结果不是缺少信息，而是缺少整合：系统能找回事实，却难以形成稳定用户模型，也难以处理冲突与状态变化。
这也是为什么很多 Agent 的表现会出现一种很奇怪的反差：
- 问一个昨天聊过的小细节，它能答对；
- 但只要问题牵涉多个时间点、多个约束或者当前状态，它就开始摇摆、遗漏、甚至前后矛盾。
从工程角度看，这说明问题并不只是 retrieval 精度不够，而是整个系统没有形成一套像样的记忆机制。
也就是说，真正缺少的不是某个召回 trick，而是一套 Memory System。
可以先把这一篇的核心判断放在这里：
AI Agent 要想真正拥有长期记忆，首先需要的不是更大的上下文，而是一套像样的 Memory OS。
二、为什么"聊天记录"不能直接当长期记忆
这是一个很容易被忽略、但几乎决定后续上限的问题。
很多系统会默认认为：只要把历史对话保存下来，记忆这件事就已经完成了一半。可实际上，原始聊天记录更像日志，不像长期记忆。
1. 原始对话太零碎
对话天然带有大量口语特征：
- 省略
- 跳跃
- 代词指代
- 情绪化表达
- 临时性的想法
这些内容对当下交流很自然，但对长期维护并不友好。把它们原样存起来，等于把"原始噪声"和"真正有价值的信息"一起塞进记忆层。
2. 原始对话不适合直接检索
真实的长期事件，往往不会完整出现在某一轮对话里。它可能分散在几天、几周甚至几个月的多次交互中。直接检索聊天记录，很容易拿到一些相关片段，却很难还原一件完整的事。HyperMem 论文的出发点就是这个问题：长对话里的有用信息通常跨多个 episode、多个事实节点分布，传统 pairwise 或 chunk-based 检索容易把原本属于同一主题的内容打散。(arXiv)
3. 原始对话不利于更新
新信息进来之后，系统不只是要"多存一条"，还要判断：
- 这条信息是在补充旧状态，还是覆盖旧状态？
- 是长期偏好，还是短期约束？
- 应该升权，还是降权？
如果底层保存的只是聊天原文，那么这些更新动作几乎都只能在回答时临时做推断，系统本身没有稳定的维护对象。
所以更准确的说法是：
聊天记录更像日志，长期记忆更像经过整理后的状态数据。
三、一套真正的 Memory System，至少要回答四个问题
如果把"长期记忆系统"看成一条完整链路，而不是一个数据库接口，那么它至少要回答四个问题：
1. 什么值得记？
不是所有对话内容都应该进入长期记忆。系统需要有一套写入逻辑，判断哪些内容值得沉淀，哪些只属于短期上下文。
2. 记成什么结构？
记忆不是越多越好，而是越可维护越好。原始对话、事件摘要、事实、画像、计划、约束，本来就不是同一种对象。
3. 什么现在仍然有效？
长期记忆最难的地方之一，不是"有没有历史"，而是"哪部分历史在当前时间点仍然生效"。EverMemOS 在设计里专门引入了 time-bounded foresight 和 user profile，就是为了解决这一层。
4. 回答问题时该怎么取？
记忆调用不该只是固定 top-k。系统需要知道：哪些信息是必要的，哪些是充分的，哪些还需要继续补证据。EverMemOS 把这一阶段定义为 Reconstructive Recollection，强调的是"重建足够回答当前问题的上下文"，而不是把所有疑似相关内容一次性塞进去。
这四个问题加在一起，才构成"长期记忆系统"的完整边界。
长期记忆系统的设计，不是"怎么存更多"，而是"怎么选择、组织、更新和重建"。
四、第一层：记忆单元------不是 chunk，而是事件
真正的长期记忆，第一步通常不是"先存下来"，而是"先整理成能被系统理解的单位"。
1. 为什么 chunk 不够
chunk 是一种切分技术，不是一种记忆抽象。它更适合服务 embedding 和检索效率，而不是服务长期语义维护。只要对话稍微复杂一点，就会出现两个问题：
- 一个完整事件被切裂；
- 多个无关内容被塞进同一个块里。
这会直接影响后续的检索、更新和推理。
2. 什么是更合适的记忆单元
长期记忆更适合的基本单位，通常是事件化、语义完整的对象。EverMemOS 在第一阶段提出 MemCell，把它作为从对话流中抽取出来的离散记忆单元，内部包含 episode、atomic facts、foresight 和 metadata；HyperMem 也采用了 topic / episode / fact 的三层记忆设计，其中 episode 是连接原始对话和长期结构的关键层。
换句话说，这一层想解决的不是"怎么更好切文本"，而是：
怎么把原始对话，转成系统真正能维护的中间对象。
3. 为什么这一层很关键
只有先有稳定的记忆单元，后面的东西才站得住：
- 画像更新要依赖它；
- 事实抽取要依赖它；
- 状态冲突处理要依赖它；
- 检索重建也要依赖它。
如果底层没有稳定单元，后面所有"长期记忆"都会退化成对日志的反复扫描。
所以这一层最重要的结论其实很朴素：
长期记忆的第一步，不是存聊天记录，而是把聊天记录整理成事件。
五、第二层：状态层------长期记忆不是事实仓库，而是状态系统
这是最容易讲浅、也最容易被低估的一层。
很多系统以为，只要把事实保存得足够全，长期记忆问题自然会解决。但事实只能回答"发生过什么"，不一定能回答"现在该怎么判断"。
1. facts 不够，状态才是关键
举个最典型的例子：
- "喜欢 IPA"
- "最近在吃抗生素，不喝酒"
这两条都是真实信息，也都值得保存。但在当前时刻，它们的作用完全不同。前者更接近长期偏好，后者更接近短期约束。EverMemOS 在引言里就用了几乎一样的例子来说明 fragment-based memory 的局限：如果系统只召回"喜欢 IPA"，却没把"正在服药"纳入当前状态，就会给出明显错误的建议。
2. 什么是状态层
状态层不是把事实再存一遍，而是把事实整合成一种更接近"当前有效用户模型"的表示。通常会包括：
- 稳定偏好
- 当前限制
- 正在执行的计划
- 短期有效的前瞻信息
- 持续变化中的身份、目标或生活状态
EverMemOS 里对应的就是 profile 与 foresight 的组合：前者沉淀相对稳定的用户画像，后者维护带时间边界的短期预测与约束。
3. 为什么偏好和约束必须分开
如果系统把所有信息都视为"事实"，那调用时就只能靠模型自己在上下文里临场判断轻重缓急。短期内也许偶尔能答对，但长期看一定会越来越不稳定。
状态层存在的意义，就是把这一步提前系统化：
- 什么是长期的；
- 什么是临时的；
- 什么优先级更高；
- 什么已经过期。
所以这一层真正想解决的，不是"怎么保存更多用户信息"，而是：
怎么把历史事实整合成当前有效状态。
六、第三层：组织层------记忆必须有层次，不能平铺
当记忆从"聊天记录"升级为"事件、事实、画像、计划、约束"之后，下一个问题自然就来了：
这些东西应该怎么组织？
答案很简单：不能平铺。
1. 为什么不能混在一起
事件、事实、画像、约束，本来就不是同一个层级的对象。如果把它们都塞进同一个 memory bucket，系统后面几乎一定会遇到三个问题：
- 更新逻辑混乱；
- 检索粒度混乱；
- 优先级判断混乱。
2. 一个可用的层次结构长什么样
可以先用非常朴素的方式理解：
text
原始对话
→ 记忆单元（episode / event / MemCell）
→ 事实层（facts / logs）
→ 状态层（profile / constraint / foresight）
→ 检索与重建HyperMem 则把这种层次进一步结构化成 topic / episode / fact 三层，并用超图来建模多节点间的高阶关联；EverMemOS 虽然不强调超图，但同样强调从 episodic trace 到 semantic structure 的逐层组织。两者路线不同，但共识是一样的：长期记忆必须从平铺记录转向分层结构。
3. 分层之后的收益是什么
一旦分层，系统会立刻获得几个非常实际的好处：
- 更新更容易做
- 检索更容易控噪
- 状态判断更容易稳定
- 上下文重建更容易做到"少而够用"
反过来说，如果没有分层，系统最终还是会退回到"在一堆历史文本里靠相似度碰运气"。
长期记忆一旦没有分层，系统最终就只能退回到语义相似度碰运气。
七、第四层：重建层------记忆不是存着等查，而是面向当前问题重建
很多长期记忆系统最后体验不行，不是因为前面完全没做，而是因为最后这一步还停留在"粗暴 top-k"。
这一步其实最接近用户真正感受到的"记忆能力"。
1. 为什么不能一次 top-k 结束
不少问题不是找一条答案，而是找一组足以支持当前判断的证据。第一次检索通常只能找到线索，未必能直接找到完整上下文。
EverMemOS 在第三阶段提出 Reconstructive Recollection，并显式引入 necessity and sufficiency 原则：不是把所有可能相关内容都丢给模型，而是围绕当前问题主动重建足够、但不过量的上下文。论文还提到其系统会进行 query rewrite、scene match、episode rerank 和 sufficiency check，必要时触发下一轮检索。
2. 什么叫"重建"
重建不是"原样返回历史"，而是：
- 先找相关状态；
- 再找关联事件；
- 必要时补充事实和时间线；
- 最后拼成一个面向当前问题的最小回答上下文。
这和"找几段相关文本回来"有本质差别。
3. 为什么这一层决定体验上限
前面写得再好、存得再多，如果最后调用还是固定 top-k，系统依然会出现：
- 证据不完整；
- 当前约束被忽略；
- 相关但无用的信息过多；
- 回答缺乏状态一致性。
所以从用户体验角度看，长期记忆的最后一步，其实不是检索，而是重建。
长期记忆的最后一步，不是检索，而是重建。
八、把这些拼起来，Memory OS 到底是什么
写到这里，其实已经可以给出一个更完整的定义了。
Memory OS 不是一个单独模块，也不是一个"接在大模型旁边的向量库服务"。它更像一条完整的系统链路：
- 对话进入系统
- 被整理成稳定记忆单元
- 从中抽取事件、事实、前瞻信息和用户状态
- 这些对象再被组织成分层结构
- 当问题到来时，系统按当前需求重建足够回答的上下文
- 最后才交给模型生成
EverMemOS 把这条链路概括为三个阶段：Episodic Trace Formation、Semantic Consolidation、Reconstructive Recollection；HyperMem 则从数据结构角度把长期记忆组织成 topic / episode / fact 的层级超图。无论具体实现细节如何不同，它们都在说明同一件事：长期记忆不是存储问题，而是运行时系统问题。
所以可以把本文的核心定义收束成一句话：
Memory OS，本质上是一套把对话转化为长期状态，并在需要时正确重建出来的系统。
九、如果现在就做一个 Memory System，最小落地版本应该是什么
写到这里，很容易让人觉得这件事太大、太复杂。但现实里，真正有用的升级，往往并不是从最重的方案开始。
如果现在就要给一个 Agent 做 Memory System，最小可用版本其实可以很朴素：
1. 先把原始对话整理成事件级单元
哪怕暂时没有复杂的边界检测，先做一层 episode summary，也会比直接存聊天原文强很多。
2. 从事件中抽取 facts，并维护基础状态层
先把 profile 和 constraint 分开。长期偏好是一类对象，短期限制是另一类对象。只要这两层开始分离，很多错用记忆的问题就会明显下降。
3. 检索不要停在固定 top-k
哪怕暂时没有完整的 agentic retrieval，也应该引入最基础的：
- hybrid retrieval
- rerank
- 二次补检
- 或简单的 sufficiency 判断
这几步看起来不大，但它们决定的不是"性能能不能多涨 2 个点"，而是记忆系统会不会从"能存"跨到"能用"。
从这个角度看，Memory System 的升级往往不是从最复杂的模型开始，而是从最基本的数据结构、状态建模和调用链路开始。
十、结尾：下一篇为什么必须讲"结构"
这一篇试图讲清的，不是某篇论文里的技巧，而是一个更底层的系统认知：
长期记忆不是"日志存储 + 检索增强"，而是一条从写入、组织、更新到重建的完整链路。
但讲到这里，其实还剩下一个非常关键的问题没有展开：
如果记忆真的需要组织，那这种组织到底应该长什么样？
事件之间怎么连？ 主题和事实之间怎么关联？ 为什么有些问题只靠 episode 还不够，必须要有更强的结构表达？
这就是下一篇要继续往下拆的内容。
因为当记忆不再只是"存储"，结构就会成为长期记忆系统里最关键的能力之一。
引用论文
- Hu, C., Gao, X., Zhou, Z., Xu, D., Bai, Y., Li, X., Zhang, H., Li, T., Zhang, C., Bing, L., & Deng, Y. EverMemOS: A Self-Organizing Memory Operating System for Structured Long-Horizon Reasoning. arXiv:2601.02163, 2026.
- Hu, C., Gao, X., Xu, D., Zhou, Z., Li, X., Bai, Y., Li, T., Zhang, H., Zhang, C., Bing, L., & Deng, Y. HyperMem: Hypergraph Memory for Long-Term Conversations. arXiv:2604.08256, 2026. (arXiv)
- Hu, C., Gao, X., Xu, D., Zhou, Z., Bai, Y., Li, X., Zhang, H., Li, T., Zhang, C., Bing, L., & Deng, Y. MSA: Memory Sparse Attention for Efficient End-to-End Memory Model Scaling to 100M Tokens. arXiv:2603.23516, 2026. (arXiv)