Claude Code 记忆系统:它为什么会忘事,以及修复它的两个数字

我在 Claude Code 里运营着一家设计工作室的日常事务。十到二十个终端同时开着,每一个都是我。而好几个月里,每一个终端都让同一个人把同样的话再说一遍。

Brainy 团队开启这次对话时只说了一句话:我们受够了一遍遍重复自己。接着他们贴出了一份对比七款记忆产品的基准测试和一个代码仓库,问我背后的记忆系统为什么做不到那样。

这篇论文,就是我们认真对待这句话之后发现的东西。四项工作构成了它:

• 我们重建了整个记忆系统
• 十六个研究智能体审查了我们能叫得出名字的每一款记忆插件和服务商,其中八个专门去反驳另外八个
• 我们用真实的提示词测量了自己的成果,而不是自己出的考题
• 我们亲自跑了那个基准测试,用同一个评判标准给每个竞品打分

结果不是一份插件推荐清单。而是两个数字、一道悬崖,以及一条关于"记忆能声称什么"的规则。

这个 bug:认真地写,随性地读

这四个词就是"重复自己"这个 bug 的全部。

一个被认真写下、却全凭一时兴起去读取的记忆系统,能通过每一次审查,因为每个文件都在,每条事实都对。

而人类还是会第四次解释部署规则,因为在规则真正要紧的那一刻,没有任何东西主动去把它找出来。

我们的系统就是这样。每个会话都会写记忆。而读取记忆全靠一个手工维护的索引文件足够短才能被加载进来,还得靠我在任务进行到一半时,自己想起来要去查一下。

这两件事都不总能发生。这个存储库是"只进不出"式的,而一个只进不出的记忆库是日记,不是记忆。

认真地写,随性地读。

你的记忆文件里藏着一道悬崖

Claude Code 加载你的自动记忆索引,也就是 MEMORY.md 文件,上限是 200 行或 25,000 字节,以先到者为准。 超过这条线,后面的内容就不会加载,而且不会有任何提示。

我们的文件是 229 行、31,283 字节。字节上限在第 176 行截断了它。这条线以下,是整整三个板块的常设规则,其中就包括安全规则。

五十三行,占索引的 23%。它们一次都没有真正抵达过任何一个会话。

情况还会更糟,因为这个文件是按最新追加的方式写的。而上限是从底部往上砍的。所以最先被砍掉的记忆,恰恰是你最近写下的那些,也就是你正在处理的这件事相关的记忆。

如果你曾经往记忆里加过一条规则,一周后却看着智能体把它当没看见,数数你的行数吧。这个上限在 Claude Code 的问题追踪器里有两个 issue 记录在案,而且只要你的文件行数或字节数超过任何一个限制,它此刻就正在这样对你。

一个满分成绩,实际正确率只有 17%

修复方案的第一版只花了两小时。给整个存储库建一个全文索引,一个钩子(hook)在每次提示词时搜索它,把命中率最高的结果注入进去。在一套 23 条测试查询组成的测试集上,它拿到了 22 分。

然后我们看了实际运行日志。六条真实提示词,注入了 18 条记忆,其中大约只有三条相关。百分之十七。

那套基准测试用的是像"部署到生产环境"这样的查询语句。团队里没人是这么打字的。他们打的是又长又口语化、带多个从句的提示词,里面还贴着截图和网址。

字面提示词文本是个糟糕透顶的搜索查询,而话题往往藏在上一轮对话里。我们造了一根好管道,却往里灌了脏水。

五个原因,每一个都经过实测,每一个都被修复了:

第五个原因是最糟的。让会话对话内容主导搜索,意味着一场关于记忆系统的对话,每一轮都会把所有记忆笔记都翻出来;而一个关于部署的问题,得到的却是索引文件而不是部署规则。上下文可以精修一个已经有主题的查询,但绝不能凭空发明一个主题。

重写之后:16 条真实提示词里有 14 条,前两个命中结果就是对的记忆;18 条闲聊式提示词(比如"好的,继续吧"这种)里,全部 18 条都正确地什么都没召回。

沉默也是一种功能。一条被注入到根本不需要它的提示词里的记忆,就是模型不得不多读一遍的噪音。

唯一的规则:模型绝不出现在提示词处理路径上

这是第一个数字。从钩子里发起一次语言模型的往返请求要花 8.6 秒。而对整个存储库做一次全文搜索只要 18 毫秒。

你打的每一条提示词,都会先经过这个钩子,然后智能体才会看到你的文字。如果在这个钩子里放一个模型,你问的每一个问题在开始之前都要先付出八秒的代价。这正是大多数"智能"记忆插件让人觉得卡顿的全部原因。

所以这条规则是绝对的:模型绝不出现在提示词处理路径上。 它只在离线状态下运行,在会话结束时,以及每日的定期扫描中,把学到的东西写进索引。它在那里要做三件事:

• 从对话记录中提炼出候选记忆
• 推导出一个人实际会打出来的词,这样一条标题为"生产环境部署事故"的笔记,才能匹配上"我是不是快要把生产环境搞炸了"这样的提问
• 找出重复项和矛盾之处

然后它就退场了,而在提示词发生的那一刻真正负责回答的,是纯粹的 SQLite。

这个拆分方案花费为零美元、耗时 18 毫秒

这个拆分方案的成本是零美元。每一次模型调用都走我们已经付费订阅的通道,而检索,也就是每条提示词都会触发的那部分,完全不花钱。当没有任何匹配时,不消耗任何 token。这套记忆系统的边际成本,从设计上讲,永远就是零。

时间才是真正吃紧的预算。这个钩子每次提示词都是从头启动,所以它加载的一切,下一次都要重新加载一遍。以下是各个选项的实测结果:

关键词搜索还没等到讨论质量,就已经在延迟上赢了。

打字体验必须保持即时响应。这就是整个决策的出发点。

"文件太分散"这个批评方向错了

我们一直听到的批评分两半:你的记忆分散在各个 markdown 文件里,而且你没有把完整的记忆带入每一场对话。团队指出的智能体运行框架 Hermes,有一个会随你不断成长的单一记忆。

这两半都值得正面回答。

把完整的记忆带入每一场对话,在算术上就是不可能的。我们的存储库有 875,553 个 token。而上下文窗口是 200,000。这相当于 4.4 个窗口的记忆量,而且每天都在增长。

没有人会带着完整的记忆走。每个人靠的都是检索。

而 Hermes 的"单一记忆",实际上只有 3,575 个字符。一份 2,200 字符的记忆文件,加上一份 1,375 字符的用户画像,两者都始终常驻在提示词里,而且都设了硬性上限。Hermes 知道的其他一切,都存在磁盘上的文件里,靠一套跟我们类似的索引按需搜索。

"分散在 markdown 文件里"这个描述,两套系统都适用。文件数量只是存储方式。真正决定一切的是访问方式,是索引。四百八十七个文件背靠一个全文索引,这不叫分散;一次查询能在 18 毫秒内触及全部文件。

这次批评说对的地方

它说对的地方,恰好和它宣称的相反。Hermes 的常驻层大约只有 1,300 个 token。我们的却有 6,152 个。他们精简了 4.7 倍,而这种精简来自一条硬性规则:当记忆容量满了,写入就会失败,智能体必须先做整合,才能添加新内容。

我们仔细研究了这条规则,然后否决了它。Hermes 自己的问题追踪器上有一个部署案例,把上限提高到了 8,000 和 3,000 字符,结果照样撞上限,"导致 memory.add 调用失败,操作者的更正被反复丢失"。

写入失败不会催生整合,它只会催生沉默,而丢失的正是用户刚刚做出的更正。 我们的方案是把画像里最弱的那一行降级放进可搜索的存储库里,而不是让写入失败。有一次十二行内容被硬塞进一份十四行的画像:四行被降级,而用户实际说过的每一行都保留了下来。

七款记忆产品教会我们的事

团队一开始拿出的那份 MemConflict 基准测试,让七款自托管的记忆服务商,面对同样的 30 个模拟用户,回答同样的 3,750 个问题。答错记负一分,而不是零分。就这一个选择,暴露出了后面几乎所有的问题。

三个比排名更重要的发现

那张表里,排名恰恰是最没用的部分。三种模式在各家服务商之间反复出现:

• 没有一家能可靠地识破被植入的虚假记忆。 表现最好的 Honcho,面对这类问题也只有 36.4% 能完全答对,而它坚持断言那条虚假信息的比例高达 25.8%。Mnemosyne 得分是负的:它给出错误答案的频率比正确答案还高。

• 随着历史记录增长,每一家都在变差。 从第 6 到第 10 场会话,再到第 46 到第 50 场会话,mem0 的错误回答比例从 8.3% 一路涨到 22.1%。几乎每家服务商的错误率都翻了一倍。

• 看起来"安全"的那几家,其实大多只是在沉默。 OpenViking 有 67% 的答案是空白,Mnemosyne 是 50%。要是评分标准的下限是零,它们看起来会显得很有竞争力。

而那个改变了我们设计思路的发现是:证据被检索到了,却没被用上。在被植入虚假事实的那些问题上,Honcho 有 81% 的概率能把正确的支撑记忆检索进前三名,却依然有 18% 的概率答错。检索从来不是瓶颈。系统检索到之后做了什么,才是瓶颈。

Honcho 每场会话在后台推导上要花掉 617,278 个模型 token。而我们整个存储库才 875,553 个 token。采用它就意味着每场会话都要烧掉我们语料库的绝大部分,永远如此,只为回答一套搜索索引本来就能回答的问题。

这就是"自建还是采购"这道决策题的真实面貌。他们的长处不是我们的瓶颈。他们的短处恰恰就是我们的核心需求:一个语言模型删掉矛盾中的一方,却没有任何东西去核实它,或者在错了之后撤销它。

我们亲自跑了这套基准测试:第一次尝试拿到 0.409 分

别人做出来的一张表,只是一个断言,所以我们把它当断言来对待。我们把自己的记忆系统接入同一套测试框架,用同样的模拟用户和问题给它打分。

有两个细节决定了这样一个数字是否真的有意义:

• 所有行都用同一个评判者打分。 原发表的那张表是由某个模型评判的,而我们的系统跑在另一个模型上,测试框架自己的文档也说明,这两个评判者给出的分数从不可以互相比较。所以我们拿来每个竞品已发表的答案,用我们自己的评判者重新打分,和我们自己的结果放在一起:同样的五个用户,同样的 616 个问题。

• 调优过程绝不能泄露测试数据。 每一次改动都是在另外两个用户身上调优,然后只在那被报告的五个用户身上按照事先写好的规则打分恰好一次。

第一轮跑下来,我们和 RetainDB 打平,落后于另外两个我们能评分的对手。

瓶颈是召回深度,不是回答能力

诊断出的问题只有一个,而且既不是排序也不是回答质量。当正确的那句话进入了我们的前五名结果时,答案正确率是 94%。 问题只是它通常根本进不了前五。

大部分漏掉的情况,都排在前五十以内,只是排名太靠后而没被读到。关键词搜索还有一个盲区,深度再怎么增加都补不了:问一个用户的居住地是否变了,它没法找到"我刚搬去了墨尔本"这样一句话,因为一个字都对不上。

于是我们做了三处改动,每一处都在两个调优用户身上打了分。

修复方案:语义搜索,加上会自我更新的事实笔记

这里的语义搜索不是模型。它是一张静态的嵌入表,每个词片一个向量,取平均值。用 numpy 运行,不联网,在一台笔记本电脑上 34 秒就能把我们 71,062 轮历史对话全部嵌入完毕。每条提示词的钩子依然完全不碰它。

事实笔记是这套存储库以前完全没有的东西。一条关于某个人或某个组织的持久事实,只写一次,之后随着变化不断更新:新值写在最上面,标注生效起始日期,所有旧值保留在下面,各自附带日期。在这之前,一处变化只能被提议出来等人工审核,而没人会真去审这个队列,于是存储库能学会一个客户存在,却永远学不会这个客户已经搬走了。

如果不设上限,这些笔记会排到对话内容前面,占满所有位置。那些需要周边对话的问题,比如某人在什么条件下有什么偏好,就丢失了上下文。任何一个存储源都绝不能垄断模型能读到的那个窗口。

只打分一次,我们和 mem0 打成 0.520 平手

在那五个被报告的用户身上,只打分一次,最终版本和 mem0 打成了平手。

在这个平手成绩背后,我们在两项指标上领先,在两项指标上落后:

我们对几乎一模一样的答案独立打分了两次,两次结果只差 0.007,所以这个平手是真的平手。但读这个结果时要留三个心眼:

• 这五个用户对谁都很友好。 mem0 在全部三十个用户上公开发表的成绩是 0.392,在这五个用户身上却拿到 0.520,所以这张表里的任何数字都不能反推回那份公开榜单。

• Honcho 没有出现在这张表里。 它在公开榜单上领先,但它给模型灌了 114,804 个字符去回答每个问题,而在一块 GPU 上给它打分,速度慢到每分钟才能出一道题的结果。它很可能依然是领先的。

• 准确率打平不等于胜利。 一套记忆系统,在准确率上打平的同时,归档一场对话的速度是对方的二十倍,用的文本量只有对方的一半,这是一个不同的产品,而不是一个更好的产品。哪个更重要,取决于你要付的账单。

"会自我修复的记忆"其实是两套系统

"会自我修复的记忆"是团队清单上的一项。研究结果告诉我们这句话到底是什么意思,而答案不是单一的东西。

一篇关于记忆控制平面的论文测量过这一点:在某一类清理任务上,确定性规则得分只有 5%,而一个模型能拿到 100%;可在意图感知型删除任务上,同一个模型却只能拿 0%,规则反而表现良好。两者都做,能多拿 27.8 个百分点。能自我修复的记忆需要在不同环节分别跑一遍确定性规则和一遍模型判断,两者缺一不可,绝不能只用其中一种。

确定性环节负责找出字节级完全重复的内容,以及指向已经不存在的文件路径的记忆。第一轮运行就发现了十三个真实问题。模型环节负责找出相关记忆之间的矛盾,并提议哪一条应该取代哪一条。

没有防护措施的情况下,模型环节的判断大约只有 55% 是对的,而且每一次犯错都表现得信心十足。它曾用一条关于云端会话的参考笔记,去撤销一条常设权限规则。它还曾用另一个产品的发布说明,干掉了一条关于某产品 CDN 的事实,原因仅仅是两条笔记里都提到了"CloudFront"。

它还曾让一张指针索引图撤销了它自己所指向的那条真实记忆。它甚至撤销了一份列出六项待决事项的清单,只因为一条新记忆解决了其中一项。

四道防护栏和一个撤销功能,让这个"策展人"变得安全

四道防护栏解决了这个问题:

装上这些防护栏之后,同一次扫描自动应用了恰好一次取代操作,而且是正确的那次,同时把三个真正存在张力的情况送去了人工审核队列。

之所以能放心让它无人值守地运行,不是因为模型在这件事上有多擅长,而是因为没有任何东西会被真正删除,每一个决定都记在审计日志里,而且一条命令就能撤销它。

被取代的记忆依然留在存储库里,带着醒目的标签和排名惩罚。旧的事实按半衰期衰减,而不是直接消失:一条项目笔记每 150 天权重减半,而用户亲口给出的规则永远不会衰减。

绝不能为了让这个"策展人"看起来更有产出,而放松这些防护栏。

一条记忆就是一个断言,所以要核实它

这是我们研究过的所有东西里,唯独我们做到、别人都没做的部分。

一条在五月份是真的、后来悄悄不再是真的记忆,是隐形的。它不会��任何东西产生矛盾,也不会指向什么已经消失的路径,它只是静静地待在那里,是错的。

我们的库里有一条写着 Instagram 令牌"由一个 Lambda 函数每周自动轮换"。实际上根本没有这个 Lambda。这个令牌从头到尾就没被轮换过一次。这条记忆被当作真的读了好几个月。

于是,现在每一条记忆都被当作一组"断言"来处理,这些断言会被逐一探测核实。一个模型会读取这条记忆,然后为一套固定的探测器填入带类型的参数:这个路径存在吗,这个分支存在吗,这个拉取请求(pull request)是否已合并,这个 Doppler 项目是否存在,这个密钥是否存在,这个实例是否存在,这个网址是否有响应。

模型从不会亲自编写命令。每一个参数在运行前都会经过校验,针对它发起的九次提示词注入攻击全都被拒绝了。让模型自己按计划编写并执行 shell 命令,本质上就是一个带了额外步骤的远程代码执行漏洞。

第一次完整运行,从 365 条记忆里提取出了 383 条断言。三百二十八条通过了核实。二十五条核实失败,而且这些失败都是真的问题:

一条记忆有资格声称什么

这些失败案例带来了两条规则,两条都关乎"一条记忆有资格声称什么"这个问题。

一个拉取请求的状态不是一个事实,而是一种情绪。它几秒钟就能变。所以提取器现在只接受"已合并"这个状态,因为"已合并"是终态,而拒绝接受"打开"或"关闭"这两种状态。因为这条规则,十一条断言被剔除了。

而且每个探测器的失败结果,要按其含义区别对待。一个不存在的文件路径,是确凿的证据:文件系统从任何地方去查,说的都是实话。而一个网址没有响应,却不是确凿的证据,因为"这台笔记本电脑连不上"不等于"这个服务挂了"。

所以这个网址探测器在设计上就不可能返回"失败"这个结果。它能证明存活。它被禁止用来证明死亡。 之所以定下这条规则,是因为我曾经在一次审计里,把一个健康的、只是设了防火墙的产品连续三次错判为"已下线",而一条需要你自己记住的规则,根本算不上规则。

一条核实失败的断言,会给对应的记忆打上"未核实"的标记。召回结果会在命中项旁边显示这个标记。人不需要主动去处理它,记忆到手时就已经带着标签了。

我们从哪些人那里"偷师",又偷了谁的招

十六个研究智能体读了这些代码仓库,在固定的提交版本上克隆下来,跑起代码,还互相试图反驳对方。在 64 项主张中,55 项经受住了考验。有两处"引用"是编造出来的,还有一张表被偷梁换柱换成了另一张。这就是为什么要对研究型智能体的成果做事实核查。

取舍:三个智能体框架

取舍:剩下的这些

一条引用只是一个假设

研究过程中有一段插曲,值得单独写一节,因为这正是每一个读到这篇论文的人接下来最可能犯的错误。

一篇被广泛引用的检索论文,在一个标准基准测试上测量了"文档扩展"这个技术。用释义改写的方式来扩展文档,得分反而低于完全不扩展的基线。而用复制文档自身用词的方式来扩展,得分则远高于基线。

我们的增强提示词,曾明确告诉模型生成的词语绝不能出现在笔记原文里。也就是说,我们一直在生成那个"输的"版本,压制那个"赢的"版本,还把那个"输的"版本的权重放大了 1.75 倍。

于是我们套用了这个发现,重新推导了全部 474 条记忆。结果测试成绩从 16 条对 14 条,掉到了 16 条对 13 条。更差了。

那篇论文的基线,是一份没有索引自身用词的文档,在那种情况下,把这些词复制回去才叫"扩展"。而我们的系统本来就已经索引了标题、描述和正文。把这些词复制进别名字段,只是重复劳动,反而挤掉了释义改写的内容,而释义改写才是我们唯一真正有效的扩展手段。

撤销改动,重新推导,成绩回到 16 比 14。花了四十分钟,而如果我们先测量再相信,本可以是零分钟。

一条引用,只是关于别人那套系统的一个假设。

这套记忆系统随后做了一件值得注意的事。它在会话结束时,自动把这个假设当作记忆捕捉了下来。但它没有捕捉到后来的反驳。

那条写着"应该把这些词包含进去"的笔记,今天依然作为一条鲜活的记忆留在存储库里。采集环节记录的是当时相信的东西,它不知道那个信念一小时后就被推翻了。这是一个尚未解决的问题,列在下面的清单里。

让智能体自己写技能,反而会让它变差

团队提出了一个需求:自主创建技能。当某个流程反复出现时,智能体应该把它写成一个可复用的技能,并且主动告知。这本该是一项超能力,但研究结果表明,最朴素的实现方式反而是个负担。

在一套包含 87 项任务、带确定性检查器的基准测试上,智能体为自己生成的技能,表现比完全没有技能还要低 8.1 个百分点,而且用的还是 Claude Code 上最强的模型。在另外两套运行框架上,同样的规律也成立。

人工整理的技能,把通过率从 33.9% 提升到了 50.5%。而当让模型去判断两个技能哪个更好时,在两者差距确实存在的情况下,模型有 84% 的概率会选中较差的那一个。

长度带来的影响出人意料。它不是一条斜线,而是一个驼峰:

超过一页篇幅之后,文档就不再带来帮助了。

我们做出来的版本会等人来把关

所以我们最终做出来的版本,恰恰是"自主"的反面。它只会检测一个在三次或更多独立会话中反复出现的流程,而它之所以能做到这一点,靠的是计数,因为全部 71,062 轮对话记录都已被索引,所以"这是不是一个重复出现的流程"这个问题,只是一次数据库查询,而不是模型的一次猜测。

它会把这个技能写成"未激活"状态,这样它的描述就绝不会进入任何人的上下文。准入门槛是结构性的,绝不是靠一段散文式的判断:必须点明这个技能能防止的具体失败场景,而且它引用的每一条路径都会拿去和文件系统核对。只有人类才能把它正式晋升为可用技能。

用六份带有对抗性的草稿测试过这套机制:冒充内置功能的、只说"能省时间"的、只出现过一次的、编造路径的、篇幅过长的,全部被拒绝,而唯一合格的那份被通过了。

第一次在三十场会话上正式运行,结果是没有发现任何值得起草的技能。这本身就是正确答案。至今只有一个技能被正式晋升,它是一道防护措施,用来拦截一个会悄悄指向生产环境的部署命令。

目前仍然存在的问题

诚实比替代方案更省事,所以这里是剩下的问题。

常驻层依然比 Hermes 的重三到四倍,目前大约是 24,000 字节,而且它是一个索引,而不是一份画像。我们欣赏的那种精简,来自一个我们已经否决掉的机制,而我们至今还没找到一个更温和、却能产生同样约束效果的替代方案。

跨边界的一致性并没有被强制执行。用户画像一上线,里面的每一条事实就同时存在了两份。这个"策展人"机制只会核对记忆和记忆之间的矛盾,不会核对画像和存储库之间的矛盾,也不会核对记忆和项目自身指令文件之间的矛盾。Honcho 就是明证:同一个事实的两份衍生视图,迟早会产生分歧,而模型会听信错的那一份。

采集环节在会话结束时以及压缩(compaction)发生之前触发,而这恰恰是最容易把一段根本没成功的操作过程,写成一份自信满满的总结的时刻。前面提到的那个被推翻的引用案例,就是活生生的例子。

一条记忆能被核实到什么程度,取决于它对应的探测器能力。路径、分支、拉取请求、密钥和实例,这些都可以核实。但"这个页面里有三千行属于这个页面"这种说法核实不了,而"用户偏好 X"这种表述根本算不上一个可核实的断言。

存储库依然可能存有一条悄悄变假的陈述性说法,它只是没法存有一条悄悄失效的路径。

在基准测试中,有条件成立的偏好依然是我们最弱的问题类型,而 mem0 依然更擅长把证据送进前五名。我们在跑基准测试时,事实笔记用的是一个小模型,而它会凭空捏造:有一条笔记把"我没有母亲可以依靠"这句话,记录成了用户是单身。而那份公开榜单上的第一名,恰恰是我们唯一没能重新打分的那个系统。

而这套记忆系统对自己的记忆,也已经开始过时了。有一条笔记指向一个钩子文件,而这个文件早已在系统把钩子迁移进插件时被删除了。它现在就躺在审核队列里,标着"未核实",和其他那些一样在等待处理。

六条规则

如果你只从这篇笔记里带走一样东西,带走这份清单。

更大的教训,是整个行业一直在从错误的方向反复重新发现的那个道理。记忆的"召回"这一半,也就是找到正确的笔记,已经被研究得很透彻,而且几乎已经被一套零成本的搜索索引解决了。而"控制"这一半,也就是决定一条笔记有资格声称什么、什么时候该被取代、一条假的笔记该怎么被抓出来,这才是记忆真正腐坏的地方。

没有人在卖这一半,因为它不是一项功能。它是一种纪律,而它必须被编译进代码里,这样才没人需要自己去记住它。

代码、基准测试适配器,以及每一项打分结果,全部开源,地址在 github.com/brainyboon/quipu。

如果你想看看 Boon 运行所依托的其余部分,可以从为设计师准备的 Claude Code 指南开始,再看看给智能体装上"双手"的 MCP 服务器,然后是为设计师准备的 AI 智能体指南,以及一个智能体的 token 到底要花多少钱,而这套记忆系统正是让这笔账单保持为零的关键。如果你想为自己的品牌获得同等级别的用心打磨,Brainy Studio 就是起点。

---

常见问题

为什么 Claude Code 会忘记我写在 MEMORY.md 里的东西?

Claude Code 加载自动记忆索引的上限是 200 行或 25,000 字节,以先触发的那个限制为准,超出的部分会被默默忽略。这个文件是按最新内容追加写入的,而截断是从底部开始的,所以最近写入的记忆会最先被砍掉。如果智能体忽略了你最近添加的一条规则,去数数这个文件的行数和字节数。

我应该给 Claude Code 装一个记忆插件吗?

先查两件事:它是否在提示词处理路径上运行了模型(这会给每条提示词增加几秒延迟),以及它是否运行了一个后台守护进程(市面上最大的那款插件,绝大多数未关闭的 issue 都出在守护进程上)。真正解决我们问题的,是一个每条提示词都会搜索的全文索引、离线运行的模型环节,以及一道核实步骤。这些都不需要守护进程。

对 AI 智能体的记忆来说,关键词搜索真的够用吗?

对于每条提示词都会触发的那个钩子来说,够用。在标准的零样本检索基准测试上,每一个单一向量嵌入模型都输给了纯粹的 BM25 关键词搜索,而一个神经网络重排序器光是加载模型就要花掉大约 1.5 秒,相比之下我们的预算只有 18 毫秒。但要搜索过去的对话记录,光靠关键词就不够了:一张静态嵌入表,本质是查表而不是跑模型,找到"发生了变化"这类陈述的概率是关键词搜索的两倍。如果只是简单地把它和关键词排序混在一起,效果反而会变差;但按排名融合、广撒网收集,它就是帮我们打平 mem0 的关键因素之一。

这套记忆系统是开源的吗?

是的。这个插件、MemConflict 基准测试适配器、方法论,以及每一份打分结果汇总,都在 github.com/brainyboon/quipu,采用 MIT 许可协议。核心部分只需要 Python 标准库;语义搜索部分需要 numpy。

你们是怎么防止记忆系统相信一个假信息的?

两种办法。一个从不删除内容的"策展人"机制:出现矛盾时,把旧的记忆标记为"已被取代",带上醒目标签和排名惩罚,每一个决定都记录在案,而且一条命令就能撤销。以及一个核实机制:把每条记忆当作带类型的断言,拿去和真实世界核对,一旦某项核实失败,就把这条记忆标记为"未核实"。

运行这套记忆系统要花多少钱?

边际成本为零美元:检索只是一次本地数据库查询,而每一次模型调用(会话结束时的采集、新记忆的增强处理、每日的矛盾扫描)都走的是已经付费订阅的通道,从不调用按量计费的 API。真正的成本是订阅额度,大约每场会话消耗一次小规模调用。在 MemConflict 基准测试中,它归档一场对话只用了 1.6 秒,而在同一台机器上 mem0 要花 31.6 秒。