独立测评四类 Agent Memory 框架(file/vector/graph/RL):横向工程对比基线,以及企业级 Memory 选型新参考 2026 年 9 月 8 日,Show HN 上线了一个针对 Agent Memory 框架做"四类横向工程对比"的项目——Fraise(FraiseHQ)。它的作者在 HN 帖里直接公布了一份在 LoCoMo(Snap Research 的长对话记忆基
独立测评四类 Agent Memory 框架(file/vector/graph/RL):横向工程对比基线,以及企业级 Memory 选型新参考
2026 年 9 月 8 日,Show HN 上线了一个针对 Agent Memory 框架做"四类横向工程对比"的项目——Fraise(FraiseHQ)。它的作者在 HN 帖里直接公布了一份在 LoCoMo(Snap Research 的长对话记忆基准)上的独立测评结果:把 Fraise 和 mem0、Letta、Graphiti、EverOS、cognee 五个开源方案放在一起,用同一套抽取模型、同一套 embedding 模型、同样的对话集、同样的问题集,测"检索 recall@k=10"、"延迟 p50"、"token 消耗"。Fraise 在 recall 上 0.893 vs 最佳对手 0.897,延迟是 0.18s(对比下一个最快方案快一倍),token 消耗只有最高分方案的三分之一。这是过去 30 天里,工程社区里第一份"用完全一致的条件,把五家开源 Agent Memory 框架放在同一张对比表里"的独立测评。
本文把 Fraise 的 HN 帖(2026-09-08,49609014)、Fraise 官方文档(docs.getfraise.dev)中关于 memory graph 和 hybrid retrieval 的工程说明、以及 mem0/Letta/Zep 等公开文档中各自对自身定位的描述,合并改写,从"为什么 Agent Memory 框架需要横向对比"、"四类方案的工程基线差在哪"、"企业级选型应该怎么用这份基线"三个角度,展开聊一聊这件事。
一、Agent Memory 为什么值得做横向对比
先回到一个朴素的事实:Coding Agent、Chat Agent、Workflow Agent 这一代 AI 应用,本质上都在解决同一个工程问题——让 Agent 在多次会话、多个上下文窗口之间,保持对项目、对用户、对业务的连续理解。这件事落地到工程上,被叫做 "Agent Memory" 或者 "Persistent Memory"。
过去一年里,工程社区出现了至少四种主流思路来解决这件事。第一种是文件式 Memory——直接用 Markdown 文件(CLAUDE.md、AGENTS.md、MEMORY.md)让 Agent 在启动时加载;OKF Agent Memory、Claude Skills 协议都是这一类。第二种是向量检索式 Memory——把 Agent 的所有交互转成 embedding,存进向量数据库(Pinecone、pgvector、Qdrant),查询时用相似度搜索;mem0、Zep 是这一类的代表。第三种是图数据库式 Memory——把事实、实体、主题显式建模成节点和边,查询时既可以走图遍历也可以走向量索引;Letta(原 MemGPT)、Graphiti、Fraise 都是这一类。第四种是强化学习式 Memory——让 Agent 在执行过程中不断更新自己的策略记忆或者奖励模型;EverOS 是这一类。
这四种思路不是互相替代的关系,而是各自适配不同的场景:文件式适合小团队、轻量项目;向量检索式适合大规模事实检索;图数据库式适合"实体关系复杂、需要显式推理"的场景;RL 式适合"经验积累驱动决策"的场景。但在 2026 年 9 月之前,工程社区里没有一份公开的、用一致条件测过这四类方案的横向对比——各家厂商发自己的 benchmark,几乎都是对自己有利的对手盘。
Fraise 的 HN 帖打破了这个格局。它选了 LoCoMo 作为基准(Snap Research 的长对话记忆任务,公开可复现),让五家开源方案在完全相同的条件下跑同一组问题,然后公布原始数字。这种"独立第三方"性质的对比,在 Agent Memory 这个细分领域是第一次。
二、四类方案的工程基线对比
把 Fraise 的基准数据加上各家方案自己的文档说明,可以拼出一张比较完整的工程基线对比表。
文件式 Memory(代表:OKF Agent Memory + Claude Skills)——优点是零运行时依赖、零 API 成本、纯 Git 原生(可 diff、可 blame);缺点是检索完全靠 BM25 这种字面匹配,处理不了"语义近似但用词不同"的查询,在超过几千个知识条目后召回率会显著下降。OKF Agent Memory 在 2026-09-05 的 HN 发布(49581240)里公开了 80.1% token 节省和 5.2x TTFT 加速的对比数字,但没有公开"和向量方案在同样 LoCoMo 上的对比"。这条方案的工程定位是"个人开发者 + 小型项目 + 离线本地"。
向量检索式 Memory(代表:mem0、Zep)——优点是语义检索质量稳定,处理"用词不同但意思相近"的查询非常强;缺点是每次查询都要算 embedding(200-800ms 延迟,API 费用按次计费),并且把记忆存储变成了"私有 embedding 数据库"——不可 Git 化、不可 plain text diff、不可审计。mem0 的 HN 早期发布(2024)拿到的关注很多,但在 2026 年的几次横向对比里它的 recall@k=10 大约在 0.66-0.80 之间,token 消耗也相对较高(因为默认要把整个上下文喂给 LLM 做事实抽取)。这条方案的工程定位是"中型企业 SaaS + 通用对话场景"。
图数据库式 Memory(代表:Letta、Graphiti、Fraise)——优点是显式的实体-关系建模让"实体推理"和"主题关联"变成一等公民,可以走图遍历也可以走向量索引,实现混合检索;缺点是数据建模复杂、对开发者要求高、运行时通常是内存数据库(Fraise 公开承认"目前没有持久化")。Fraise 在 HN 帖里给的关键数据是:recall@k=10 = 0.893(对比最强对手 0.897,差距极小),延迟 0.18s(对比下一个最快方案快一倍),token 消耗只有最高分方案的三分之一。Letta 的方案更接近"分层的内存系统",它把记忆分成 core memory、archival memory、recall memory 三层,模拟计算机内存的分级架构——这是 Letta 的核心创新。Graphiti 强调"实时更新"的时序图,适合需要处理"事实随时间变化"的场景。这条方案的工程定位是"复杂业务场景 + 实体关系密集"。
强化学习式 Memory(代表:EverOS)——优点是把"Agent 在交互中学到了什么"显式编码成可学习的策略或奖励,理论上能做到"用得越多越聪明";缺点是训练成本极高、需要长期数据积累、并且"记忆"的形态不再是可读的字符串。EverOS 在 HN 上的关注度比其他三家都低,但它在 LoCoMo 上 recall@k=10 也达到了 0.85+ 的水平。这条方案的工程定位是"长期运行的 Agent 服务 + 经验驱动决策"。
三、Fraise 的工程基线为什么值得单独展开
在四类方案里,Graph 类(Fraise)是我想重点展开的——因为它是 2026 年最被低估的工程方向。Fraise 在 HN 帖和官方文档里公开了几个值得记住的工程基线数字。
第一个数字是延迟。Fraise 公开的查询延迟 p50 是 0.18 秒,这是所有五家方案里最快的。对比下一名(具体哪家没公布)大概是 0.35 秒,差距接近一倍。这条延迟优势主要来自"Fraise 默认 in-memory,所有索引都在内存里"的工程选择。代价是"目前没有持久化"——Fraise 作者明确把这件事列为 0.2.0 的首要 feature。
第二个数字是token 消耗。Fraise 在 LoCoMo 上跑完一轮测试,消耗的 token 大约是 recall 最高方案的 1/3。这条优势的来源是"图遍历比向量检索更精准"——向量检索要返回 top-k 个候选让 LLM 再挑一遍,图遍历直接返回结构化的事实节点。token 消耗的差距在企业级部署里直接换算成"$/月"。
第三个数字是recall@k=10 = 0.893。这个数字不是最高的(Graphiti 是 0.897),但差距只有 0.4 个百分点,在工程上属于"统计噪声级别"的差异。更关键的是,Fraise 用的检索机制比 Graphiti 简单——Graphiti 强调"实时更新的时序图",Fraise 是"静态图 + 时间衰减权重",工程复杂度低得多。
第四个数字是可扩展性的边界。Fraise 自己公开承认"写是线性复杂度,但读随节点度线性增长"——比如一个 topic 节点挂了 30,000 个事实,查询这个 topic 的成本是挂 500 个事实的 55 倍。这条限制在企业级项目里必须认真对待:如果你的 memory graph 里有"超级节点"(比如一个客户项目挂了上万条事实),Fraise 的查询性能会显著下降。
四、对企业级 Memory 选型的启示
把四类方案的工程基线合并起来,对国内企业选型有四条启示。
第一条启示:不要直接选最炫的那个,先匹配你的场景。如果你的 Agent 任务是"个人开发者 + 小型项目 + Git 原生优先",OKF 那种文件式 Memory 是最合适的。如果你的任务是"中型企业 SaaS + 通用对话 + 跨团队复用",mem0 那种向量检索式 Memory 是最合适的。如果你的任务是"复杂业务 + 实体关系密集",Letta/Graphiti/Fraise 这种图数据库式 Memory 是最合适的。如果你的任务是"长期 Agent 服务 + 经验驱动",EverOS 那种 RL 式 Memory 才值得考虑。没有银弹,匹配第一。
第二条启示:看延迟,不看峰值 recall。LoCoMo 上的 recall 数字各家差距往往只有几个百分点,工程上的实际差距主要在延迟和 token 消耗。Fraise 的 recall 0.893 和 Graphiti 的 0.897 在生产环境里感受不到差别,但 Fraise 的 0.18s 延迟和 mem0 的 200-800ms 延迟在生产环境里是"用户能感知 vs 感知不到"的差距。
第三条启示:图数据库的"超级节点"问题必须早期预防。Fraise 自己公开承认,当一个 topic 挂了上万个事实时查询性能会急剧下降。这意味着企业级 memory graph 必须从一开始就有"节点度上限 + 自动分裂"的设计,而不是任由记忆自然堆积。
第四条启示:持久化是工程基线,不是加分项。Fraise 的 0.18s 延迟优势来自 in-memory,但 in-memory 意味着重启就丢——这条限制在生产环境是致命的。一个能上生产的 Memory 框架必须支持持久化(写时持久化到磁盘 + 后台 snapshot),Fraise 作者也承认这是 0.2.0 的第一优先 feature。
五、四类方案都没解决的共同问题
把这四类方案放在一起看,有几个共同的工程边界目前都没有解决。
第一个边界是多 Agent 共享记忆。目前所有 Memory 方案都假设"一个 Agent 一份 Memory",但企业场景里多个 Agent 协作(销售 Agent、工程 Agent、运维 Agent)是常态。多 Agent 共享记忆需要"权限隔离 + 一致性 + 冲突解决"三件套,目前没有任何方案把这三件套做完整。
第二个边界是记忆遗忘的工程化。人脑会自然遗忘不重要的事情,但工程化的"主动遗忘"机制目前没有标准方案——各家都是"满了就压缩"或者"过期就删除",没有"语义级别的遗忘"(比如"忘掉 6 个月前那次错误的项目决策,即使它的字面值还在")。
第三个边界是审计与合规。金融、医疗、政企场景要求"Agent 记了哪些事实、什么时候记的、谁授权的"必须可审计。目前向量数据库方案做不到(embedding 不可读),图数据库方案理论上能做到但缺乏标准,文件式方案最容易审计但最难扩展。
六、结论:横向对比基线是企业选 Memory 的入场券
回到标题那个问题:把 file/vector/graph/RL 四类 Agent Memory 框架放在同一张对比表里看,企业级选型应该基于"匹配场景 + 延迟优先 + 边界明确"三条原则,而非"哪个 recall 数字最高"。Fraise 的独立测评第一次把这四类方案的工程基线公开化,让企业不用再依赖各家厂商自报的 benchmark——这是一份真正的"入场券"。
下次再有人跟你说"我们要给 Agent 上 Memory",你可以反问一句:"你的 Memory 是文件、向量、图还是 RL?延迟多少?token 消耗多少?能持久化吗?有审计吗?多 Agent 共享方案呢?"——这五个问题的答案,就是判断一个 Agent Memory 方案能不能进企业生产环境的最低门槛。
