LLM新技术中的CS原型(三)MemGPT:将LLMs视为操作系统
LLM新技术中的CS原型(三)MemGPT:将 LLMs 视为操作系统
参考图片:

图:MemGPT 论文中的系统结构。有限上下文被划分为系统指令、工作上下文和 FIFO 队列;归档存储与召回存储位于上下文窗口之外。
官方链接:MemGPT Research
GitHub 链接:letta-ai/letta
参考链接:
- 论文:[2310.08560] MemGPT: Towards LLMs as Operating Systems
- 论文 HTML 版:MemGPT: Towards LLMs as Operating Systems
- 当前活跃实现:letta-ai/letta-code
- 中文解读:MemGPT:将 LLMs 视为操作系统——以达无限 Context
版本说明: 本文主要分析 arXiv
2310.08560v2,该版本首次提交于 2023 年 10 月,最后修订于 2024 年 2 月。MemGPT 后来更名为 Letta;截至本文编写时,letta-ai/letta已成为历史入口,活跃代码位于letta-ai/letta-code。除第 5 节外,文中的“MemGPT”均指论文所描述的原始架构,不将当前 Letta 的能力反推到早期论文。
1 项目介绍
MemGPT(Memory-GPT)是一套为有限上下文 LLM 增加长期状态的系统。它不修改 Transformer,也不训练新的长上下文模型,而是把上下文窗口视为有限的“主存”,把数据库视为容量更大的“外存”,再允许 LLM 通过函数调用主动移动、修改和检索信息。论文将这套方法命名为 virtual context management(虚拟上下文管理)。
它要解决的不是“模型最多能接收多少 Token”这一个问题,而是三个相互关联的问题:
- 对话或文档超过上下文窗口后,哪些内容应继续保留?
- 已经移出上下文的信息如何被重新找到?
- 一次任务需要多轮检索时,模型如何在不立即回复用户的情况下继续执行?
传统做法通常在窗口将满时截断旧消息,或者生成一份递归摘要。前者直接丢失信息,后者把完整历史压缩为有损表示。单次 RAG 可以取回相关片段,但检索时机和查询通常由外部程序预先决定。MemGPT 的关键变化是:把记忆管理策略交给 LLM,让模型决定写什么、搜什么、是否继续搜索以及何时返回用户。
论文标题是“Towards LLMs as Operating Systems”,但不应将其理解为 LLM 已经成为完整操作系统。更准确的结构是:
- 外部运行时提供数据库、队列、函数执行器、参数校验和容量监控等确定性机制;
- LLM 根据自然语言指令充当记忆管理策略与控制流决策器;
- 二者共同形成一个面向上下文的“小型运行时”。
因此,MemGPT 的贡献不是“无限上下文本身”,而是将上下文不足重新表述为一个可以借用分级存储、换入换出和中断机制的问题。
MemGPT 是 Agent 普及早期的重要探索。本文以论文阅读和方法分析为主,不进行本地效果复现;第 3 节数据全部来自论文,结论仅在论文的模型、数据和评测条件内成立。
2 核心内容
2.1 相关工作与问题背景
论文将已有方案分为三条路线:
| 路线 | 主要方法 | 优点 | MemGPT 关注的缺口 |
|---|---|---|---|
| 扩大模型上下文 | 稀疏注意力、低秩近似、位置外推、长上下文训练 | 单次推理可以看到更多 Token | 注意力成本随长度增长;上下文容量增加不等于信息能被稳定利用 |
| 检索增强生成 | 从外部语料检索片段,再交给 LLM 回答 | 不需要把全部知识放入 Prompt | 检索通常发生一次,查询和停止条件由外部流程预设 |
| Agent 与工具调用 | 让 LLM 调用搜索、浏览器或环境工具 | 可以在推理过程中采取行动 | 早期工作更关注行动和规划,长期记忆的容量治理尚不完整 |
MemGPT 同时吸收了三条路线的部分能力:它可以使用长上下文模型作为更大的“主存”,使用向量数据库作为外部检索器,并用 Agent 的函数调用能力控制信息移动。论文特别强调,即使未来上下文窗口继续扩大,这套机制仍有意义,因为:
- 更长的窗口带来更高的计算与内存成本;
Lost in the Middle等研究显示,模型对长上下文中部信息的利用并不稳定;- 长期对话和多文档集合的规模可以持续增长,不存在一个固定窗口能够永久覆盖。
这里需要区分两个概念:
| 概念 | 含义 |
|---|---|
| 上下文容量 | API 或模型允许输入的最大 Token 数 |
| 上下文可利用性 | 目标信息进入窗口后,模型能否定位、组合并正确使用它 |
MemGPT 主要扩大的是可寻址的外部状态规模,而不是底层 Transformer 的物理上下文窗口。所谓“无限上下文”是一种接口幻觉:外部存储可以继续增长,但模型每次推理仍只能看到有限信息。
2.2 从操作系统到 MemGPT 的角色映射
论文明确声明其原型来自操作系统的分级存储和虚拟内存。对应关系如下:
| 操作系统角色 | MemGPT 对应物 | 保留的性质 | 关键差异 |
|---|---|---|---|
| 物理内存 / RAM | Main Context | 容量有限、访问快、处理器可直接读取 | 内容以 Token 表示,每次推理都需要重新计算 |
| 磁盘 / 外存 | External Context | 容量更大,访问前需要显式搬运 | 通过关键词、时间或语义检索访问,不是按地址读取 |
| 虚拟地址空间 | Virtual Context | 向应用提供大于主存的可用状态空间 | 不存在稳定页地址和硬件地址转换 |
| 页换入 / 换出 | 记忆搜索、写入和上下文编辑函数 | 在快慢存储之间移动信息 | 搬运对象是变长文本,选择策略由概率模型执行 |
| 缺页异常(Page Fault) | 搜索需求、记忆压力提醒 | 暴露“当前上下文不足”的信号 | 不是精确硬件异常;模型未必知道自己缺少什么 |
| 系统调用 | Function Calling | 通过受控接口请求运行时能力 | 接口说明是自然语言契约,调用可能遗漏或参数错误 |
| 中断 | 用户消息、容量警告、定时事件 | 外部事件触发处理器运行 | 中断处理仍要消耗一次 LLM 推理 |
| 内存管理器 | Queue Manager + Function Executor + LLM | 管理容量、数据移动与执行顺序 | 确定性机制与概率性策略共同完成管理 |
这不是一一等价的复制。经典操作系统由内核掌握地址、访问位和缺页位置,能够确定某一页是否在内存;MemGPT 只能依靠模型对自然语言内容的判断,决定哪些信息重要、应该使用什么查询以及何时停止。因此,它迁移的是分级存储与控制流结构,不是硬件虚拟内存的全部契约。
2.3 两级上下文与五类状态
MemGPT 首先把全部状态分为 Main Context 和 External Context 两级。
2.3.1 Main Context:模型本轮真正可见的内容
Main Context 由三段连续的 Prompt Token 构成:
| 区域 | 可写性 | 主要内容 | 生命周期 |
|---|---|---|---|
| System Instructions | 只读 | 控制流、记忆层级说明、函数 Schema 和行为约束 | 每轮持续存在 |
| Working Context | 通过函数读写 | Persona、用户偏好、关键事实和当前目标 | 跨轮次保留,但容量固定 |
| FIFO Queue | Queue Manager 写入 | 用户消息、模型回复、系统警告、函数调用及结果 | 随消息滚动并触发淘汰 |
FIFO 队列的第一个位置保存一份递归摘要。队列被压缩时,旧摘要与本次被淘汰的消息共同生成新摘要;被淘汰的原始消息则继续保存在 Recall Storage 中。这样,模型始终看到一份历史轮廓,同时保留回查原文的可能。
在早期实现中,Working Context 也常被称为 Core Memory,并进一步分成 persona 与 human 等块。典型编辑接口包括 core_memory_append 和 core_memory_replace。这些名称属于实现层,论文中的抽象仍是固定容量、可由函数修改的 Working Context。
2.3.2 External Context:窗口外的持久状态
External Context 又分为两类:
| 存储 | 写入来源 | 检索方式 | 适合内容 |
|---|---|---|---|
| Recall Storage | Queue Manager 自动保存消息与回复 | 字符串或日期范围检索,并分页返回 | 完整会话历史、工具调用记录 |
| Archival Storage | LLM 主动写入或预先导入 | 语义检索,并分页返回 | 文档、反思、长期知识和不适合常驻的记忆 |
两者的差异不只是“短期”和“长期”。Recall Storage 是事件日志:尽量保存完整交互;Archival Storage 是 Agent 主动组织的知识区:需要模型决定写入内容和表达方式。论文文档问答实验还会把整个 Wikipedia Passage 集合作为 Archival Storage,使它同时承担传统 RAG 知识库的角色。
2.4 Queue Manager:容量监控与递归压缩
Queue Manager 负责接收新消息、拼接 Prompt、触发推理、写入 Recall Storage,并在上下文接近上限时执行淘汰。论文给出的示例策略如下:
1 | 新事件到达 |
70%、100% 和 50% 是论文用于说明机制的示例值,不应理解为所有 MemGPT/Letta 版本的固定参数。真正重要的是两阶段结构:先预警,让 LLM 有机会主动写回;再由运行时强制回收容量。
这一结构类似“软中断 + 强制回收”,但存在一个关键差别:操作系统可以根据页表精确判断哪些页被访问过,MemGPT 只能让 LLM 阅读文本后主观判断重要性。如果模型忽略警告、错误总结或没有写回关键信息,后续只能依靠 Recall Storage 再次找回。
2.5 Function Executor:把记忆操作变成受控接口
模型输出的 Completion Token 不直接被视为最终回复,而是先交给 Function Executor 解析。运行时校验函数名和参数,执行成功或失败后,再把结果写回 Main Context。
论文与早期实现中的典型能力包括:
| 能力 | 典型函数 | 作用 |
|---|---|---|
| 回复用户 | send_message |
产生用户可见消息,并让当前执行让出控制权 |
| 编辑核心记忆 | core_memory_append、core_memory_replace |
更新始终在上下文中的关键事实 |
| 搜索会话 | conversation_search、日期范围搜索 |
从 Recall Storage 找回原始交互 |
| 写入长期记忆 | archival_memory_insert |
把反思或知识写入 Archival Storage |
| 语义搜索 | archival_memory_search |
从归档知识中检索相关文本,并支持分页 |
函数执行失败也会作为消息返回模型,例如工作上下文已满、参数无效或页码越界。这里体现了一个早期 Agent Runtime 的重要结构:LLM 负责提出操作,确定性程序负责验证并执行,执行结果再进入下一轮推理。
2.6 事件、中断与函数链
MemGPT 不只响应用户消息。论文把能够触发 LLM 推理的输入统一称为 Event,包括:
- 用户消息;
- 上下文容量警告等系统消息;
- 用户登录、文档上传完成等外部事件;
- 定时触发事件。
一次检索经常不能完成任务。例如嵌套 KV 需要根据第一个值继续查找第二个键,多文档问答可能需要翻页或改写查询。为此,函数参数可以携带 request_heartbeat=true:函数执行完成后立即再次调用 LLM,使模型继续调用下一函数。若不请求 Heartbeat,运行时则 Yield,等待下一个外部事件。
1 | Event |
Heartbeat 的意义不只是“再调用一次模型”。它把传统单轮 Tool Calling 扩展为一个可以在回复用户前进行多步检索、编辑和校验的控制循环。今天 Agent 框架中的工具循环、节点重入和后台任务,都能看到类似结构。
2.7 方法的主要优点与缺点
主要优点
- 不要求重新训练模型。 记忆层位于模型外部,可以替换底层 LLM,并随着模型工具调用能力提升而受益。
- 完整历史与压缩表示并存。 递归摘要提供低成本轮廓,Recall Storage 保留原始消息,必要时仍可回查证据。
- 支持多步主动检索。 Heartbeat 允许模型在回复前改写查询、翻页并组合多个结果,能力超过固定的一次 Top-K 注入。
- 记忆可以被模型主动修改。 Working Context 不只是静态用户画像,Agent 可以根据新信息修正 Persona、偏好和目标。
- 事件模型适合长期运行。 用户消息、系统警告和定时任务使用统一入口,为后续有状态 Agent Runtime 提供了雏形。
主要缺点
- 高度依赖底层模型。 较弱模型可能忽略 Memory Pressure、生成错误函数参数或在完成检索前过早停止。
- 多轮推理成本较高。 每次搜索、翻页、写回和校验都可能增加一次 LLM 调用,论文没有完整报告端到端费用与长尾延迟。
- 记忆写入是有损且概率化的。 摘要、事实选择和文字改写都可能遗漏信息或形成错误记忆。
- 缺少强一致性契约。 Working Context、原始消息、归档文本与索引之间没有论文级的事务、版本和冲突模型。
- 指令与数据没有硬隔离。 从外部存储换入的文本可能被模型当作指令解释,传统页权限并未随虚拟内存类比一起迁移。
MemGPT的核心方法论集中在如何扩展LLM的上下文窗口,以及如何与用户进行更有效的交互。以下是其主要的方法和技术细节:
- 虚拟上下文管理(上图虚线框):
- 分层记忆系统:MemGPT采用了一个分层的记忆管理系统,模仿了传统操作系统中的内存管理。内部存储分为主上下文(main context)和外部上下文(external context)。前者面向LLM直接访问,后者用于完整历史的存儲。主上下文又细分为系统指令、对话内容和工作内容三部分。
- 系统指令(system instructions):是只读的,并且在MemGPT代理程序的生命周期内保持不变。
- 对话上下文(conversational context):是只读的,并且有一个特殊的剔除策略(如果队列达到一定大小,会通过递归摘要(recursive summarization)来截断或压缩部分前端)。
- 工作上下文(working context):可以通过函数调用由LLM处理器进行写入。
- 这三个部分的总和不能超过LLM处理器的最大上下文大小。在实践中,会限制对话上下文和工作上下文的大小为一个固定的常数,该常数由处理器的上下文窗口和系统指令的长度决定。因此,MemGPT通过合理划分主上下文,并使用适当的剔除策略,实现了无限上下文记忆的效果。
- 动态数据迁移:这是MemGPT的核心机制。简言之,系统让LLM可以自主地在主上下文和外部上下文之间移动数据,而无需外部干预。
- 具体来说,MemGPT在LLM的prompt中提供了详细的Function Call说明。这些函数具有预定义的输入和输出格式。在每次推理时,LLM会根据当前上下文,主动调用这些函数来读取或修改记忆。
- 当LLM需要引用过去的对话内容时,它可以调用搜索回忆存储的函数。该函数会在外部上下文中查找相关信息,并将结果页以明确格式返回到主上下文中。LLM就可以在当前的有限上下文里看到这些信息了。
- 类似地,LLM也可以主动调用写工作内容的函数,来将重要信息保存到外部上下文中。
- MemGPT使用解析器来验证和执行LLM生成的函数调用。并将执行结果反馈给LLM,这样可以训练LLM学习和调整自己的记忆策略。
2. 智能中断机制:在传统的计算机系统中,中断是一种机制,允许硬件或软件暂停当前执行的任务,以便处理更紧迫或更重要的事情。借鉴这一概念,MemGPT在用户与模型的交互中引入了“智能中断”。
- 用户指令中断:
- 在与MemGPT的交互过程中,用户可以发送特定的指令来改变会话的方向或请求特定的上下文信息。例如,用户可能希望模型回顾之前的某个主题,或者暂时忽略某些信息。
- 这些指令可以被看作是“中断”,它们使用户能够直接与模型的内部状态交互,实现更为灵活的会话管理。
- 一个例子:假设用户在与MemGPT讨论天气时突然想知道关于某部电影的信息。用户可以直接发送一个指令如“转到昨天关于《星际穿越》的讨论”。MemGPT会识别这个“中断”,并迅速切换到与该电影相关的上下文。
- 上下文切换:
- 当用户发出中断指令时,MemGPT需要快速地调整其当前的上下文,以便满足用户的新请求。这就是所谓的“上下文切换”。
- 例如,继续上面的情景,一旦用户请求回顾关于《星际穿越》的讨论,MemGPT会从其存储的历史上下文中检索该部分,并在当前会话中为用户呈现。
- 中断优先级:
- 不是所有的中断指令都有相同的优先级。有些请求可能比其他请求更紧迫或更重要。MemGPT通过为每个中断指令分配一个优先级来管理这些请求。
- 当多个中断请求同时出现时,根据其优先级,MemGPT会决定首先处理哪一个,确保最关键的任务得到优先处理。
- 例如,用户在与MemGPT的会话中同时发送了两个指令:“告诉我明天的天气”和“请提醒我5分钟后喝水”。尽管这两个指令都是中断,但“请提醒我5分钟后喝水”可能具有更高的优先级,因为它涉及到时间敏感性。
通过这种智能中断机制,MemGPT不仅提供了更大的上下文窗口,而且还为用户提供了与模型更为深入和灵活的交互方式。
3. 扩展的上下文窗口技术:
- 上下文窗口分段:为了更高效地处理超出其原始上下文窗口的信息,MemGPT将长上下文分段,并在需要时动态地加载它们。
- 优先级排序:MemGPT为上下文中的每一部分分配了一个优先级,基于其与当前交互的相关性。这确保了最相关的信息始终处于快速记忆中,并随时可供访问。
通过以上的方法,MemGPT成功地扩展了LLM的上下文窗口,同时提供了与用户更为灵活和高效的交互方式。
3 论文实验数据
本节仅复盘论文官方实验,没有进行本地复现。模型版本、数据集和评测器均按论文记录;结果不能直接外推到当前模型或当前 Letta 实现。
3.1 实验范围与模型版本
论文评估两类长上下文场景:长期对话和文档分析。
| 场景 | 任务 | 主要测量目标 |
|---|---|---|
| 长期对话 | Deep Memory Retrieval | 能否从过去会话找回一个窄范围事实 |
| 长期对话 | Conversation Opener | 能否主动利用用户长期信息生成个性化开场 |
| 文档分析 | Multi-document QA | 文档数增长并超过窗口后,问答准确率是否保持 |
| 文档分析 | Nested KV Retrieval | 能否连续执行多次检索完成多跳查找 |
论文中的模型名称对应以下固定端点:
| 论文名称 | 具体端点 | 上下文窗口 |
|---|---|---|
| GPT-3.5 Turbo | gpt-3.5-turbo-1106 |
16,385 Token |
| GPT-4 | gpt-4-0613 |
8,192 Token |
| GPT-4 Turbo | gpt-4-1106-preview |
128,000 Token |
这些端点已经不能代表当前模型能力。实验主要用于验证“让模型主动管理外部上下文”这一机制,而不是比较今天应选择哪个模型。
3.2 Deep Memory Retrieval:长期对话一致性
DMR 基于 Multi-Session Chat 数据集。原数据包含五段由人工角色扮演生成的会话,每段约十余条消息。作者使用另一个 LLM 生成第六段中的记忆挑战问题:答案必须来自过去对话,不能从 Persona 直接推断。
固定上下文基线只能看到过去五段对话的有损摘要;MemGPT 可以访问完整会话历史,但必须通过分页搜索把相关消息重新送入 Main Context。评测同时使用 ROUGE-L Recall 和 GPT-4 Judge。
| 底层模型 | 固定上下文 Accuracy | MemGPT Accuracy | 提升 | 固定上下文 ROUGE-L R | MemGPT ROUGE-L R |
|---|---|---|---|---|---|
| GPT-3.5 Turbo | 38.7% | 66.9% | +28.2 个百分点 | 0.394 | 0.629 |
| GPT-4 | 32.1% | 92.5% | +60.4 个百分点 | 0.296 | 0.814 |
| GPT-4 Turbo | 35.3% | 93.4% | +58.1 个百分点 | 0.359 | 0.827 |
该结果说明,在此任务中,保留可检索的原始对话明显优于只保留递归摘要。但它不能证明 GPT-4 基线一般性地弱于 GPT-3.5;单个数据集上的 Prompt、采样和评测方差都可能造成排序变化。
还应注意,论文中的 Judge 提示要求“宽松评分”,只要回答触及 Gold Answer 的同一主题即可判为正确。DMR 问题本身也由 LLM 合成,因此 93.4% 是这一生成与判分管线下的结果,不等于人工长期对话中的事实正确率。
3.3 Conversation Opener:长期信息能否转化为参与感
该任务要求 Agent 根据过去会话主动生成下一段对话的开场。论文用生成开场与 Persona 标签的余弦相似度衡量其覆盖程度:SIM-1 关注最相似的一个 Persona 事实,SIM-3 聚合前三个;SIM-H 则表示与人工开场的相似度。
| 方法 / 底层模型 | SIM-1 | SIM-3 | SIM-H |
|---|---|---|---|
| Human | 0.800 | 0.800 | 1.000 |
| MemGPT + GPT-3.5 Turbo | 0.830 | 0.812 | 0.817 |
| MemGPT + GPT-4 | 0.868 | 0.843 | 0.773 |
| MemGPT + GPT-4 Turbo | 0.857 | 0.828 | 0.767 |
MemGPT 生成的开场通常更长,并覆盖更多 Persona 信息,因此 SIM-1/3 高于人工开场。这里的“超过人工”只表示与 Persona 标签更相似,不应解释为对话质量全面超过人类。自然度、重复感和是否过度暴露记忆均未由该指标测量。
3.4 Multi-document QA:多轮检索对抗固定窗口
文档问答采用 NaturalQuestions-Open 的 50 条抽样问题和 2018 年 Wikipedia Passage。MemGPT 与基线共享同一套 text-embedding-ada-002 向量、余弦相似度检索器和 Gold Answer;MemGPT 使用 PostgreSQL、pgvector 与 HNSW 索引承载 Archival Storage。
区别在于:固定基线在推理前取得一次 Top-K 文档并全部塞入上下文;MemGPT 将完整文档集合置于 Archival Storage,可以改写查询、重复检索和翻页。答案必须同时返回支持答案的文档片段,再由 LLM Judge 判断。

图:论文 Figure 5。横轴为提供或可检索的文档数量,纵轴为准确率。
论文图中,MemGPT + GPT-4 与 MemGPT + GPT-4 Turbo 的准确率约为 0.72,并未随外部文档数量增长而下降;GPT-3.5 版本约为 0.40。固定上下文基线在少量文档时可能达到较好结果,但为塞入更多文档而截短每篇文本后,目标片段被裁掉的概率上升,准确率随之下降。
这组实验验证的是“Agent 可反复调用检索器”相对“一次检索后压入固定窗口”的优势,不是一个纯粹的内存层消融实验。论文也观察到:即使正确文档存在于完整排序中,MemGPT 仍可能过早停止翻页。因此,外部容量可以无限增长,模型愿意搜索多深仍然是有限的。

3.5 Nested KV:函数链能否完成多跳查找
Nested KV 把传统键值查找改造成多跳任务:键的值可能又是另一个键,模型必须继续查询,直到得到不再作为键出现的最终值。实验固定 140 个 UUID 键值对,约占 8K Token,并对初始键及中间键位置采样 30 种排列。

图:论文 Figure 7。论文正文描述了 0~4 层设置,公开图表展示到 Nesting Level 3。
图中结果可以概括为:
- GPT-3.5 固定基线在第 1 层即降至 0%;
- GPT-4 与 GPT-4 Turbo 固定基线在第 3 层降至 0%;
- MemGPT + GPT-4 在图示的 0~3 层均保持 100%;
- MemGPT + GPT-4 Turbo 在第 2、3 层约为 70% 和 60%;
- MemGPT + GPT-3.5 虽优于对应基线,但仍因没有执行足够多次查询而快速下降。
该结果揭示了 MemGPT 对底层模型能力的依赖。外部运行时可以提供 Heartbeat 和搜索函数,却不能保证模型正确理解停止条件、持续发起调用或识别当前值是否仍是键。换言之,机制提供了执行路径,策略质量仍由 LLM 决定。
3.6 官方证据的适用边界
| 边界 | 对结论的影响 |
|---|---|
| 模型版本较早 | 结果不能代表当前长上下文模型、工具调用模型或当前 Letta |
| DMR 数据由 LLM 合成 | 问题分布可能偏向生成模型容易表达和判定的事实 |
| 多项指标使用 LLM Judge | 判分存在模型偏好与提示词敏感性,且 DMR Judge 明确采用宽松标准 |
| 文档问答只有 50 条抽样问题 | 点估计的统计稳定性有限,论文未报告置信区间 |
| MemGPT 与基线的检索流程不同 | 收益同时来自完整历史、主动多次检索和函数链,不能全部归因于“分页” |
| 缺少完整成本报告 | 多轮 LLM 调用带来的 Token、延迟和费用没有与准确率一起系统呈现 |
| 递归摘要与记忆写入有损 | 论文证明可以重新检索原文,但未证明长期记忆不会累积错误或冲突 |
综合来看,论文有力证明了一个机制性结论:在有限窗口之外保留可检索状态,并允许 LLM 进行多轮记忆操作,可以完成固定 Prompt 难以完成的任务。 它没有证明真正的无限上下文、确定性记忆或低成本运行。
4 迁移解剖与联想
4.1 迁移深度:从命名到运行结构
MemGPT 是本专题中少见的、由作者在论文标题与正文中主动声明原型来源的案例。按照概念、架构和问题三层判定:
- 概念迁移明确成立。 论文直接使用虚拟内存、分级存储、分页、中断和处理器等词汇重述上下文问题。
- 架构迁移较深。 Main/External Context、Queue Manager、Function Executor、容量警告和 Heartbeat 真正参与系统运行;抽离这些结构后,MemGPT 将退化为普通 RAG 或摘要对话。
- 问题迁移只完成一部分。 系统确实把有限窗口改写为存储分层与数据移动问题,但没有获得虚拟内存的稳定地址、精确缺页、访问权限和确定性替换策略。
因此,MemGPT 超越了“LLM 像操作系统”的修辞,却没有迁移完整的虚拟内存问题形式。它更接近一套由 LLM 提供策略的用户态上下文管理器。
4.2 最关键的变化:机制确定,策略概率化
经典操作系统通常区分 Policy 与 Mechanism:页表、异常和 I/O 提供机制,CLOCK、LRU 或工作集算法决定策略。MemGPT 也存在这种分离,但策略执行者发生了变化:
| 层面 | 确定性运行时 | 概率性 LLM |
|---|---|---|
| 容量 | 计算 Token、触发 Warning、强制 Flush | 判断哪些事实值得写回 |
| 存储 | 保存消息、执行数据库读写 | 生成要保存的文本和检索查询 |
| 接口 | 校验函数与参数、报告错误 | 决定调用哪个函数及是否继续调用 |
| 控制流 | 实现 Heartbeat 与 Yield | 决定请求 Heartbeat 还是回复用户 |
这既是 MemGPT 的创造性所在,也是其主要不确定性来源。自然语言模型可以根据语义选择记忆,比 LRU 更理解“重要性”;但它可能忽略警告、错误改写事实、停止过早,且相同输入未必做出相同选择。
4.3 阻抗失配:虚拟内存前提为何不能直接复制
| 失配项 | 经典虚拟内存 | MemGPT | 后果 |
|---|---|---|---|
| 缺失检测 | 访问不存在页时产生精确 Page Fault | 模型通常不知道自己忘了什么 | 只有用户提问或搜索失败后才可能暴露缺失 |
| 寻址 | 虚拟地址映射到固定页 | 关键词、日期或向量相似度检索文本 | 结果可能漏召回,且同一事实没有稳定地址 |
| 页面大小 | 固定页或少量页规格 | 消息、摘要、文档片段长度不等 | 淘汰与装载预算难以精确规划 |
| 替换依据 | 访问位、时间戳和确定性算法 | LLM 对语义重要性的判断 | 更灵活,但不可重复且难以审计 |
| I/O 成本 | 缺页主要支付存储 I/O | 每次策略决策可能增加一次模型推理 | 多轮检索的主要成本可能是 LLM,而非数据库 |
| 接口契约 | 系统调用与 ABI 强约束 | Function Schema 由自然语言解释 | 需要运行时校验、重试和回退 |
| 隔离 | 页表、权限位和特权级 | 检索文本与系统指令共同进入 Prompt | 外部记忆可能携带 Prompt Injection |
| 恢复 | 页和进程状态可按确定格式保存 | LLM 内部推理状态不可转储 | 能恢复外部状态,不能精确恢复同一行为轨迹 |
这说明“上下文窗口 = RAM”只是一条起点。迁移真正困难的部分,是补足 MMU、页表、权限位和异常机制原本免费提供、而 LLM 系统并不具备的保证。
4.4 纵向联想:原始 MemGPT 尚未取用的操作系统机制
以下判断针对论文中的原始架构,不代表当前 Letta 全部缺失。
| 尚未充分迁移的机制 | 操作系统中的作用 | 在虚拟上下文中的候选实现 |
|---|---|---|
| 稳定虚拟地址与页表 | 位置变化时仍保持逻辑地址 | 为事实与文档分配稳定 ID,检索只负责发现,后续操作按 ID 定位 |
| Working Set | 估计进程近期真正需要的页集合 | 统计任务阶段内的记忆访问集合,而非完全依赖模型主观选择 |
| CLOCK / 二次机会 | 在低成本下近似 LRU | 当模型没有给出可靠淘汰建议时,提供确定性回退策略 |
| Dirty Bit 与写回 | 区分未修改页和待持久化页 | 标记由对话修正但尚未验证、尚未提交的记忆 |
| WAL 与原子提交 | 故障后重放并避免部分写入 | 将核心记忆、归档文本、索引和来源更新作为一次提交 |
| Prefetch | 根据局部性提前装入页面 | 根据任务计划预取下一步可能使用的记忆,同时限制误取预算 |
| TLB / 查询缓存 | 减少重复地址转换 | 缓存“任务意图—稳定记忆 ID”映射,避免重复向量检索 |
| 保护环与 Capability | 限制进程可执行的特权操作 | 区分可读记忆、可写记忆和可执行指令,敏感写入要求授权 |
| 共享内存与 COW | 多进程共享数据并隔离修改 | 多 Agent 共享项目知识,个人修改采用写时复制或显式合并 |
其中最优先的并非更复杂的检索,而是稳定身份、来源和原子写入。若一个事实被摘要、移动或重新 Embedding 后失去稳定引用,后续的审计、冲突检测和权限控制都难以建立。
4.5 横向联想:虚拟上下文还能管理什么
将 MemGPT 的机制抽象为“有限的活动区 + 大容量外部区 + 显式换入换出 + 可重入控制流”,可以得到三类横向迁移:
| 候选问题 | 页 | 页表 / 索引 | 换入触发 | 换出策略 |
|---|---|---|---|---|
| MCP 工具按需加载 | 完整 Tool Schema | 工具名与一句话能力摘要 | 任务意图命中某类工具 | 最近使用频率与任务阶段 |
| 多 Agent 工作区 | 子任务上下文与中间产物 | 任务树和产物 ID | 调度到某个子 Agent | 子任务完成、阻塞或预算耗尽 |
| 代码库上下文 | 文件、类或函数片段 | 符号表与引用图 | 编辑目标或错误栈命中符号 | 与当前调用链的距离和近期访问 |
这些联想只有在四个角色都能明确指认时才成立。如果不知道由什么信号触发换入,或没有可度量的换出标准,“分页”就仍然只是一个比喻。
4.6 反向联想:让语言模型参与经典存储策略
MemGPT 的特殊之处是用语义判断替代单纯的访问频率。该思路可以反向用于企业文档归档、客服记录或事故知识库:模型提出哪些记录应摘要、合并或进入热层,确定性系统负责校验来源、权限、容量和保留期。
但这种反向迁移不应进入内核正确性路径。磁盘页、数据库事务和安全授权不能依赖模型“可能正确”的判断。适合迁移的是语义策略建议,不是对确定性机制的替代。
4.7 候选设计:双平面虚拟上下文管理器
基于上述失配,可以提出一个可证伪的候选设计:确定性控制平面 + 概率性策略平面。
- 控制平面维护稳定 Context ID、Token 预算、访问计数、来源、权限、Dirty 状态和版本。
- LLM 只提出写回、淘汰、预取和合并建议,并附目标 ID、理由和置信度。
- 控制平面检查容量、权限、引用完整性和冲突,再原子执行或拒绝操作。
- 模型未响应、建议无效或超时后,使用 CLOCK/LRU 等确定性策略回退。
- 检索内容默认标记为数据;只有经过 Capability 校验的对象才能进入指令区。
验证时应对照原始 MemGPT 策略、纯递归摘要和固定 RAG,至少测量:DMR Accuracy、Nested KV 完成率、每题 LLM 调用数、输入 Token、P95 延迟、错误写回数、故障恢复后的孤儿记录,以及注入恶意记忆后的越权调用率。如果准确率没有提升,或相同准确率下成本和延迟显著增加,就应否决该设计。
5 相关项目扩展分享
5.1 从 MemGPT 到 Letta:从论文原型到有状态 Agent 平台
项目链接:letta-ai/letta-code
Letta 是 MemGPT 的后续形态,但两者不能直接画等号。原论文集中研究虚拟上下文;当前 Letta 的目标已经扩展到 Agent Harness、应用服务、终端与桌面端、Channel、Skill、MemFS、长期学习和 Agent SDK。
截至本文编写时,letta-ai/letta README 明确说明活跃源码已经迁移到 letta-ai/letta-code,旧 API Server 保留在 archive 分支与历史 Tag 中。复现论文时应固定早期版本或论文发布的实验代码;评估当前产品时则应使用新仓库和新文档,不能混合两条基线。
主要优点
- 将论文中的长期记忆思想扩展为可使用的 Agent Runtime,而非只提供实验脚本。
- 状态、工具、记忆和会话具有明确的服务端对象,适合构建长期运行的 Agent。
- 延续了自编辑记忆和多步工具调用思想,并增加更完整的开发与部署入口。
主要缺点
- 产品演化较快,论文术语、旧 API 和当前实现之间存在明显版本差异。
- 系统能力增加后,部署、权限、模型配置和状态迁移成本也随之增加。
- “能够保存状态”不自动等于“能够形成正确记忆”,仍需评测、审计和清理。
5.2 RAG 与 FLARE:检索增强而不是完整内存管理
论文链接:Active Retrieval Augmented Generation
传统 RAG 在生成前完成一次检索;FLARE 等主动检索方法允许模型在生成过程中判断何时检索。它们与 MemGPT 共享“外部数据按需进入上下文”的思想,但通常不负责对话队列淘汰、核心记忆编辑和跨事件控制流。
主要优点
- 结构简单,容易接入现有问答系统和知识库。
- 检索链路、Top-K 和引用结果比较容易单独评测。
- 不要求模型同时承担长期记忆写入与容量治理。
主要缺点
- 单次检索难以完成需要改写查询、翻页或多跳查找的任务。
- 缺少长期状态生命周期,无法单独解决用户偏好更新和会话接续。
- 检索器召回失败后,模型通常没有明确的恢复路径。
5.3 Generative Agents:认知架构路线
论文链接:Generative Agents: Interactive Simulacra of Human Behavior
Generative Agents 使用 Memory Stream 保存经历,并根据相关性、时间新近性和重要性检索记忆,再生成 Reflection 与 Plan。它把长期记忆解释为一种认知架构,而 MemGPT 把它解释为一种存储层级与控制流问题。
主要优点
- 显式建模观察、反思和规划,适合模拟角色行为与社会互动。
- 检索分数同时考虑语义、时间和重要性,比单一相似度更接近行为需求。
主要缺点
- 反思和规划需要额外模型调用,运行成本较高。
- 重要性评分同样由 LLM 产生,可能漂移或受到提示词影响。
- 更关注行为可信度,不提供类似虚拟内存的容量与故障契约。
5.4 OpenViking:从虚拟内存转向文件系统
项目链接:OpenViking
OpenViking 与 MemGPT 都把有限 Prompt 外的数据做成可管理状态,但原型不同:MemGPT 以虚拟内存解释换入换出,OpenViking 以文件系统解释命名、目录、分层摘要和确定性读取。
| 维度 | MemGPT | OpenViking |
|---|---|---|
| 首要问题 | 有限窗口如何承载长期运行状态 | 大量上下文如何组织、发现和治理 |
| 经典原型 | 虚拟内存、分级存储、中断 | 文件系统、命名空间、目录与索引 |
| 热层 | Main Context | 被召回并注入 Prompt 的上下文 |
| 冷层 | Recall / Archival Storage | Resource、Memory、Skill 的持久存储 |
| 数据移动 | LLM 主动调用记忆函数 | 自动召回与显式 URI 读取并存 |
| 确定性入口 | 函数 Schema | viking:// URI 与文件操作 |
| 主要风险 | 模型写错、搜错或停止过早 | 目录路由错误、索引异步一致性与固定注入成本 |
MemGPT 更强调“模型管理自己的工作集”,OpenViking 更强调“系统为模型组织可寻址的上下文”。两者并非替代关系:前者提供运行循环,后者可以成为其中一种外部存储与检索层。
5.5 总结与思想感悟
MemGPT 最重要的影响不是留下了一组具体函数,而是改变了问题的表达:
上下文窗口不再只是模型规格中的一个数字,而是一种需要分配、回收、换入、换出和保护的运行时资源。
这一表达使许多原本分散的问题进入同一个设计空间:长期记忆、RAG、工具循环、后台事件、会话压缩和 Agent 状态恢复都可以被统一讨论。它也暴露了新的工程事实:当策略制定者从确定性算法变成 LLM 后,传统系统中的每一个“保证”都必须重新检查。
因此,MemGPT 不应被概括为“通过数据库获得无限 Context”。更准确的结论是:它用外部持久状态和可重入控制流,为有限上下文模型建立了一个虚拟上下文接口。 这个接口扩大了可处理状态的范围,但没有消除检索失败、摘要损失、模型波动、安全隔离和运行成本。其真正留下的研究方向,是如何让概率性的语义策略与确定性的系统机制共同工作。



