做过AI Agent开发的人都遇到过一个尴尬场景：用户昨天告诉Agent"我是素食主义者，别推荐含肉食谱"，今天Agent却热情地推荐了红烧肉。

这就是没有记忆的Agent的悲剧——每次对话都是一张白纸，不知道用户是谁，不记得说过什么。一个没有记忆的Agent，本质上只是一个高配版计算器。

在Agent系统中，记忆能力直接决定了用户体验的连贯性、系统的决策质量，甚至关系到安全性（医疗Agent记错药物禁忌、金融Agent记错风险偏好都会造成严重后果）。

今天我整理了5款主流的开源记忆框架，帮助你在架构选型上做出正确决策。

Agent记忆的三个维度

在选择框架之前，需要先明确Agent需要哪种类型的记忆：

• 情景记忆（Episodic Memory）——具体发生过什么事。存储对话片段、交互历史、事件记录。例：用户上次说不喜欢辣的食物。
• 语义记忆（Semantic Memory）——用户是什么人。存储事实、偏好、用户画像，跨会话持久存在。例：用户是素食主义者，在上海工作，喜欢健身。
• 程序记忆（Procedural Memory）——Agent学会了什么。存储行为规则、工作流、反思后的策略。例：每次用户问价格，先问预算范围再推荐。

三种记忆的完整组合，才构成一个真正"有脑子"的Agent。

框架一：Mem0 — 最成熟的生产级选择

GitHub Stars：4.8万 | 官网：https://github.com/mem0ai/mem0 | 融资背景：$24M

定位：给Agent装一个自动去重、三层隔离的智能记忆层。

核心架构：

• 混合存储设计（Vector + Graph + KV），三层记忆作用域隔离
  • User层：用户偏好、历史画像（跨所有会话持久）
  • Session层：当前对话上下文（会话级别）
  • Agent层：Agent自身的知识（Agent私有）
• 自编辑机制——新事实与旧记忆冲突时自动更新而非追加，保持记忆精简
• 代码接入简洁，托管云部署可用

性能指标：LongMemEval基准49.0%（时序推理场景有局限）

适用场景：个性化推荐Agent、客服Agent、需要快速落地的团队。

缺点：图记忆功能需要$249/月Pro订阅；无时序建模能力。

框架二：Zep / Graphiti — 时序推理最强

GitHub Stars：5K | 官网：https://github.com/getzep/graphiti | 产品地址：getzep.com

定位：把每条记忆都打上时间戳和有效期，能推理"这个事实什么时候变了"。

核心架构：

• 时序知识图谱——每个事实作为知识图谱节点，附带有效时间窗口
• 事实版本化管理："Kendra喜欢Adidas球鞋"（有效期：2025-01至2026-03）被新事实覆盖后变为"Kendra喜欢Nike球鞋"（有效期：2026-03至今）
• 旧事实不删除只失效，历史记录完整保留，支持事实变化追溯
• 检索延迟P95约300ms，查询不需要额外LLM调用（混合语义+BM25+图遍历）

性能指标：LongMemEval基准63.8%——比Mem0高15个百分点，时序任务优势明显

适用场景：金融风控Agent、医疗Agent、CRM类需要追踪事实变化的系统。

缺点：部署复杂度高于Mem0；社区规模较小，文档相对有限。

框架三：Letta / MemGPT — OS级记忆管理

GitHub Stars：3.6万 | 官网：https://github.com/letta-ai/letta | 前身：MemGPT

定位：把操作系统的分层内存管理思路引入Agent。

核心架构：

• 分层内存设计，模仿OS内存层级

  层级	类比	内容	特点
  Core Memory	内存RAM	当前对话核心信息	始终在context窗口内
  Recall Memory	缓存Cache	近期对话历史	按需检索
  Archival Memory	硬盘HDD	长期知识存储	无限扩展

• Agent自主记忆管理——提供工具供Agent主动调用：core_memory_replace()、archival_memory_search()、archival_memory_insert()
• 原生多Agent协作——多个Agent可共享同一记忆池
• 与其他框架最大的差异在于Agent自己知道自己在管理记忆

适用场景：需要长期自我进化的Agent、研究型Agent、多Agent协作的复杂系统。

缺点：上手成本高；需要部署Letta Server；工程化要求较高。

框架四：A-MEM — 论文级别的算法创新

GitHub：https://github.com/agiresearch/A-mem | 论文：arXiv 2502.12110 | 学术引用：412次

定位：用"卡片笔记法（Zettelkasten）"组织AI记忆，让记忆之间自动建立关联网络。

核心架构：

• Zettelkasten启发设计——每条记忆是一张"知识卡片"，卡片间自动建立关联链接
• 记忆处理流程
  1. 构建笔记：提取关键概念、上下文、标签
  2. 动态链接：分析与已有记忆的关联，自动建立索引链接
  3. 进化更新：已有记忆根据新信息动态更新，不是简单追加
• 返回的不是单条记忆，而是关联记忆网络
• 被引用412次（arXiv），2025年记忆领域引用量最高论文之一

适用场景：知识密集型Agent、学术研究助手、需要复杂推理关联的系统。

缺点：工程化程度不如Mem0/Letta；生产案例较少；学习曲线陡峭。

框架五：MemOS — 系统级统一调度方案

GitHub：https://github.com/MemTensor/MemOS | 论文：arXiv 2505.22101 | 发布时间：2025年5月

定位：不只是记忆框架，而是把"记忆"当成操作系统资源来统一调度。

核心架构：

• 三态记忆统一调度（MemCube）

  记忆类型	实现形式	类比
  激活记忆（Activation Memory）	KV-Cache	CPU寄存器
  文本记忆（Plaintext Memory）	向量数据库/文档	内存RAM
  参数记忆（Parameter Memory）	LoRA权重微调	硬盘固化

• 三态互相转化机制
  • 高频访问的文本记忆自动转为KV-Cache加速访问
  • 持续活跃的激活记忆可调度为参数记忆永久固化
• MemScheduler根据访问频率、重要性、时效性自动管理三态迁移

适用场景：做LLM底层系统的团队、记忆机制研究、有定制化需求的大型Agent平台。

缺点：工程成熟度最低，仍处研究阶段；文档不完善；需要深度定制开发。

框架横向对比矩阵

快速选型指南

场景1：快速上线的个性化推荐/客服Agent
➜ 选择Mem0
理由：API接入3行代码，有托管云服务，社区最大，文档最全，一周内可上线

场景2：金融、医疗、法律领域需追踪事实变化
➜ 选择Zep / Graphiti
理由：时序知识图谱是该场景的标准解，LongMemEval基准63.8%，能准确追踪"事实如何随时间变化"

场景3：长期运行、自我进化、多Agent协作的复杂系统
➜ 选择Letta
理由：OS级内存调度+原生多Agent协作，适合有工程能力的团队做深度定制，一个月时间完成部署

场景4：研究型Agent、知识关联推理
➜ 选择A-MEM
理由：NeurIPS 2025论文级算法，关联推理能力最强，适合学术实验和知识密集型应用

场景5：做LLM底层系统，有定制化需求
➜ 关注MemOS
理由：三态记忆调度是未来研究方向，现在跟进研究可抢占先发优势，为未来生产落地做准备

典型落地架构参考

用户输入
   ↓
[记忆检索层] ← Mem0/Zep（语义检索+时序推理）
   ↓
[上下文构建] ← 将相关记忆注入Prompt
   ↓
[LLM推理] ← Claude/GPT-4o/Qwen
   ↓
[记忆写入层] ← 自动提取关键信息存入记忆
   ↓
[记忆存储] ← Vector DB（Qdrant/Chroma）+ Graph DB（Neo4j）

推荐组合方案：

• 快速场景：Mem0托管云+OpenAI API → 一周上线
• 高精度场景：Zep+自建Neo4j → 两周上线
• 长期进化场景：Letta Server+PostgreSQL → 一个月上线

总结

Agent的记忆能力不是"有就行"的问题。错误的记忆比没有记忆更危险——医疗Agent记错了药物禁忌，金融Agent记错了用户风险偏好，客服Agent记错了投诉状态，都会造成严重后果。选对架构、从一开始就设计好记忆的边界和机制，才能构建可靠的Agent系统。

这5款框架各有战场：Mem0是现在最快的落地路径，Zep是时序场景的标准答案，Letta是长期复杂系统的技术基石，A-MEM是算法创新的前沿阵地，MemOS是未来系统级方向的研究赌注。根据你的具体需求和工程能力选择合适的框架，比盲目追求"最新最强"要明智得多。

参考资源

• Mem0：https://github.com/mem0ai/mem0
• Zep/Graphiti：https://github.com/getzep/graphiti
• Letta：https://github.com/letta-ai/letta
• A-MEM：https://github.com/agiresearch/A-mem
• MemOS：https://github.com/MemTensor/MemOS