跳到主要内容
Agent Memory ANN 系统

第4章：Agent Memory 系统总览 —— Mem-GPT / A-MEM / MIRIX / MemOS / AgeMem 功能矩阵

把 2023-2026 这条 Agent Memory 应用层演进线讲透：Mem-GPT 的 OS-style memory、A-MEM 的 Zettelkasten 语义链接、MIRIX 的 6 类记忆 + 多 Agent、MemOS 的 MemCube 抽象、AgeMem 的 RL lifecycle、SimpleMem 的语义压缩。给出一张能力矩阵和选型决策树，最后讲清楚这些 Stage 4 系统的「功能优先」哲学为什么留下了「系统层性能」这个空洞——这正是 Pancake 等 Stage 5 工作的 motivation。

Agent Memory Mem-GPT A-MEM MIRIX MemOS AgeMem SimpleMem Letta

第 3 章把动态 ANN 系统这条工程线讲完了，但有一类读者会质疑：“这些都是 ANN 索引层面的工作，跟 Agent 实际怎么用记忆有什么关系？” 这个质疑很正当——ANN 索引是地基，Agent Memory 框架是建筑。2023-2025 这两年 Agent Memory 应用层冒出来一堆框架，从 Mem-GPT 到 MemOS，每家都有自己的”记忆模型”。本章按时间序把六个最有代表性的系统拆开讲：每个系统讲它”把记忆建模成什么”、“提供什么 API”、“内部怎么用 ANN”，最后用一张能力矩阵和选型决策树把它们摆到一起。读完这章你会明白：这些应用层框架在”什么是记忆”上有大量分歧，但在”底下 ANN 索引怎么管”上几乎完全沉默——这就是 Pancake 等系统层工作的研究价值。

📑 目录

1. 为什么”应用层框架”是独立一层

1.1 三层架构图

┌─────────────────────────────────────────────────────┐
│  Application Layer（本章覆盖）                       │
│  Mem-GPT / A-MEM / MIRIX / MemOS / AgeMem / ...    │
│  ┌────────────────────────────────────────────┐    │
│  │  问题：「Agent 应该记什么？什么时候忘？        │    │
│  │   多 Agent 怎么共享？Episodic 还是 Semantic？」│    │
│  └────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────┘
                       │
                       ▼ 调用
┌─────────────────────────────────────────────────────┐
│  Indexing Layer（第 2-3 章 + 第 5-7 章覆盖）         │
│  Faiss / hnswlib / DiskANN / SPFresh / Pancake      │
│  ┌────────────────────────────────────────────┐    │
│  │  问题：「向量怎么搜得快？动态插入怎么不掉           │    │
│  │   recall？多 agent 怎么共享索引？」            │    │
│  └────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────┘
                       │
                       ▼ 调用
┌─────────────────────────────────────────────────────┐
│  Storage Layer（模块十三 / 模块十六覆盖）            │
│  DRAM / SSD / CXL / RDMA / 鲲鹏 UB                   │
└─────────────────────────────────────────────────────┘

🌟 关键事实：Stage 4 应用层框架几乎只关心顶层那个问题——他们假设”底下有一个能工作的 vector store”就够了，往往直接用 Pinecone / Chroma / Faiss 作为 backend，不深究索引层细节。

1.2 这一层在解什么问题

Agent 用记忆时，会问几个”应用语义”层面的问题：

问题静态 RAG 回答Agent Memory 框架回答
该记什么？所有文档选择性：重要事件、用户偏好、工具调用结果
怎么组织？扁平文档库分层（Working / Episodic / Semantic）
什么时候忘？永不忘有遗忘机制（TTL / RL / 摘要）
怎么检索？单次向量搜索多 hop / context-aware / agent profile
多 Agent 怎么共享？不支持共享池 + ACL + 一致性协议

🍎 直觉对应：ANN 索引层是图书馆的书架排列方式，应用层框架是”什么书该买、什么书该扔、不同读者怎么共用书”的策略。两者解决的问题正交，互不替代。

2. Mem-GPT / Letta：OS-style memory 的起点

2.1 论文背景

Mem-GPT（Packer et al., 2023, arXiv:2310.08560）是这个领域的开山之作。论文标题就是 “MemGPT: Towards LLMs as Operating Systems”——把 LLM 当 OS 看，把上下文窗口当物理内存看。

2.2 核心抽象：三层内存

┌──────────────────────────────────────────┐
│  Working Memory (主上下文)                │  ← LLM 当前看得见的
│  ── system prompt + 最近对话 + 工具 ──    │     ~32K tokens
│  最近、最相关、最不可妥协                  │
└──────────────────────────────────────────┘
              ↕ swap in/out
┌──────────────────────────────────────────┐
│  Archival Memory (向量库)                 │  ← LLM 通过工具调用访问
│  ── 所有历史对话、知识、文档 ──            │     无限大
└──────────────────────────────────────────┘
              ↕ recall
┌──────────────────────────────────────────┐
│  Recall Memory (FIFO + 关键词索引)        │  ← 最近 N 轮原始对话
│  ── 短期"缓存层"，配合 archival 工作 ──    │     ~万级
└──────────────────────────────────────────┘

🍎 直觉对应：Working = L1 cache，Recall = L2 cache，Archival = 硬盘。LLM 用”工具调用”显式 swap in/out（memory_insert, memory_search, core_memory_replace）。

2.3 关键 API

# 用 Letta（Mem-GPT 的工业化实现）
from letta import create_client

client = create_client()
agent = client.create_agent(
    name="my-agent",
    persona="A helpful AI assistant",
    human="The user is a Python developer"
)

# 让 agent 处理消息（内部自动管理 memory）
response = client.send_message(
    agent_id=agent.id,
    message="Remember that I prefer dark mode in all apps."
)

# Agent 内部会调用：
# - core_memory_replace(label="human", new_content="...prefers dark mode")
# - archival_memory_insert(content="User stated preference for dark mode")

2.4 内部怎么用 ANN

  • Archival memory：默认 Chroma 或 pgvector，HNSW 索引
  • 每次检索：向量相似度 top-10
  • 更新：每次 archival_insert 触发一次 HNSW insert

🧠 关键洞察：Mem-GPT 把 ANN 索引当作”黑盒键值对存储”。它不在乎索引是 HNSW 还是 IVF，只在乎能 insert + search。这种解耦在 demo 阶段很好，但 agent 跑久了，索引退化（剪枝悖论、recall 悬崖）会直接拖垮整个系统。

2.5 留下的开放问题

  • ❌ 核心内存边界靠 hard-coded 大小 —— 没有自适应
  • ❌ Recall + Archival 的归并由 LLM 决定 —— 不可控、不可解释
  • ❌ 不支持多 Agent

🌟 结论：Mem-GPT 是”概念奠基”——它告诉了世界”LLM 也需要分层 memory”，但留了几乎所有系统层细节给后人。

3. A-MEM：Zettelkasten 式语义链接

3.1 论文背景

A-MEM（Xu et al., 2025, arXiv:2502.12110）由 Rutgers + Cornell 等团队提出，标题 “A-MEM: Agentic Memory for LLM Agents”。它问了一个 Mem-GPT 没回答的问题：记忆和记忆之间应该怎么连接？

3.2 核心思想：Zettelkasten 卡片盒

Zettelkasten 是 20 世纪德国社会学家 Niklas Luhmann 发明的研究方法——每张卡片记一个独立想法，卡片之间用人工建立的链接形成知识网。A-MEM 把这个思想搬到 Agent Memory：

原始记忆（事件）：
  ┌─────────────────────────────────┐
  │ Event 1: "User asked about Y"   │
  │ Event 2: "Tool returned Z"      │
  │ Event 3: "User edited code A"   │
  └─────────────────────────────────┘
        ↓ Agent 自主创建语义链接
  ┌─────────────────────────────────┐
  │ Card-1: {content: "...",        │
  │   tags: ["coding", "Python"],   │
  │   links: ["Card-3", "Card-7"]   │
  │ }                                │
  │ Card-3: {                        │
  │   content: "...",                │
  │   links: ["Card-1", "Card-5"]    │
  │ }                                │
  └─────────────────────────────────┘

关键创新：链接不是预定义的，而是 Agent 在生成记忆时自己决定连到谁（“哪些过去的记忆和这条相关？”）。

3.3 实证发现

  • 在 LongMemEval / LoCoMo 等长记忆 benchmark 上，A-MEM 比 Mem-GPT 提升 15-25% 准确率
  • 链接密度越高，检索召回越高（但延迟也增加）

3.4 内部怎么用 ANN

  • 每张卡片仍然是一个向量（用 OpenAI ada-002 或类似 embedding）
  • 检索时：先做向量 top-k 找”候选卡片”，再沿着链接做 1-2 hop 扩展

🧠 关键洞察：A-MEM 不改变 ANN 索引，但把 ANN 检索的结果当成”图扩展的起点”。这意味着检索质量极度依赖 top-k 准不准——ANN 退化的影响在 A-MEM 里被链接扩展放大。

3.5 留下的开放问题

  • ⚠️ 链接质量依赖 LLM 自评 —— 链接太多或太少都不好
  • ⚠️ 链接图怎么遗忘 —— 一个被删除的卡片，它的链接是死链
  • ❌ 不支持多 Agent

4. MIRIX：6 类记忆 + 多 Agent 协同

4.1 论文背景

MIRIX（Wang & Chen, 2025, arXiv:2507.07957）是第一个明确把多 Agent 共享记忆作为一等公民的框架。论文标题 “MIRIX: Multi-Agent Memory System for LLM-Based Agents”。

4.2 核心创新：6 种记忆类型

MIRIX 把记忆细分为 6 类，每类有不同的 API 和存储后端：

记忆类型用途存储
CoreAgent 自身 persona / system promptKV
Episodic”在某个时间发生的事件”向量库 + timestamp 索引
Semantic抽象知识、概念定义知识图 + 向量库
Procedural工具用法、操作流程结构化 schema
Resource文档、代码、图片文件系统 + 向量库
Workflow多 step 任务的中间状态关系数据库

4.3 多 Agent 协同

       Agent A          Agent B          Agent C
          │                │                │
          ▼                ▼                ▼
    ┌─────────────────────────────────────────┐
    │           共享 Episodic Memory          │  ← 所有 agent 都能读
    └─────────────────────────────────────────┘
    ┌─────────────────────────────────────────┐
    │  私有 Core (per agent)                  │  ← 只有自己能读写
    │  Agent A's Core │ Agent B's Core │ ...  │
    └─────────────────────────────────────────┘
    ┌─────────────────────────────────────────┐
    │  共享 Semantic Memory                   │
    │  (主动同步：A 学到的概念立刻 B 可用)     │
    └─────────────────────────────────────────┘

🧠 关键洞察：MIRIX 把 ACL 和一致性抽象在框架层——但它假设底下的 vector store 支持多读者多写者。实际上 HNSW 在并发更新下退化严重（参见第 3 章），这是 MIRIX 没解决的”系统盲点”。

4.4 内部怎么用 ANN

  • 默认 backend: Chroma / Milvus / Weaviate
  • 多 Agent 共享同一个 collection，但每条记忆带 agent_id filter
  • 没有特殊处理多租户场景下的索引设计

4.5 留下的开放问题

  • ❌ 多 Agent 一致性靠手动 —— 没有自动同步协议
  • ❌ 共享池下索引退化 —— 频繁混合插入让 HNSW 更易退化
  • ⚠️ 6 类记忆的边界靠经验 —— “这条算 episodic 还是 semantic” 是 fuzzy 的

🌟 结论：MIRIX 是 Stage 4 多 Agent 方向的开拓者，但留下了”多 Agent 共享 ANN”这个系统问题——这正是 Pancake 第 6 章的腹地。

5. MemOS：MemCube 抽象与系统资源化

5.1 论文背景

MemOS（2025, arXiv:2507.03724）借鉴 OS 的资源管理哲学，提出 MemCube 作为记忆的统一抽象。

5.2 核心抽象：MemCube

MemCube = (Content, Metadata, Policy)

Content:  
  - 可以是文本、向量、知识图节点、文件路径
  - 多模态原生支持

Metadata:
  - 时间戳、agent_id、TTL、importance score
  - 关系（parent/child/sibling MemCube）

Policy:
  - 谁能读、谁能写（ACL）
  - 什么时候迁移到冷存储（tiering）
  - 什么时候过期（GC）

🍎 直觉比喻：MemCube 之于记忆 ≈ 文件之于操作系统——统一抽象，让上层 agent 不关心存储细节。

5.3 MemOS 的”系统资源化”

MemOS 把”内存”当作 OS 管理的资源：

  • 配额：每个 agent 有上限（防止单 agent 占满）
  • 优先级：高优先级 MemCube 优先驻留内存
  • 迁移：低频访问的 MemCube 自动迁移到 SSD/对象存储
  • GC：到期或被标记删除的 MemCube 异步回收

5.4 内部怎么用 ANN

  • ANN 是 MemOS 的”存储后端之一”——内存中的 MemCube 用 HNSW 索引
  • 迁移到 SSD 的用 DiskANN
  • 迁移到对象存储的用 IVF-PQ + 倒排索引

🧠 关键洞察：MemOS 是第一个把”分层存储”作为 Agent Memory 一等公民的框架——但它的”分层”主要是策略层，底下 ANN 索引仍然是每一层独立的，跨层一致性靠 metadata 同步。

5.5 留下的开放问题

  • ❌ 跨层迁移代价高 —— 把 MemCube 从 SSD 拉回内存要重建 HNSW
  • ⚠️ 策略表达力受限 —— ACL / TTL 都是声明式，不支持动态调整
  • ⚠️ 基线工业系统少 —— 论文实验主要在自造 workload

6. AgeMem：用 RL 学习记忆 lifecycle

6.1 论文背景

AgeMem（2026, arXiv:2601.01885）的副标题是 “Learning Unified Long-Term and Short-Term Memory Management”。它问了一个所有前面工作都回避的问题：到底什么时候该忘？谁来决定？

6.2 核心思想：把记忆操作建模为 RL

AgeMem 定义了五种记忆动作：

动作含义
store新记忆入库
retrieve检索记忆用于当前任务
update用新信息覆盖旧记忆
summarize把多条记忆合并为一条摘要
discard丢弃过期或不重要的记忆

用 RL 训练一个 policy 来决定何时做哪个动作：

state  = (current_task, current_memories, recent_events)
action = one of {store, retrieve, update, summarize, discard}
reward = task_success - α × memory_size - β × retrieval_latency

🧠 关键洞察：AgeMem 把”记忆管理”从 hard-coded 规则升级为”可学习的 policy”。但这只是应用层决策——它决定的是 store/discard，不决定底层 ANN 怎么实现这些操作的高效性。

6.3 实证发现

  • 在长对话 benchmark 上，AgeMem 减少 50%+ 记忆存储，同时保持任务准确率
  • 学到的 policy 表现出”重要事件保留更久、闲聊快速 discard” 的直觉行为

6.4 留下的开放问题

  • ❌ 底下 ANN 不感知 lifecycle —— summarize / discard 动作在索引层都是 delete，没有特殊优化
  • ⚠️ 训练成本高 —— RL policy 需要大量交互数据

7. SimpleMem：语义压缩 + 意图感知检索

7.1 论文背景

SimpleMem（2026, arXiv:2601.02553）回到了一个更实用的角度：在不引入 RL 的情况下，用启发式做语义压缩 + 意图感知检索。

7.2 核心技巧

  1. 语义压缩：每 N 条对话用 LLM 生成一条 “摘要 memory”，原始对话进冷存储
  2. 意图感知检索：检索时先用 LLM 推断”当前任务意图”，然后做带意图过滤的向量搜索
  3. 两阶段召回：第一阶段宽召回（top-50），第二阶段用 LLM 重排（top-10）

7.3 工程数据

  • 在 LongMemEval 上比 Mem-GPT 提升 20% 准确率
  • 总记忆量减少 60-70%

7.4 留下的开放问题

  • ⚠️ 重排引入额外 LLM 调用 —— 延迟 + 成本
  • ⚠️ 意图推断准确率有限 —— 复杂任务下意图不明确

🌟 结论：SimpleMem 是”工程实用派”代表——没有理论突破，但用扎实的工程把效果做出来了。

8. 能力矩阵与选型决策

8.1 六个框架能力矩阵

能力Mem-GPTA-MEMMIRIXMemOSAgeMemSimpleMem
分层记忆✅ (3 层)⚠️ (扁平 + 链接)✅ (6 类)✅ (MemCube)⚠️ (RL 决定)⚠️ (压缩层)
语义链接❌✅ (核心)⚠️ (类型间)⚠️ (parent/child)❌⚠️ (意图过滤)
多 Agent❌❌✅ (核心)✅❌❌
可学习 lifecycle❌❌❌⚠️ (策略)✅ (核心)❌
分层存储⚠️❌❌✅ (核心)❌⚠️ (冷/热)
底层 ANN 关心程度黑盒黑盒黑盒黑盒黑盒黑盒

⭐ 关键发现：六个框架在”底层 ANN 关心程度”上都是黑盒——这就是 Stage 5 系统层工作的研究空间。

8.2 选型决策树

你的 Agent 是什么类型？
│
├── 单 Agent / 个人助手 ─────────→ Mem-GPT (Letta) ⭐ 工业级最成熟
│                                  或 SimpleMem (工程实用派)
│
├── 长对话 / 角色扮演 ───────────→ A-MEM ⭐ 语义链接最适合
│
├── 多 Agent 协作团队 ──────────→ MIRIX ⭐ 唯一专门设计的
│
├── 企业级 / 多租户 ──────────→ MemOS ⭐ 系统资源化
│
└── 极度成本敏感 ─────────────→ AgeMem (压缩 50%+)
                                 或 SimpleMem (语义压缩)

8.3 与底层 ANN 索引的搭配

Agent Memory 框架推荐底层 ANN理由
Mem-GPTHNSW（小库）→ DiskANN（大库）单 Agent 读写比可控
A-MEMHNSW + 链接图（自定义）链接 traversal 内存友好
MIRIXPancake（推荐） 或 IVF-PQ多 Agent 共享，需要 multi-tenant 优化
MemOSDiskANN + Object Store分层存储天然适配
AgeMem任意（lifecycle 在上层）ANN 选型独立
SimpleMem任意 + 重排层压缩后规模通常较小

9. Stage 4 的盲点：系统层性能

9.1 一组刺眼的数字（来自 Pancake 论文）

把 Stage 4 的六个框架放到一个统一 workload 下（Mem-GPT 风格、8M 向量、50 个 agent）：

框架Memory 操作占总时长ANN 查询占 memory 操作
Mem-GPT (Letta + Chroma)82%95%
A-MEM (论文实现)78%90%
MIRIX (论文实现)85%92%

🌟 关键事实：所有 Stage 4 框架，agent 跑起来 80%+ 时间花在 memory 操作，而 memory 操作 90%+ 是 ANN 查询——但这些框架的论文没有一句话讨论 ANN 索引设计。

9.2 为什么 Stage 4 集体忽略系统层

三个原因：

  1. 学术分工：应用层论文 reviewer 不期待你讲索引细节；系统论文 reviewer 不在乎你的 agent 任务定义
  2. 工业默认：大家都用 Pinecone / Chroma 当 backend，索引细节”运营商负责”
  3. demo 规模：论文实验通常 1M 以下向量，HNSW 单机不退化，看不出问题

9.3 什么时候这变成问题

  • 规模 > 10M 向量
  • 持续动态更新（每秒 > 100 次）
  • 多 Agent 共享
  • 长尾延迟敏感（P99 < 100 ms）

这四个条件任一满足，Stage 4 的”黑盒 ANN”假设就开始破产。这就是 Pancake / Quake / OdinANN 在 2025-2026 年涌现的根本原因——工业落地把 Stage 4 的盲点逼出来了。

🌟 关键判断：Agent Memory 系统的研究主战场，从 2026 年开始正在从”应用层语义”转移到”系统层性能”。如果你做研究，未来 2-3 年的论文增长点会更多在 Stage 5（本模块第 5-9 章）。

✅ 自我检验清单

  • 应用层 vs 索引层 vs 存储层：能画出这三层的分工图，并解释每一层解决什么核心问题
  • Mem-GPT 三层结构：能口述 Working / Recall / Archival 各自的角色和大小
  • A-MEM 语义链接：能解释 Zettelkasten 思想，并讨论”链接太多 vs 太少”的权衡
  • MIRIX 6 类记忆：能列出这 6 类并说出每类典型用途；能指出 MIRIX 在底层 ANN 上的盲点
  • MemCube 抽象：能解释 (Content, Metadata, Policy) 三元组各自的作用
  • AgeMem 五动作：能列出 store/retrieve/update/summarize/discard，并解释 RL 在其中扮演什么角色
  • 能力矩阵：能根据”单 agent 长对话 / 多 agent 协作 / 企业多租户”三种场景，给出框架选型建议
  • Stage 4 盲点：能引用 Pancake 的 “82% 时间花在 memory” 数据，解释为什么应用层框架不够

📚 参考资料

概念入门

关键论文（按时间序）

Stage 4 应用层框架：

  • MemGPT: Towards LLMs as Operating Systems（Packer et al., 2023）：arXiv 2310.08560 ⭐ —— 开山之作
  • A-MEM: Agentic Memory for LLM Agents（Xu et al., 2025）：arXiv 2502.12110 —— Zettelkasten 语义链接
  • MIRIX: Multi-Agent Memory System for LLM-Based Agents（Wang & Chen, 2025）：arXiv 2507.07957 —— 多 Agent + 6 类记忆
  • MemOS: A Memory OS for AI System（2025）：arXiv 2507.03724 —— MemCube 抽象
  • AgeMem: Learning Unified Long-Term and Short-Term Memory Management（2026）：arXiv 2601.01885 —— RL lifecycle
  • SimpleMem: Efficient Lifelong Memory for LLM Agents（2026）：arXiv 2601.02553 —— 语义压缩

评测 / 综述：

  • LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory（2024）：arXiv 2410.10813 —— Stage 4 主流 benchmark
  • LoCoMo: Long Conversational Memory Benchmark（2024）：arXiv 2402.17753
  • Memory in LLMs: A Survey（2024）：搜索 arXiv “memory in LLMs survey”

行业讨论

框架文档

本系列其它章节