Agent 记忆框架：架构分类与主流方案对比

调研日期：2026-08-04

范围：LangGraph、LlamaIndex、Mem0、Graphiti/Zep、Letta、CrewAI 及其代表性记忆架构。

本文由Codex主笔。

目录

• 0. 核心结论
• 1. 先区分几个容易混淆的概念
• 2. 主流 Agent Memory 的通用架构
• 3. 推荐的分类方法
• 4. 五类主流架构及代表框架
• 5. 各框架详细分析
• 6. 横向差异矩阵
• 7. 各家最容易混淆的区别
• 8. 如何选型
• 9. 设计和评估记忆系统时应检查什么
• 10. 建议的组会分享叙事
• 11. 官方资料
• 12. 版本说明

0. 核心结论

主流 Agent 框架并没有采用同一种“记忆数据库”。它们真正趋同的是一条完整的记忆流水线：

交互事件 / 对话 / 工具结果
          ↓
线程状态与 Checkpoint
          ↓
记忆形成：筛选、抽取、摘要、去重、合并、时间标注
          ↓
持久化：文档、结构化记录、向量索引、关键词索引、图、文件仓库
          ↓
检索、重排与冲突处理
          ↓
按 Token 预算装配进 LLM Context

后台路径：反思、巩固、衰减、遗忘、重新组织、权限治理

各框架的核心差异不在于“有没有 Memory API”，而在于：

• 什么信息会被写入长期记忆。
• 长期记忆以事实、文档、图还是文件的形式保存。
• 新旧事实冲突时，是追加、覆盖、失效还是保留版本。
• 查询时采用最近性、向量、关键词、实体、图关系还是时间检索。
• 记忆由业务代码、LLM、Agent 自己还是后台任务维护。

一个实用判断是：

• LangGraph 更像状态与持久化基础设施。
• LlamaIndex 更像可组合的记忆组件工具箱。
• Mem0、CrewAI Memory 更像自动形成和召回事实的记忆引擎。
• Graphiti/Zep 更像面向动态事实的时序知识图谱。
• Letta MemFS 更像由 Agent 自己维护的版本化 Context Repository。

生产系统通常会组合使用这些模式，而不是只选择一个框架。

1. 先区分几个容易混淆的概念

Memory 与 RAG 的边界

两者都可能使用向量数据库，但语义不同：

• RAG 回答“外部资料中写了什么”。
• Agent Memory 回答“这个用户、Agent 或任务过去发生过什么、学到了什么”。
• Memory 通常需要身份隔离、在线更新、时间信息、冲突处理、遗忘和删除能力。
• 在高风险系统中，Memory 不应替代原始事件日志或业务数据库成为唯一事实源。

Checkpoint 与长期记忆的边界

• Checkpoint 主要解决“任务从哪里继续”。
• 长期记忆主要解决“跨任务和跨会话应该记住什么”。
• Checkpoint 可以保存全部运行状态，但不代表这些状态都应该进入下一次 Prompt。
• LangGraph 等框架通常同时提供线程级 Checkpoint 和跨线程 Store，但两者职责不同。

2. 主流 Agent Memory 的通用架构

3. 推荐的分类方法：使用五个正交维度

“短期记忆、语义记忆、向量记忆”不应该作为同一级类别。它们分别描述生命周期、内容和存储方式。

3.1 按生命周期和作用域分类

3.2 按记忆内容分类

这一分类接近 CoALA 和认知科学中常用的划分。

需要注意：Semantic Memory 与 Semantic Search 不是同一个概念。前者描述“事实类记忆”，后者描述“按语义相似度检索”。

3.3 按表示和存储架构分类

3.4 按写入和更新策略分类

3.5 按召回策略分类

3.6 建议的标签格式

可以用以下格式描述任意框架，而不是只给它贴“长短期记忆”标签：

[作用域] × [内容类型] × [存储表示] × [写入策略] × [召回策略]

例如：

• Mem0：User/Session × Semantic Facts × Vector + Entity Index × 自动抽取、ADD-only × Hybrid Retrieval。
• Graphiti：Subject × Semantic + Episodic × Bi-temporal Graph × Episode 增量抽取 × Graph + Time + Hybrid Retrieval。
• Letta：Agent/Shared × Semantic + Procedural × Git-backed Files × Agent 自编辑、后台巩固 × 文件搜索、按需读取。

4. 五类主流架构及代表框架

这些分类不是完全互斥的。例如 Mem0 也包含实体连接，CrewAI 也包含层级 Scope，Letta 也可以安装向量搜索。但每个框架都有一个主导架构。

5. 各框架详细分析

5.1 LangGraph：状态与持久化基础设施

核心架构

• 短期记忆是 Graph State 的一部分，按 thread_id 隔离。
• Checkpointer 在节点执行后保存状态，使线程可以恢复、回放和分支。
• 长期记忆使用 Store，通过自定义 namespace + key 组织跨线程 JSON 数据。
• Store 可支持结构化过滤和语义检索。

Thread Input
    → Graph State
    → Node Execution
    → Checkpoint

Cross-thread Memory
    → Namespace / Key Store
    → Filter or Vector Search

记忆形成与更新

LangGraph 通常不替开发者决定“什么值得记住”。记忆写入可以：

• 在主执行路径的某个 Node 中完成。
• 由 Agent 调用记忆工具完成。
• 由独立后台任务完成。

抽取、去重、冲突处理和遗忘策略需要应用自行设计或连接外部记忆引擎。

优势

• 工作流状态、Checkpoint 和长期 Store 的边界清晰。
• 对复杂 Agent、长任务、中断恢复和 Human-in-the-loop 支持好。
• 开发者控制力高，适合做记忆系统的编排层。

局限

• 它不是开箱即用的“智能记忆引擎”。
• 不默认提供事实抽取、记忆巩固、冲突解决或时序关系建模。
• 直接把全部 State 当成长期记忆会导致 Context 膨胀。

最合适的定位

Runtime State + Persistence + Orchestration

生产中经常用 LangGraph 管理运行状态，再接 Mem0、Graphiti 或自研 Memory Service 管理长期记忆。

5.2 LlamaIndex：Buffer 与 Memory Block 组合

核心架构

• 短期层默认保存 Token 限制内最近的消息，行为类似 FIFO 队列。
• 短期消息超过阈值后，较老消息会 Flush 到长期 Memory Blocks。
• 读取时将短期历史和各个 Block 的结果重新合并。
• 通过 Priority 和 Truncate 控制总 Token 预算。

当前预定义的代表性 Block 包括：

• StaticMemoryBlock：始终注入的固定信息。
• FactExtractionMemoryBlock：从历史消息中抽取事实。
• VectorMemoryBlock：将历史批次写入向量库并按相关性召回。

Recent Messages
    → Token-limited FIFO
    → Overflow / Flush
        ├── Static Block
        ├── Fact Extraction Block
        └── Vector Memory Block
    → Merge + Priority Truncation

优势

• 组件化程度高，适合实验不同记忆策略。
• 短期和长期的 Token 分配、Flush 大小和 Block 优先级均可控制。
• 容易接入不同 Vector Store 和自定义 Memory Block。

局限

• 默认仍以消息和 Block 为中心，身份治理和复杂冲突语义需要额外实现。
• 多个 Block 的结果可能重复或相互矛盾。
• Workflow Context 与 Memory 是两个对象，使用时需要明确职责。

最合适的定位

Composable Memory Components for RAG and Agents

5.3 Mem0 v3：原子事实与多信号混合检索

作用域模型

Mem0 将记忆划分为 Conversation、Session、User 和 Organization 等层次，并通过 user_id、run_id 等实体字段进行隔离。

当前写入架构

Mem0 v3 已从旧版两阶段 ADD/UPDATE/DELETE 判断转向单次 LLM、ADD-only 抽取：

Input Conversation
    → 召回相关旧记忆作为去重上下文
    → 单次 LLM 抽取新的原子事实
    → 批量 Embedding
    → Hash 精确去重
    → 写入 Vector Store
    → Entity Extraction + Linking

新事实不会直接覆盖或删除旧事实。信息变化时，新旧事实可以同时保留，检索阶段负责将当前更相关的信息排在前面。

当前召回架构

Query
    → Semantic Vector Search
    → BM25 Keyword Boost
    → Entity Matching Boost
    → Score Fusion
    → Top-K

需要注意：

• BM25 和 Entity Matching 主要参与排序加权，并不一定扩展向量召回候选集。
• 当前所谓 Graph Memory 是实体与 Memory 的连接，用于提升相关记忆排名。
• 它不是 Graphiti 那种带类型关系和双时态边的完整知识图谱。
• OSS 新架构已移除外部 Neo4j 等 Graph Store 配置，改为现有向量库中的内置 Entity Store。

优势

• 接入成本较低，适合用户偏好和跨会话个性化。
• 原子事实比整段 Transcript 更容易复用。
• Semantic、BM25 和 Entity 三类信号对自然语言查询覆盖较好。
• 提供 User、Agent、Run 等常用隔离能力。

局限

• ADD-only 会保留互相矛盾的历史事实，最终正确性较依赖召回排序。
• Entity Linking 不能代替明确的关系类型和时间有效性。
• 在超长历史中，大量相似事实可能导致候选竞争。

最合适的定位

General-purpose Personalization Memory Service

5.4 Graphiti/Zep：面向动态事实的双时态知识图谱

核心架构

Graphiti 以 Episode 作为增量摄取单位，将非结构化文本或结构化 JSON 转换为实体、关系和事实：

Episode
    → Entity / Relation Extraction
    → Entity Resolution
    → Temporal Edge Construction
    → Contradiction / Fact Invalidation
    → Context Graph

它采用双时态模型，通常需要区分：

• 事实在现实世界中何时有效。
• 系统何时获知或记录该事实。

这使系统可以同时回答当前状态和历史状态问题。

召回架构

Graphiti 将多种检索信号组合使用：

• 向量语义相似度。
• BM25 全文检索。
• 图遍历和节点距离。
• 时间过滤和事实有效性。

Graphiti 与 Zep 的关系

• Graphiti 是开源时序知识图谱框架，负责抽取、双时态、事实失效和混合检索。
• Zep 是基于该思路构建的托管平台，增加规模化存储、治理、性能和企业能力。

优势

• 最擅长实体关系、多跳推理、事实变化和历史查询。
• Append Episode 的方式保留来源和演化过程。
• 比纯 Vector Memory 更能表达“谁在什么时候与谁有什么关系”。

局限

• 实体消歧、关系抽取和时间抽取错误会进入图结构。
• 图数据库、索引和数据治理的复杂度高于普通向量记忆。
• 对简单用户偏好场景可能过重。

最合适的定位

Dynamic Relationship and Temporal Memory

5.5 Letta：Agent 自己维护的 Git-backed MemFS

当前核心架构

Letta 当前 Agent Harness 使用 MemFS 保存长期记忆：

• 每个 Agent 拥有一个 Git-backed Memory Repository。
• 记忆以带 YAML Frontmatter 的 Markdown 文件保存。
• system/ 中的内容每轮加载进 System Prompt。
• 其他目录仅保留在目录树中，需要时由 Agent 搜索和读取。
• skills/ 可以保存 Agent 自己维护的 Procedural Memory。

$MEMORY_DIR/
├── system/
│   ├── persona.md
│   └── human.md
├── reference/
│   └── project-notes.md
└── skills/
    └── my-skill/
        └── SKILL.md

MemFS 默认不依赖向量索引。Agent 可以使用普通文件搜索；需要时可安装 Keyword、Semantic 或 Hybrid Search 模块。

写入和巩固

• Agent 可以直接读取、编辑、拆分和重组 Memory Files。
• 每次编辑形成 Git Commit，保留版本历史。
• Dreaming 使用后台 Agent 审查近期对话、提炼长期经验并更新记忆。
• 后台维护可以通过 Git Worktree 与主 Agent 并发工作。
• 多个 Agent 可以挂载同一个 Shared Memory Repository。

与旧版 Letta/Memory Blocks 的关系

旧版 Letta API 强调：

• Core Memory Blocks 常驻 Context。
• Archival Memory 通过语义检索按需召回。
• Agent 通过工具修改自己的 Memory Blocks。

当前 Harness 的主线已经转向 MemFS，但“少量核心内容常驻，大量长期内容按需加载，Agent 自己维护记忆”的思想保持不变。

优势

• 记忆对人和 Agent 都可直接阅读、修改和审查。
• Git 提供版本、差异、回滚和冲突处理能力。
• 特别适合项目规范、工作偏好、Agent 身份和 Skills。
• Procedural Memory 的表达能力强于仅保存事实的向量系统。

局限

• 目录层级和核心文件可能逐渐膨胀，需要定期 Doctor/Reorganize。
• 未安装索引时，大规模事实检索能力弱于专业 Vector/Graph Memory。
• 允许 Agent 自编辑规则，需要权限、审计和防提示注入设计。

最合适的定位

Versioned, Human-readable, Self-editable Context Repository

5.6 CrewAI 1.15.7：统一、层级化的 Memory Engine

当前核心架构

CrewAI 已将旧版分离的 Short-term、Long-term、Entity 和 External Memory 合并为统一 Memory 类。

主要特点包括：

• 记忆组织为类似文件系统的层级 Scope，例如 /project/alpha、/agent/researcher。
• 未指定 Scope 时，LLM 根据内容和已有树结构自动推断位置。
• Memory Slice 可以让 Agent 同时读取多个 Scope，并配置只读权限。
• Crew 会在任务完成后抽取离散事实，在下一任务前召回相关记忆。

写入和合并

保存时，LLM 可以推断：

• Scope。
• Category。
• Importance。
• Entity、Date、Topic 等 Metadata。

新内容与已有高相似记录发生冲突时，Consolidation Pipeline 可以执行：

• keep：保留现有内容。
• update：合并和更新现有内容。
• delete：删除过期或被替代内容。
• insert_new：将新内容作为独立记录插入。

这与 Mem0 v3 的 ADD-only 路线形成明显区别。

召回与排序

CrewAI 使用复合评分：

score = semantic_weight × similarity
      + recency_weight × decay
      + importance_weight × importance

它还提供两类召回深度：

• Shallow：直接向量检索和复合排序。
• Deep：LLM 分析查询、选择 Scope、并行检索，并在置信度较低时继续探索。

批量写入可以在后台进行，recall() 通过 Read Barrier 等待待处理写入，保证读到最新数据。

优势

• 与 Crew、Agent 和 Flow 生命周期集成紧密。
• Scope 和 Slice 适合多 Agent 的共享、私有和组合记忆。
• 同时考虑语义、最近性和重要性。
• 内置去重和可变更新，比单纯向量检索完整。

局限

• Scope 推断、重要性评分、合并和 Deep Recall 都依赖 LLM，成本和行为稳定性需要评估。
• 没有 Graphiti 那种显式双时态关系模型。
• 自动更新可能错误覆盖历史事实，因此仍需保留原始事件和 Provenance。

最合适的定位

Integrated Hierarchical Memory for Multi-agent Workflows

6. 横向差异矩阵

6.1 架构与表示

6.2 写入、冲突与时间

6.3 能力侧重点

“强弱”表示框架的原生侧重点，不代表通过扩展无法实现。

7. 各家最容易混淆的区别

7.1 LangGraph 与 Mem0/CrewAI 不是同一层竞争关系

• LangGraph 解决运行时状态、节点编排、Checkpoint 和 Store 接口。
• Mem0/CrewAI Memory 解决事实抽取、长期存储、召回和部分巩固逻辑。
• 常见组合是 LangGraph 管运行，Mem0 或其他 Memory Engine 管长期记忆。

7.2 LangGraph 与 LlamaIndex

• LangGraph 的主抽象是 Stateful Graph 和 Checkpoint。
• LlamaIndex 的主抽象是数据、索引、Retriever 和可组合 Memory Blocks。
• 复杂状态机和中断恢复优先 LangGraph；快速实验不同检索/Memory Block 优先 LlamaIndex。

7.3 Mem0 与 CrewAI Memory

共同点：

• 都面向原子事实和跨会话召回。
• 都提供 Scope/Entity 隔离和自动 LLM 抽取。
• 都使用向量语义检索并叠加其他信号。

关键区别：

• Mem0 v3 采用 ADD-only，尽量避免更新阶段的第二次 LLM 判断。
• CrewAI 会用 LLM 对相似记录执行 Keep/Update/Delete/Insert。
• Mem0 的召回强调 Semantic + BM25 + Entity Fusion。
• CrewAI 强调层级 Scope、Semantic + Recency + Importance，以及 Deep Recall。
• Mem0 更适合作为独立 Memory Service；CrewAI Memory 与 Crew/Agent/Flow 集成更紧。

7.4 Mem0 Graph Memory 与 Graphiti 不是同一种图

• Mem0 当前图结构主要连接“实体”和“提到该实体的记忆”，用于检索加权。
• Graphiti 保存实体之间带语义和时间的关系边，并处理事实有效区间和失效。
• “查询关于 Alice 的所有记忆”适合 Mem0 Entity Boost。
• “Alice 在去年和今年分别负责什么、关系何时变化”更适合 Graphiti。

7.5 Letta 与向量记忆系统

• Mem0/CrewAI 倾向让 LLM 抽取记录，再由检索器找到相关记录。
• Letta 倾向让 Agent 像维护项目文件一样维护自己的长期上下文。
• Letta 对规则、偏好、项目知识、Prompt 和 Skills 的版本化管理更自然。
• 大规模事实召回仍可能需要给 MemFS 增加关键词或向量索引。

7.6 Graphiti 与 Zep

• Graphiti 是开源的时序知识图谱构建和查询框架。
• Zep 是面向生产规模、治理和低延迟服务的托管平台。
• 两者的架构思想一致，但运维边界和企业能力不同。

8. 如何选型

8.1 按核心问题选择

8.2 常见组合架构

通用对话 Agent

LangGraph Checkpoint
    + Mem0 User Memory
    + 业务数据库
    + 原始对话 Event Log

企业关系型 Agent

Workflow Runtime
    + Graphiti/Zep Context Graph
    + CRM / ERP Source of Truth
    + 权限与审计层

编码 Agent

Session Checkpoint
    + Letta-style Context Repository
    + Project Files / Git History
    + 可选 Vector Code Search

多 Agent 研究或内容生产

CrewAI Scope / Slice
    + Shared Project Memory
    + Agent-private Memory
    + 文档 RAG

8.3 一个简化决策顺序

• 先判断是否需要恢复任务状态。需要则先设计 Checkpoint。
• 再判断长期内容主要是事实、关系还是规则/文件。
• 事实优先考虑 Atomic Fact + Hybrid Retrieval。
• 动态关系和历史状态优先考虑 Temporal Graph。
• 规则、技能和人机共同维护内容优先考虑 Context Repository。
• 最后设计写入、冲突、遗忘、权限和 Context Budget，而不是只选数据库。

9. 设计和评估记忆系统时应检查什么

不应只看单一 Benchmark 分数

评测需要固定以下条件后再比较：

• 使用相同的抽取模型、Embedding 模型和 Answer Model。
• 使用相同 Top-K、Token Budget 和延迟预算。
• 同时报告准确率、召回 Token 数、写入成本和查询延迟。
• 区分小规模对话 Benchmark 与百万 Token 级长期历史。
• 单独测试知识更新、矛盾、时间、多跳、拒答和跨用户隔离。

10. 建议的组会分享叙事

可以按以下顺序组织分享：

• 为什么 Context Window 不等于 Memory：窗口有限，而且长上下文本身会降低质量并增加成本。
• 统一流水线：事件、记忆形成、持久化、召回、Context Assembly、后台巩固。
• 五维分类法：作用域、内容、表示、写入更新、召回。
• 五类架构：Checkpoint、Memory Block、Atomic Fact、Temporal Graph、Context Repository。
• 框架对比：LangGraph、LlamaIndex、Mem0、Graphiti/Zep、Letta、CrewAI。
• 真正困难的问题：冲突、时间、遗忘、权限、污染和评估。
• 结论：工程上通常采用组合架构，记忆库不是业务事实源。

可以用下面这句话收束：

Agent Memory 的本质不是把所有历史塞回模型，而是持续地把经历转化为可治理的外部状态，并在正确的时间以有限成本取回正确的部分。

11. 官方资料

• LangGraph: Memory overview
• LangGraph: Add and manage memory
• LlamaIndex: Memory
• Mem0: Memory Types
• Mem0: Migrating to the New Memory Algorithm
• Mem0: Graph Memory
• Graphiti/Zep: Overview
• Letta: MemFS
• Letta: Memory and Dreaming
• CrewAI 1.15.7: Memory
• CoALA: Cognitive Architectures for Language Agents

12. 版本说明

Agent Memory 框架变化很快，阅读旧文章时需要特别检查版本：

• Mem0 旧版的外部 Graph Store 和 ADD/UPDATE/DELETE 流程已不能代表当前 v3 架构。
• CrewAI 旧版 Short-term、Long-term、Entity、External 四套 Memory 已被统一 Memory API 替代。
• Letta 旧版 Core/Archival Memory 仍有概念价值，但当前 Agent Harness 的主架构是 MemFS。
• 框架宣传的 Benchmark 往往使用不同模型、Top-K 和 Token Budget，不宜直接横向比较。