2026 Agent 记忆系统之战：Hindsight 不再是 SOTA，然后呢？
- 一、四强并立
- 二、BYTEROVER：让 LLM 自己管理记忆
- 三、MemPalace：verbatim 哲学的极端实践
- 四、Mastra OM：极简架构反而最高分
- 五、四系统横向对比
- 六、benchmark 分数不是选型依据
- 七、选型建议
- 八、结语
2025 年 12 月，Hindsight 发了一篇论文，宣布自己在 LongMemEval 和 LoCoMo 两个 benchmark 上拿下 SOTA（State-of-the-Art）。Virginia Tech 复现了，The Washington Post 也复现了。MIT 开源，SDK 完整，Fortune 500 在用。
五个月后，它的 SOTA 位置已经被三个新系统抢走了。
但这不重要。
一、四强并立
2026 年初，Agent Memory 赛道同时冒出了三个新玩家：
| 系统 | LongMemEval | LoCoMo | 核心差异 |
|---|---|---|---|
| Hindsight | 91.4%（Gemini-3） | 89.6% | 四路检索 + LLM fact extraction |
| BYTEROVER | 92.8% | 96.1% | Agent-native，LLM 自己管记忆 |
| MemPalace | 96.6%（raw） | 88.9% | verbatim，存所有对话原文 |
| Mastra OM | 94.87%（GPT-5-mini） | 未查到 | 纯文本压缩，无数据库 |
数字看起来很简单：MemPalace 96.6% 最高，Mastra 94.87% 次之，BYTEROVER 92.8%，Hindsight 91.4% 垫底。
但这些数字背后是三个完全不同的设计哲学，选型时看分数远远不够。
二、BYTEROVER：让 LLM 自己管理记忆
BYTEROVER（arXiv:2604.01599，2026年4月，论文名 "ByteRover"）的核心主张是：当前所有记忆系统都在犯同一个错——把记忆当 external service。
Hindsight 把记忆存进 PostgreSQL，Mem0 存进向量库。它们都是：LLM 生成内容 → 外包给另一个系统存储。这个分离导致语义漂移——存储的人不理解上下文，理解上下文的人不掌控存储。
BYTEROVER 的解法是把记忆操作集成到 LLM 的推理循环里。同一个模型既做推理，又管理自己的记忆。它用 Context Tree 组织知识：Domain → Topic → Subtopic → Entry，每层都有 context.md 定义节点语义。
用分层文件搜索替代向量数据库——这是 BYTEROVER 与 Hindsight 最大的架构差异。所有记忆以 Markdown 文件形式存在本地，检索时先模糊文本匹配，再做 LLM 驱动的深度搜索。没有向量数据库，没有外部存储依赖。
| 指标 | 数值 |
|---|---|
| LongMemEval-S | 92.8% |
| LoCoMo | 96.1% |
| 查询延迟（中位数） | 1.6s |
| 外部依赖 | 无 |
BYTEROVER 在 LoCoMo 上拿到 96.1%，比 Hindsight 的 89.6% 高出 6.5 个百分点。但要注意：这个数字是 BYTEROVER 自己报告的，没有第三方独立复现。
三、MemPalace：verbatim 哲学的极端实践
MemPalace（GitHub: MemPalace/mempalace，作者：Milla Jovovich + Ben Sigman，2026年初）是另一个路数的极端代表。
当前所有记忆系统都遵循同一套哲学：用 LLM 提取"重要"内容，丢弃其余。MemPalace 直接颠覆这个前提——它存储所有对话的原始文本，然后让它可被检索。
架构叫 Palace：Wings（人/项目）→ Rooms（主题）→ Closets（AAAK 压缩）→ Drawers（逐字记录）。AAAK 是自定义压缩 dialect，把 1000 token 压到 ~120 token，实现 30x"无损"压缩。
| 指标 | 数值 | 可信度 |
|---|---|---|
| LongMemEval R@5 raw（零 API） | 96.6% | ✅ 最高 zero-API 分数 |
| LongMemEval R@5 hybrid + Haiku | 100%（500/500） | ⚠️ 有争议 |
| LongMemEval held-out | 98.4% | ✅ 泛化能力 |
96.6% raw 是目前唯一一个不需要 LLM API、不需要外部服务就能跑出高分的方案。纯 ChromaDB 向量检索，完全本地。
但 100% 这个数字有严重方法论问题。MemPalace 自己在 benchmark 页面 承认：最后 0.6%（2道题）是通过查看特定错题后针对性调优得到的——这本质上是 teaching to the test。Hindsight 作者 Vectorize 在 2026年4月发了篇技术拆解（vectorize.io），指出 MemPalace 的 LoCoMo 评估用 top_k=50，但候选池最多 32 项，方法论有漏洞。
最可信的数字是 96.6%（raw），不是 100%。
四、Mastra OM：极简架构反而最高分
Mastra（开源 AI 框架，前 Gatsby 团队创建）提出的 Observational Memory（研究页面）是另一个极端——架构比 Hindsight 简单得多。
核心设计：上下文窗口分成两个 block。Block 1 存压缩后的 observations（持久）。Block 2 存原始消息（滚动），超过 30k token 时触发 Observer agent 压缩，新 observations 追加到 Block 1。不需要向量数据库，不需要图数据库，纯文本。
| 指标 | 数值 |
|---|---|
| LongMemEval with GPT-5-mini | 94.87% |
| LongMemEval with GPT-4o | 84.23% |
| 外部依赖 | 无 |
94.87% with GPT-5-mini——Mastra 称之为"任何系统在任何模型上的历史最高分"。比 Hindsight 的 91.4%（Gemini-3 Pro）高出 3.5 分。
更值得关注的是另一个数字：Mastra 用 GPT-4o 跑出了 84.23%，而 GPT-4o 的 Oracle 基线（知道答案但只靠上下文）只有 82.4%。这意味着 Mastra OM 已经超越了全上下文上界——它不是比别的系统准，而是比"把所有上下文都塞给模型"这条路的极限还高。
一个有意思的对比：Hindsight 用四路检索 + LLM fact extraction 才能跑出 91.4%，Mastra 用纯压缩 + 无检索跑出了 94.87%。
这说明什么？
LongMemEval 这个 benchmark 可能对"检索"类系统有结构性偏见。如果答案就在压缩后的上下文里，不需要复杂的向量检索，模型自己就能找到。Mastra 的方案本质上是"把答案放得离模型更近"，而不是"把答案检索得更准"。
但 Mastra 也坦承了 tradeoff：Observational Memory 优先 agent 已经处理过的内容，不适合开放域知识发现和需要从大量历史中精确检索的场景。
五、四系统横向对比
| 维度 | Hindsight | BYTEROVER | MemPalace | Mastra OM |
|---|---|---|---|---|
| 论文发布时间 | 2025-12 | 2026-04 | 2026-01 | 2026-02 |
| LongMemEval | 91.4% | 92.8% | 96.6%（raw） | 94.87%（GPT-5-mini） |
| LoCoMo | 89.6% | 96.1%（v2.1.5，自报） | 88.9% | 未查到 |
| 向量数据库 | 需要 | 不需要 | ChromaDB（可选） | 不需要 |
| LLM 做抽取 | 需要 | 同 LLM 推理 | 不需要（raw） | 不需要 |
| 外部存储 | PostgreSQL | 文件系统 | SQLite（可选） | 无 |
| 核心架构 | 三层记忆 + 四路检索 | Context Tree + AKL | Palace + AAAK | Observer/Reflector |
| Reflect/学习 | Reflect 操作 | AKL lifecycle | 无专门 reflection | Reflector agent |
| 独立复现 | ✅ Virginia Tech + WaPo | ❌ 自报 | ❌ 自报 | ❌ 自报 |
| Claude Code | ✅ 官方插件 | ✅ 官方插件 | ❌ 社区自制插件 | ❌ 官方插件 |
| OpenCode | ✅ 官方插件 | ✅ 官方插件（Claude Code 兼容层） | ❌ 社区自制插件 | ❌ 官方插件 |
关于 OpenCode 支持的重要说明：
OpenCode 原生只支持 Claude API，不支持外部 memory 系统对接。但 BYTEROVER 官方提供了基于 Claude Code 兼容层的 OpenCode 支持——它通过 opencode-claude-code-plugin 接入 Claude Code 的插件体系，间接支持 BYTEROVER。这是 OpenCode 目前唯一原生支持的外部记忆系统。
Hindsight 同时支持 Claude Code 和 OpenCode，两者都有官方插件（@vectorize-io/hindsight-claude-code 和 @vectorize-io/opencode-hindsight）。
MemPalace 和 Mastra OM 均未提供官方插件，但 MemPalace 有社区用户报告通过 MCP server 手动配置使用（OpenClaw 社区有用户分享了 custom plugin 方案）。
一个被忽视的事实：Hindsight 是唯一一个被第三方独立复现的系统。BYTEROVER、MemPalace、Mastra OM 的数字都是 self-reported。
这不是说它们的数据造假，而是说：Hindsight 的 91.4% 是有 Virginia Tech Sanghani Center 和 The Washington Post 两个机构背书的，其他系统的数字缺乏同等程度的验证。
六、benchmark 分数不是选型依据
为什么说看分数选型是危险的，看两个具体例子：
MemPalace 100% 的教训：官方 marketing 打出了"史上最高分"，但 100% 是通过针对特定错题调优得到的，不是真实泛化能力。MemPalace 自己后来在 GitHub 上承认了这一点。单纯看 100% 这个数字，你会得出 MemPalace 远优于 Hindsight 的结论；看 98.4% held-out 和 96.6% raw，结论完全不同。
Mastra 94.87% vs Hindsight 91.4%：如果只看分数，Mastra 赢了。但两者的设计哲学完全不同——Mastra 不做检索，优先 agent 已经处理过的内容；Hindsight 做四路检索，优先从大量历史中精确召回。不同场景下，分数低的可能更适合。
benchmark 测的是检索精度，但实际产品需要的是：延迟、成本、运维复杂度、特定场景下的行为稳定性。这些都不体现在 LongMemEval 和 LoCoMo 的分数里。
七、选型建议
看场景，而不是看分数：
| 场景 | 推荐 | 原因 |
|---|---|---|
| 需要从大量历史中精确检索 | Hindsight | 四路检索 + 时间感知，架构最完整 |
| 完全离线/无 API 场景 | MemPalace（raw） | 唯一 zero-API 高分方案 |
| 需要 LLM 和记忆深度绑定 | BYTEROVER | agent-native 架构，LLM 自己管记忆 |
| 上下文窗口紧张/需要 prompt 缓存 | Mastra OM | 纯文本，压缩率高，context 稳定 |
| 已有 Hindsight 在用 | 不用换 | 工程成熟度高，第三方复现，有生产验证 |
一个反直觉的结论：如果你的场景是 AI Employee/Agent，需要从大量历史中精确检索信息，Hindsight 的四路检索 + Reflect 操作反而可能是最合适的。MemPalace 虽然 raw 分数更高，但它的设计哲学是"存所有东西再检索"，在开放域知识发现场景下未必优于 Hindsight 的结构化抽取。
八、结语
2026 年的 Agent Memory 赛道不再是 Hindsight 一家独大。BYTEROVER、MemPalace、Mastra OM 各自代表了不同的架构方向：
- BYTEROVER：agent-native，LLM 自己管理记忆，无外部依赖
- MemPalace：verbatim 哲学，存所有原文，纯 ChromaDB 检索
- Mastra OM：极简压缩，prompt cacheable，无任何数据库
Hindsight 的 SOTA 位置被取代了，但它还有一张其他系统都没有的牌：第三方独立复现。在 benchmark 数字可信度普遍存疑的当下，这是被低估的优势。
选型时，少看 SOTA，多看场景匹配。
本文链接：2026 Agent 记忆系统之战：Hindsight 不再是 SOTA，然后呢？ - https://h89.cn/archives/597.html
版权声明：原创文章 遵循 CC 4.0 BY-SA 版权协议，转载请附上原文链接和本声明。