4 种 Agent 长时记忆方案对比：Mem0 到 LLM Wiki

为 Agent 选长时记忆方案时，我卡住了。

你说让 Agent 记住用户偏好算简单吧，但一跑起来就露馅了：要么把整段对话历史塞进 context 窗口，token 烧得比算力还快；要么搞个摘要压缩，结果是 Agent 越来越"健忘"，3 轮对话之后就忘了用户刚才说的事。

这不是我技术选型不够谨慎的问题——是目前所有大模型自带的上下文都撑不住"真正长期"的记忆需求。全历史注入，token 爆炸；摘要压缩，细节丢失。两个方向都走不通。

我研究了当前主流的三个方案：Mem0、Memora、Atlas。各自背后的范式完全不同，这篇不聊虚的，直接讲三种范式的架构差异和选型建议。

问题究竟在哪——当前记忆方案的三重困境

先说清楚 Agent 长时记忆的痛点到底在哪。

从工程角度，任何一个记忆系统都要回答三个问题：记什么、怎么存、怎么查。目前的方案在两个极端之间反复横跳：

• 全历史注入：把整段对话揉进 prompt。优点是信息完整，缺点是 token 数随轮次线性增长，跑 20 轮就能把 context 窗口塞满。GPT-5.5 的 128K context 也扛不住持续的日常对话。
• 摘要压缩：让 LLM 定期给对话打压缩摘要。优点是 token 省了，缺点是细节几乎全丢——用户上轮说的具体需求、代码里的变量名、约定的接口格式，摘要里一句带过。
• RAG 外挂：把对话记录向量化存到向量库，检索时召回。比前两者灵活，但检索精度取决于 embedding 质量，且“原子事实”的提取粒度很难把控。

从 Memora 在 ICML 2026 发表的论文来看，上述方案的问题被归结为同一个：存储与索引没有解耦。全历史注入是把所有内容既当存储又当索引；摘要是把压缩后的内容既当存储又当索引。一旦索引丢失细节，检索召回的信息就是残缺的。

在这个背景下，三种不同的记忆范式出现了。与其说它们是技术路线的差异，不如说是对“记忆应该长什么样”的不同理解。

Mem0：最成熟的事实提取范式

Mem0 是目前社区最活跃的选择——GitHub 59.8k stars，2,421 次提交，Apache 2.0 许可。它的核心思路很直接：从对话中提取“原子事实”，存到向量库，检索时做语义召回。

用起来极其简单：

frommem0importMemory# 初始化m=Memory()# 加入一条对话记忆m.add("用户喜欢 Python 异步编程，特别关注 asyncio 在 Web 框架中的应用",user_id="u1")# 检索相关记忆results=m.search("这个用户对 Python 哪部分感兴趣？",user_id="u1")print(results)# 返回用户偏好

它真正的成熟度体现在生态上——支持 Claude Desktop 插件、Cursor 插件、Codex 集成，甚至有一个 Desktop App。也就是说，你不需要自己写记忆逻辑，直接装个插件就有记忆能力。

但 Mem0 的“事实提取”范式有一个根本性问题：事实是碎片化的。当用户说“我喜欢 FastAPI 而且最近在学 Pydantic v2 的改进”，Mem0 可能会提取两条事实：

1. 用户喜欢 FastAPI
2. 用户在学习 Pydantic v2

但它不会记录“这两件事是紧密关联的，因为 FastAPI 就是基于 Pydantic 的”。这种叙事连贯性的丢失，在长期对话中会变成一个问题——Agent 能查到用户喜欢 FastAPI，但不知道为什么。

Memora 论文中专门指出了这个问题，并把它归为“索引与存储耦合”的缺陷：Mem0 把提取出来的事实同时当存储和索引，事实之间缺少关联结构。

Memora：抽象层解耦存储与索引

Memora 是 2026 年 6 月微软研究院开源的方案，刚被 ICML 2026 接收。它的核心创新是harmonic memory，核心思路是“存储归存储、索引归索引”。

# Memora 的核心抽象frommemoraimportMemoraClient,HarmonicConfig config=HarmonicConfig(llm_provider="azure",# 需要 Azure/OpenAIembedding_model="text-embedding-3-large",retrieval_strategy="hybrid"# semantic / prompted / hybrid / GRPO)client=MemoraClient(config)# 写入记忆client.remember(content="用户说他的生产环境用的是 k3s，资源吃紧，不想用完整的 Prometheus 监控栈",session_id="s1")# 检索——通过抽象层定位到完整值relevant=client.recall(query="用户对监控有什么偏好？",session_id="s1",top_k=3)

关键区别在于内部架构。Memora 把每条记忆拆成三个部分：

• Memory Value：原始内容的完整记录，不建立索引
• Primary Abstraction：对 memory value 的一对一抽象（类似于结构化摘要），只有这部分被索引
• Cue Anchors：多对多的语义接入点，用于关联不同记忆

检索时，系统通过 Cue Anchors 匹配查询意图，先定位 Primary Abstraction，再由 Primary Abstraction 引导到完整的 Memory Value。这样既保留了细节（Memory Value 不被压缩），又控制了索引开销（只有 Primary Abstraction 被索引）。

Memora 在 LoCoMo 和 LongMemEval 两个基准上拿了 SOTA，比全历史注入节省了 98% 的 context tokens——这在生产环境里是实打实的成本差异。

但 Memora 有两个现实的麻烦：

1. 只有 2 周——截至写这篇文章，它的 GitHub 仓库只有 1 个 commit，妥妥的科研项目。代码成熟度远不到生产级。
2. 需要 Azure 或 OpenAI 的 embedding+LLM——这意味着一运行就开始计费，没有本地运行的选项。

Atlas：认知科学三分法，结构化程度最高

Atlas 是 Elastic 搜索实验室的工程师 Noam Schwartz 在 2026 年 5 月开源的个人项目，但它背后的思路值得所有做长时记忆的人关注。

Atlas 直接借鉴了认知科学对记忆的分类：Episodic（情景记忆）→ Semantic（语义记忆）→ Procedural（程序性记忆）。

• Episodic memory：记录“发生了什么”——带时间戳的原始事件，支持自然衰减（不常访问的事件权重下降）
• Semantic memory：记录“什么是对的”——从 episodic 中由 LLM consolidation 提取的持久事实，每个事实附带 supporting evidence，支持 supersession（新证据覆盖旧结论）
• Procedural memory：记录“什么好用”——playbook 步骤，附带成功/失败计数器，影响检索时的排序权重

# Atlas 的 API 设计（FastAPI + MCP Server）fromatlasimportAtlasClient client=AtlasClient(es_host="localhost:9200")# 写入一个情景client.add_episodic(agent_id="a1",event="用户要求重构 auth 模块，从 Django REST -> FastAPI",timestamp="2026-06-15T10:00:00Z")# 检索——三索引联合搜索results=client.search(query="用户对 auth 栈的偏好",agent_id="a1",memory_types=["episodic","semantic"],top_k=5)# 返回综合排序结果，带来源标注

Atlas 的灵活性很高——一套 ES 集群跑三个独立的索引，检索时 BM25 + dense hybrid + reranker 三级 pipeline。根据官方数据，R@10 达到 0.89。

但 Atlas 的问题也很明显：

• 需要 Elasticsearch 集群——Elastic Cloud 要付费，自建要运维
• 个人项目——不是 Elastic 官方产品，代码成熟度需自行评估
• Inference Service——需要额外的 LLM 服务做 consolidation

LLM Wiki：Filesystem 优先，Zero 基础设施

第四种范式来自 Andrej Karpathy 的一个 gist。思路简单到令人怀疑：让 LLM 自己维护一份 markdown wiki，直接把记忆写成文件、从文件读回。没有向量库、没有索引层、没有特殊服务——就是文件系统读写。

听起来太简单了？但它解决了一个其他方案都绕不过去的问题：记忆的可组合性。

# Home.md — Agent 启动时自动读取 ## 当前项目状态 - Auth 模块：已从 Django REST 迁移到 FastAPI，待合并 - 部署架构：k3s 集群，资源吃紧，监控栈暂不部署 ## 已知决策记录 - 2026-06-15：决定用 FastAPI 替代 Django REST，理由是团队熟悉 Python 异步 - 2026-06-18：决定监控方案先跳过 Prometheus，用轻量 self-host 替代 ## 开放问题 - 迁移后的性能基准测试未做（阻塞项）

工作流是这样的：Agent 启动时读 Home.md 和当前域的几个核心 wiki 页，了解上下文。整个工作会话中，Agent 会不断更新 wiki 页——加新决策、更新状态、归档已完成的任务。结束时用/crystallize（Karpathy 术语）把会话中沉淀的知识蒸馏成 wiki 页，供下一次会话使用。

这个模式的核心竞争力不在检索精度（它根本没有"检索"），而在零基础设施的增量知识积累：每轮对话产生的深度内容，都被结构化存入 markdown，下一轮会话的 Agent 直接读。知识随使用次数复合增长，而不是每次从零开始检索。

社区已经有了几个实现——vanillaflava/llm-wiki-skills（42 stars）把 Karpathy 的思路做成了 6 个 agent skill，支持 Claude Desktop、Claude Code、Gemini CLI、Codex CLI。读取、写入、lint、复合查询全是独立的 skill，用 filesystem MCP 直接操作本地 markdown 文件。r0b0tlab 做了 Obsidian 集成版（26 stars），把 wiki 和笔记系统的交互打通了。

LLM Wiki 的代价很明确：没有语义检索。文件是按名字和目录组织的，不是按语义向量。如果你需要"从 5000 条对话中找出用户对异步编程的偏好变化"，LLM Wiki 不如 Mem0。但如果你需要 Agent “知道自己正在做什么、之前做了什么决策”，LLM Wiki 在工程简洁性上完胜——零依赖、零运维、零成本。

四范式对比

四套方案的实际感受

拆一下四个方案的工程落地要点：

Mem0 真的"能用"。装个 pip 包、写两行代码就能跑起来，Claude Desktop 插件直接装上就能体验。但它的事实提取范式有边界：Agent 能记住用户说过"用 k3s"，记不住"用户说因为团队只有两个运维所以选择 k3s"——后一句的因果关系到检索时就丢了。

Memora 架构漂亮但得先忍一忍。Harmonic memory 的设计是四个方案里最有工程直觉的。但只有 1 个 commit 意味着什么？意味着如果你现在就把它搬进生产，连 bug report 都没人回。建议关注它的论文（arxiv.org/abs/2602.03315），等代码成熟到 v0.5 再考虑集成。

Atlas 的认知分类设计最自然。把记忆按"发生过的、知道的、熟悉的"三个层级组织，在工程上很对应真实的记忆管理需求——程序性记忆的"playbook+成功率"设计，直接对应了 Agent 行为优化的需求。但 Elasticsearch 集群的成本不能忽略，尤其是如果你只是为了记忆功能专门起一套 ES。

LLM Wiki 是最意想不到的惊喜。我试了 vanillaflava 的 llm-wiki-skills 跑自己的项目 wiki，效果不错。每次新会话启动，Agent 不问我"项目当前状态是什么"，直接读 wiki 就知道了。代价是它不适合做事实检索——问"用户三个月前说过什么具体需求"，它翻文件比 Mem0 慢得多。

如何选：四套方案的适用场景

回到工程视角，选型不能只看架构设计，得考虑你的团队和现有基础设施：

选 Mem0，如果：

• 你要在 1 周内给 Agent 加上基本的长时记忆
• 团队没有运维 Elasticsearch 的能力
• 你的 Agent 对叙事连贯性要求不高（比如工具调用类 Agent）

关注 Memora，如果：

• 你的 Agent 需要处理长对话（30轮以上）且对细节敏感
• 你有预算跑 Azure/OpenAI 的 embedding 服务
• 你愿意等几个月直到它成熟到 v1.0

考虑 Atlas，如果：

• 你已经在用 Elasticsearch 做搜索或日志
• 你需要灵活的记忆分类——比如对"程序性记忆"做版本管理
• 你的 Agent 行为优化（基于经验学习）是核心需求

先用 LLM Wiki，如果：

• 你要的是"Agent 知道自己当前在做什么"，而不是"Agent 能找到去年的一条对话"
• 你不想引入任何额外基础设施——文件系统就够了
• 你已经在用 Obsidian/Logseq 管理笔记，wiki 可以直接复用

从选型角度看，这是个很自然的问题：能不能混搭？我的回答是——可以。Mem0 做事实抽取作为语义记忆的基础层，Atlas 做程序性记忆存放 playbook 经验，LLM Wiki 做项目上下文管理。但混搭意味着多套运维成本，如果不是特别必要，优先选一套用透。

四种范式并不是非此即彼的选择。真正的生产环境，很可能是一个叠加层：底层用 Mem0 的事实提取作为快速召回，上层用 LLM Wiki 做项目上下文管理。不管是哪种路线，核心原则是一样的——存储与索引分开管，记忆按生命周期分层，检索策略随场景变。抱着这个原则去选型，比追着项目 star 数跑要靠谱得多。

项目的代码和文档都是公开的：Mem0 在 github.com/mem0ai/mem0，Memora 在 github.com/microsoft/Memora，Atlas 在 github.com/noamschwartz/atlas-memory-demo。三个仓库都建议自己去读一遍，尤其是各自的 README 里的“动机”部分——每个方案的设计者为什么选择这条路线，往往比 API 文档更能帮你做判断。

不是选 star 数最多的，不是选架构最漂亮的，而是选与你们系统的记忆生命周期最贴近的。长时记忆这个话题在未来 6-12 个月只会越来越重要——随着 Agent 进入生产化部署，记忆不再是「锦上添花」的功能，而是决定 Agent 能否持续性工作的核心基础设施。现在花时间理解三种范式的差异，到需要选型的时候，比临时翻 GitHub 要从容得多。