支柱四：记忆系统 —— 从"金鱼脑"到"上下文数据库"
这一章是整篇文章最重要的部分。把记忆系统讲清楚，你就理解了 2024-2026 这两年 Agent 工程最大的演化主线。
7.1 为什么记忆是问题 —— LLM 的"金鱼脑"困境
第 1 章讲过，LLM 没有自带记忆。它的"记忆"完全等于当前这次请求里塞进去的 context。这就带来三个具体痛点：
- 上下文窗口有上限：哪怕 1M 上下文，也塞不下一个用户三年聊天记录 + 公司全部文档 + 当前任务的所有中间步骤。
- 越长越笨（Lost in the Middle）：研究反复证明，长 context 中段的信息更容易被 LLM 忽略。塞得多 ≠ 用得好。
- 越长越贵越慢：context 是按 token 计费的，每多塞 10 万 token，每次推理成本和延迟都线性涨。
所以问题变成：怎么聪明地决定每次请求带哪些信息进 context、哪些信息留在外面、什么时候把外面的捞进来。这个问题的所有解法，统称为"Agent 记忆系统"。
7.2 记忆其实有三种 —— 别一锅端
把记忆当成一个东西讨论是新手最大的误区。研究界和工程界目前公认至少要分三层（受人脑神经科学启发）：
| 类型 | 记什么 | 类比 | 典型实现 |
|---|---|---|---|
| 工作记忆 (Working Memory) | 当前任务的临时信息：用户刚说的话、上一步工具返回结果、待办列表 | 大脑里"还在想的事" | 当前 context 窗口 + 滚动摘要 |
| 情景记忆 (Episodic Memory) | 用户的偏好、过往对话事实、做过的项目、说过的话 | "我记得他不喜欢香菜" | 向量库 / 知识图谱 / 结构化条目 |
| 程序性记忆 (Procedural Memory) | "做某类任务的标准流程"、复用的代码模板、SOP | 骑车的肌肉记忆 | Skill 库 / Prompt 模板 / 工作流 |
下面要讲的"记忆系统演进史"，几乎全部围绕第二种"情景记忆"展开 —— 因为它最复杂、商业价值最大、也是踩坑最多的地方。
7.3 记忆系统的五阶段演进史
2023 到 2026 年，"怎么给 Agent 加长期记忆"这件事经历了五个明显的阶段。我们一个一个看。
原始 Buffer：把所有历史对话往 prompt 里塞
这个阶段的代表是 LangChain 早期的 ConversationBufferMemory：每轮对话开始时把过去 N 轮对话原原本本拼在 system prompt 后面，让 LLM"自己看历史"。
优势：实现一行代码，对话连贯性好。
致命缺陷：长一点的对话立刻把 context 塞爆；同一句信息会被重复带进每一轮请求，token 浪费严重；用户切换话题时旧话题的信息还在干扰。
MemGPT：把 LLM 当操作系统看
2023 年 10 月，UC Berkeley 团队在 arXiv 发表论文《MemGPT: Towards LLMs as Operating Systems》（arXiv:2310.08560），提出一个石破天惊的思路：把 LLM 类比成 CPU，把 context 类比成 RAM，把外部存储类比成磁盘。当 RAM 满了，LLM 自己用 function call 把不重要的内容"换页"到外部存储，需要时再"换页"回来。
这是历史上第一次让记忆管理 由 LLM 主动控制 而不是被动塞。MemGPT 论文带火了"分层记忆"概念，催生了后来的 Letta（同团队商业化产物，CEO Charles Packer）。Letta 在 GitHub 上长期维持 ~16.7K Star。
优势：模型自己学会"什么该记什么该忘"，理论上下文无限。
缺陷：LLM 自己调记忆 function call 不稳定（早期模型尤其差）；首次响应延迟变高；prompt 工程复杂。
独立 Memory Layer：Mem0 们把记忆做成"中间件"
2024 年向量数据库（Pinecone、Weaviate、Milvus）大规模成熟，RAG 范式在企业场景里被验证。这时候出现一批专门做"Agent 记忆中间件"的开源项目，最具代表性的是 Mem0（github.com/mem0ai/mem0，2024-07 开源）。
Mem0 把记忆抽象成可独立部署的服务：Agent 每说一句话，Mem0 自动抽取里面的"事实"（你叫什么、住哪里、喜欢什么），打 embedding 存进向量库，下次对话开头按相似度捞回相关条目塞进 prompt。还原生支持 user / session / agent 三级 scope。
Mem0 团队 2026-04 公布的算法基准：在权威记忆评测集 LoCoMo 上从 71.4% 提升到 91.6%，LongMemEval 从 67.8% 提升到 94.8%（数据来自 Mem0 论文 arXiv:2504.19413，自评，需独立复现）。
优势：与具体 Agent 框架解耦，接入简单；scope 模型清晰；社区繁荣。
缺陷：纯 ADD-only 单次抽取，事实矛盾（"以前喜欢蓝色，现在喜欢红色"）处理弱；向量召回的相关性 ≠ 事实正确性。
知识图谱 + 主动式上下文：Zep / Graphiti / MineContext
2025 年初，Zep 团队在 arXiv 发了《Zep: A Temporal Knowledge Graph Architecture for Agent Memory》（arXiv:2501.13956），用 时序知识图谱（temporal knowledge graph）替代单纯的向量召回。底层引擎 Graphiti 把记忆建成三层子图（情节层 episode / 语义层 semantic / 社区层 community），每条事实带"有效起止时间"双时态字段。当事实变化时（用户搬家、换岗），旧事实不被删除而是被"过时标记"，模型可以追溯历史。
Zep 在 DMR 评测上拿到 94.8%（对比 MemGPT 93.4%），LongMemEval 提升 18.5%，延迟降 90%（自评数据）。它的优势是处理"事实演化"和"复杂关系查询"远好于纯向量库。
同年 10 月，字节火山引擎团队开源 MineContext（github.com/volcengine/MineContext），提出"主动式上下文"理念：不等用户问，系统持续观察用户行为，提前把可能相关的上下文准备好。
优势：事实演化清晰、可追溯审计、关系查询强。
缺陷：图谱构建本身用 LLM 做，成本不低；schema 设计门槛高；社区生态比 Mem0 小。
上下文数据库：OpenViking 的 "Everything is a File"
2026 年 1 月，字节火山引擎 Viking 团队开源 OpenViking（github.com/volcengine/OpenViking），发布约一个月就攒到 ~4.5k Star。它的定位非常野心 —— "面向 AI Agent 的上下文数据库"，不仅管 memory，还把 resources（文档、图片、代码）和 skills（可执行流程）一起统一管理，背后哲学是 Unix 风格的"Everything is a File"。
OpenViking 提供 L0/L1/L2 三层加载策略（按需 / 按相关 / 按全量），让 Agent 能在大数据规模下控制 token 成本。在 LoCoMo10 评测里，OpenClaw 原生 35.65%，接入 OpenViking 后跳到 52.08%，同时 token 用量从 24.6M 降到 4.26M。
优势：把 memory / 资源 / 技能统一抽象，工程一致性好；针对大上下文做了系统化裁剪。
缺陷：发布太新，生态早期；适合自建中台，对小团队偏重。
记一条主线：记忆系统的演进 = 抽象层级一路上升。从最早"塞 prompt"，到 OS 范式（MemGPT），到独立中间件（Mem0），到知识图谱（Zep），再到上下文数据库（OpenViking）。每一层抽象都是为了解决前一层暴露出来的工程痛点。
记忆系统主流方案横向对比与选型
把上面五个阶段提到的代表系统拉到一张表上，再给一份按场景挑选的口诀。
7.4 主流记忆系统横向对比
| 系统 | 核心思路 | 底层结构 | 优势 | 劣势 |
|---|---|---|---|---|
| Mem0 | 独立中间件，自动抽取事实并存向量 | 向量库 | 接入最简单；user/session/agent 多级清晰；社区大 | 事实矛盾处理弱；纯相似度召回；ADD-only |
| Zep / Graphiti | 时序知识图谱，记录事实变化历史 | 知识图谱（图 + 时间） | 事实演化可追溯；关系查询强；DMR 94.8%（自评） | 构建成本高；schema 设计门槛；生态较小 |
| Letta (MemGPT) | OS 范式，LLM 主动管理分层 memory | main context + external context | 理论上下文无限；模型主导适合复杂 agent | function call 不稳；首响延迟高；调试困难 |
| LangMem | LangChain/LangGraph 内置记忆原语 | kv + 向量 + namespace | 与 LangGraph 编排无缝；命名空间隔离好 | 强绑定 LangChain 生态；非框架用户接入麻烦 |
| Cognee | 语义图 + 向量混合检索 | 图 + 向量 | 结构化推理 + 模糊召回兼顾 | 新生项目；运维栈较重 |
| MemoryOS / EverMemOS | "记忆即 OS"完整发行版，含调度/GC | 分层 memory + 生命周期管理 | 覆盖记忆全生命周期；研究界关注度高 | 工程复杂度高；适合长期 agent，不适合快速验证 |
| OpenViking | 上下文数据库，统一 memory/资源/技能 | 分层 L0/L1/L2 + 文件抽象 | 统一抽象；大上下文 token 节省 5-6 倍（自评 LoCoMo10） | 2026-01 才开源，生态最早期；偏重型方案 |
| MineContext | 主动式上下文，提前预备相关信息 | 行为观察 + 上下文图 | "不问也准备好"，C 端体验好 | 对端侧/行为采集依赖强；隐私要小心 |
| Generative Agents 风格 | 记忆 + 反思 + 计划循环（斯坦福小镇论文路线） | 事件流 + 反思摘要 | 角色化拟人 agent 表现自然 | 研究向，不太适合企业 toB |
关于 benchmark 数据的免责声明：表中提到的 LoCoMo / LongMemEval / DMR 指标，目前几乎全部来自各项目自己发布的 paper 或 README。不同项目的实验设置（base model、检索 top-k、prompt 模板）差异巨大，互相之间不可直接横比。选型时不要被分数带偏，跑一遍你自己的真实数据才作数。
7.5 怎么挑 —— 三条选型口诀
- 个人助理 / 客服 / 通用 chatbot：先上 Mem0。开发量小、文档好、社区大、问题快速能搜到。等你触达 Mem0 的天花板（事实演化弱、跨用户关系查不动），再考虑升级。
- 需要事实演化、关系推理、合规审计：用 Zep / Graphiti。典型场景：销售 CRM Agent、医疗助手、合规风控 Agent。这些场景"事实会变 + 要追溯"是硬需求，向量库扛不住。
- 大企业自建 Agent 中台、希望统一 memory + 资源 + 技能：盯紧 OpenViking。它的目标用户就是有自己的 Agent 平台、需要把记忆能力做成基础设施的团队。但 2026 年它还非常年轻，建议先做 PoC，别贸然全量替换。
另外有一条反向建议：不要一上来就上重型记忆系统。很多 Agent 实际上只需要"会话内 + 简单偏好"两层，硬塞一套 Zep 反而引入复杂度。先做最小可用，遇到具体痛点再加。
产品参照：
· Claude Code：会话级 working memory + 项目级 CLAUDE.md 程序性记忆，长期记忆做得克制 —— 把"该记什么"决定权交给用户在仓库里手写。
· 悟空（钉钉）：跨会话长期记忆 + 用户偏好（USER.md）+ 组织上下文（部门、上下级、近常协作的同事）三层，是企业级 Agent "把事和人都记住"的代表形态。
· OpenClaw + OpenViking（字节）：解耦组合代表 —— harness（OpenClaw）负责调度，记忆系统（OpenViking）作为可插拔后端，LoCoMo10 从 35.65% 提升到 52.08%。