为什么「无限扩上下文」不是答案
2026 年头部模型的上下文窗口已延伸到数十万 token，直觉上似乎可以把历史全塞进去。但专门为百万级长对话设计的 BEAM 基准给出了相反的结论：即便上下文最大的模型，仍在「矛盾消解」上吃力——当早期事实与后续更新冲突时，难以维持全局一致状态。同时，把完整历史每次都载入上下文的成本在规模化后快速累积。
VentureBeat 2026 年 AI 基础设施报告预测：到 2026 年底，专用上下文记忆层在智能体场景下的采用将超越 RAG。根因是——实现了多类记忆类型的生产级 Agent，在多会话基准上的任务完成度，优于仅依赖更长上下文窗口的单上下文 Agent。记忆不是「塞更多」，而是「放在对的地方、在对的时刻取回」。
记忆的四类：按「记住什么」而非「能做什么」
本轮测评不按功能列表排名，而是按记忆类型映射存储与检索模式，因为记忆类型决定适配度。四类主流记忆映射如下：
| 记忆类型 | 记住什么 | 典型存储/检索 | 代表框架 |
|---|---|---|---|
| 会话与用户记忆 | 说过的话、用户偏好、账户事实 | 分层向量 + 晋升机制 | Mem0 |
| 实体与关系记忆 | 以图为结构的实体、关系、时效 | 时序知识图谱 | Zep（Graphiti） |
| Agent 自管上下文 | 可编辑的核心记忆块、归档、共享状态 | 上下文内块 + 归档存储 | Letta（MemGPT lineage） |
| 程序/行为记忆 | 如何行为的学习规则，回灌 Prompt | 语义/情景集合 + Prompt 优化 | LangMem |
以上四类都覆盖「流经 Agent 的内容」，但都不覆盖第五类——数据库锚定的语义上下文：你的数据库里真正有什么、它意味着什么、如何关联。后者目前仍是大片空白，需要把结构化检索与对话记忆组合使用。
热路径与冷路径：一套可落地的分层模型
生产级记忆架构通常按延迟分为热路径与冷路径两层。设计铁律：热路径保持精简，冷路径检索可预测。
| 层 | 存储 | 延迟 | 放什么 |
|---|---|---|---|
| 工作记忆 | LLM 上下文窗口 | < 1ms | 近 5–10 轮对话、结构化草稿板、已加载偏好 |
| 缓存 | Redis / 进程内 | < 5ms | 高频事实（用户偏好、团队设置） |
| 语义 | 向量库（Pinecone / Weaviate） | 20–100ms | 知识库、语义相似检索 |
| 情景 | 向量库 + SQL | 50–200ms | 过去相似情境、 episodic 记录 |
| 程序 | 结构化存储 + 缓存 | 5–50ms | 行为模板、工作流触发 |
关键工程点：冷路径记忆「检索质量」比「存储」更致命。检索到无关情境或错误语义事实，比没有记忆更糟——Agent 会基于自信的错误信息行动。因此应在嵌入模型、重排、元数据过滤上的投入不低于存储本身。
Mem0：分层语义向量，上手极简
Mem0（Y Combinator S24，Apache 2.0）是 2026 年采用最广的记忆层。它把记忆组织为四层：会话记忆（当前轮）、会话级记忆（短任务）、用户记忆（长期个人知识）、组织记忆（团队共享）。消息从会话层进入，按 user_id / run_id 等标识向上晋升，检索时用户记忆优先、再会话笔记、最后原始历史。
架构与取舍
- 优势：社区大（约 48K GitHub Stars）、文档广度好、Python/JS SDK 完善、5 分钟接入；托管云开箱即用
- 短板：图谱能力（实体关系、多跳查询）放在 $249/月 Pro 档之后，免费档仅向量检索；LongMemEval 时序查询仅 49%，四家中偏低；记忆随框架迁移成本高
- 适合：快速原型、单用户个性化、需要 5 分钟接入的团队
- 不适合：图谱依赖负载、空气隔离（需 Qdrant + Neo4j）、时序推理强的场景
Zep：时序知识图谱，事实失效可追
Zep 运行在开源 Graphiti 引擎之上，把知识存为时序知识图谱。每个事实带有效性窗口——系统知道「事实何时为真」，而不只是「是否为真」。当用户改了编程语言或更新业务联系人，Zep 能推理该事实在哪个时间点有效。
架构与取舍
- 优势：时序推理头部（LongMemEval 63.8%，明显优于 Mem0）；图谱能力 $25/月即包含（非 $249 门槛）；开源 Graphiti 可扩展
- 短板：自托管需管理图数据库（Neo4j / FalkorDB / Kuzu）；高阶特性（冲突消解、托管图谱记忆）仅云上
- 适合：事实随时间演变的场景（定价变更、政策更新、团队成员角色变化）、合规需事实有效期的系统
- 六个原语：facts / entities / episodes / thread summaries / observations / user summaries，组装为 token 高效的上下文块
Letta：OS 式分级，Agent 自管上下文
Letta 源自 UC Berkeley 的 MemGPT 研究，用操作系统类比重构记忆：上下文窗口是 RAM，外部存储是磁盘，由 Agent 自己决定分页。2026 年 Letta 重写了 Agent 循环，引入 git 追踪的记忆块与跨模型提供商的运行时。
三层显式结构
| 层 | 位置 | Agent 权限 |
|---|---|---|
| 核心记忆 Core | 常驻上下文（RAM） | 直接读写 |
| 归档记忆 Archival | 向量库，显式工具调用检索 | 查询 |
| 回忆记忆 Recall | 可搜的历史 | 按需检索 |
- 差异化：记忆由 Agent 自主决定存什么、忘什么、何时取回——与后台自动抽取的方案哲学不同
- 代价：Agent 工具调用更多，记忆质量依赖模型判断力
- 适合：要最大控制权的团队、合规/审计需记忆透明、从零搭建有状态系统的研究者
LangMem：LangGraph 原生记忆原语
LangMem 来自 LangChain 团队，不是独立服务，而是扩展 LangGraph 内置 store 的 Python 库：create_manage_memory_tool 与 create_search_memory_tool。已在用 LangGraph 的团队几乎是零基础设施接入。
- 优势：LangGraph 上零额外基础设施；热路径（Agent 自管）与后台（自动抽取）双模式；框架原生
- 短板：强依赖 LangChain 生态；时序记忆弱于 Zep / Letta；检索延迟偏高（见基准）
- 适合：已用 LangGraph、想以最小摩擦加记忆的团队
基准量化对比：LongMemEval 与 LoCoMo
量化数据来自 Vectorize 的 Mem0 替代评测与第三方 LoCoMo 对比（数据截止 2026 年中）。注意 Mem0 的 49% 与 LangMem 的 N/A 来自不同评测口径，对比时看同基准。
| 框架 | 记忆类型 | LongMemEval | LoCoMo | 检索延迟 p50 | 自托管 |
|---|---|---|---|---|---|
| Mem0 | 会话/用户 | 49%（GPT-4o） | 约 64% | 0.148s | ✅ |
| Zep | 实体/关系（时序） | 63.8% | 78.94% | < 100ms | 需图库 |
| Letta | Agent 自管上下文 | 83.2% | — | 取决于调用 | ✅ |
| LangMem | LangGraph 原生 | N/A（SDK） | 78.05% | 17.99s | ✅（库） |
Mem0 托管检索 p50 仅 0.148s，LangMem 达 17.99s（p95 59.82s）。差距来自 LangMem 的按需抽取管线在查询时做更多工作。对语音 Agent、客服对话、编码助手这类交互场景，亚 200ms 检索是「像原生」与「在加载」的分界线——延迟直接决定产品手感。
选型框架与工程边界
结论按记忆类型而非功能列表：
| 你的场景 | 推荐 | 理由 |
|---|---|---|
| 快速原型 / 简单偏好 | Mem0 | 5 分钟接入、生态成熟、成本低 |
| 已在 LangChain / LangGraph | LangMem | 零摩擦、原生 store 集成 |
| 事实随时间演变 / 合规 | Zep | 时序图谱、事实失效可追 |
| 长期陪伴 / 跨月画像 | Letta | Agent 自管、git 追踪、透明 |
工程边界三点：① 不要过早过度设计——先工作记忆 + 一个外部存储，撞到上限再加层；② 检索质量与存储同等重要，投入嵌入与重排；③ 目前无单一框架覆盖数据库锚定的语义上下文，该类需求需组合结构化检索。预测到 2027 Q1，四类方案中将至少有两个整合或转向——生存者是自托管故事强、延迟低者。