agentmemory 与其他 AI 智能体持久记忆方案对比检索准确率、功能矩阵、Token 成本与可复现基准【免费下载链接】agentmemory#1 Persistent memory for AI coding agents based on real-world benchmarks项目地址: https://gitcode.com/GitHub_Trending/age/agentmemoryagentmemory本仓库即agentmemory/agentmemory是一款面向 AI 编程智能体的持久记忆引擎本文基于仓库内 benchmark/COMPARISON.md 这一官方对比文档系统梳理它与其他主流持久记忆方案Mem0、Letta/MemGPT、Khoj、supermemory、MemPalace、oracleagentmemory、Hippo 等在 LongMemEval 检索准确率、功能矩阵、Token 效率三方面的对比结论并结合仓库源码检索实现、基准脚本、结果 JSON解释这些数字是如何测出来、如何复现的。读完本文你将掌握 agentmemory 的混合检索BM25VectorGraph原理、它声称的 95.2% R5 的方法论边界以及如何在自己的机器上跑一遍同样的基准来验证。一、对比的前提哪些数字可信哪些只是厂商自报COMPARISON.md 的开篇就划定了证据边界这一点在引用任何对比结论前都必须先明确文中的全部数字要么来自已发表的公开基准要么来自公开仓库文档尽可能给出可复现的原始出处但只有 agentmemory 自身的 95.2% 是仓库自己实测并可从下述方法复现的结果其他系统的数字均为厂商公开发布、未经本仓库独立复现的声明。也就是说这张对比表的目的不是谁赢谁输而是把各家宣称放到同一张桌上并诚实标注每一格数字的性质agentmemory 95.2%本仓库自测完整方法见 benchmark/LONGMEMEVAL.md结果 JSON 已提交在 benchmark/data/longmemeval_results_hybrid.jsonMemPalace ~96.6%、oracleagentmemory 94.4%厂商自报。后者使用 GPT-5.5 在 xhigh reasoning 下评测且依赖 Oracle AI Database前者为纯向量检索 更大的嵌入模型无 hooks / MCP / 多智能体集成面Letta/MemGPT 83.2%、Mem0 68.5%来自LoCoMo基准与 LongMemEval 并非同一数据集属于不同赛道的数字。文档明确给出了一条重要的方法论警告Apples vs oranges caveat跨系统、跨基准的数字只能当作量级参考不能视为同一数据上的正面对决。文档同时表达了开放态度——欢迎各维护者用同一数据集跑全量对比通过开 issue 协作。1.1 核心检索准确率对比表系统基准R5备注agentmemoryBM25 VectorLongMemEval-S95.2%all-MiniLM-L6-v2嵌入本地运行无需 API keyagentmemory仅 BM25LongMemEval-S86.2%无嵌入 Provider 可用时的回退路径MemPalaceLongMemEval-S~96.6%自报厂商发布、未经本仓库复现纯向量 更大嵌入模型无 agent 集成面oracleagentmemoryLongMemEval94.4%自报厂商发布GPT-5.5 xhigh reasoning 评测依赖 Oracle AI Databaseagentmemory 的 95.2% 使用免费本地嵌入Letta / MemGPTLoCoMo83.2%不同基准LoCoMo非 LongMemEvalMem0LoCoMo68.5%不同基准LoCoMo非 LongMemEval1.2 这些数字在仓库中的原始证据对比文档中的两组 agentmemory 数字并非凭空而来而是可以从仓库中直接复现的混合检索BM25Vector模式的完整结果已提交在 benchmark/data/longmemeval_results_hybrid.jsonquestions: 500、recall_any_at_5: 0.952、recall_any_at_10: 0.986、recall_any_at_20: 0.994、ndcg_at_10: 0.8786、mrr: 0.8821纯 BM25 模式的结果在 benchmark/data/longmemeval_results_bm25.jsonrecall_any_at_5: 0.862、recall_any_at_10: 0.946、ndcg_at_10: 0.7302、mrr: 0.7154。两份 JSON 都包含per_question级别的逐题明细任何对结果存疑的人都可以逐题核对。二、方法论拆解LongMemEval-S 是怎么跑的要正确理解 95.2% 这个数字必须看懂 benchmark/LONGMEMEVAL.md 和基准脚本 benchmark/longmemeval-bench.ts 里定义的评测口径。2.1 数据集与评测口径数据集LongMemEval-SICLR 2025 论文 LongMemEval 的 S 变体500 道题每题约 48 个会话session每个问题对应的语料约 115K tokens源数据集为 HuggingFace 上的xiaowu0162/longmemeval-cleaned约 264 MB指标recall_anyK—— 只要任意一个 gold答案所在会话出现在检索结果 Top-K 中即计 1.0逐题平均得到百分比嵌入模型all-MiniLM-L6-v2384 维本地运行不需要 API key无 LLM 参与这是纯检索评测——只测检索是否召回正确的会话不做答案生成也没有裁判模型因此排除了 LLM 读数的差异。从 benchmark/longmemeval-bench.ts 的源码可以看到评测的完整链路排除 abstention 类问题single-session-user_abs、multi-session_abs、knowledge-update_abs、temporal-reasoning_abs实际跑 500 题对每个问题把其约 48 个 haystack 会话逐一会话文本写入内存中的SearchIndexBM25hybrid 模式下再用LocalEmbeddingProvider计算嵌入并写入VectorIndex用问题文本做检索BM25 模式直接bm25.searchhybrid 模式构造HybridSearch(bm25, vector, provider, kv, 0.4, 0.6, 0.0, false)后调用hybridSearch.search按recallAny、ndcg、mrr三个函数计算指标最后把结果与per_question明细写入 JSON。2.2 混合检索的融合原理文档中BM25 单独 86.2%、加上向量后 95.2%9pp的结论背后是 src/state/hybrid-search.ts 中实现的三流融合triple-streamBM25 流src/state/search-index.ts 实现了经典 BM25 打分常数k1 1.2、b 0.75配合 Porter 词干化src/state/stemmer.ts、同义词扩展src/state/synonyms.ts和 CJK 分词src/state/cjk-segmenter.ts向量流all-MiniLM-L6-v2本地嵌入见 src/providers/embedding/local.ts图谱流实体抽取后经GraphRetrieval做 BFS 检索与 chunk 扩展src/functions/graph-retrieval.ts。融合采用RRFReciprocal Rank Fusion默认权重为 BM25 0.4、向量 0.6、图谱 0.3并带 0.05 的多流命中加成agreement bonus随后还会按会话去重每会话最多 3 条并支持可选的 LLM 重排RERANK_ENABLEDtrue时启用见 src/state/reranker.ts。注意LongMemEval-S 评测脚本里将图谱权重设为 00.0因此 95.2% 这个数字实际验证的是BM25Vector 双流能力。2.3 按题型拆解的结果LONGMEMEVAL.md 给出了按 LongMemEval 问题类型的细粒度表现与 JSON 中per_type一致BM25Vector混合题型R5R10题数knowledge-update98.7%100.0%78multi-session97.7%100.0%133single-session-assistant96.4%98.2%56temporal-reasoning95.5%97.7%133single-session-user90.0%97.1%70single-session-preference83.3%96.7%30仅 BM25题型R5R10题数knowledge-update92.3%98.7%78single-session-user91.4%95.7%70temporal-reasoning88.0%94.7%133multi-session86.5%96.2%133single-session-assistant80.4%91.1%56single-session-preference60.0%80.0%30由此得出六条核心分析结论混合95.2%几乎追平纯向量96.6%差距仅 1.4pp且双方使用同一个嵌入模型纯 BM25 也有 86.2%——带 Porter 词干化与同义词扩展的关键词检索在对话数据上意外地强向量是最大的单项增益86.2% → 95.2%9pp偏好类preference是最难的题型BM25 只有 60%、混合也只有 83.3%因为需要理解隐含/间接表述多会话multi-session与知识更新knowledge-update最强混合 97.7% 以上事实分散在多个会话时混合检索优势明显R10 达 98.6%——几乎所有 gold 会话都落在 Top-10 内。2.4 必须说清的口径限制LONGMEMEVAL.md 特别强调这些是检索召回率不是端到端 QA 准确率。官方 LongMemEval 排行榜的指标是 QA 准确率检索 生成 GPT-4o 裁判在该口径下系统普遍在 60~95% 区间例如 Oracle GPT-4o 约 82.4%。因此本文与对比文档都不把这些数字称为LongMemEval 分数而是在 LongMemEval-S 语料上的纯检索评测。三、功能矩阵一次看清各家的能力边界COMPARISON.md 的核心篇幅是一张 9 个系统 × 19 项能力的功能矩阵覆盖了从自动捕获搜索策略多智能体协调到实时查看器隐私过滤审计追踪的完整能力面这里完整保留功能agentmemorymem0Letta/MemGPTKhojsupermemoryMemPalaceoracleagentmemoryHippoGitHub stars增长中58K23K35K26K54KPyPI (Oracle)Trending类型Memory engine MCP serverMemory layer API完整 agent 运行时Personal AIMemory API app基准导向 OSSMemory engine (Oracle DB)Memory systemhooks 自动捕获✅ 12 个生命周期 hooks❌ 手动add()❌ Agent 自编辑❌ 手动❌ API 侧抽取❌ 手动❌ API 抽取❌ 手动搜索策略BM25 Vector GraphVector GraphVectorarchivalSemanticVector RAG纯 Vector大模型Vector semantic衰减加权多智能体协调✅ Leases signals mesh❌仅运行时内部❌❌❌仅作用域内多智能体共享框架锁定无无高独立无drop-in wrappers无Oracle Database无外部依赖无Qdrant/pgvectorPostgres vector多个托管云向量库Oracle AI Database无可自托管✅ 默认可选可选✅❌ 仅云✅✅需 Oracle DB✅知识图谱✅ 实体抽取 BFS✅ Mem0g 变体❌文档链接❌❌❌❌记忆衰减✅ Ebbinghaus 分层❌❌❌✅ Auto-forget❌❌✅ 半衰期4 层整合✅ Working → episodic → semantic → procedural❌OS 启发分层❌❌❌❌Episodic semantic版本/取代✅ 基于 Jaccard被动❌❌✅ Auto-resolve❌❌❌实时查看器✅ 端口 3113云仪表盘云仪表盘Web UI云仪表盘❌❌❌隐私过滤✅ 存储前剥离密钥❌❌❌❌❌❌❌Obsidian 导出✅ 内置❌❌原生格式❌❌❌❌跨 agent✅ MCP RESTAPI 调用运行时内独立MCP API独立Python API多智能体共享审计追踪✅ 所有变更记录❌有限❌❌❌❌❌语言 SDK任意REST MCPPython TS仅 PythonAPIPython TSPython仅 PythonNode3.1 几个值得展开的关键行hooks 自动捕获agentmemory 的✅ 12 个生命周期 hooks对应仓库 plugin/hooks/ 下post-commit、pre-tool-use、post-tool-use、session-start、session-end、pre-compact、stop、subagent-start/stop、task-completed、prompt-submit、notification等 12 个钩子脚本*.mjs并在 src/hooks/ 有对应 TS 实现。这是零手动add()调用的机制基础多智能体协调Leases租约、signals信号、mesh网格对应 src/functions/leases.ts、src/functions/signals.ts、src/functions/mesh.ts实时查看器端口 3113实现见 src/viewer/server.ts隐私过滤存储前剥离 API 密钥等敏感信息见 src/functions/privacy.ts跨 agent通过 MCP serversrc/mcp/server.ts与 REST API 暴露能力因此任意语言 SDK成立——任何能发 HTTP 请求或走 MCP 协议的语言都能接入。四、Token 效率持久记忆存在的根本理由COMPARISON.md 明确指出使用持久记忆的首要动机是Token 成本。下表对比重度使用一年在不同方案下的量级注意这是文档给出的估算口径supermemory / Mem0 未公开其 Token 预算方案Token/年成本/年说明把全部历史贴进上下文19.5M不可能约 200 条 observation 后即超出上下文窗口LLM 摘要式记忆抽取式~650K~$500有损——摘要会丢失细节agentmemoryAPI 嵌入~170K~$10Token 预算控制只注入相关记忆agentmemory本地嵌入~170K$0all-MiniLM-L6-v2进程内运行supermemory未公开云定价托管 API无本地 Token 预算Mem0因集成而异因集成而异抽取式无 Token 预算文档强调agentmemory 内置 Token 节省计算器运行若干会话后执行npx agentmemory/agentmemory status会直接显示与粘贴全部历史相比节省了多少 Token。4.1 仓库内的量化佐证这一节的数据在仓库的另外两份基准文档中有更细致的支撑benchmark/QUALITY.md240 条 observation、30 个会话的内部数据集20 个带标注查询三流检索在 K10 召回 58.0%对比关键词 grep 的 55.8%只返回 Top-10 结果3,142 tokens对比把全部上下文载入22,610 tokensToken 减少 86%并给出随 observation 增长 MEMORY.md200 行上限看不见的记忆占比从 17%240 条一路膨胀到 96%5,000 条的对照表benchmark/SCALE.md5 档语料规模 12 条跨会话查询agentmemory Top-10 结果约 1,924~1,981 tokens与语料规模无关保持恒定而内置记忆在 5,000 条 observation 时需 ~250K tokens 已超出常见上下文窗口跨会话查询 BM25 与混合均命中 12/12而 200 行上限的内置记忆只能触及 10/12。这两份文档共同解释了上表中~170K tokens/年、成本 $10 或 $0的量级来源只注入相关记忆 恒定大小的 Top-K 返回而非全量摘要。五、如何选择各工具最擅长的场景COMPARISON.md 明确声明这不是一张 agentmemory 全赢的页面并逐工具列出了适用场景这里完整保留其判断框架。选择 agentmemory如果你想要零手动add()调用的自动捕获可跨 Claude Code、Cursor、Codex、Gemini CLI 等工作的 MCP serverBM25 向量 图谱的混合检索实时查看器观察你的 agent 正在学到什么零外部数据库、可自托管的部署对 API key 和密钥的隐私过滤多智能体协调leases、signals、routines。选择 Mem0如果你想要可接到现有 agent 上的框架无关 API带仪表盘的托管云选项用于直接集成的 Python TypeScript SDK以实体/关系抽取为主要抽象。选择 Letta/MemGPT如果你想要完整 agent 运行时不只是记忆OS 启发的记忆分层core/archival/recall通过函数调用自编辑记忆的 agent长周期数周/数月对话式 agent。选择 Khoj如果你想要个人 AI第二大脑而非 agent 基础设施对文件和网页的文档优先搜索Obsidian/Notion/Emacs 集成定时自动化与研究任务。选择 supermemory如果你想要带服务端自动抽取与自动遗忘的托管记忆 API面向主流 AI 框架Vercel AI、LangChain、LangGraph的 drop-in wrapper无需自建基础设施的托管仪表盘单次查询同时获得 RAG 与记忆。选择 MemPalace如果你想要简单、免费、开源的向量记忆存储追逐其自报的检索基准注意未经本仓库复现纯粹的检索而非 agent 工作流能力注意无自动捕获、无 MCP、无多智能体协调所有集成都需要自己接线。选择 oracleagentmemory如果你想要已经运行在 Oracle AI Database 上、希望在库内获得记忆同库内向量搜索的企业级 Oracle 技术栈LLM 支撑的抽取且不介意为前沿模型付费其基准使用 GPT-5.5注意仅 Python、必须 Oracle Database、无 MCP、无实时查看器。选择 Hippo如果你想要生物启发的记忆模型衰减、巩固、睡眠把多智能体共享记忆作为首要特性默认遗忘、靠使用赢得持久的理念。选择 TencentDB Agent Memory如果你想要团队级共享记忆会话、文档、代码转化为四类资产Chat Memory、Skill、Wiki、CodeGraph带团队角色与归属通过 LLM 代理把 agent 的 base URL 指向它实现的零集成捕获无需 hooks 或 MCP与记忆并存的 CodeGraph 影响分析符号、调用关系注意代理位于每次模型调用的前置路径部署是多服务 Docker 栈Core Hub Proxy其发布基准为 PersonaMem76%自报且按其 README 所述自动记忆路由仍在推进中。选择 Zep / Graphiti如果你想要时间知识图谱事实携带时间维度某个时刻什么是真的是一等查询已发布的最强时间查询结果LongMemEval 63.8%注意图谱构建在后台运行新摄入的事实需要时间才可检索且每个会话的记忆占用据称远高于抽取式系统。选择 Cognee如果你想要查询前从文档与结构化数据构建知识图谱把实体-关系抽取作为首要产品而非会话捕获注意仅 Python面向文档摄入而非编码 agent 记忆。六、自己动手跑基准完整复现步骤COMPARISON.md 的态度是与其相信任何 README不如自己测。以下是文档给出的复现路径并补充了仓库当前实际可用的脚本与数据细节。6.1 克隆与准备# 克隆仓库 git clone https://gitcode.com/GitHub_Trending/age/agentmemory cd agentmemory npm install6.2 运行基准# 运行 LongMemEval-S npm run bench:longmemeval # 运行质量基准240 条 observation20 个查询 npm run bench:quality # 运行规模基准 npm run bench:scale # 运行真实嵌入基准 npm run bench:real-embeddings结果统一落在benchmark/results/。所有脚本、数据集与结果均已提交保证可复现。与当前 package.json 的核对截至本仓库当前 HEADpackage.json 中实际注册的基准相关脚本为bench:loadnode --import tsx benchmark/load-100k.ts、eval:longmemevaltsx eval/runner/longmemeval.ts、eval:coding-lifetsx eval/runner/coding-life.ts。若你希望直接运行 LongMemEval-S 评测benchmark/LONGMEMEVAL.md 提供了不经 npm 脚本的直接调用方式见 6.3这也与 benchmark/longmemeval-bench.ts 的入口签名process.argv[2]接收bm25/hybrid模式完全吻合。6.3 LongMemEval-S 数据下载与直接运行# 下载数据集264 MB pip install huggingface_hub python3 -c from huggingface_hub import hf_hub_download hf_hub_download(repo_idxiaowu0162/longmemeval-cleaned, filenamelongmemeval_s_cleaned.json, repo_typedataset, local_dirbenchmark/data) # 运行 BM25-only npx tsx benchmark/longmemeval-bench.ts bm25 # 运行 BM25Vector 混合模式需要 huggingface/transformers npx tsx benchmark/longmemeval-bench.ts hybrid脚本内部逻辑benchmark/longmemeval-bench.ts会从benchmark/data/longmemeval_s_cleaned.json加载数据缺失即报错退出→ 剔除 abstention 题型 → 对每题构建独立的内存索引 → 逐题检索并计算recall_any5/10/20、NDCG10、MRR→ 打印按题型的汇总 → 把完整明细写入benchmark/data/longmemeval_results_mode.json。6.4 附带可参考的负载基准除检索质量外benchmark/README.md 还记录了面向运行中 daemon 的负载压测脚本 benchmark/load-100k.ts默认矩阵为 N ∈ {1000, 10000, 100000} × 并发 C ∈ {1, 10, 100}覆盖POST /agentmemory/remember、POST /agentmemory/smart-search、GET /agentmemory/memories?latesttrue三个端点统计 p50/p90/p99 与吞吐。仓库已提交一份实跑结果 benchmark/results/load-100k-96c0ed0.jsongit sha96c0ed0N1000、C10每单元 200 次请求含p99_ms、throughput_per_sec等字段errors: 0。运行方式# 先以任意方式启动 daemon npx agentmemory/agentmemory # 再开一个终端执行 npm run bench:load # 覆盖矩阵参数 BENCH_N1000 BENCH_C1,10 BENCH_OPS100 npm run bench:load负载内容由mulberry32(BENCH_SEED)伪随机生成器驱动同一 seed 同一构建会产生字节级一致的种子语料保证延迟差异来自 daemon 本身而非载荷抖动结果落盘为benchmark/results/load-100k-short-git-sha.json带schema_version: 1字段并随每次发布追加到CHANGELOG.md的 Performance 章节。七、更正与共建让对比数字更准确COMPARISON.md 在结尾明确了开放共建的规则任何维护者都可以参与修正如果你维护上述某个工具且发现数字有误请开 issue 或 PR——我们宁愿要准确的数字也不要方便的数字如果想把自己的工具加入对比请提交 PR并附上三点基准方法论的链接所测指标与数据集可复现的 commit hash / 版本号。文档末尾列出的信息来源包括 LongMemEval 论文ICLR 2025、LoCoMo 论文、Mem0 与 Letta 的 LoCoMo 基准博客等公开出处。请记住第三节的对照框架agentmemory 的 95.2% R5 是仓库内可复现的实测BM25Vector、本地免费嵌入、纯检索口径其余数字均为厂商自报且多来自不同基准。想验证任何数字最好的方式就是按第六节在自己机器上重跑一遍。【免费下载链接】agentmemory#1 Persistent memory for AI coding agents based on real-world benchmarks项目地址: https://gitcode.com/GitHub_Trending/age/agentmemory创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考