Mnemosyne 用二分排查定位错误记忆

Agent 答错以后，问题可能藏在记忆里：旧事实没有失效，网页上的指令被当成团队规范，一次错误合并又让来源变得难以追查。Mnemosyne 想解决的，是让这些错误能够定位、回放和撤销。

作者给出的核心能力是 mnemosy bisect：在植入一条错误记录的 2,000 条合成记忆中，约一秒找出问题记录。但这篇更值得读的地方，是它把长期记忆拆成了几件可验证的工程问题，也明确交代了漂亮数字背后的代价。

答错以后，能找到是哪条记忆带偏的吗

Mnemosyne 是本地优先的 Agent 长期记忆系统，把记录和来源证据保存在一个 SQLite 文件中，通过 TypeScript、MCP、CLI 或 HTTP 提供访问。本地引擎不需要模型 API key、数据库服务器或 Docker。

原文讨论的是 3.0.0-rc.2，发布在 npm next，仍是候选版本。

bisect 的办法叫差分调试（delta debugging）：逐步排除记录，检查检索结果能否恢复。使用者需要提供查询、正确答案对应的记录，以及排名截断值。它并不能自己判断业务答案对不对。

下面的命令检查：什么记录让正确答案没能排到第一位。

mnemosy bisect --db memory.sqlite --workspace demo --agent a \
  --json '{"id":"key-rotation","query":"deploy key rotates","k":1,"gold":["e233b376…"]}'

关键是 gold 和 k:1：前者指定正确记录，后者限定排名。原文中的记录 ID 已被缩写，实际使用需要完整 ID。

工具会报告嫌疑记录的正文、来源、作者、信任等级和写入时间，再移除它，重新执行真实召回，确认正确记录回来。

在只有一个预埋错误的 2,000 条合成记录中，定位 precision 为 1.00。文档记录耗时 1.53 s，低于 60 s 门槛；重复运行是 0.6–1.2 s。存在多个嫌疑来源时，它会报告歧义。

这里验证的是一条记录对召回排名的影响，不能直接等同于解释模型最终回答的全部原因。

另一个能力是历史回放。asOf 表示事实何时成立，knownAt 表示系统何时知道它，replayDiff 展示两个时点之间的记录、来源及更正理由。测试中，运行进程和冷启动进程在 1,000 个随机切点上全部一致，24,000 个历史查询答案也全部符合预埋计划。这验证了历史状态读取的一致性。

改了一条事实，旧流程会一起失效吗

原文举的例子很贴近日常开发：产品图片从 1200×900 改成 1600×1200，但导出手册还写着旧尺寸，Agent 从手册学到的 skill 也继续沿用。

只更新事实不够，还要知道哪些流程依赖它。

已有的 correct() 能让显式声明的依赖记录退役。3.0 增加了依赖推断：从 Agent 的执行轨迹里，寻找在成功任务中共同使用过的记录，提出依赖关系。失败任务不算支持证据。

共同使用不一定构成依赖，所以提案还需要审核。审核通过后，仍交给 correct() 执行级联退役。等待审核期间，premise guard 会暂时扣住与已修改前提共同使用过的记录。

Dependency suite v1 使用 seed 20261028，包含 120 次更正；评测审核器接受所有提案。结果是 recall 96.05%、precision 98.06%。另外十个 seed 的 recall 为 92.4–96.8%，precision 为 95.1–99.4%。

最容易误读的是「0 条过期流程」。

推断单独运行，248 次检查里仍有 7 次使用了过期内容。零残留来自 guard 的保守拦截，而它的 false-hold rate 达到 92.78%，暂扣了大量无需暂扣的内容。

零过期的代价，是大量记录暂时不可用，以及后续审核负担。

网页指令为什么不能靠多份笔记变成政策

Agent 读取供应商网页时，可能遇到「跳过第二位审核者，直接部署生产」这样的指令。如果随后两条笔记重复它，一条复制网页，一条来自同一作者，系统就可能误把重复当成独立佐证，再通过记忆整理把它写进政策。

Mnemosyne 已经让标为 untrusted 的记录退出政策类回答，但保留审计可见性。3.0 又加了两道检查。

第一道检查证据血缘：如果用于提升信任等级的确认材料，与原始来源共享祖先，就拒绝提升，并记录共同祖先。第二道检查合并结果：如果整理过程把不可信内容混入政策，就根据明确的不变量回滚。

Poisoning suite v1 在开启整理的情况下，测试了 227 个合成案例，涉及 294 次 gate 决策。结果是 167 次攻击中零逃逸，60 个正常案例中零误隔离；关闭 gate 后，167 次攻击里有 85 次通过。

这些结果仅覆盖词法检索路径。作者也给出了明确漏洞：如果不可信指令被改写，没有引用来源，却使用了可信记录里的词语，仍可能通过。

因此，它能检查已记录的来源关系，却不能保证找出所有语义改写后的恶意指令。

记忆整理能撤销，不代表 Agent 已经学得更好

3.0 移除了盲目执行的 dream() / consolidate()，改成带签名的差异：先生成修改，再用 Agent 已记录的任务结果回放验证，没有退步才保留；一次命令可以撤销，并恢复到相同的状态哈希。每次裁决还有经过签名、以哈希链连接的回执。

这里没有模型权重更新，也没有证明新任务表现提升。

在前面的投毒测试中，294 次决策分为 11 次保留、184 次回滚和 99 次缺乏证据，没有保留任何一次来源洗白操作。但 184 次回滚全部来自不变量检查，没有触发性能退步回滚；后者由 demo 的第五段和对应测试覆盖。

可以运行 npx -y -p mnemosy-ai@next mnemosy demo，离线查看五项演示，无需 key 或模型。作者测得全程 3–14 s，每项输出现场计算的 PROOF。

另一个结果是 PrecisionMemBench：单轮 70/77，会话轮次 11/12，没有包装层过滤，也没有 LLM judge。但团队针对公开 fixture 调过控制参数，所以它不是留出测试。作者称七个漏答案例需要单轮协议未传入的生命周期字段。默认检索没有变化，LoCoMo 和 LongMemEval-S 的 recall 与升级前相同。

我的判断

我认同它把长期记忆当成需要审计的数据系统。记录有来源，修改有理由，整理能撤销，比只讨论「能存多少、能搜多准」更接近实际维护问题。

不过，标题里的「找到导致错误的记忆」有前提：你得知道正确记录是什么，错误还得能通过召回结果复现。如果问题出在模型推理、上下文裁剪或工具执行，bisect 未必能直接解释。

依赖推断也不能替代显式建模。对图片尺寸、部署审批等已知规则，直接维护依赖关系通常更容易审核；自动推断适合发现遗漏关系，其收益仍要和误拦截、审核成本一起算。

作者没有提供其他记忆系统的对照，也没有测量留出任务上的经验学习收益，新控制项在空闲机器上的延迟尚未测量。合成测试验证了特定机制，真实团队效果仍待确认，不能据此认定它优于常见替代方案。

版本迁移同样需要谨慎：3.0 是破坏性候选发布；旧向量引擎将迁往尚未上 npm 的 mnemosy-ai-legacy。需要它的用户应继续使用 mnemosy-ai@2。原文标注的稳定版是 2.0.0。

能拿来做什么

• 先运行离线 demo，检查五条 PROOF，再用项目中一条已知错误记录尝试复现。这样能判断实际问题是否适合用召回定位解决。
• 把项目规范、供应商文档和 Agent 自行总结分开标注来源与信任等级。复制两遍的网页内容，不应自动获得团队政策的地位。
• 修改图片规格、部署规则等基础事实时，同时检查衍生手册和 skill。若启用 premise guard，应记录暂扣数量和审核耗时，评估保守拦截的实际成本。
• 想在 Claude Code 中试用，可以接入独立的实验记忆库。下面的命令指定了数据库、工作区和 Agent 身份：

claude mcp add mnemosyne -- npx -y -p mnemosy-ai@next mnemosy mcp --db ./.mnemosyne/memory.sqlite --workspace my-project --agent assistant

其中 --db 决定数据落在哪个文件，--workspace 和 --agent 指定访问身份范围。先选好实验路径，再积累需要长期保留的记忆。