业界 Agent Memory 方案调研

OpenAI Memory / ChatGPT Memory 机制分析

OpenAI 在 2024 年为 ChatGPT 引入的 Memory 功能是目前覆盖面最广的 Agent Memory 实现。

架构特征

• 显式记忆：用户或 AI 可以主动创建/删除记忆点
• 隐式记忆：AI 在对话中自动提取值得记住的信息
• 记忆格式：短句（每条记忆是一个简短的陈述句）
• 注入方式：每次对话开始时将所有记忆拼接注入 System Prompt

设计取舍

对 claude-mem 的启发

OpenAI 的方案证明了”记忆短句”的格式对消费级产品有效，但对工程场景不够用——软件决策需要 narrative（叙述）和 facts（依据），不是一句话能概括的。claude-mem 的 Observation 结构（type + title + narrative + facts）是对这个限制的回应。

LangChain / LangGraph Memory 模块

LangChain 的 Memory 模块是开发者最常接触的 Agent Memory 框架。

架构特征

# LangChain Memory 类型
ConversationBufferMemory      # 完整对话历史
ConversationSummaryMemory     # 对话摘要
ConversationKGMemory          # 知识图谱记忆
VectorStoreRetrieverMemory    # 向量检索记忆

设计取舍

• 框架耦合：Memory 深度绑定到 LangChain 的 Chain/Agent 抽象
• 运行时范围：主要解决单次运行内的上下文管理，跨运行的持久化需要额外接入
• 灵活性高：提供多种 Memory 类型组合使用
• 无 Observation 概念：记忆单元是”消息”或”摘要”，不是结构化的工作观察

与 claude-mem 的对比

LangChain Memory 解决的是”框架内的对话记忆管理”，claude-mem 解决的是”IDE 级别的跨会话工作记忆”。两者面向不同层次：LangChain 在 Agent Runtime 层，claude-mem 在 Developer Tool 层。

LangGraph 的 State Persistence（CheckPointer）更接近 claude-mem 的定位——它持久化 Agent 的执行状态，支持恢复和回放。但它是执行级持久化，不做语义压缩。

Mem0：开源 Memory Layer

Mem0（前身 embedchain）是目前最活跃的开源 Agent Memory 项目之一。

架构特征

from mem0 import Memory
 
m = Memory()
m.add("用户偏好使用 TypeScript", user_id="alice", metadata={"category": "preference"})
results = m.search("编程语言偏好", user_id="alice")

核心组件：

• Memory Store：向量数据库（Qdrant / ChromaDB / Pinecone）
• LLM Extraction：用 LLM 从对话中提取记忆点
• Graph Memory：可选的知识图谱层（Neo4j）
• Multi-Level：用户级 / Agent 级 / 会话级记忆分层

设计取舍

值得借鉴的设计

• Memory 分层（user/agent/session）是企业级场景的刚需
• Graph Memory 用知识图谱建立记忆间的关系，比纯向量检索多了一层”关联性”
• Memory 冲突检测：新记忆与旧记忆矛盾时主动处理

Zep：长期记忆服务

Zep 定位为 Agent 的长期记忆基础设施服务。

架构特征

• 自动摘要：对话过长时自动生成 running summary
• 实体提取：从对话中提取人名、组织、概念等实体
• 时间感知：记忆带时间戳，支持”最近 vs 久远”的衰减排序
• 多会话：跨会话共享用户画像
• Fact Extraction：从非结构化对话中提取结构化事实

独特之处

Zep 的”时间感知”设计值得关注：记忆不是平等的。一周前的决策比一年前的偏好更可能相关。Zep 通过时间衰减因子影响检索排名。

claude-mem 后来走了一条相近的路：v13.29.0 加入了可选的 ACT-R 强化排序（CLAUDE_MEM_REINFORCE_ALPHA，默认关闭），被反复确认的老观察可以重新进入 SessionStart 的窗口（第 10 章）。区别在于 Zep 用衰减压低旧记忆，claude-mem 用强化抬高仍然有效的旧记忆。

MemGPT / Letta：操作系统式内存管理

MemGPT（现在的 Letta）将操作系统的虚拟内存概念引入 Agent：

架构特征

Main Context (Working Memory) ← → Archival Memory (Long-term)
        ↕                              ↕
  Conversation Buffer            Vector Database
  (当前对话窗口)                (所有历史信息)

核心创新：

• 自我编辑的上下文：Agent 可以主动将信息从 Working Memory 移到 Archival Memory
• 分页系统：类似 OS 的 page in/page out
• 持久化 Agent：Agent 状态完整保存，支持暂停和恢复
• Function Calling 驱动：内存操作通过工具调用完成

设计取舍

MemGPT 给予 Agent 完全的内存管理自主权——Agent 自己决定什么放 Working Memory、什么归档。代价是：

• Agent 需要额外的”内存管理 Token”开销
• 不合理的内存管理决策可能导致关键信息丢失
• 调试复杂度高（为什么 Agent 忘记了某个信息？）

与 claude-mem 的对比

Cognee：知识图谱驱动的记忆引擎

Cognee 的独特之处在于将知识图谱作为记忆的底层表示。

架构特征

• 知识图谱优先：每条信息转化为图中的节点和边
• 关系推理：可以回答”A 和 B 有什么关系？”
• 增量更新：新信息自动合并到图中，处理冲突
• Multi-Source：支持从文档、代码、对话等多种来源提取知识

对企业级 Memory 的启发

知识图谱在以下场景特别有价值：

• 团队知识管理：谁负责什么模块？模块之间怎么依赖？
• 决策追溯：这个技术选型影响了哪些后续实现？
• 冲突检测：新的决策是否与旧决策矛盾？

宿主自带的记忆：Claude Code 与 Codex

前面几种都是独立的记忆层。还有一类越来越重要的方案：Agent 宿主自己带的记忆。

Claude Code 的 auto-memory：Claude Code 会把它认为值得记住的内容写成 Markdown 文件，放在 ~/.claude/projects/<编码后的工作目录>/memory/ 下，由一个 MEMORY.md 做索引，新会话开始时读取。Codex 也有自己的记忆目录 ~/.codex/memories。这两个路径都出现在 claude-mem 的源码里，下面会讲到原因。

宿主自带记忆的优势是零安装、与宿主的上下文管理深度集成；局限是格式和能力由宿主决定，记忆只在这一个宿主里可用，也没有自动的“观察 → 压缩”流水线，记什么由模型临场决定。

claude-mem 对它的态度在一年里变了一次，这个变化本身就很说明问题：

• v12.7.2（2026-05）：安装时默认给 Claude Code 设置 CLAUDE_CODE_DISABLE_AUTO_MEMORY=1，关掉内置记忆，避免两套记忆同时注入
• v13.29 起：提供 npx claude-mem memory ingest，把 auto-memory 的 Markdown 文件导入成观察（不调用模型，跳过 MEMORY.md 和超过 64 KiB 的文件）
• v13.35.0（2026-10）：安装时改成询问，推荐“保持开启”；PreToolUse Hook 在宿主读取自己的记忆文件、或调用 memory_search 这类原生记忆工具时，用同一个查询在 claude-mem 里检索一次，把结果作为补充上下文附上；还可以配置一个笔记目录监听，持续导入（docs/native-memory-bridge.md）

从“替代”到“共存并桥接”，背后的判断是：宿主的原生记忆不会消失，用户也不会只用一个宿主。独立记忆层的价值，越来越多地体现在跨宿主、跨设备、跨团队这几个宿主自己不做的方向上。第 18 章（多宿主）和第 19 章（多设备同步）展开这两个方向。

Quick Try：各方案 5 分钟体验

想亲自感受各方案的差异？以下是最快的体验路径：

Mem0

pip install mem0ai
python3 -c "
from mem0 import Memory
m = Memory()
m.add('用户偏好 TypeScript 和 React', user_id='demo')
m.add('项目使用 PostgreSQL 数据库', user_id='demo')
results = m.search('数据库技术栈', user_id='demo')
print(results)
"

LangChain Memory

pip install langchain langchain-community
python3 -c "
from langchain.memory import ConversationSummaryBufferMemory
from langchain_community.llms import FakeListLLM
llm = FakeListLLM(responses=['摘要：用户在讨论数据库选型'])
memory = ConversationSummaryBufferMemory(llm=llm, max_token_limit=100)
memory.save_context({'input': '我们用 PostgreSQL 还是 MongoDB?'}, {'output': '取决于数据结构'})
print(memory.load_memory_variables({}))
"

MemGPT / Letta

pip install letta
# Letta 需要更多配置，以下仅展示核心概念
python3 -c "
from letta import create_client
client = create_client()
# 需要配置 LLM provider，详见 https://docs.letta.com
print('Letta client created. See docs for full setup.')
"

Zep

# Zep 需要运行服务端，推荐 Docker
docker run -p 8000:8000 ghcr.io/getzep/zep:latest
pip install zep-python
python3 -c "
from zep_python import ZepClient
client = ZepClient('http://localhost:8000')
print('Zep server running. Add messages via client.memory.add_memory()')
"

Cognee

# Cognee 依赖 Neo4j（知识图谱数据库），门槛较高
# 这段只验证安装是否成功；真正运行需要配置 LLM Key 和图数据库
pip install cognee
python3 -c "
import cognee
# 需要配置 LLM 和图数据库，详见 https://github.com/topoteretes/cognee
print('Cognee installed. Requires Neo4j for full graph features.')
"

如果你只想体验一个，推荐 Mem0——安装最简单，API 最直观，且不需要额外的数据库服务。

各方案横向对比与启发提炼

按“记忆由谁管理、服务于哪一层”来划分，各方案的定位如图 15-1 所示：

图 15-1：Agent Memory 方案的定位分类

再从能力维度做横向对比：

Star 数为 2026-10-12 通过 GitHub API 查询的数值（claude-mem 99,871、LangChain 147,662、Mem0 67,025、Cognee 32,073、Letta 25,111、Zep 4,956），四舍五入到千位。

构建企业级平台时的关键借鉴

1. 来自 Mem0：记忆分层。Mem0 分 user / agent / session 三层，放到组织里对应的是个人 / 团队 / 组织
2. 来自 Zep：时间衰减与自动摘要
3. 来自 MemGPT：Agent 应有”主动管理记忆”的能力
4. 来自 Cognee：知识图谱做关系追溯和冲突检测
5. 来自 claude-mem：Progressive Disclosure + Hook 驱动的非侵入性，以及与宿主原生记忆共存而不是对抗

思考题

1. Mem0 和 claude-mem 都支持本地存储。如果你要做一个 “Memory 迁移工具”（从 Mem0 导入到 claude-mem），数据模型的映射关系是什么？哪些字段会丢失？
2. MemGPT 让 Agent 自己管理内存，claude-mem 用外部系统自动管理。对于”写代码”这个场景，哪种方案更合适？为什么？
3. 如果你是技术负责人要在这些方案中选型，除了技术能力外，还要考虑哪些因素？（提示：社区活跃度、商业可持续性、锁定风险）

本书开源发布于 inferloop.dev，转载请注明出处。

下一章将基于这些调研结论，设计从单机 Plugin 到分布式多租户平台的架构升级路径。