Agent Memory 哪家强？8 家横评与 benchmark 罗生门

Agent Memory 哪家强？8 家横评与 benchmark 罗生门

八家都说自己 SOTA，但没人用同一把尺子。

先说一个可能会让这篇文章白写一半的结论：这 8 个 Agent memory 方案的 benchmark 分数，互相之间没有可比性。 不是"需要谨慎解读"，是根本不在同一个坐标系里。

有意思的是，这 8 家其实同处一个生态——它们全部是 Nous Research 的 Hermes Agent 的 memory provider 插件，在 plugins/memory/ 目录下并列存在：byterover、hindsight、holographic、honcho、mem0、openviking、retaindb、supermemory。同一时刻只能启用一个外部 provider，而内置的 MEMORY.md / USER.md 文件记忆始终并行工作。这个细节本身就说明了一件事：外部记忆层是可选增强，不是必需品。

本文把这 8 家摆在一起，看它们的架构范式分成几派、许可证有哪些坑、以及各家 benchmark 是怎么打架的。数据核实时间 2026-09-07，全部来自官方仓库、文档和论文。

本文提纲

  1. 8 家速览：一张表看清家底
  2. 架构范式：四个流派，不是八个产品
  3. Benchmark 罗生门：数字是怎么打架的
  4. LoCoMo 为什么被三家同时质疑
  5. 许可证：最容易被忽略的硬约束
  6. 按场景选型
  7. 已知的坑与失效边界

8 家速览：一张表看清家底

方案 仓库 Stars 语言 License 存储后端
Mem0 mem0ai/mem0 64.8k Python Apache-2.0 SQL + 向量 + 实体库
OpenViking volcengine/OpenViking 35.9k Python + Rust AGPL-3.0 AGFS/RAGFS + 向量索引
Supermemory supermemoryai/supermemory 29.3k TypeScript MIT Postgres + Cloudflare Workers
Hindsight vectorize-io/hindsight 23.2k Python MIT Postgres + pgvector / Oracle 23ai
Honcho plastic-labs/honcho 7.0k Python AGPL-3.0 Postgres + pgvector（新增 Qdrant）
ByteRover campfirein/byterover-cli 5.0k TypeScript Elastic License 2.0 本地 .brv/ context tree
Holographic NousResearch/hermes-agent 内置插件 — Python MIT 单文件 SQLite + FTS5
RetainDB RetainDB/RetainDB 54 TypeScript Apache-2.0 / BSL 1.1 双轨 本地快照 + journal / Postgres

Stars 数从 64.8k 到 54，差了三个数量级。年龄也跨度极大：Mem0 建仓于 2023-06，Holographic 随 Hermes 存在，而 OpenViking 建仓于 2026-01、RetainDB 建仓于 2026-04、Hindsight 建仓于 2025-10。最年轻的三个里有两个已经冲到 2 万 stars 以上，另一个只有 54 stars 且近三个月没有提交。

活跃度差异同样值得注意：Hindsight 和 OpenViking 在核实当天（2026-09-07）都有 push，Supermemory 最后提交 09-02，Mem0 09-04，Honcho 09-05；而 ByteRover 停在 06-25，RetainDB 停在 06-12。

采用度的另一个指标是包下载量：Supermemory 的 npm 包月下载 33.7 万，ByteRover 5.9 万，RetainDB 58 次。58 次这个数字，基本等于只有作者自己在用。

架构范式：四个流派，不是八个产品

八家听起来很热闹，但架构上其实只有四种思路。分类清楚之后，选型问题会简单很多。

MERMAID_BLOCK_0

流派一：事实抽取 + 混合检索

这是最主流的路线，Mem0 和 RetainDB 都属于这一派。

Mem0 的写入流程是：上下文查重 → LLM 抽取事实 → 去重和 embedding → 实体抽取与链接 → 分别落到 SQL 库（事实与元数据）、向量库（embedding）和实体库。v3 有个重大变更：改成单遍 ADD-only，不再有 UPDATE 和 DELETE 操作，同时 Graph Memory 从开源版移除，改为托管平台内置。检索是多信号并行融合——语义向量、BM25 关键词、实体匹配，外加时间感知排序。

RetainDB 在这条路线上做得最细：12 种 memory type（factual / preference / semantic / procedural / decision / constraint / instruction / goal / event / correction / session_summary / project_state）加 5 种关系（updates / extends / contradicts / supports / derives），双时间戳设计（eventDate / documentDate 加 validFrom / validUntil），还有 recall reinforcement——记忆被访问得越多，strength 越高，越用越强。它的 delta compression 也有意思：/v1/context/delta 只回传上次 context pack 之后的变化。

Holographic 是这一派的极简本地版。单文件 SQLite（WAL 模式）加 FTS5 全文虚表，混合检索的做法是 FTS5 取 limit×3 候选，再用 Jaccard 加 HRR 向量相似度重排，最后 trust 加权。它的 HRR（Holographic Reduced Representation）是相位编码：bind 是相位相加（循环卷积），unbind 是相位相减（循环相关），bundle 是圆均值，原子向量由 SHA-256 确定性生成，所以跨进程、跨机器、跨 Python 版本都一致。默认 1024 维。

这里有个值得注意的实现细节：Holographic 的 numpy 是可选依赖，缺失时所有 HRR 算子直接降级为 FTS5 关键词搜索。也就是说，你以为在跑向量检索，实际可能在跑全文匹配，而且不会报错。

流派二：图谱与信念层推理

这一派不满足于"存事实、查事实"，要在记忆之上做推理。

Hindsight 的架构是仿生四网络：world facts（世界事实）、experiences（agent 自身经历）、observations（后台把相关事实固化为去重信念，保留原文引用与 proof count，新证据是 refine 而非覆盖）、mental models（对某个 bank 的常设问题给出常驻答案）。最后这一层的设计很关键：读取 mental model 是纯数据库读取，没有检索、没有 LLM 调用。

它的三个操作也分工明确：retain 用 LLM 抽取事实、时间、实体、关系并归一化；recall 走 4 路并行（语义向量、BM25、图谱实体与时间与因果链接、时间范围过滤），RRF 融合后 cross-encoder 重排，按 token 预算裁剪——全程无 LLM 调用，召回是零 LLM 成本的；reflect 才做深度 agentic 分析、跨记忆建立新连接。把"读"和"想"分开计费，这是很务实的工程决策。

Hindsight 还有个独特的组织单位叫 bank——一个 user / agent / project 一个"大脑"，严格隔离无跨 bank 泄漏。bank 携带背景上下文和 disposition traits（怀疑度、字面性、共情程度），这些特质会影响 reflect 的推理方式。

Honcho 走的是另一条推理路线：peer-centric 的辩证建模。它的层级是 Workspace → Peer → Session → Message，外加 Scope（session 分组，界定召回边界），Peer 与 Session 是多对多关系。人类和 AI 在这里是一等实体，可以建模"A 眼中的 B"这种关系型认知。内部用按 (observer, observed) peer 对索引的向量集合，对外暴露为 Conclusions。推理是后台异步跑的（内部叫 dreaming，做归纳、去重、演绎），服务拆成 Storage（同步）和 Insights（异步 deriver worker）两块。

异步这一点要划重点：Honcho 的 README 明确警告，新消息不会立即反映在推理结果里。如果你的场景需要"刚说的话马上生效"，这个架构就不合适。

流派三：结构化上下文即文件系统

这一派反其道而行——不用黑盒向量库，把上下文做成 Agent 能直接浏览的结构。

OpenViking 是这一派最彻底的代表。它把所有上下文装进 viking:// 协议的虚拟文件系统，Agent 用 ls / tree / find / grep 浏览自己的上下文，而不是查询一个不透明的向量索引。内容分三类：resources、memories、skills。

它的核心机制是三层分级加载：L0 abstract（约 100 tokens）→ L1 overview（约 2k tokens）→ L2 details（全文），每级目录自带 L0 和 L1。存储是双层的：AGFS 内容层（已用 Rust 重写为 RAGFS，后端支持 localfs / s3fs / memory）加向量索引层（只存 URI、dense vector、sparse vector 和元数据）。检索路径是 IntentAnalyzer 生成 0-5 条 typed query，然后做目录级递归分层检索——先定位得分最高的目录，再逐层下钻，结果自带上下文。每次查询还保留目录浏览的 trajectory，可观测可调试。

这个设计的洞察在于：向量检索返回的是碎片，而目录检索返回的是带层级的碎片。Agent 知道这条记忆属于哪个上下文分支，这比单纯的相似度分数信息量大得多。

ByteRover 是同一思路在编程场景的特化。它用层级化 context tree 而非向量库，核心机制是 LLM 驱动的 curation：

brv curate "Auth uses JWT with 24h expiry" @src/middleware/auth.ts

由 LLM 决定把这条知识挂到树的哪个节点。查询走分层检索（模糊文本 → LLM 驱动搜索）。最有意思的是它把 Git 的语义整套搬了过来：brv vc init/add/commit/log/branch/checkout/merge/clone/push/pull/fetch/remote/reset，配合 worktree link（.brv 指针文件，和 git worktree 一个思路）。还有 pre-compression extraction——在上下文压缩丢弃信息之前抢救洞见。

流派四：托管 context cloud

Supermemory 是这一派的代表，也是八家里唯一真正拿到融资的公司。种子轮 TechCrunch 确认 260 万美元（创始人本人的说法是 300 万，两个数字并存），2025 年 10 月由 Susa Ventures、Browder Capital、SF1.vc 领投，天使投资人包括 Jeff Dean（Google AI 负责人）、Dane Knecht（Cloudflare CTO）、Logan Kilpatrick（DeepMind/Gemini）、David Cramer（Sentry 创始人）。创始人 Dhravya Shah 融资时 19 岁。

技术上它是 Postgres 加 Cloudflare Workers 的组合，MIT 许可，约 107 位贡献者，是八家里社区最实的。产品面铺得最广：API、开源引擎、消费级 App（内含 agent "Nova"）、浏览器扩展、MCP、插件矩阵和 SMFS 文件系统。

需要说明的是，Honcho Cloud 和 Hindsight Cloud 也提供托管形态，所以"托管"不是 Supermemory 的独占特征，区别在于它从第一天就是 API 优先的商业公司，而其他几家是开源项目加托管选项。

Benchmark 罗生门：数字是怎么打架的

这是本文最需要仔细读的一节。八家都公布了自己领先的分数，但只要交叉核对，就会发现数字之间存在系统性的矛盾。

Mem0：同一个指标，两个数

Mem0 的原始论文（arXiv:2504.19413）称在 LOCOMO 上用 LLM-as-a-Judge 指标相对 OpenAI memory 提升 26%，p95 延迟降低 91%，token 成本节省超过 90%。

2026 年 4 月的新算法在 README 里写的是：LoCoMo 从 71.4 提升到 92.5（7.0K tokens，p50 0.88s），LongMemEval 从 67.8 提升到 94.4。但官方迁移文档里写的是 LoCoMo 91.6、LongMemEval 93.4。同一家公司，同一个版本，两个数。

更要紧的是 README 里的一句免责声明："Scores reflect Mem0's managed platform, which includes proprietary optimizations not available in the open-source SDK"——这些分数属于托管平台，开源 SDK 拿不到。你 pip install mem0ai 装的那个东西，跑不出 92.5。

Hindsight：README 和实时看板不一致

Hindsight 的 benchmark 仓库（vectorize-io/hindsight-benchmarks）给出：LongMemEval-S（500 题）Hindsight + Gemini-3 达 91.4%，全场最佳；LoCoMo overall 89.61%。同一份表里，Supermemory + Gemini-3 是 85.2%，Zep + GPT-4o 是 71.2%，Mem0-Graph 68.44%，Mem0 66.88%。README 称结果由 Virginia Tech Sanghani Center 与《华盛顿邮报》独立复现，基础设施仅本地 MacBook 加 PostgreSQL。

但它的实时看板 benchmarks.hindsight.vectorize.io 现在显示的是 LongMemEval-S 94.6%、LoCoMo-10 92%，都比 README 高。而且这个页面目前只有 Hindsight 自家分数，没有竞品对比、没有延迟、没有成本、没有日期——和 README 声称的"live, continuously updated results including per-model accuracy, latency and cost"不符。

Honcho 公开质疑 Hindsight

Honcho 的官方博客（2025-12-19）脚注 5 直接点名：Hindsight 声称的 91.4% LongMemEval-S 站不住，因为 Gemini 3 Pro 裸跑同一份题目就有 92.0%——也就是说，加上这个记忆层反而拖累了模型的潜在能力。Honcho 附了可复现代码，同时提醒 LLM judge 的方差很大。

Honcho 自己的数字是：LongMem S 90.4%（Oracle 91.8%，Haiku 裸跑全上下文仅 62.6%），LoCoMo 89.9%，BEAM 100K/500K/1M/10M 分别是 0.630/0.649/0.631/0.406（原论文最佳是 0.358/0.359/0.336/0.266）。token 效率方面，LongMem 中位数只用了 5% 的 token；Gemini 3 Pro 直塞全上下文跑 LongMem S 约 115 美元，用 Honcho 总计 47.15 美元，省 60%。

这组数据的可信度相对高，因为它同时给了 Oracle 上限和裸模型下限作为参照系。但注意，Honcho 自己也承认时间推理是弱点（LongMem 88.7%、LoCoMo 时间类 77%、BEAM 500K 0.49）。

RetainDB：混采竞品数字，且跑的不是生产路径

RetainDB 公布的 LongMemEval（oracle split）Overall 是 79%，对比 Supermemory 81.6%、Zep 约 72%。分类里 SS-Preference 拿到 88%，自称 SOTA，比 Supermemory 的 70% 高 18 个百分点。

问题在于它引用的 Supermemory 数字是跨行混采的。Supermemory 官方研究页当前公布的是：gpt-4o 行 Overall 95%、SSP 90%；gpt-5 行 Overall 84.6%、SSP 76.67%；gemini-3-pro 行 Overall 85.2%、SSP 70.00%。RetainDB 的 SSU 97.1 取自 gpt-5 行，SSP 70.0 取自 gemini-3-pro 行——从不同模型配置里各挑一个对自己有利的数字。而且它排除了 single-session-assistant 整类，理由是"设计上只存用户陈述的事实"。

最要命的一处：RetainDB 的"检索"步骤实际是全量时间线倾倒，文档里明确写着 "No lossy semantic retrieval step"。也就是说，benchmark 跑的不是生产环境的检索路径。这个分数衡量的是"把全部记忆塞给模型"的效果，不是这个记忆系统的效果。

ByteRover：口径不同，不能并列排名

ByteRover 的数字是八家里最高的：LoCoMo 96.1%（1,982 题，272 docs，约 20K tokens / 35 sessions）、LongMemEval-S 92.8%（500 题，23,867 docs），论文在 arXiv:2604.01599，声明跑在生产 byterover-cli 代码库本身而非研究原型。

但指标口径是 LLM-as-Judge accuracy，而 Supermemory 的 95% 是 Recall@15 with aggregation。这两个数字不能直接比大小——一个是"答案对不对"，一个是"该召回的有没有召回"。把它们放进同一张排行榜，是在制造一个不存在的排名。

LoCoMo 为什么被三家同时质疑

八家里最有共识的一件事，居然是"最常用的那个 benchmark 不可信"。

Zep 先开火。 2025 年 5 月发文《Lies, Damn Lies, & Statistics: Is Mem0 Really SOTA in Agent Memory?》（2026-06 更新），称正确实现下 Zep 的 LoCoMo J 指标是 75.14% ± 0.17，比 Mem0 最佳配置（Mem0 Graph）相对高约 10%，而 Mem0 论文只给 Zep 记了 65.99%。Zep 指出原因是 Mem0 用错了 user model（把 user 角色赋给了对话双方）且使用串行搜索。Zep 还翻出一个更尴尬的事实：Mem0 自己公布的结果里，full-context 基线（约 73% J）就打过了 Mem0 的最佳配置（约 68%）——记忆层跑输了直接把全部对话塞进上下文。

Zep 同时列了 LoCoMo 本身的设计缺陷：category 5 缺 ground truth 被迫弃用、BLIP 多模态描述错误、说话人归属错误、问题欠定、不测 knowledge update。

Hindsight 自己也承认。 它在 README 里明确声明 LoCoMo「不是记忆系统质量的可靠指标」，列了 5 条理由：ground truth 缺失或错误、问题歧义、16k-26k tokens 太短装得进上下文、不测 knowledge update 与时间推理、多模态与对话设计质量问题。

但同一个 README 里，它发布了 LoCoMo 榜首分数 89.61%。一边说这把尺子不准，一边用这把尺子量出自己第一——这个修辞矛盾，读者自己判断。

Honcho 从另一个方向质疑。 它没有质疑 LoCoMo 本身，而是质疑用 LoCoMo/LongMem 分数横向比较这件事：既然 Gemini 3 Pro 裸跑就有 92.0%，那么任何低于这个数字的记忆层方案，实际是在降低模型能力，而不是提升。

这三条质疑合起来指向一个方法论问题：记忆系统的 benchmark 必须同时给出裸模型基线和全上下文基线。没有这两个参照系，任何单一分数都没有意义。Honcho 给了（62.6% 裸跑 / 91.8% Oracle），Zep 给了（73% full-context），大多数家没给。

许可证：最容易被忽略的硬约束

技术方案可以换，许可证踩了就是法务问题。八家的许可证分四档，风险等级差别很大：

许可证 方案 含义与风险
Apache-2.0 Mem0 最宽松，商用无忧，含专利授权
MIT Hindsight、Supermemory、Holographic 宽松，几乎无限制
AGPL-3.0 Honcho、OpenViking 网络服务传染：如果你把它做成 SaaS 对外提供，你的服务端代码也要开源
Elastic License 2.0 ByteRover 非 OSI 开源，明确禁止"作为托管/管理服务向第三方提供"
BSL 1.1（部分） RetainDB local / sdk / mcp 是 Apache-2.0，但 server 是 BSL 1.1；GitHub API 整体标 Apache-2.0，不准确

AGPL 这一档要特别小心。Honcho 和 OpenViking 都是好项目，但如果你打算在自己的产品里内嵌它们并对外提供服务，AGPL 的网络条款会要求你开源整个服务端。这不是理论风险，是 MongoDB、Elastic 都经历过的现实。

ByteRover 的 ELv2 更直接：它就不是开源软件。你可以自己用，但不能拿它做托管服务卖给别人。

RetainDB 的双轨制最容易看错——GitHub API 返回的整体 license 是 Apache-2.0，但 packages/server 目录下是 BSL 1.1。自托管它的 server 做商业服务需要单独授权。

按场景选型

抛开 benchmark，按实际约束选：

要最宽松许可证 + 最成熟生态：Mem0。64.8k stars、Apache-2.0、库/自托管/云三档形态齐全、YC S24 背书。代价是接受"开源版性能不等于宣传数字"，以及 v3 把 Graph Memory 移到了托管平台。

中文场景 / 国内企业自托管：OpenViking。虚拟文件系统加 L0/L1/L2 分级加载的思路对长上下文友好，官方 benchmark 显示接入后输入 token 降 34.3-91.0%、查询延迟降 58.45-66.10%。代价是 AGPL-3.0、项目只有 8 个月、664 个 open issue，且已发布 benchmark 依赖 Doubao 模型和火山服务，海外难复现。

纯本地、零依赖、零成本：Holographic。单文件 SQLite，不装 numpy 也能跑（会降级为关键词检索）。但要接受：单用户设计、无多租户、无云端同步、零公开 benchmark，以及 memory bank 有硬性容量天花板——snr_estimate() 在 SNR 低于 2.0 时会告警"存储接近容量上限，检索精度可能退化"，1024 维下这个阈值约等于单个 bank 装 256 条。

编程 Agent 专用：ByteRover。context tree 加 Git 式版本控制对代码知识库是天然契合的，pre-compression extraction 也是编程场景的真痛点。但要接受 ELv2 非开源，以及开源仓库停留在 V3 而产品线已经切到闭源的 V4 Desktop。

不想运维、要托管 API：Supermemory。八家里唯一的专业公司，npm 月下载 33.7 万，MIT 许可，107 位贡献者，产品面最全（API + App + 浏览器扩展 + MCP + SMFS）。

要图谱推理、要 reflect 能力、要 bank 隔离：Hindsight。四网络架构加 retain/recall/reflect 三操作分工，recall 零 LLM 成本这个设计在高频读取场景能省不少钱。MIT 许可，23.2k stars，只有 71 个 open issue（八家里 issue 治理最好的）。

要建模人与 AI 的关系、要后台归纳推理：Honcho。peer-centric 加 dreaming 是八家里唯一的辩证建模路线，为 Claude Code / Codex / Cursor / OpenCode 等提供了一方插件。代价是 AGPL、异步推理不即时、社区最小（7.0k stars，最老的项目之一）。

先别急着上外部记忆层：Hermes Agent 的做法值得参考——内置的 MEMORY.md / USER.md 文件记忆始终工作，外部 provider 是可选增强且同一时刻只能启一个。如果你的 Agent 记忆需求还在"记住用户偏好和项目约定"这个量级，一个 Markdown 文件加向量检索就够了。

已知的坑与失效边界

选型前先看这些具体的 issue，比看 README 的卖点有用：

Mem0：#4884 —— BM25 关键词搜索与实体抽取硬编码为英文，中文场景是硬伤。#5245 —— V3 add 管线在 batch embedding 部分失败时静默丢记忆（20 条评论）。#5794 —— OSS TypeScript SDK 因依赖 openai@4，在部分主机上 embedding 接近 100% 失败。

Hindsight：#4142 —— v0.9.x 在 ARMv8.0 / Cortex-A57（QNAP NAS）上 SIGILL 崩溃，用户被迫锁回 0.8。#3509 —— 没有 per-fact 删除或 correction-expiry 机制，错误事实写进去就清不掉。#2841 —— cross-encoder 重排会惩罚图扩展结果（语义相关性和结构相关性错配）。#3216 —— 无实体 merge / alias API，导致实体碎片化。#1517 —— Windows 加中国网络环境下本地部署踩坑。

Honcho：后台推理异步，新消息不会立即反映（README 明确警告）。PR 必须挂在带 maintainer-approved 标签的 issue 下，否则自动关闭——外部贡献门槛很高。

OpenViking：#2357 —— 要求重构 VectorDB 抽象以支持自托管外部后端（Milvus / Qdrant 等），说明当前向量后端局限于 local / http / 火山 VikingDB。分布式部署需要 license key。

Holographic：相位 HRR 是 bag-of-words 级语义，不是学习型 embedding，没有语义泛化能力。auto_extract 默认关闭，需要手动开启会话结束抽取。实体抽取用正则模式匹配，不是 NER 也不是 LLM。

RetainDB：OSS server 默认单租户，RETAINDB_API_KEY 是共享部署密钥，组织级隔离只在 Cloud 有。零 release、零 open issue、社区规模近零，npm 月下载 58 次。选型时要评估项目存续风险。

ByteRover：Hacker News 上的自然讨论热度极低，相关帖子只有 1-8 分，评论区是清一色泛泛好评，没有实质技术质询。开源仓库落后于 V4 产品线，近两个半月无提交。

最后一个跨方案的观察：这 8 家里有 6 家的存储后端都是 PostgreSQL（加 pgvector 或不加）。所谓"记忆数据库"的竞争，很大程度上是在 Postgres 之上竞争组织方式和检索策略，不是竞争存储引擎。这一点想清楚，选型时就不会被"专用数据库"的叙事带走。

参考文档与链接

官方仓库与文档

论文与 benchmark

关键 issue

你的 Agent 现在用什么记忆方案？是被 benchmark 说服的还是被许可证逼的？评论区聊聊。觉得有用点个在看，让选型少走弯路。

作者: itech001
来源: 公众号：AI人工智能时代(the-ai-era)
网站: https://www.theaiera.top/
关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top

本文首发于 AI人工智能时代，转载请注明出处。

posted @ 2026-09-07 22:17  iTech  阅读(11)  评论(0)    收藏  举报