一、定位与设计哲学
在深入源码之前,先明确两者的定位差异——这是理解后续所有架构差异的根源。
| 维度 | ReMe | Mem0 |
|---|---|---|
本文对比了 ReMe 和 Mem0 两款 AI 记忆管理框架的架构差异。ReMe 侧重于 Agent 上下文管理与文件化工作记忆,通过自动压缩和持久化 Markdown 文件来管理记忆,适合单用户助理及需要上下文压缩的场景。Mem0 定位为 AI 应用的个性化记忆层,采用向量数据库存储结构化事实,支持多用户隔离、知识图谱及丰富的云存储后端,适用于 SaaS 产品及需要用户画像积累的客服场景。两者在触发方式、存储结构、检索能力及集成侵入性上存在显著区别,可根据具体需求选择或结合使用。
在深入源码之前,先明确两者的定位差异——这是理解后续所有架构差异的根源。
| 维度 | ReMe | Mem0 |
|---|---|---|
| Agent 的上下文管理 + 工作记忆框架 |
| AI 应用的个性化记忆层 |
| 核心问题 | '对话太长,上下文溢出了怎么办?' | '如何记住用户的偏好和事实?' |
| 记忆来源 | 对话流中自动提取(压缩副产品) | 开发者显式调用 memory.add() |
| 记忆粒度 | 文件级(Markdown 文档) | 事实级(一条条独立的 fact) |
| 架构风格 | 框架型(继承、Hook、可选子系统) | 服务型(API 调用、托管平台) |
| 开源协议 | Apache 2.0 | Apache 2.0 |
| 背景 | AgentScope 团队 | Y Combinator S24 |
ReMe 的哲学:记忆是上下文管理的副产品——对话太长需要压缩,压缩产生的摘要顺便持久化为记忆。记忆的生命周期与对话的生命周期紧密耦合。
Mem0 的哲学:记忆是独立于对话的一等公民——每次交互后主动提取事实,存入独立的记忆库,下次交互前检索出来注入上下文。记忆的生命周期独立于任何具体对话。
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 的记忆写入是上下文压缩的副产品:
上下文 token 超限
↓
FbCompactor:压缩上下文(生成摘要替代原始消息)
↓
↓ _compressed_summary(滚动更新)
FbSummarizer:异步持久化
↓
LLM 按 prompt 指令写入 memory/YYYY-MM-DD.md
↓
FileWatcher 检测变化 → 更新向量索引
核心特点:
| 维度 | Mem0 | ReMe |
|---|---|---|
| 触发方式 | 开发者显式调用 memory.add() | 上下文溢出时自动触发 |
| LLM 调用次数 | 2 次(提取 + 决策) | 1 次(压缩/持久化共用) |
| 写入目标 | 向量数据库(结构化 payload) | Markdown 文件 → FileWatcher → 向量索引 |
| 记忆格式 | 独立的 fact 字符串 | 按日期组织的文档段落 |
| 去重策略 | LLM 判断 ADD/UPDATE/DELETE | 依赖 FbSummarizer prompt 中的"智能合并"指令 |
Mem0 的每条记忆存储为向量数据库中的一条记录:
{
"id":"uuid-xxx",
"vector":[0.1,0.2,...],
"payload":{
"data":"Name is John",
"user_id":"user_123",
"agent_id":null,
"hash":"abc123",
"created_at":"2025-02-12T...",
"updated_at":"2025-02-12T..."
}
}
同时在 SQLite 中维护变更历史:
CREATE TABLE history (
id TEXT PRIMARY KEY,
memory_id TEXT,
old_memory TEXT,
new_memory TEXT,
event TEXT,
created_at DATETIME,
updated_at DATETIME,
is_deleted INTEGER,
actor_id TEXT,
role TEXT
);
这意味着 Mem0 可以追踪每条记忆的完整变更历史——什么时候加的、改过几次、每次改了什么。
ReMe 的记忆存储在纯 Markdown 文件中:
working_dir/
MEMORY.md ← 长期记忆(用户/Agent 手动维护)
memory/
2025-02-12.md ← 每日日志(自动 + 手动)
2025-02-13.md
向量索引由 FileWatcher 自动维护——文件一改,自动切 chunk、embedding、写入向量数据库。
| 维度 | Mem0 | ReMe |
|---|---|---|
| 存储介质 | 向量数据库(Qdrant/Chroma/Pinecone 等 25+ 种) | Markdown 文件 + 可配置向量存储 |
| 记忆单元 | 一条 fact = 向量数据库一条记录 | 一个文件 = 多个 chunk = 多条向量记录 |
| 变更追踪 | SQLite 完整变更历史 | 无(文件被覆盖就丢失旧版本) |
| 人可读性 | 需要通过 API 查看 | 直接打开 Markdown 文件 |
| 可编辑性 | 需通过 memory.update() API | 直接编辑文件,FileWatcher 自动同步 |
results = memory.search(query="项目语言", user_id="user_123", limit=5)
内部流程:
查询 → Embedding → 向量数据库检索(带 metadata 过滤)
↓
可选:Reranker 重排序
↓
可选:知识图谱实体检索(Neo4j/Kuzu)
↓
合并返回结果
Mem0 的检索特点:
user_id、agent_id、run_id 三维度的 metadata 过滤eq、ne、in、gt、contains、AND/OR/NOT)results = memory_search(query="项目语言", max_results=5, min_score=0.1)
内部流程:
查询 → 向量语义搜索(权重 0.7) → BM25 全文检索(权重 0.3)
↓
按 chunk 去重 + 加权融合 + 排序截断
↓
返回 top-N 结果
ReMe 的检索特点:
| 维度 | Mem0 | ReMe |
|---|---|---|
| 检索方式 | 纯向量 + 可选 Reranker | 向量 + BM25 混合 |
| 知识图谱 | 支持(Neo4j/Kuzu/Memgraph) | 不支持 |
| 过滤能力 | 丰富(多操作符、逻辑组合) | 基础(按文件路径/来源) |
| 精确匹配 | 依赖向量语义相似度 | BM25 擅长精确 token 匹配 |
| 多用户隔离 | 原生支持(user_id/agent_id/run_id) | 通过文件目录隔离 |
Mem0 的去重是其架构中最精巧的部分。每次 add() 时:
已有记忆:["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 的 FbSummarizer 通过 prompt 指令实现去重:
工作流程:
1. 先 read memory/YYYY-MM-DD.md
2. 智能合并新信息与现有内容:
- 避免重复已记录的信息
- 在相关时丰富现有条目的新细节
- 在适用时保持时间顺序
3. 写入更新后的内容
去重的质量完全依赖 LLM 对 prompt 的遵循程度,没有 Mem0 那样的结构化检索 + 决策流程。
ReMe 类):Draft-Retrieve-DeduplicateReMe 的 ReMe 类(CoPaw 未使用的长期记忆子系统)有更精细的去重机制:
这与 Mem0 的流程非常相似,但 ReMe 的 ReMeFb 子系统(更常用)没有这套机制。
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 类(向量化长期记忆)
| |-- PersonalSummarizer 个人记忆
| |-- ProceduralSummarizer 程序性记忆
| |-- ToolSummarizer 工具记忆
| |-- ReMeFb 类(文件化工作记忆)
|-- MEMORY.md 长期事实
|-- memory/*.md 每日日志
ReMe 的 ReMe 类支持四种记忆类型(personal / procedural / tool / task),由 DelegateTask 自动路由。但实践中更常用的 ReMeFb 类不区分类型,统一按文件组织。
这是两者最根本的差异所在。
Mem0 不参与上下文窗口的管理。它只负责"记住"和"想起",至于上下文 token 超限的问题需要开发者自行处理:
# Mem0 的典型用法——开发者自己管理上下文
def chat_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 的核心能力就是上下文管理——自动检测 token 超限、自动压缩、自动持久化:
每次 LLM 推理前(pre_reasoning Hook)
↓
FbContextChecker 检测 token 是否超限
↓
超限 FbCompactor 压缩上下文
↓
同时 FbSummarizer 异步写入 memory/*.md
| 维度 | Mem0 | ReMe |
|---|---|---|
| 上下文压缩 | ❌ 不支持 | ✅ 核心能力 |
| 自动触发 | ❌ 需手动调用 add/search | ✅ Hook 自动触发 |
| 与 Agent 耦合度 | 低(独立服务) | 高(继承/Hook 集成) |
Mem0 内置了完整的 LLM 和 Embedding 管理:
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 管理,但其架构允许外部委托——如 CoPaw 通过 return_prompt=True 绕过 ReMe 的 LLM,只使用其 Embedding。这种灵活性是 Mem0 不具备的。
| 后端 | Mem0 | ReMe |
|---|---|---|
| Qdrant | ✅ | ✅ |
| ChromaDB | ✅ | ✅ |
| Elasticsearch | ✅ | ✅ |
| FAISS | ✅ | ❌ |
| Pinecone | ✅ | ❌ |
| Milvus | ✅ | ❌ |
| pgvector | ✅ | ❌ |
| MongoDB Atlas | ✅ | ❌ |
| Redis | ✅ | ❌ |
| Weaviate | ✅ | ❌ |
| Supabase | ✅ | ❌ |
| SQLite(本地) | ❌ | ✅ |
| JSONL(本地) | ❌ | ✅ |
Mem0 在向量存储生态上占据明显优势(25+ 种后端),这与其"服务化"定位一致——适合部署在各种云环境。ReMe 的后端较少但包含轻量级本地选项(JSONL、SQLite),更适合桌面/边缘场景。
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 架构。
from reme import ReMeFb
class MemoryManager(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 注入,侵入性更强但功能更深入。
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| 多用户 SaaS 产品 | Mem0 | 原生多用户隔离,丰富的云存储后端 |
| 单用户 AI 助理 | ReMe (ReMeFb) | 自动上下文管理,文件化记忆透明可控 |
| 客服/销售 Agent | Mem0 | 用户画像积累,跨 session 个性化 |
| 开发者 Copilot | ReMe (ReMeFb) | 长对话压缩是刚需,代码记忆需要 BM25 精确匹配 |
| 需要知识图谱 | Mem0 | 原生 Neo4j/Kuzu 支持 |
| 桌面/边缘部署 | ReMe | JSONL/SQLite 本地存储,无需云服务 |
| 已有 Agent 框架 | Mem0 | API 调用零侵入,不改架构 |
| 从零搭建 Agent | ReMe | 框架级集成更深入,上下文管理自动化 |
ReMe 和 Mem0 解决的是 AI 记忆管理的不同侧面:
上下文管理 用户画像
(对话压缩) (事实提取)
↑ ↑
| |
ReMe Mem0
| |
↓ ↓
文件化工作记忆 结构化向量记忆
(Markdown + FileWatcher) (向量数据库 + 变更历史)
两者并非互斥。一个理想的 Agent 系统完全可以同时使用 ReMe 管理上下文(防止 token 溢出),用 Mem0 管理用户画像(跨 session 个性化)——它们工作在记忆管理的不同层级,天然互补。

微信公众号「极客日志」,在微信中扫描左侧二维码关注。展示文案:极客日志 zeeklog
使用加密算法(如AES、TripleDES、Rabbit或RC4)加密和解密文本明文。 在线工具,加密/解密文本在线工具,online
生成新的随机RSA私钥和公钥pem证书。 在线工具,RSA密钥对生成器在线工具,online
基于 Mermaid.js 实时预览流程图、时序图等图表,支持源码编辑与即时渲染。 在线工具,Mermaid 预览与可视化编辑在线工具,online
解析常见 curl 参数并生成 fetch、axios、PHP curl 或 Python requests 示例代码。 在线工具,curl 转代码在线工具,online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具,Base64 字符串编码/解码在线工具,online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具,Base64 文件转换器在线工具,online