Letta 的「记忆优先」运行时：把上下文窗口当操作系统的虚拟内存管，为什么比外挂向量库更扛长任务
Letta 源自 MemGPT 研究，核心命题只有一个：别再把记忆当外部插件，而把上下文窗口当成操作系统管理的稀缺内存。框架替 Agent 做分页、压缩、归档与召回，Agent 还能在运行时自主编辑自己的记忆。本文拆解它相对『框架 + 向量库』方案的机制差异、代价与适用边界——读完你会知道什么场景该上 Letta、什么场景它纯属过度工程。
大多数 Agent 框架处理「记忆」的方式，是在你的主循环外面挂一个向量数据库：每轮把对话切块、embedding、存进去，需要时再检索拼回 prompt。Letta 不这么干。它把 MemGPT 论文里那个最反直觉的类比当成产品骨架：上下文窗口不是数据库，是 RAM；而记忆管理是操作系统该做的事，不是应用层该手搓的胶水。
上下文窗口不是数据库，是 RAM：MemGPT 的关键类比
MemGPT（2023）的出发点是一句话：LLM 的上下文窗口和电脑的内存一样，是个容量有限、但访问极快的稀缺资源。操作系统怎么对付内存？它不让你直接操心物理内存多大，而是给你一套虚拟内存抽象——活跃页驻留、不常用的页换出到磁盘、需要时再调页回来。MemGPT 把这个机制翻译成 Agent 的「记忆层级」：工作记忆（working context）是 RAM，核心记忆（core memory）是常驻的寄存器，归档记忆（archival memory）是硬盘。上下文管理由框架接管，Agent 只负责「决定什么该留下、什么该归档」，而不是每次都靠检索兜底。
这一步的代价是认知负担：开发者必须接受「Agent 是一个带内存层级的长驻进程」，而不是一个请求-响应函数。这正是 Letta 比「框架 + 向量库」更难上手的地方，也是它更 principled 的地方。
三层记忆各自管什么：核心 / 工作 / 归档
Letta 把记忆切成清晰的层级。核心记忆是一小块始终在上下文里的文本（身份、用户画像、长期约束），类似 OS 的寄存器——小但永远在线。工作记忆是当轮活跃区，承载当前任务的草稿与中间结果。归档记忆是容量近乎无限的外部存储（PostgreSQL 持久化），放长尾历史、文档与过期上下文。框架在三者之间做自动分页：当工作区快满，就把低优先级内容压缩或归档，并在相关性回升时调回。
和「每轮全量检索」相比，这种层级让 Agent 在数周、数百轮的交互里保持身份与知识连续，而不必每轮把整段历史塞回窗口、也不必依赖检索召回率。对一个跑一个月的私人助理，这差别是质的不同。
自编辑记忆：Agent 在运行时改写自己的「人设与知识」
Letta 最不像外挂记忆的一点，是记忆自编辑（self-editing memory）：Agent 在运行时能主动调用工具去读、写、整理自己的记忆块。它可以在对话中把「用户偏好暗色主题」写进核心记忆，也可以把一段长文档摘要后归档。记忆不是被动存取的黑盒，而是 Agent 自己维护的状态。
这正是 MemGPT 研究主张的「agent manages its own context」——把上下文管理从「框架猜」变成「Agent 决定」。代价是你需要信任 Agent 的编辑动作，并给它足够的工具边界；否则一个写坏的记忆块会污染后续所有轮次。Letta Code 0.31.x 引入了共享记忆的 frontmatter 校验和 Git 自动推送，就是把「自编辑」从野路子变成可审计的同步事件。
0.31.x 把记忆做成带校验的文件系统，意味着什么
Letta Code 在 2026-08-27 到 09-03 之间连续发布了 0.31.4–0.31.12，最大的架构变化都围绕「记忆成为可校验的文件系统」：可配置内存布局、可配置大小上限、共享记忆 frontmatter 校验、更准确的 MemFS v2 token 估算，以及提交后自动 Git 推送。实际含义是——记忆结构可以变，但校验不再可选；一个 malformed 的 markdown/frontmatter 会在进入持久上下文前就被拒绝。
同期还有两个值得注意的变化：子代理（subagent）改为后台运行，父 Agent 拿到 task id 后继续干活，子代理可以指向另一台机器或新的 Cloud sandbox；MCP 收敛到一个统一 letta mcp CLI（发现、列工具、查 schema、调用），旧的 cloud-mcp 命令被移除。这些改动让「记忆 / 远程执行 / 工具发现」三件事的边界更干净，但也意味着老脚本要跟着迁移。
和「框架 + 向量库」比，Letta 改了哪件事
把 Letta 和三种常见方案放一起看，差异就很清楚了。Mem0 是「给你的 Agent 加记忆层」——你保留自己的 Agent 模型，它只管存和取；LangGraph 是「显式状态图」——你用节点和边编排，状态是你自己定义的 JSON；「框架 + 向量库」是你手工拼检索与注入，控制力最大但决策最多。Letta 处在另一条轴：它要求你用它的 Agent 运行时，换回的是一套被编码进框架的上下文管理决策。
换句话说，Mem0 卖的是记忆，Letta 卖的是「把记忆管理本身做成运行时的心智模型」。当你的问题核心就是「上下文如何不爆、长任务如何不丢状态」时，Letta 的取舍是划算的；当你只是想给一个短会话聊天机器人记住用户名，它就是过度工程。
代价：你买到的不是记忆层，是一整套 Agent 心智模型
这套架构不是免费午餐。第一，学习曲线比外挂记忆陡：团队要从请求-响应思维切换到「长驻进程 + 内存层级」。第二，你必须接受 Letta 的 Agent 模型，而不是把记忆加进已有 Agent——迁移成本在重构。第三，生态比 Mem0 小，周边工具与案例更少。第四，对单会话、短生命周期的 Agent，它的价值几乎为零，反而增加运维面。
Letta Code 0.31.x 的远程执行还暴露了一个现实约束：原来固定 10 分钟等待会被改成「看 runtime 状态是否还活跃」，说明长任务真正跑起来后，调度与生命周期本身成了工程重点，而不是框架宣传语里的「自动管理」。
作者判断：什么时候该上 Letta，什么时候该绕开
一句话：上下文管理是你系统的核心难题时，Letta 是当下开源里最 principled 的答案；否则它多半是杀鸡用牛刀。具体看三条——任务是否跨周/跨数百轮（是才值）；你是否愿意把 Agent 重构成 Letta 运行时（不愿就选 Mem0）；记忆是否要可检视、可调试、可审计（要，Letta 强；不要，外挂层更轻）。把 MemGPT 的虚拟内存类比当成一个真实的产品决策来看，而不是营销词，你就能判断它适不适合你的下一条 Agent 流水线。