为 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 stars2,421 次提交Apache 2.0 许可。它的核心思路很直接从对话中提取“原子事实”存到向量库检索时做语义召回。用起来极其简单frommem0importMemory# 初始化mMemory()# 加入一条对话记忆m.add(用户喜欢 Python 异步编程特别关注 asyncio 在 Web 框架中的应用,user_idu1)# 检索相关记忆resultsm.search(这个用户对 Python 哪部分感兴趣,user_idu1)print(results)# 返回用户偏好它真正的成熟度体现在生态上——支持 Claude Desktop 插件、Cursor 插件、Codex 集成甚至有一个 Desktop App。也就是说你不需要自己写记忆逻辑直接装个插件就有记忆能力。但 Mem0 的“事实提取”范式有一个根本性问题事实是碎片化的。当用户说“我喜欢 FastAPI 而且最近在学 Pydantic v2 的改进”Mem0 可能会提取两条事实用户喜欢 FastAPI用户在学习 Pydantic v2但它不会记录“这两件事是紧密关联的因为 FastAPI 就是基于 Pydantic 的”。这种叙事连贯性的丢失在长期对话中会变成一个问题——Agent 能查到用户喜欢 FastAPI但不知道为什么。Memora 论文中专门指出了这个问题并把它归为“索引与存储耦合”的缺陷Mem0 把提取出来的事实同时当存储和索引事实之间缺少关联结构。Memora抽象层解耦存储与索引Memora 是 2026 年 6 月微软研究院开源的方案刚被 ICML 2026 接收。它的核心创新是harmonic memory核心思路是“存储归存储、索引归索引”。# Memora 的核心抽象frommemoraimportMemoraClient,HarmonicConfig configHarmonicConfig(llm_providerazure,# 需要 Azure/OpenAIembedding_modeltext-embedding-3-large,retrieval_strategyhybrid# semantic / prompted / hybrid / GRPO)clientMemoraClient(config)# 写入记忆client.remember(content用户说他的生产环境用的是 k3s资源吃紧不想用完整的 Prometheus 监控栈,session_ids1)# 检索——通过抽象层定位到完整值relevantclient.recall(query用户对监控有什么偏好,session_ids1,top_k3)关键区别在于内部架构。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 有两个现实的麻烦只有 2 周——截至写这篇文章它的 GitHub 仓库只有 1 个 commit妥妥的科研项目。代码成熟度远不到生产级。需要 Azure 或 OpenAI 的 embeddingLLM——这意味着一运行就开始计费没有本地运行的选项。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 ServerfromatlasimportAtlasClient clientAtlasClient(es_hostlocalhost:9200)# 写入一个情景client.add_episodic(agent_ida1,event用户要求重构 auth 模块从 Django REST - FastAPI,timestamp2026-06-15T10:00:00Z)# 检索——三索引联合搜索resultsclient.search(query用户对 auth 栈的偏好,agent_ida1,memory_types[episodic,semantic],top_k5)# 返回综合排序结果带来源标注Atlas 的灵活性很高——一套 ES 集群跑三个独立的索引检索时 BM25 dense hybrid reranker 三级 pipeline。根据官方数据R10 达到 0.89。但 Atlas 的问题也很明显需要 Elasticsearch 集群——Elastic Cloud 要付费自建要运维个人项目——不是 Elastic 官方产品代码成熟度需自行评估Inference Service——需要额外的 LLM 服务做 consolidationLLM WikiFilesystem 优先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 页——加新决策、更新状态、归档已完成的任务。结束时用/crystallizeKarpathy 术语把会话中沉淀的知识蒸馏成 wiki 页供下一次会话使用。这个模式的核心竞争力不在检索精度它根本没有检索而在零基础设施的增量知识积累每轮对话产生的深度内容都被结构化存入 markdown下一轮会话的 Agent 直接读。知识随使用次数复合增长而不是每次从零开始检索。社区已经有了几个实现——vanillaflava/llm-wiki-skills42 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事实提取Memora抽象层Atlas认知分类LLM Wiki文件系统核心思路提取原子事实→向量存储→语义检索存储与索引解耦抽象层做索引认知科学三分法按类型分索引LLM 读写 markdown 文件作记忆基础设施向量数据库默认嵌入ChromaDB Azure/OpenAIElasticsearch 集群本地文件系统检索方式语义向量搜索4种策略含GRPO RLBM25 dense hybrid文件名 目录索引无语义叙事连贯性❌ 碎片化✅ 通过抽象层保留上下文✅ 通过 consolidation 保留✅ 文件本身就是叙事生产就绪度✅ 成熟59.8k stars❌ 科研项目1 commit⚠️ 个人 Demo⚠️ 早期42 stars集成方式pip install 插件pip install -e .FastAPI MCP ES文件读写 MCP filesystem隐藏成本无自带默认 embeddingAzure/OpenAI API 费用ES 集群 Inference Service零已有文件系统即可适合场景快速召回、事实问答长对话、细节敏感多角色、行为优化项目上下文、决策记录四套方案的实际感受拆一下四个方案的工程落地要点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/mem0Memora 在 github.com/microsoft/MemoraAtlas 在 github.com/noamschwartz/atlas-memory-demo。三个仓库都建议自己去读一遍尤其是各自的 README 里的“动机”部分——每个方案的设计者为什么选择这条路线往往比 API 文档更能帮你做判断。不是选 star 数最多的不是选架构最漂亮的而是选与你们系统的记忆生命周期最贴近的。长时记忆这个话题在未来 6-12 个月只会越来越重要——随着 Agent 进入生产化部署记忆不再是「锦上添花」的功能而是决定 Agent 能否持续性工作的核心基础设施。现在花时间理解三种范式的差异到需要选型的时候比临时翻 GitHub 要从容得多。
