跳到主要内容

MemGPT:大语言模型智能体的虚拟上下文管理

· 阅读需 7 分钟
Mike Thrift
Mike Thrift
Marketing Manager

限制大多数 LLM 智能体的约束因素不是智能,而是记忆。我在处理跨越多年交易的 Beancount 账本时对此有着切身的体会:无论底层模型的能力有多强,一旦账本历史超过了上下文窗口,智能体就会开始遗忘。MemGPT(Packer 等,加州大学伯克利分校,2023)借用了操作系统数十年前解决问题的方法,直接应对这一挑战。

论文概览

2026-05-02-memgpt-towards-llms-as-operating-systems

“MemGPT: Towards LLMs as Operating Systems”(Packer, Wooders, Lin, Fang, Patil, Stoica, Gonzalez; arXiv:2310.08560)提出了虚拟上下文管理——这是一个刻意的类比,模仿了操作系统通过在快速 RAM 和慢速磁盘之间进行分页来创造大容量虚拟内存幻觉的方式。LLM 的上下文窗口扮演了 RAM 的角色:稀缺、快速且可直接访问。两个外部存储扮演了磁盘的角色:召回存储(recall store,最近的消息历史)和归档存储(archival store,一个可搜索的长期数据库,用于存放任意文本)。智能体本身通过显式的函数调用——即在各层之间移动数据的工具——来决定从外部存储中读取什么内容以及从上下文中剔除什么内容。系统会在上下文容量达到 70% 时触发剔除警告,并在 100% 时强制刷新,生成被剔除消息的递归摘要,以避免信息的完全丢失。

该论文在两个领域对 MemGPT 进行了评估:多会话对话智能体(多会话聊天数据集)以及针对超过模型原生上下文窗口的大规模语料库的文档分析。

核心思想

  • 三层记忆结构:上下文内的工作内存(快速、有限)、召回存储(最近的消息,可搜索)和归档存储(长期、已索引)。智能体通过工具调用向这三层写入数据。
  • 深度记忆检索 (DMR):这项评估任务要求在过去多个会话中保持一致的召回。使用 GPT-4 时,标准的固定上下文基准准确率为 32.1%;MemGPT 将其提升至 92.5%。GPT-4 Turbo 基准:35.3% → 93.4%。
  • 嵌套键值检索:文档分析压力测试。在三层嵌套时,标准 GPT-4 的准确率为 0%;而搭载 GPT-4 的 MemGPT 通过迭代的归档查找维持了性能。
  • 通过中断控制流:智能体在响应之前会发出信号表示需要更多时间(以执行内存操作),类似于操作系统的中断。这保持了系统的响应性,而无需将所有内容挤压到单次推理过程中。
  • 剔除问题:当上下文满载时,内容会被总结并刷新。递归摘要虽然保留了要点,但不可避免地会丢失细节——该论文承认了这一权衡,但未进行完全的量化。

哪些观点经得起推敲,哪些则不然

DMR 的数据非常显著:在多会话聊天数据集中,MemGPT 与标准 GPT-4 基准之间 60 个百分点的准确率差距绝非偶然。嵌套键值检索的结果——基准测试在 0% 处失败,而 MemGPT 继续工作——证明了迭代的、工具介导的检索相较于被动的长上下文暴露具有真实价值。这与 Liu 等人的“迷失在中间(Lost in the Middle)”发现(arXiv:2307.03172)相吻合:即使信息在物理上能容纳在上下文窗口中,模型对埋藏在中间的内容的处理能力也会下降。MemGPT 通过仅检索即刻需要的内容规避了这一问题。

尽管如此,评估中仍存在明显的漏洞。多会话聊天数据集较为狭窄——它是格式受控的人工生成的角色对话。该方法如何扩展到更混乱的现实世界对话或特定领域的语料库(财务申报、监管函件)尚未经过测试。实验中的归档存储是一个简单的向量数据库;随着归档增长到数百万个文档,检索质量是否能保持高水平仍是一个悬而未决的问题。更根本的是:智能体的检索策略仅取决于其查询能力。如果智能体不知道自己不知道什么——这是长跨度任务中常见的失败模式——它就永远不会发出正确的归档查找请求,整个架构就会优雅地退化为同样的固定上下文失败模式。

此外还有论文轻描淡写的延迟成本。每次归档查找都是一次额外的 LLM 推理调用(用于生成查询)外加一次向量搜索。对于处理多年数据的日常对账的 Beancount 智能体来说,这可能会演变成每次响应都需要多次往返。论文没有报告实际消耗时间的对比。

随后的工作加剧了这些批评。A-MEM (arXiv:2502.12110) 声称在多跳任务上的性能至少比 MemGPT 好 2 倍,认为 MemGPT 僵化的分层结构不如更动态的记忆管理。Mem0 基准测试(2024-2025)显示,在某些场景下,竞争方法在准确性和速度上均优于 MemGPT。原作者后来将该项目演变为 Letta(2024 年 9 月),这是一个具有异步“睡眠时间计算”以进行记忆整合的开源智能体框架——这隐含地承认了同步、单智能体设计存在扩展限制。

为什么这对金融 AI 至关重要

一个小企业的 Beancount 账本在十年间会累积数万条交易。一个负责年终对账、异常调查或多年趋势分析的智能体无法将所有内容放入上下文中。MemGPT 的三层设计几乎可以直接映射:工作内存保存当前审查的交易批次;召回存储保存最近的会话上下文(我们上次对账的内容);归档存储保存完整的账本历史、日记账分录和之前的异常报告。用于内存操作的函数调用接口本质上与智能体已经需要的写回操作接口相同——这不是一种新的能力类别,只是同一套工具调用机制的新应用。

更深层的意义在于框架的转变:MemGPT 不再询问“我们能否在上下文中放入更多内容?”,而是询问“智能体能否管理自己的注意力?”对于金融领域,这才是正确的问题。税务审计可能会提出关于三年前某笔交易的问题。一名合格的人类会计师会检索原始发票,将其与账本进行核对,并回想起当年的政策背景。这种按需检索的行为正是 MemGPT 训练我们去设计的。

诚实的提醒:MemGPT 并未在金融数据上进行评估,而财务文档在结构上与角色对话不同。针对密集数值数据、多货币交易和复式记账模式的检索质量需要其自身的基准测试。

延伸阅读

  • 迷失在中间:语言模型如何使用长上下文 (Liu et al., arXiv:2307.03172) —— 这是解释为什么仅靠更长的上下文窗口无法解决问题的实证基础;模型无法关注文档中间的内容,这促使了像 MemGPT 这样基于检索的方法的产生。
  • A-MEM:LLM 智能体的代理记忆 (arXiv:2502.12110) —— 一篇 2025 年的后续论文,声称通过用动态记忆管理取代 MemGPT 僵化的分层结构,实现了更优的多跳记忆性能;这是一个必要的对比点。
  • Gorilla:连接海量 API 的大语言模型 (arXiv:2305.15334) —— 本阅读列表的下一篇;其中的检索增强工具调用设计通过解决智能体如何从庞大的 API 接口中选择正确工具的问题,补充了 MemGPT 的记忆管理。