用 Git 为编码 Agent 构建有效记忆

给你的 AI 编程 Agent 一份记忆，它迟早会利用这份记忆，自信满满地重犯一个错误。

来看一个具体的失败场景：某个 Agent 为了加快缓慢的导出任务，尝试调大 batch size。本地运行没有问题，于是它提交了这项改动。几周后，在另一次会话中——同一个 repo、同一个 Agent，却不记得之前的尝试——它又提出了一模一样的优化方案。它不知道调大 batch size 早已试过并被回滚，因为这会导致 staging 环境超时；而原来那个更小的 batch size，恰恰是为了避免这个问题才特意选定的。没有记忆，Agent 只会不断重复这个循环。而使用大多数「AI memory」工具，它同样会重复这个循环——那次已经放弃的尝试会被存储下来，之后又像仍然有效的建议一样被重新呈现，因为从来没有任何机制告诉存储系统：这条建议已经过期。

这正是我构建 robo-cortex 想要填补的空白。

「AI 现在有记忆了」背后的盲区

大多数 Agent memory 项目最终都可以归结为同一套做法：对一些文本做 embedding，存储得到的向量，再通过相似度进行检索。用它来实现「回忆」确实合理——我们以前是否说过类似的内容？但它完全没有「有效性」这个概念——考虑到代码现在的样子，这件事还成立吗？

vector store 无法区分一条仍然准确的经验，和一条早在三次重构之前就已经被代码库悄然淘汰的经验。二者都会以很高的相似度分数返回。Agent 得不到任何信号，无法判断「现在仍然是这样运作的」，还是「在有人修复它之前，过去曾经是这样运作的」。于是，它会同等信任两者——对于后一种情况，这意味着 Agent 最终可能比完全没有记忆时错得更加自信。

解决办法：把记忆锚定到代码，而不是向量

robo-cortex 刻意选择了一条并不炫酷的路线：不使用 embeddings，不使用 vector database，也不依赖云服务。每条记忆——无论是经验、决策还是实验——都可以关联到它所涉及的具体文件，并记录该记忆创建时这些文件对应的 git blob hash。

当文件内容发生变化时，hash 就不再匹配。下一次检索时，这条记忆会被自动标记为 needs_review——不会在没有提示的情况下继续被信任，也不会被悄悄删除。如果某项改动后来被回滚了（提交后的文件再次匹配原始 hash），这条记忆还会自动恢复。整个过程不需要 LLM 作出判断，也没有需要调校的相似度阈值——blob hash 要么匹配，要么不匹配。

前面提到的「已放弃实验」场景，正是这套机制要捕获的典型模式。下面是取自项目自身测试 fixtures 的实际操作流程：先将一个实验标记为 abandoned，并记录原因；再让一条 lesson 关联到该实验。下一次针对同一任务进行检索时，这条 lesson 的排名会高于那个已经失效的想法，而已放弃的实验本身则不会出现在默认结果集中：

$ robo-cortex status fixture-repo-a 2 abandon --reason "batch_size 500 caused the same staging timeout the original 50-item limit was chosen to avoid; reverted." --json
{"id": 2, "status": "abandoned"}

$ robo-cortex retrieve --repo fixture-repo-a --task "should I increase the scanner batch size to speed up exports" --json
{"data": [
  {"id": 3, "type": "lesson", "status": "provisional", "score": 0.599, ...}
], "meta": {"matched": 2, "returned": 2, ...}}

lesson（id 3）会被返回；已放弃的实验（id 2）则会从默认记忆包中被过滤掉——它没有被删除，只是不再作为当前有效的工作知识提供给 Agent。

坦诚面对一个不大的数字，代价是什么

我进行了一项包含 30 个会话的 benchmark：从 robo-cortex 自己的 repo 中选取 3 个真实的历史 bug，重新引入这些 bug，再让一个小模型（Claude Haiku 4.5）分别在使用和不使用 robo-cortex memory pack 的情况下，各自重复解决 10 次。以下结果取自每项任务配对差值的中位数：

修复质量：两组完全相同——30/30 全部正确，零次不合格

Fresh tokens：使用 memory pack 后减少约 12%

API-equivalent cost：降低约 15%

在无辅助情况下最难定位的任务：tokens 最多减少 26%，成本最多降低 39%

盈亏平衡点：一条已记录的记忆在被复用约 1～6 个会话后即可收回成本（中位数约为 5）

Wall-clock：不作任何结论——耗时差异主要被噪声支配

已知限制也应该直说，而不是藏起来：实验只使用了一个目标模型、一个文档完善的代码库（这很可能压缩了实际效果），以及三种任务类型。此前在一个更大模型上进行的较小规模先导实验，只测得了更弱的 2.7% 效果。完整的方法、每次运行的原始证据，以及 benchmark harness 本身都放在 repo 里的 benchmark-results.md 和 EVALUATION.md 中。相比发布一个我没有测出来的惊人数字，我更愿意公布一个自己实际测得、但没那么亮眼的结果。

它刻意不是什么

不使用 embeddings，不使用 vector database；除非你主动启用证据验证，否则也不会发起网络请求。它只使用 SQLite（通过 FTS5 实现搜索），并将作用域限定在你的 repo 中——.cortex/memory.db 就是一个普通文件，你随时可以用 sqlite3 棱查。每条记忆都带有审计记录：每次状态变更都必须通过 --reason 提供原因，而且会被永久记录。任何内容都不会悄无声息地消失。

上面的 benchmark 是诚实的，但规模确实很小，而且是在我自己那个文档完善的 repo 上运行的。真正悬而未决的问题是：在更加混乱、规范程度更低的真实代码中，git-blob-hash anchoring 是否仍能以同样的方式发挥作用——在那里，文件可能因为各种与其关联经验毫无关系的原因而频繁变动。我现在还不知道答案。如果你在真实项目中尝试了它，我确实很想知道究竟会在哪里出问题。

pip install robo-cortex[mcp]

PyPI · GitHub · 论文（Zenodo）

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。