你的编码 agent 每开一个新会话，都要把你上周讲过的架构再问一遍；你也只好再讲一遍。
这次我盯上了 agentmemory——一个 2.9 万 Star、专治这个毛病的开源记忆系统。它首页挂着一块徽章：95.2% 检索命中率。我把它的数据集和脚本都拉下来，在同一份数据上重跑了一遍，发现这个 95.2%，量的其实是「五个结果里，只要有一个是答案就行」。
换成「答案要找齐」的口径，同一份成绩单只剩 81.8%。
它到底是什么
一句话：给编码 agent 装一个「记住事情」的外挂。
它挂在 Claude Code、Cursor、Codex 这类编程助手旁边，你每跑一次命令、改一个文件，它就把这次动作悄悄记下来，压缩成可以搜的条目；下一个会话开始时，它再把相关的几条塞回模型眼前。官方支持十多个助手，都走同一套协议——MCP（意思是「让模型调用外部工具」的通用接口）。
它自己列出来的能力是这些：
| 它自己怎么说 | 是什么 |
|---|---|
| 12 个自动钩子 | 挂在助手的会话开始、工具调用等时机上，不用你手动喊「记一下」 |
| 54 个 MCP 工具 | 能被模型调用的 54 个具体动作，查询、写入、导出这类 |
| 17 个技能 | 内置的固定套路，比如「回顾上次改到哪」「把这次的决定记下来」 |
| 零外部数据库 | 数据存在本地文件里，不用另装数据库 |
| 2,700+ 个测试 | 仓库自带的全套自动化测试 |
安装是一条命令，跑脚本的行为也一样：不配任何密钥也能启动，只不过这时它不用向量检索，退回纯关键词搜索。
评测全程跑在隔离沙箱里：被评项目拷进沙箱自己的工作目录，宿主目录被临时文件系统盖住，全程没碰到生产机上的任何凭证，也没有联网调用任何付费接口。
它的 95.2%，和它自家文档里的 84.68% 对不上
先说数字的出处。这个 95.2% 不在宣传语里，而在仓库一个叫「基准测试」（benchmark）的目录里，用的是一份公开的学术数据集，叫 LongMemEval，2025 年 ICLR 会议的论文。它测的是长期记忆：每道题给几十轮对话，问你之前提过的某件事。
我把它自带的脚本原样跑了一遍，两个档都跑了。结果是：
| 我怎么跑 | 纯关键词档 | 混合检索档 |
|---|---|---|
| 仓库 commit 进去的那份成绩单（脚本上次跑完留下的） | 86.2% | 95.2% |
| 我用同一份数据集、同一个脚本、当前代码重跑 | 96.8% | 96.8% |
两处都值得看。第一，仓库里存的两份成绩单和现在能跑出来的对不上：纯关键词档差了 10.6 个百分点，500 道题里有 57 道结果不一样——说明提交进仓库的成绩单已经过期了，项目迭代很快，成绩单没跟着更新。首页那个数字是个历史快照。
第二更微妙：重跑之后，纯关键词和混合检索打到同一个数（96.8%），而首页表格里这两档差 9 个百分点。也就是说首页想突出的「加了向量检索更好」，在当前代码上已经看不出来了。
真正值得看的是口径。我把它的成绩单拆开逐题算了两遍：
| 口径 | 怎么算 | 混合检索档 | 纯关键词档 |
|---|---|---|---|
| 它首页用的「任一命中」 | 五个结果里，只要有一个是答案，这题就算对 | 95.2% | 96.8% |
| 换成「答案找齐」 | 这题的所有答案都得在五个结果里 | 81.8% | 84.2% |
差了 13.4 个百分点。
为什么差这么多？我数了一下题面：500 道题里，324 道需要找齐两个以上答案，占比 64.8%，最多的一道要 6 个。而「任一命中」只要捞到其中一个就算全对。所以这个 95.2% 天然偏向「捞到一个就行」——这恰好是 324 道多答案题里最容易达成的那一档。
更耐人寻味的是它自己的文档。仓库里另有一份 10 月 9 日的评估报告，用的也是这份数据集，写的却是：「严格证据检索从 309/470（65.74%）提升到 398/470（84.68%）」。
84.68% 和首页的 95.2% 摆在同一份仓库里。区别在于那份报告用的是「找齐」口径——正是我上面算出来的那个更严的标准。
也就是说，这个项目自己知道严口径下的读数是多少：它把这套成绩写成了一份很诚实的技术报告，但首页挂的是另一个更宽松的数字。这两个数都不算错，但它们不是一回事。
我不是要把它写成「数字造假」。恰恰相反，这份仓库里真正让我意外的，是它主动写了一整段「怎么才算能拿出来比」的规矩：必须用同一版数据集、同一份上下文预算、同一个读者模型和裁判、公开每一题的过程和失败率——它还专门写明「打平或者只挑几百道题的一小块，都不足以证明领先」。一家公司愿意把自家的比较规则先写死，这在开源仓库里不多见。
但首页仍然是 95.2%。
那块「省 92% token」的徽章，公式写死在代码里
它的首页还挂着第二块徽章：省 92% 的 token。
我去找了这条结论的出处。它有一个叫 agentmemory status 的命令，跑一下就会打印「省了多少 token」。这段代码我扒出来了，它是这么算的：
| 代码里写死的两个常量 | 含义 |
|---|---|
| 每条记忆 × 80 | 假设「不装它」的话，一条记忆要花 80 个 token |
| 最多注入 50 条 × 38 | 假设「装了它」，最多塞 50 条、每条 38 个 token |
真相是：这个百分比不来自任何实测，就是一个乘法。我按这个公式逐点算了一遍：
| 你积累了多少条记忆 | 它算出来的省幅 |
|---|---|
| 1 条 | 53% |
| 50 条 | 53% |
| 240 条 | 90% |
| 280 条起 | 92% |
| 1,000 条 | 98% |
也就是说，「省 92%」这个数，只要你记的东西够多，它必然会到 92% 甚至更高——这个数字不是你实际省了多少，是「50 × 38 除以总条数」这个公式的自然结果。记到 1 万条，它会显示省 100%。
而首页表格自己写的组合是「240 条记忆 / 22K+ token」。按它自己的公式，240 条算出来是 90%，不是徽章上的 92%。
这块徽章还跟着翻译复制了出去：英文首页有，另外 30 个语言版本里也有 30 个带着同一句话。中文版照抄了「少 92%」和「240 条记忆」这个组合——那个组合按它自己的公式算不出 92%。
同一套公式还被写进了和其他产品对比的那张表里，用的是「每次会话约 1,900 个 token、每年 10 美元」这样的口径。
我得说句公道话：省 token 这件事本身是真的——它只在会话开始时注入几条相关记忆，而不是把整个历史塞进去，这个方向没问题。问题只在于「92%」被做成了徽章，而它背后是一行常数，不是一次测量。
它本地建库那段是真本事
说了半天数字，也得讲清楚哪些是我亲手验证、确实成立的。
我把全套测试在沙箱里跑到跑完，结果是这样的：
| 项目 | 实测 |
|---|---|
| 通过 | 2,772 |
| 失败 | 10 |
| 跳过 | 4 |
| 耗时 | 379 秒 |
那 10 个失败我逐个查了，没有一个是它的代码问题，全是我的沙箱造成的：
- 6 个失败是「同时起很多个钩子进程」的用例，沙箱的任务数上限把子进程掐掉了，报的是系统级的资源错误；
- 4 个是 Docker 相关的用例，它的代码用一个叫
which的系统小工具去查 Docker 在不在，而我的沙箱里没装这个工具，于是它误判成「Docker 不见了」，打印出了错误的提示。
我把任务数上限调高重跑，那 6 个全绿；把 Docker 那组单独拿出来看，原因也确认了。也就是说，2,772 通过、0 个真失败。
它的代码规模我也自己数了一遍，不转述文档：
| 部分 | 文档声称 | 我实测 |
|---|---|---|
| 业务代码 | 223 个文件 / 约 53,000 行 | 223 个文件 / 53,133 行 ✓ |
| 测试代码 | 2,700+ 个 | 251 个测试文件 / 56,409 行；静态用例 2,605 条，实际跑到 2,786 条 ✓ |
| MCP 工具 | 54 个 | 54 个 ✓ |
| 钩子 | 12 个 | 12 个 ✓ |
| 技能 | 17 个 | 17 个（另有 1 个共享目录）✓ |
这几项它一个都没虚报，连行数都精确到个位。尤其是「测试代码比业务代码还多」这一点——56,409 行的测试对 53,133 行的业务代码，这个投入在同类项目里是相当舍得的。
还有一个我没想到的设计：它把每段记忆分成两类来源，一类是源码里明写的事实，一类是它自己推断出来的，标得清清楚楚。你一眼能分清哪些是读到的、哪些是猜的。敢把这两类分开标的项目不多。
放进同类里怎么选
市面上的记忆方案大致三种路子：
| 路子 | 代表 | 特点 |
|---|---|---|
| 框架内建 | Letta / MemGPT | 记忆和 agent 运行时绑在一起，等于换一套开发方式 |
| 通用接口 | Mem0 | 只做记忆层，接到你现有的 agent 上，但要自己调 |
| 编码助手外挂 | agentmemory | 挂在现成助手旁边，靠钩子自动记录 |
适合谁：你同时用好几个编程助手、又懒得每换一个就重讲一遍背景，它的「一个服务、多个助手共用一份记忆」确实省事；而且零外部数据库、不配密钥也能跑，想在自己机器上试，门槛很低。
不适合谁：如果你只用一个助手、或者干脆靠一份写得好的项目说明文件就能解决，那它带来的是一整套常驻进程和 12 个钩子，维护成本不一定划算；另外它要常驻一个本地服务，这件事本身就有运维负担。
它和同类真正的差别，不在那些徽章上，而在两件实事：一是测试和代码规模扎得够深；二是那份「怎么才算可比的评测」的自我约束——这套规矩写得比很多拿融资的项目都清楚。
我的判断
agentmemory 值得装来试试：它的方向对——把「记住事情」从你脑子里搬到一个可以去查的本地库；它的底子也确实扎实，2,772 个测试全绿、代码规模和它说的分毫不差。
但你在首页看到的那两个数字，都得打个折再看：
- 95.2% 是「五个结果里有一个对」的宽松口径；换成更严的「答案要找齐」，同一份成绩单是 81.8%。而这个项目自己的技术报告里，写的正是那套更严的 84.68%。
- 省 92% token 是一行写死的常数算出来的，不是量出来的；只要记得够多，这个数字自己就会涨上去。
这两处不能算造假——它有诚实的文档、也留了原始成绩单供人核对。但首页挂的和文档里写的不是同一个口径，这件事本身就值得每个看数字的人多问一句：你看到的那个百分比，分母是什么、分子又允许多少水分。
关注 AI商业快讯，每天一篇 AI 热点深度解读。
相关阅读：