分层内存压缩:你的智能体内存缺失的四个层级
大多数智能体内存系统将一个四层的问题压缩成两层,然后在出现破绽时表现得大吃一惊。一个是当溢出上下文窗口时会被截断的会话缓冲区(conversation buffer),另一个是旧内容堆放其中的“长期记忆”向量数据库。那不是内存架构。那只是一个队列和一个杂物抽屉。
如果一个智能体连续三个周一向老用户询问同一个新手引导问题,这并不是因为模型不好,而是因为系统中没有一个地方能保存“该用户跨会话告知我的事情”,并且其生命周期不同于“所有用户告知我的关于产品如何运作的事情”。这是不同的记忆。它们有不同的访问模式、不同的隐私契约以及不同的遗忘规则。将它们混为一谈是架构上的错误——而且这是可以修复的。
四个层级,以及为什么两个层级远远不够
关于语言智能体的认知架构研究——CoALA 分类法是其中最清晰的表述——将内存分为工作内存(working)、情境内存(episodic)、语义内存(semantic)和程序内存(procedural)。对于大多数产品级智能体,你可以将程序内存留在模型和代码库中,重点关注其他三层,外加一个介于工作内存和情境内存之间的会话层(session tier)。四个层级,每一层都有其他层无法替代的功能。
工作内存(Working memory) 对应当前的任务。它是草稿板:用户最新的消息、最后几次工具输出、智能体正在执行的部分计划。任务结束时它会重置。其生命周期的衡量单位是秒到几分钟。其中的所有内容当前都在提示词中,且大部分内容不应在任务结束后保留。
会话内存(Session memory) 对应当前的单次使用(sitting)。用户十五分钟前打开了助手,并在三个相关的任务之间切换。他们在早期命名了一个项目,之后一直将其称为“那个项目”。任务三的工作内存完全不知道“那个项目”是什么——那个事实存在于任务一中。会话内存负责保存它:一个精简、结构化的记录,保存本次会话早期发生的事情,在单次使用的不同任务间保持存在,并在用户关闭对话时销毁。
情境内存(Episodic memory) 是针对每个用户的历史记录。特定用户告诉智能体的事情——偏好、进行中的项目、上周做出的决定、他们喜欢的语气——在与当前任务相关时被检索。生命周期是数周到永久。作用域是单个用户。正是这一层级让智能体不再重复提问。
语义内存(Semantic memory) 是跨用户的知识。关于产品、领域、集成、工具组合方式的事实——从多次会话和多位用户中提炼、去重并验证。生 命周期是永久。作用域是所有人。
之所以两个层级不够,是因为这四层中的任意两层都具有根本不同的特征。会话内存事实和情境内存事实在捕捉瞬间看起来是一样的(“用户说该项目名为 Atlas”),但它们有不同的衰减规则——一个在会话结束时消失,另一个持续存在直到用户更改。语义内存事实和情境内存事实在检索时看起来也是一样的(“邮件集成使用 OAuth”),但它们有不同的隐私契约——一个在租户间共享,另一个绝不能泄露。将它们混在一起,你就会得到两者的最差表现:系统要么将用户特定的事实视为全局事实并导致泄露,要么将全局事实视为用户特定事实并在每次会话中重新推导。
晋升与剔除才是架构的核心
四层内存不仅仅是四个存储桶,而是四个存储桶加上它们之间移动数据的规则。这些规则——晋升(promotion,数据向更长生命周期的层级移动)和剔除(eviction,数据移出)——才是让架构运作的关键。如果没有明确的规则,各层级就会充斥着噪音,每一层的检索质量都会崩溃。
晋升必须是有选择性的。大部分工作内存应该在任务结束时挥发。智能体组装的计划、中间工具输出、错误的尝试——这些都不属于会话内存,更不用说情境内存了。应该晋升的是任务期间产生的一小部分持久事实:用户做出的决定、表达的偏好、引入的项目名称。同样的原则也适用于整个栈。大部分会话内存应该在单次使用结束时挥发。被晋升到情境内存的是那些关于用户而非关于本次对话的子集——即用户期望系统下周还能记得的事实。
从情境内存晋升到语义内存是三者中最难的,也是大多数团队跳过的。它需要“去个性化”:一个针对特定用户的事实变得通用到足以适用于其他人。“用户报告导出 CSV 按钮损坏”是情境性的;一旦在多个用户中得到验证,它所指向的 Bug 就会成为关于产品的语义事实。这一层最值得通过定期的 LLM 驱动整合任务来实现自动化,扫描情境模式并提出语义事实——但这也是你绝对需要验证步骤的地方,因为错误的晋升会污染下游每个用户的共享存储。
剔除是与之对称的问题。如果没有任何东西移出,情境存储将无限增长。基于时间的过期是错误的默认设置——有用的事实虽然变旧了,但并不会变得没用,大多数用户会讨厌一个在 90 天后“忘记”公司名称的助手。更好的默认设置是:基于矛盾剔除(用户说了替代旧事实的新内容)、基于无关性剔除(用户不再提及的项目在消失前检索权重会衰减)、以及基于用户请求剔除(明确的“忘记那个”应该实际删除,而不只是标记为隐藏)。每一层都需要自己的剔除策略。工作内存对提示词预算有硬性限制;会话内存有时间绑定的 TTL;情境内存有基于活动的衰减;语义内存在被取代时剔除,而非基于时间。
层级感知检索:更省钱、更高效
朴素的检索模式只问一个问题——“获取与该查询相关的所有内容”——并在所有存储的记忆并集上运行。这种模式既浪费又危险。浪费是因为它在向语义记忆查询那些明明就在两行之前的工作记忆中的事实;危险是因为它在向情境记忆查询本应由会话记忆提供的事实,并为一个对话缓存本可以免费回答的请求支付了向量查询的成本。
正确的模式是首先查询最接近的层级,只有当本地上下文不足时才进行回退。从提示词中已有的工作记忆开始——如果答案就在那里,就不执行检索调用。接着降级到会话记忆,这是一个响应速度在个位数毫秒级的小型结构化存储。然后是针对该用户的情境记忆,这是一个带有严格租户过滤的向量查询。最后才是语义记忆,这是最广泛、也是成本最高的搜索。
这种模式对成本至关重要:最便宜的层级是你没有查询的那一层。它对正确性也同样重要。如果用户在 5 轮对话前刚刚告诉了智能体某件事,而系统却深入向量数据库去尝试寻找同一个事实的一个可能过时的版本,那么新鲜度顺序就颠倒了。工作记忆在定义上就是最及时的。将其视为一等检索源——而不仅仅是提示词——可以消除一类 Bug,即智能体在单个会话中自相矛盾,因为它提取了一个过时的情境事实,而非新鲜的工作记忆事实。
捕捉这种层级错误的评估(Eval)写起来很直接:取一个用户在 3 轮前给出答案的问题,验证它是从工作记忆或会话记忆中回答的,而不是从语义记忆中回答的。如果追踪记录显示,针对原本存在于对话缓存中的事实,系统却对租户范围的存储进行了向量检索,那么无论答案是否凑巧正确,层级结构都已失效。
隐私契约必须基于层级,否则就是空谈
四层模型最重要的特性是隐私边界与层级边界对齐。工作记忆存在于用户的会话中,并驻留在提示词内;从结构上讲它不会泄露,因为其他用户的提示词无法读取它。会话记忆亦是如此。情境记忆是针对每个用户的,但它是持久的;它必须通过一个无法绕过的租户过滤器来查询。语义记忆在设计上就是跨用户共享的;任何用户特定的内容都不应存在于此。
当团队将情境记忆和语义记忆合并到同一个带有 user_id 字段(假设查询层会进行过滤)的向量存储中时,他们就制造了跨会话泄露的漏洞,这已成为多租户 LLM 系统红队报告中的常客。来自另一个用户历史记录的语义相似内容被检索出来,是因为嵌入相似度分数超过了租户过滤器——或者是由于开发者后来写的查询忘记了添加过滤器。防御手段不是“记得过滤每个查询”,而是将情境记忆和语义记忆放在不同的存储中,这样查询错误的层级就需要连接到错误的数据库,而不仅仅是漏掉一个 WHERE 子句。
同样的原则也适用于组织边界。如果你的智能体是企业意义上的多租户——不同的公司使用相同的部署——那么情境层本身就需要按租户进行分区,并将查询路径硬编码到单个分区。原本会提升到共享存储的语义事实,除非明确批准进行全局提升,否则应保留在租户本地。提升流水线成为了进行隐私审查的地方,因为它是数据跨越边界的唯一场所。在这里集中处理比在应用程序的每个查询中分散设置租户过滤器要容易审计得多。
这就是为什么当“智能体记忆”被当作一个整体看待时,它是一个危险的抽象。这个短语暗示了一个具有单一隐私态势的单一系统,而实际上你拥有的是四个具有四种不同态势的系统。最安全的部署将它们视为四个具有四个独立授权范围的独立服务,并将它们之间移动数据的整合流水线视为其原本应有的高信任边界。
无需引入框架即可构建
你不需要采用专门的记忆框架来实现这种架构。层级模型可以映射到大多数团队已经拥有的原语:工作记忆是提示词缓冲区,会话记忆是缓存中设置了 TTL 的行,情境记忆是向量存储的按用户分区,而语义记忆是全局分区。架构上的承诺在于在存储层保持它们的独立,并将提升和检索流水线作为一等代码编写,而不是作为临时的摘要调用。
从明确的边界开始,而不是从复杂的提升逻辑开始。定义什么属于会话记忆 vs. 情境记忆,并编写一个简单的分类器——即使是在会话结束时运行的手写提示词,也比默认的“一切都存入向量存储”要好。在存储填满之前定义每个层级的淘汰策略,因为在积累了两年噪声的向量存储上补救淘汰策略,比尽早制定正确的政策要困难得多。将检索构建为层级化的查询计划,而不是单个函数——回答“用户想要什么”的函数应该按顺序咨询各个层级,这个函数正是你可以分摊掉大部分检索成本的地方。
智能体记忆问题无法通过更大的上下文窗口或更好的嵌入器来解决。这两者都有帮助,但都无法解决一个事实:智能体需要四个执行四种不同任务的记忆。只交付两个记忆的团队,将在检索成本、重复提问以及最终导致上头条的跨租户泄露中持续付出代价。构建这四个层级,编写提升规则,根据层级确定隐私契约的范围——然后大多数“智能体遗忘”和“智能体泄露”的故障模式将不再神秘。
- https://arxiv.org/abs/2310.08560
- https://arxiv.org/abs/2309.02427
- https://arxiv.org/abs/2504.19413
- https://www.letta.com/blog/agent-memory
- https://docs.letta.com/advanced/memory-management/
- https://atlan.com/know/episodic-memory-ai-agents/
- https://towardsdatascience.com/a-practical-guide-to-memory-for-autonomous-llm-agents/
- https://arxiv.org/abs/2512.13564
- https://arxiv.org/html/2602.11510v1
- https://www.giskard.ai/knowledge/cross-session-leak-when-your-ai-assistant-becomes-a-data-breach
- https://aiagentmemory.org/articles/llm-hierarchical-memory/
- https://mem0.ai/blog/memory-in-agents-what-why-and-how
