How AI Agents Manage Memory and Avoid Forgetfulness

AI代理如何管理记忆并避免遗忘

ByteByteGo

2026年6月29日

谁在真正审查所有这些AI生成的代码？（赞助内容）

当开发者使用AI生成数千行未经验证的代码时，你可能会面临代码库的灾难性混乱。审查环节成为团队的瓶颈，而这是在细微错误与生产环境之间最后的防线。

Greptile通过完整仓库上下文审查每个PR，并通过评论、反应和合并内容逐步学习团队的规范。它能标记真实问题并提供符合团队风格的修复建议，而非泛泛的最佳实践。

✅ 最近推出的TREX功能可以运行代码，而不仅仅是阅读代码。Greptile在沙箱中执行更改，并返回截图、日志和追踪记录作为实际问题的证据。

✅ 从终端进行审查。Greptile CLI可以在你打开PR之前在本地运行相同的审查。

✅ 被NVIDIA、Scale AI和Brex的工程团队信任。

✅ 现已与Claude Code集成：通过/plugin安装。

✅ 开源项目免费使用。

立即查看开发者为何喜爱Greptile →

即使是你堆栈中最先进的AI代理，每次消息处理都始于一张白纸。

模型本身只能看到当前时刻面前的文本，而其余对话则完全超出其意识范围。我们在与Claude或ChatGPT聊天时感受到的连贯性，实际上是平台在模型的协助下通过插入正确上下文实现的。一旦我们理解这个关键区别，代理记忆的整个领域就变成了一个与最初看似完全不同的工程问题。

在本文中，我们将尝试从迫使这种架构存在的约束条件，到随之而来的权衡取舍，逐步理解这种架构是如何构建的。

免责声明：本文基于来自多个来源的公开信息。如果您发现任何不准确之处，请在评论中指出。

无状态性

调用大型语言模型遵循一个简单的模式。系统发送提示，模型返回响应，交互就此结束。每个后续调用，即使是在一毫秒后进行的调用，都从一张全新的白纸开始。这是每个商业LLM的API合同，也反映了变压器如何处理流量。

请参见下图：

当我们说“Claude记住了我们昨天的对话”时，我们描述的是产品的属性，而非模型本身的属性。平台代表模型记录信息，然后在恰到好处的时刻将它们重新读入提示中，使模型能够推理出仿佛一直都在场的效果。智能存在于模型本身，而记忆则存在于围绕它的系统中。

如果模型本身是这样工作的，那么下一个问题是：我们是否可以通过在每次调用时将所有内容写入模型的视野来解决记忆问题？这种方法的失效方式为我们提供了更好的洞察，以解决这个问题。

上下文

每个API调用都有一个上下文窗口。这基本上是模型在生成响应时读取的文本块。这包括系统提示、用户的当前消息以及开发者放置在那里的任何其他内容。模型可以完全看到窗口内的内容，而窗口外的任何内容可能就像在另一台机器上一样。

一个显而易见的内存管理方法是每次调用时都将完整对话历史写入上下文窗口。这种方法在对话初期几轮交互中表现良好。然而当对话变长时，会同时出现三个显著问题：

• 第一个问题涉及成本。上下文窗口中的每个token在每次调用时都需要付费，这既体现在金钱成本也体现在延迟上。因此线性增长的对话会产生线性增长的账单。到第80条消息时，系统可能需要在每次交互中重新发送数万个token以维持连贯性。

• 第二个问题是延迟。更大的上下文需要更长时间处理，一个在短提示下2秒内响应的模型，在上下文窗口接近满载时可能需要10到15秒。

• 第三个问题是三个中最反直觉的。模型在长上下文中的注意力会退化，长提示中间的信息比开头或结尾的信息更难被可靠召回。研究人员将这种现象称为"中间信息丢失效应"。

更大的上下文窗口看似能彻底解决记忆问题。实际上它们只是扩大了空间却未解决导航问题。重要信息可能就在窗口内却仍可能被模型忽略。

由于单纯扩大窗口不是正确工具，我们需要一种能决定任何时刻哪些内容应进入窗口的架构。

当规则失效时，AI接棒处理（赞助）

当确定性代码触及知识边界时会发生什么？在这场实时网络研讨会中，你将看到基于Temporal实体工作流模式构建的植物健康监测系统。每个植物都是一个长期运行且防崩溃的工作流，负责轮询传感器、触发警报，并在规则耗尽时自动切换至GPT-4o。

架构设计清晰：优先使用结构化数据，其次使用AI。边界可审计。状态可持久化。无论你是构建患者监测系统、供应链检测系统，还是任何偶尔需要智能答案的长期运行流程，这里的模式都能直接应用。

7月9日加入我们

分层架构

真实生产系统通过分层方式组织内存，每层在访问速度、总容量和每token成本之间进行权衡。上下文窗口位于顶层，下方是逐渐变慢、容量更大且成本更低的存储。

与操作系统内存的类比显而易见。现代智能体记忆系统大量借鉴了操作系统在快速RAM和慢速磁盘之间分页数据的方式，根据信息相关性变化进行信息的提升和降级。

典型的四层架构从顶层的上下文窗口开始，其访问速度快但容量有限，每个token在规模上都很昂贵。其下是短期或会话内存，保存尚未汇总或清除的近期活动。再下层是长期存储，跨会话保存持久事实、嵌入和结构化摘要。最底层是冷归档，用于存储审计或未来参考的罕见访问材料。

随着智能体运行，信息会在这一层级体系中上下移动。三会话前声明的事实可能存储在长期存储中，当其变得相关时，系统会检索并将其提升回上下文窗口。相反，当会话结束时，上下文窗口中最有用的部分会被汇总并写入下层。

ChatGPT 的记忆功能使用了这个想法的简化版本。存储的用户事实和近期对话摘要会前置到每个新提示中，而当前会话则位于工作层级。复杂之处在于最初哪些内容会被提升到长期记忆中，而非读取时的复杂检索过程。

记忆的层级描述了记忆存储的位置。我们存储的记忆类型是另一个问题，按照不同的维度进行组织。

类型

该领域已收敛于代理记忆的四种功能类别，这些类别借鉴了认知科学的概念，并针对语言模型代理进行了调整：

• 工作记忆保存当前任务的实时上下文窗口中的内容。例如，如果代理正在帮助我们调试一个函数，该函数代码和我们最近的消息会占据工作记忆。一旦该任务结束，工作记忆就会清除。

• 情景记忆保存特定过去互动的记录，以时间为锚点。例如，“三天前，用户询问了如何为新工程师提供入职指导，我们讨论了检查表模板”这样的陈述代表情景记忆，它捕捉了特定事件及其上下文。

• 语义记忆存储独立于任何具体互动的事实和知识。例如，“Adam 更喜欢 Python 而非 JavaScript”和“他的团队使用 GitHub Actions 进行 CI”这样的陈述作为语义记忆，它们跨会话存在，并在相关场景中适用。

• 程序性记忆记录学习到的做事方式。如果代理发现用户更倾向于使用三部分格式进行状态更新，这种偏好会成为程序性记忆，当下次请求状态更新时，代理会自动应用该格式。

这四种类型与上一节中的层级结构相互独立。

一段语义记忆可能物理上存储在长期存储中，并在相关时被拉入上下文窗口。大多数生产环境中的代理至少实现了这三种类型中的一种，具体组合取决于代理的构建目标。客服代理更依赖情景记忆和语义记忆，而代码代理则更依赖程序性记忆。合适的组合是设计选择，而非固定公式。

所有这些仍然留下了一个重要问题未解答。

代理如何在每次交互中实际决定检索并展示给模型的内容？

检索

存储可以被视为代理记忆中较容易实现的部分。将事实写入数据库或在向量存储中索引摘要都是已有成熟工具支持的已解决的问题。更困难的部分是检索，即在每次新交互中决定哪些内容应进入模型的视野。

检索困难在于需要判断相关性，而相关性会随着每条消息的变化而变化。例如，当用户询问新项目时，他们对 Python 的偏好很重要；但当他们询问披萨食谱时，这一偏好的重要性会减弱。一个好的检索系统会在相关内容恰好有用时将其呈现，而将其他内容安静地保留在存储中。

完整的检索流程会在每次用户消息到来时运行。

用户发送一条消息后，系统会通过关键词搜索、语义相似性和时效性信号等多种方式，从各个记忆层级中检索相关信息。系统会按照特定顺序构建上下文窗口，通常将最重要的内容放在开头和结尾，这两个位置是模型注意力最集中的区域。模型运行并返回响应后，系统会将新对话的一部分写回内存，通常以摘要形式存储，有时还会附带衰减评分，使重要性随时间逐渐减弱。

通过两个代理的对比，可以理解检索机制的重要性。

第一个代理拥有完美的历史交互数据库，但检索系统经常错误地匹配记录。第二个代理则没有记忆存储，仅根据当前会话中用户提供的信息进行操作。第二个代理通常表现优于第一个，因为它清楚自身依赖信息的边界，而第一个代理会自信地呈现过时或无关的信息，并基于这些信息进行推理，仿佛它们是绝对正确的事实。

换句话说，生产环境中的记忆失效通常是以检索失效的形式隐藏的。

权衡取舍

上述记忆架构涉及多个工程团队需要谨慎权衡的方面。其中四个尤为关键：

• 时效性与相关性：是优先检索最近的记忆内容，还是语义最相关的内容？大多数系统会同时采用两者，如何有效融合它们是持续的工程难题。过度依赖时效性会导致代理遗忘有用的旧信息，而过度依赖相关性则会让代理过度聚焦于某些虽相关但已过时的匹配项。

• 摘要与保真度：将旧信息压缩成摘要可以节省token，从而降低成本并提高速度。但这种压缩是信息丢失的，且丢失分布不均。姓名、日期和具体承诺等细节在摘要过程中会被模糊处理，而一般性主题则得以保留。即使精确细节已悄然消失，代理仍会保持自信。

• 信息过时：六个月前的正确事实可能在今天已完全错误。例如，2024年告诉代理“我是素食者”的用户，可能在2026年又开始食用非素食。记忆系统仅能通过粗略的启发式方法猜测世界已发生变化，因此会持续以完全自信的方式提供旧信息。高相关性记忆中的信息过时问题仍是开放性研究难题。

• 记忆污染：长期记忆也是长期攻击的潜在目标。六个月前写入存储的细微恶意指令会持续影响所有检索，直到被发现。记忆的有用性源于其持久性，但当内容错误或具有敌意时，这种特性也会使其变得危险。

当代理需要跨会话保持连续性，或执行长期任务（上下文会累积影响结果）时，记忆系统才有意义。对于一次性任务，它会引入超出任务需求的复杂性。

结论

本文的核心观点包括以下五点：

• 模型本身是无状态的。每次API调用都从空白状态开始，我们观察到的任何连续性都是外围系统的工作成果，而非模型自身特性。

• 上下文窗口是模型唯一感知界面。将所有信息写入上下文窗口会因成本、延迟和长提示中注意力下降等问题而失败。

• 实际系统会以层级结构组织内存，顶层是上下文窗口，下方则是逐渐变慢、容量更大、成本更低的存储层级。

• 不同类型的信息需要不同类型的内存支持，工作记忆、情景记忆、语义记忆和程序性记忆各自承担着独特的功能。

• 这个领域的主要工程挑战是检索机制，即在每次新交互中决定哪些信息值得进入模型的意识范围，这需要在信息过时性、摘要损失和安全性之间进行权衡。

所有这些内容带来的实际启示非常简单。

当下次我们看到标有"memory"（内存）的产品功能，或读到某个代理系统能"跨会话记忆"时，正确的问题应该从"模型能否记住这个信息？"转向"围绕这个模型的内存架构实际上做了什么，它接受了哪些取舍？"

参考文献：

• Lost in the Middle: How Language Models Use Long Contexts
• MemGPT: Towards LLMs as Operating Systems
• Cognitive Architectures for Language Agents
• Memory and new controls for ChatGPT