Letta（原 MemGPT）：有状态 Agent 平台的工程取舍
从 arXiv 论文到商业化平台，Letta 把「记忆」做成了 Agent 运行时的一部分。它解决了什么问题，又为什么集成成本偏高。
2026-04-1712分钟
来源：MemGPT 论文 arXiv 2310.08560（UC Berkeley）、Letta 官方文档 https://docs.letta.com 、官方仓库 https://github.com/letta-ai/letta
在记忆赛道里，绝大多数产品走的是「外挂」路线：应用照旧自己管 Agent，只在旁边加一个记忆服务。Letta 走的是另一条路——把记忆当作 Agent 运行时的一部分，从头设计。理解这条路线的好处与代价，是与 MemGPT 这篇论文和它后来的商业化最相关的部分。
要点速览：一句话定位——Mem0 是给现有应用外挂记忆服务，Letta 是让应用长在自带记忆的运行时上；Agent File 让记忆可导出、可 diff、可回滚。换来的是架构侵入性强、接入成本高。从零构建长期运行的 Agent，这条路线才值得。
一、起点：一篇把 LLM 当操作系统的论文
MemGPT 的原始论文标题是 MemGPT: Towards LLMs as Operating Systems（arXiv 2310.08560），作者来自 UC Berkeley。它提出的核心类比是：
把 LLM 的上下文窗口看作「物理内存」，把外部存储看作「磁盘」，再让 LLM 通过函数调用自己做页面调度。
这个类比之所以有效，是因为它把「上下文不够用」从一个模型能力问题，转化成了一个已经被操作系统领域研究了几十年的资源调度问题。论文给出的关键机制包括：
- 分层内存：主上下文（main context）承载当前推理所需信息，外部上下文（external context）承载召回存储与归档存储
- 自主换页：模型通过函数调用自行决定何时把信息写入外部存储、何时取回
- 中断机制：在长流程中主动触发自我编辑与再检索，而不是等上下文塞满才处理
- 告警机制：在上下文接近容量上限时提示模型主动整理
口径说明：MemGPT 论文报告的是特定设置下的实验结论，与今天生产环境的表现不构成直接可比。论文的贡献在于提出了可复用的架构范式，而非证明某个固定分数。
二、演进：从论文到 Letta 平台
项目后来更名为 Letta，定位从「一个记忆增强的 LLM 方案」转向「具状态智能体（stateful agents）平台」。官方文档披露的能力面包括：
| 能力 | 说明 |
|---|---|
| Agent 持久化 | Agent 的状态（含记忆块 memory blocks）持久存储，可随时恢复继续对话 |
| 记忆块（Memory blocks） | 把记忆拆成命名块，可读可编辑，模型通过工具调用增删改 |
| Agent File（.af） | 把 Agent 的完整状态导出为可移植文件，支持迁移与版本化 |
| 多后端部署 | 自托管服务端、本地运行，或使用 Letta 托管云服务（Constellation） |
| SDK 与 CLI | Python / TypeScript SDK；CLI 工具 @letta-ai/letta-code |
| 模型无关 | 通过统一接口接入多家模型供应商 |
其中 Agent File 是个容易被忽略但很有工程价值的设计：记忆不再是锁在某个数据库里的黑盒，而是可导出、可 diff、可回滚的工件。这对「Agent 行为出现回归时如何排查」这类问题提供了直接抓手。
三、与 Mem0 的路线差异
两者最本质的差别不是功能多少，而是谁承担记忆管理的职责。
| 维度 | Mem0 | Letta |
|---|---|---|
| 定位 | 记忆层 / 记忆 API | Agent 运行时 |
| 集成方式 | 外挂到既有应用，调用 add / search | 应用接入 Letta 运行时，Agent 在其中运行 |
| 谁决定记什么 | 提取管线（写入侧策略） | Agent 自身（工具调用决策） |
| 记忆形态 | 结构化事实条目 | 可编辑的记忆块 + 归档存储 |
| 可控性 | 策略在管线中，应用侧较难干预 | 记忆是 Agent 的一等状态，可读取、编辑、导出 |
| 接入成本 | 低，几行代码 | 高，需要接受一套运行时 |
用一句话概括：Mem0 是给现有应用加一个记忆服务，Letta 是让应用长在一个自带记忆的运行时上。
四、代价与适用边界
Letta 的设计自由度换来了更高的复杂度，这一点在选型时往往被低估：
- 架构侵入性强：接受 Letta 意味着接受它的 Agent 抽象、工具调用协议与部署形态，迁移成本高于调用一个记忆 API
- 自托管门槛：要完整获得能力通常需要自己跑服务端，对只想加记忆的团队偏重
- 记忆质量依赖模型决策：由 Agent 自主决定何时写入、何时归档，意味着效果与所用模型的工具调用能力直接相关，弱模型上表现会明显波动
- 调试链路更长：一次「记错了」可能来自模型决策、记忆块编辑、检索召回任一环节，排障需要看完整轨迹
适合与不适合：
- 适合：从零构建的长期运行 Agent、需要 Agent 自主管理状态的多会话场景、研究性质的记忆机制实验（可复现、可导出状态是刚需）
- 不适合：只想给现有应用补一层记忆的轻量需求、团队不愿意引入额外运行时、对冷启动延迟极其敏感的短交互场景
五、小结
MemGPT 论文的长期价值，是把「上下文有限」重新定义为一个调度问题；Letta 平台的长期价值，是把「Agent 的记忆」变成了可持久化、可迁移、可审计的工程对象。如果你的项目需要 Agent 自己掌握记忆的主动权，这条路线值得认真评估；如果只是想让 AI 记住用户偏好，外挂式方案通常更省事。
参考来源
- MemGPT 论文：https://arxiv.org/abs/2310.08560
- Letta 官方文档：https://docs.letta.com
- Letta 官方仓库：https://github.com/letta-ai/letta
- Letta 官网：https://www.letta.com