Letta / MemGPT 深度解读

“操作系统式虚拟内存——让 Agent 自己决定记什么、忘什么、什么时候翻旧账”

一句话定位

源自 MemGPT 论文的有状态 Agent 框架，核心创新是借鉴操作系统虚拟内存的 page in/out 机制，让 Agent 通过工具调用自主管理自己的记忆——而不是交给系统自动处理。

设计哲学上最精彩的地方

Letta 的核心思想是：记忆管理不应该是系统的职责，而是 Agent 自己的能力。其他记忆系统像一个帮你整理书架的图书管理员——你说了什么，它自动归档。Letta 更像是给你自己一套整理工具（标签、文件夹、搜索引擎），让你自己决定怎么整理。

这个设计直接映射了操作系统的虚拟内存模型。Core Memory 是 RAM——容量小但始终在线，每次对话都完整注入 system prompt；Archival Memory 是硬盘——容量无限但检索需要主动发起。Agent 需要”意识到”自己缺少某个信息，然后主动去 archival 里搜——这要求 Agent 有足够好的”元认知”能力，也是 Letta 和所有”系统自动管理”派（DB-Agent-Memory、mem0、Graphiti）的根本分歧。

Block-based Core Memory——Context Window 的预算分配

Letta 的 core memory 不是一个数据库，而是几个有字符限制的”文本块”（block）：human block 存用户信息，persona block 存 Agent 人设，每个 block 有字符上限（如 2000 chars）。Agent 通过 core_memory_append()、core_memory_replace() 等工具调用来修改这些 block——但要注意预算，满了就得先删旧的再加新的。

这个设计把 LLM 的 context window 限制变成了一个显式的资源管理问题，而不是其他项目那样在系统层面悄悄截断或压缩。好处是 Agent 有完全的控制权，坏处是弱模型可能会犯低级错误——覆盖重要信息、忘记搜索归档、把无关信息塞满 core memory。

Recall vs Archival——被动回忆与主动搜索的互补

Recall Memory 是对话历史的自动检索层——系统自动从历史对话中检索相关片段，不需要 Agent 主动触发。Archival Memory 则需要 Agent 主动调用 archival_memory_search() 去搜。两者形成互补：recall 是”下意识想起来的”，archival 是”刻意去翻找的”。这个区分在认知科学上对应自动记忆和受控记忆，是 7 个项目中最接近人类记忆工作方式的设计。

局限性——框架耦合与代码体量

Letta 不仅仅是一个记忆系统，它是一个完整的 Agent 框架，记忆只是其中一个模块。这意味着很难”只用记忆模块”而不用整个框架。代码量大（~1155 文件），学习曲线陡峭。对于只需要”给已有 Agent 加记忆”的场景，Letta 太重了。此外，Agent 自管理记忆的可靠性强烈依赖底层 LLM 的能力——在 GPT-4 级别大致成立，在更弱的模型上容易出错。

本地代码结构

letta/
  letta/
    agent.py                   # Agent 核心，工具调用 + 记忆管理入口
    memory.py                  # 分层记忆系统（core/archival/recall）
    schemas/
      block.py                 # Block 定义（字符限制、类型）
      memory.py                # 记忆 schema
    server/
      rest_api/                # REST API 服务
      server.py                # Letta Server 主入口
    services/
      agent_manager.py         # Agent 生命周期管理
      block_manager.py         # Block 增删改查
    orm/                       # PostgreSQL/SQLite ORM
    functions/
      function_sets/
        base.py                # core_memory_append/replace 等内建工具
  tests/
  docker/

本地关键文件