用Claude Code或Cursor写代码的人都遇到过同一种尴尬:上一轮聊天里刚定好的架构决策,关掉窗口重开,智能体又忘了。项目里那些临时凑出来的CLAUDE.md、AGENTS.md,写着写着就变成一份没人维护的备忘录。
一个叫okf-agent-memory的开源项目,这几天在这个痛点上打出了一张相当漂亮的成绩单:纯Go编写,零外部依赖,内置MCP服务器,检索延迟压到300微秒以内,能把喂给模型的token量砍掉80%。它把自己摆在Mem0、Letta这类向量数据库记忆方案的对立面,意思很直白:你们要连embedding API、要等网络往返,我本地跑,零成本。
数字从哪来
先说清楚这几个数字不是空话。项目方给出的benchmark案例里,一次具体的上下文输入从3034 token压到603 token,削减比例80.1%,和README里“80%”的说法基本对得上。在Apple M2 Pro、Gemma模型上测得的首token时间,也确实从36.1秒降到20.9秒,提速约1.7倍。
这些数据可以在本地跑make benchmark复现,这一点值得肯定——至少不是纯嘴炮。
- 结论.300微秒的BM25检索、80%的token削减,是项目自测且可本地复现的结果,不是空手套白狼。
口径不一致的地方
但同一个项目,两份文档,数字就不统一了。benchmark文档记录的是80.1%,README沿用了这个说法。可release notes里,官方给出的表述是“up to 94%”——比实测数字更响亮的一句营销话。
这不是笔误级别的差异。80.1%是有具体输入输出token数支撑的实测结果,94%目前找不到对应的复现路径。一个项目同时给出两套口径,读者该信哪一个?
仓库现状:一日项目的痕迹
再往下看仓库本身,落差更明显。截至目前,main分支只有一次提交——就是初始的v0.1.0。只发布过一个release。issue区是零,而且创建功能受限,基本没有第三方的使用反馈或独立复现。
README里那张五层架构图、那张碾压式的性能对比表,给人的感觉是一套打磨已久的成熟工具链。可仓库的实际状态,更像是刚写完、还没经过任何外部检验的“一日项目”。
- 提醒.零issue不代表没问题,更可能是还没有真实用户跑起来。
标准本身没那么硬
okf-agent-memory打的旗号是“基于Google OKF v0.2标准”。听起来像是有大厂背书,但翻开OKF v0.2规范原文,YAML frontmatter里只有一个字段是强制的:type。provenance来源、trust信任等级、生命周期状态,全部是可选项。
更关键的是,Google对OKF自己的定位写得很克制:这是“一种可移植的知识/记忆交换格式,而非完整的智能体记忆系统”——不包含对话工作记忆、不包含情景记忆、不提供检索基础设施或运行时。换句话说,Google只给了一份格式规范,把“怎么实现、跑多快、能不能替代向量数据库”这些结论,全部留给了下游的实现者自己去证明。okf-agent-memory就是第一个跳出来证明的第三方仓库,证明的方式,是自己写benchmark、自己画对比表。
《孙子兵法》讲“兵者,诡道也”,商业世界里营销话术同样讲的是先声夺人。一个宽松、可选字段为主的标准之上,任何团队都能快速拼出一套“看起来工业级”的实现——这恰恰是判断这类项目时最容易被忽略的一层。
标准越宽松,实现者的自证成本就越低,读者的验证成本就越高。
回到路线选择本身。本地BM25是关键词检索,不是语义检索,同义词、跨语言查询这类场景天然吃亏——这是它换取“零API成本、零网络往返”所必须付出的代价,项目文档里没有正面回答这一点。Mem0、Letta们贵在语义理解,慢在embedding调用;okf-agent-memory快在本地词频匹配,弱在语义泛化。这是取舍,不是碾压。
判断一个基础设施项目该不该用,不该只看README里的基准表格。该看的是commit活跃度有没有持续,issue区有没有真实用户反馈,有没有独立方跑出可复现的数字。这几件事,okf-agent-memory目前都还没有。数字漂亮是第一步,经得起用才是第二步——而第二步,才刚刚开始。