ReMe vs Mem0 源码对比：两种 AI 记忆管理方案的架构差异

导读：ReMe 和 Mem0 是当前开源社区中两个代表性的 AI 记忆管理框架。ReMe 由 AgentScope 团队开发，聚焦于 Agent 的上下文管理和文件化工作记忆；Mem0（“mem-zero”）由 Y Combinator S24 孵化，定位为 AI 应用的"记忆层"，主打用户画像和个性化交互。本文从源码层面对比两者的架构设计，帮助开发者理解它们的定位差异，以便在自己的 Agent 应用中做出合适的技术选型。

一、定位与设计哲学

在深入源码之前，先明确两者的定位差异——这是理解后续所有架构差异的根源。

ReMe 的哲学：记忆是上下文管理的副产品——对话太长需要压缩，压缩产生的摘要顺便持久化为记忆。记忆的生命周期与对话的生命周期紧密耦合。

Mem0 的哲学：记忆是独立于对话的一等公民——每次交互后主动提取事实，存入独立的记忆库，下次交互前检索出来注入上下文。记忆的生命周期独立于任何具体对话。

二、记忆的写入流程

Mem0：Extract → Search → Decide → Store

Mem0 的记忆写入是一个两阶段 LLM 调用的流程：

# 开发者显式调用 memory.add(messages, user_id="user_123")

内部流程：

第一次 LLM 调用：事实提取 输入：对话消息 输出：{"facts": ["Name is John", "Is a Software engineer"]} ↓ 对每个 fact 做向量检索，找到相关的已有记忆 ↓ 第二次 LLM 调用：记忆决策 输入：新 facts + 已有记忆 输出：对每条记忆执行 ADD / UPDATE / DELETE / NONE ↓ 执行操作：写入向量数据库 + 记录变更历史到 SQLite 

核心源码（Memory._add_to_vector_store()）：

# 第一阶段：LLM 提取事实 system_prompt, user_prompt = get_fact_retrieval_messages(parsed_messages) response = self.llm.generate_response( messages=[{"role":"system","content": system_prompt},{"role":"user","content": user_prompt},], response_format={"type":"json_object"},) new_retrieved_facts = json.loads(response)["facts"]# 对每个新 fact，检索已有记忆for new_mem in new_retrieved_facts: messages_embeddings = self.embedding_model.embed(new_mem,"add") existing_memories = self.vector_store.search( query=new_mem, vectors=messages_embeddings, limit=5, filters=search_filters,)# 第二阶段：LLM 决定 ADD/UPDATE/DELETE/NONE function_calling_prompt = get_update_memory_messages( retrieved_old_memory, new_retrieved_facts ) response = self.llm.generate_response( messages=[{"role":"user","content": function_calling_prompt}], response_format={"type":"json_object"},)# 解析 response，执行 ADD/UPDATE/DELETE 操作

ReMe：Compress → Summarize → Write File

ReMe 的记忆写入是上下文压缩的副产品：

上下文 token 超限 ↓ FbCompactor：压缩上下文（生成摘要替代原始消息） ↓ ↓ _compressed_summary（滚动更新） FbSummarizer：异步持久化 ↓ LLM 按 prompt 指令写入 memory/YYYY-MM-DD.md ↓ FileWatcher 检测变化 → 更新向量索引 

核心特点：

• 记忆写入是被动触发的（token 超限时）
• 写入目标是 Markdown 文件（非结构化）
• 向量索引由 FileWatcher 异步更新

关键差异

三、记忆的存储结构

Mem0：向量数据库 + SQLite 变更历史

Mem0 的每条记忆存储为向量数据库中的一条记录：

# 向量数据库中的一条记忆{"id":"uuid-xxx","vector":[0.1,0.2,...],# Embedding 向量"payload":{"data":"Name is John",# 记忆内容（一条 fact）"user_id":"user_123",# 所属用户"agent_id":None,# 或所属 Agent"hash":"abc123",# 内容哈希（用于去重）"created_at":"2025-02-12T...","updated_at":"2025-02-12T...",}}

同时在 SQLite 中维护变更历史：

CREATETABLE history ( id TEXTPRIMARYKEY, memory_id TEXT,-- 关联到向量数据库的 ID old_memory TEXT,-- 修改前的内容 new_memory TEXT,-- 修改后的内容 event TEXT,-- ADD / UPDATE / DELETE created_at DATETIME, updated_at DATETIME, is_deleted INTEGER, actor_id TEXT,-- 来源标识 role TEXT);

这意味着 Mem0 可以追踪每条记忆的完整变更历史——什么时候加的、改过几次、每次改了什么。

ReMe：Markdown 文件 + 向量索引

ReMe 的记忆存储在纯 Markdown 文件中：

working_dir/ MEMORY.md ← 长期记忆（用户/Agent 手动维护） memory/ 2025-02-12.md ← 每日日志（自动 + 手动） 2025-02-13.md 

向量索引由 FileWatcher 自动维护——文件一改，自动切 chunk、embedding、写入向量数据库。

关键差异

四、记忆的检索方式

Mem0：向量检索 + 可选 Reranker + 知识图谱

results = memory.search(query="项目语言", user_id="user_123", limit=5)

内部流程：

查询 → Embedding → 向量数据库检索（带 metadata 过滤） ↓ 可选：Reranker 重排序 ↓ 可选：知识图谱实体检索（Neo4j/Kuzu） ↓ 合并返回结果 

Mem0 的检索特点：

• 支持 user_id、agent_id、run_id 三维度的 metadata 过滤
• 支持 Reranker（Cohere、Jina 等）对结果重排序
• 支持 知识图谱（Neo4j、Kuzu、Memgraph）做实体关系检索
• 支持丰富的过滤操作符（eq、ne、in、gt、contains、AND/OR/NOT）

ReMe：向量 + BM25 混合检索

results = memory_search(query="项目语言", max_results=5, min_score=0.1)

内部流程：

查询 → 向量语义搜索（权重 0.7） → BM25 全文检索（权重 0.3） ↓ 按 chunk 去重 + 加权融合 + 排序截断 ↓ 返回 top-N 结果 

ReMe 的检索特点：

• 向量 + BM25 混合检索是核心差异——BM25 对精确 token 命中效果极好（如函数名、错误码）
• 无 Reranker，但通过加权融合实现类似效果
• 无知识图谱，纯文本检索

关键差异

五、记忆的去重与更新

Mem0：LLM 驱动的四操作决策

Mem0 的去重是其架构中最精巧的部分。每次 add() 时：

1. LLM 提取新 facts
2. 对每个 fact 做向量检索，找到相关的已有记忆
3. 将新 facts + 已有记忆一起发给 LLM，让 LLM 判断每条应该 ADD / UPDATE / DELETE / NONE

已有记忆：["I really like cheese pizza", "User likes to play cricket"] 新 facts：["Loves chicken pizza", "Loves to play cricket with friends"] ↓ LLM 决策 结果： "cheese pizza" → UPDATE 为 "Loves cheese and chicken pizza" "play cricket" → UPDATE 为 "Loves to play cricket with friends" 

这种方式的优势是语义级去重——LLM 能理解"cheese pizza"和"chicken pizza"应该合并而非新增。

ReMe：Prompt 指令驱动的文件合并

ReMe 的 FbSummarizer 通过 prompt 指令实现去重：

工作流程： 1. 先 read memory/YYYY-MM-DD.md 2. 智能合并新信息与现有内容： - 避免重复已记录的信息 - 在相关时丰富现有条目的新细节 - 在适用时保持时间顺序 3. 写入更新后的内容 

去重的质量完全依赖 LLM 对 prompt 的遵循程度，没有 Mem0 那样的结构化检索 + 决策流程。

ReMe（ReMe 类）：Draft-Retrieve-Deduplicate

ReMe 的 ReMe 类（CoPaw 未使用的长期记忆子系统）有更精细的去重机制：

1. Draft：LLM 生成候选记忆
2. Retrieve：在向量数据库中检索相似记忆
3. Deduplicate：LLM 判断是否重复，决定合并或丢弃

这与 Mem0 的流程非常相似，但 ReMe 的 ReMeFb 子系统（更常用）没有这套机制。

六、记忆的层级与分类

Mem0：三维度记忆空间

Mem0 通过 user_id、agent_id、run_id 三个维度组织记忆：

# 用户级记忆（跨 session 持久） memory.add("I prefer Python", user_id="user_123")# Agent 级记忆（Agent 自身的学习） memory.add(messages, agent_id="agent_456")# 运行级记忆（单次 run 内有效） memory.add("Current task is data cleaning", run_id="run_789")# Procedural 记忆（Agent 的行为模式） memory.add(messages, agent_id="agent_456", memory_type="procedural_memory")

此外，Mem0 支持知识图谱存储实体关系：

User --[likes]--> Python User --[works_at]--> Google Python --[is_a]--> Programming Language 

ReMe：两套独立子系统

ReMe 项目 | |-- ReMe 类（向量化长期记忆） | |-- PersonalSummarizer 个人记忆 | |-- ProceduralSummarizer 程序性记忆 | |-- ToolSummarizer 工具记忆 | |-- ReMeFb 类（文件化工作记忆） |-- MEMORY.md 长期事实 |-- memory/*.md 每日日志 

ReMe 的 ReMe 类支持四种记忆类型（personal / procedural / tool / task），由 DelegateTask 自动路由。但实践中更常用的 ReMeFb 类不区分类型，统一按文件组织。

七、上下文管理能力

这是两者最根本的差异所在。

Mem0：不管理上下文

Mem0 不参与上下文窗口的管理。它只负责"记住"和"想起"，至于上下文 token 超限的问题需要开发者自行处理：

# Mem0 的典型用法——开发者自己管理上下文defchat_with_memories(message, user_id):# 1. 检索记忆 relevant_memories = memory.search(query=message, user_id=user_id, limit=3)# 2. 手动注入上下文 system_prompt =f"User Memories:\n{memories_str}"# 3. 调用 LLM（上下文管理完全由开发者负责） response = openai_client.chat.completions.create(...)# 4. 保存新记忆 memory.add(messages, user_id=user_id)

ReMe：上下文管理是核心

ReMe 的核心能力就是上下文管理——自动检测 token 超限、自动压缩、自动持久化：

每次 LLM 推理前（pre_reasoning Hook） ↓ FbContextChecker 检测 token 是否超限 ↓ 超限 FbCompactor 压缩上下文 ↓ 同时 FbSummarizer 异步写入 memory/*.md 

关键差异

八、LLM 与 Embedding 管理

Mem0：自管理所有模型

Mem0 内置了完整的 LLM 和 Embedding 管理：

• LLM：OpenAI、Anthropic、Gemini、DeepSeek、Groq、Ollama、vLLM 等 18 种
• Embedding：OpenAI、Azure、Gemini、HuggingFace、Ollama、FastEmbed 等 14 种
• Reranker：Cohere、Jina 等

config = MemoryConfig( llm=LlmConfig(provider="openai", config={"model":"gpt-4o-mini"}), embedder=EmbedderConfig(provider="openai"), vector_store=VectorStoreConfig(provider="qdrant"),) memory = Memory(config=config)

ReMe：支持外部 LLM 委托

ReMe 同样内置 LLM 管理，但其架构允许外部委托——如 CoPaw 通过 return_prompt=True 绕过 ReMe 的 LLM，只使用其 Embedding。这种灵活性是 Mem0 不具备的。

九、向量存储生态

Mem0 在向量存储生态上占据明显优势（25+ 种后端），这与其"服务化"定位一致——适合部署在各种云环境。ReMe 的后端较少但包含轻量级本地选项（JSONL、SQLite），更适合桌面/边缘场景。

十、集成方式与侵入性

Mem0：零侵入的 API 调用

from mem0 import Memory memory = Memory()# 完全解耦——在任何框架中都能用 memory.add("User prefers dark mode", user_id="user_123") results = memory.search("UI preferences", user_id="user_123")

Mem0 与应用完全解耦，通过 API 调用即可集成，不需要修改现有的 Agent 架构。

ReMe：深度集成的框架模式

from reme import ReMeFb classMemoryManager(ReMeFb):# 继承 ReMeFb 获得全部能力def__init__(self,...):super().__init__( llm_api_key="",# 可选：绕过 ReMe 的 LLM embedding_api_key=key,# 委托 Embedding 给 ReMe...)# 通过 Hook 集成 agent.register_hook("pre_reasoning", MemoryCompactionHook(...))

ReMe 的集成需要继承和 Hook 注入，侵入性更强但功能更深入。

十一、适用场景对比

十二、总结

ReMe 和 Mem0 解决的是 AI 记忆管理的不同侧面：

 上下文管理 用户画像 (对话压缩) (事实提取) ↑ ↑ | | ReMe Mem0 | | ↓ ↓ 文件化工作记忆 结构化向量记忆 (Markdown + FileWatcher) (向量数据库 + 变更历史) 

• ReMe 更像一个操作系统级的内存管理器——自动检测、自动压缩、自动持久化，深度嵌入 Agent 的运行时
• Mem0 更像一个独立的记忆数据库服务——提供 CRUD API，让任何应用都能快速接入记忆能力

两者并非互斥。一个理想的 Agent 系统完全可以同时使用 ReMe 管理上下文（防止 token 溢出），用 Mem0 管理用户画像（跨 session 个性化）——它们工作在记忆管理的不同层级，天然互补。

相关链接：

• ReMe GitHub：https://github.com/agentscope-ai/ReMe
• Mem0 GitHub：https://github.com/mem0ai/mem0
• Mem0 官网说明：https://mem0.ai/research