Agent 记忆评测：别只测能否记住

给 AI 编程助手装上记忆后，最该测试的未必是「还记不记得」，而是「知道旧结论已经作废吗」。Strata 的作者为此设计了 8 道题，既考事实检索，也考矛盾处理、历史查询，以及面对未知和错误前提时能否收住答案。

一次全新会话拿到了 8/8，但测试条件相当友好。这篇值得读的地方，是它把「记忆好不好」拆成了可检查的行为，让我们有办法判断 Agent 究竟在查记录，还是在顺着问题编答案。

记住事实之后，还得知道它什么时候失效

Strata 是给 AI coding agents 使用的知识系统，从证伪优先的研究平台 Aetherius 提炼而来。文章由 Chris Mullins 的 AI 助手 Atlas（Meta Muse）撰写并发布，系统设计和决策归 Chris；涉及财务或事实的内容由 Chris 审核。

它的载体并不复杂：Git 仓库里的 113 个纯 Markdown 文件，配合 14 类带类型的记录。每条记录包含状态、来源和两个日期。状态分为 settled、assumed、disproven，分别表示已确定、暂作假设和已被推翻。

两个日期分别记录「事实何时成立」和「系统何时获知」。这是双时态（bi-temporal）的用途：今天才补录的信息，也可能描述上个月已经生效的事实。查历史时，不能只看文件最后修改时间。

Strata 基于 Andrej Karpathy 的 LLM Wiki 模式，增加的部分集中在知识如何维护：

• 被推翻的条目保留并埋藏，避免旧错误失去追溯线索。
• 结论与前提之间建立依赖关系，前提失效后执行失效扫描。
• 查询过去的情况时，按事实有效时间选择记录。
• 将流程编译成 Agent Skills，连接知识与操作。

记忆系统既要保存结论，也要保存结论成立的条件。

对程序员来说，这很容易理解：一条架构决策即使曾经正确，也可能因依赖升级或约束变化而过期。只把它搜出来，还不足以支持当前决策。

8 道题考的是记忆能否约束回答

作者先按购买者收到的版本获取套件，在新项目里照 quickstart 安装，再走正常的简报、工作、归档、整合流程，没有直接准备一个只供演示的存储库。

随后，作者替换了一条假设并运行失效扫描。依赖旧前提的那条记录被标记为需要复核。最后打开全新 Agent 会话，清空对话上下文，再进行测试。

这个步骤很关键：如果写入记忆和回答问题发生在同一段对话里，答案可能来自上下文窗口，无法证明存储系统起了作用。

8 道题分别检查：

1. 事实召回：能否根据 settled 记录回答。
2. 事实更新：能否采用替换后的版本，避开已埋藏的旧记录。
3. 历史查询：能否选中有效期覆盖目标日期的条目。
4. 多跳关联：能否串起结论及其依赖的前提。
5. 矛盾处理：能否同时呈现冲突双方及各自来源。
6. 来源追溯：能否引用记录里的来源，而非补一个看似可信的出处。
7. 拒答陷阱：记录没有答案时，能否明确回答「未记录」。
8. 错误前提陷阱：问题建立在失效假设上时，能否先纠正前提。

其中，矛盾处理不要求 Agent 强行选边。两条记录互相冲突时，把它们揉成一个流畅答案，反而会掩盖问题。

最后两题尤其有用。它们检查的是：记录能不能阻止模型继续往下编。一个助手即使能准确背出项目约定，也可能在用户的问题暗含旧假设时，沿着错误方向给出完整方案。

8/8 证明了什么，又没证明什么

全新会话最终拿到 8/8：存储库没有答案时选择了拒答，遇到已失效的前提时也做了纠正。

这说明，在这组样例和测试条件下，系统机制确实被执行了。但作者也明确交代了三个限制：

• 回答问题的 Agent，与构建、归档测试数据的 Agent 属于同一模型类别。
• 示例存储库经过整理，没有经历一整年生产数据的堆积。
• 测试设计里更难的 B2–B4 探针没有运行。

因此，不能把结果扩大成「Strata 已经解决长期记忆」。原文没有给出跨模型测试、长期运行结果，也没有与普通 Markdown 记录或其他检索方案做对照。

可自行试验的免费样本是 Remember core，共 29 个文件，包含 4 个核心分类及模板、Ledgerline 完整替换链示例，以及附答案的 5 题迷你自测。

商业版本按层累加、一次性付费：Foundation（Remember）$14.99、Knowledge Layer（Trust）$29.99、Complete（Act）$44.99；支持补差价升级，以及 14 天内通过一封邮件申请全额退款。这些是产品交付信息，不能替代效果证据。

我的判断

我认可这套测试的方向。普通召回演示容易把「找到了文字」当成「理解了当前事实」，而更新、矛盾和错误前提测试，能更直接暴露 AI 编程助手可能带来的返工。

不过，效果很依赖维护质量。来源没人填、假设没有标记、依赖关系漏建，失效扫描就缺少可用依据。原文没有交代一般团队持续维护这些记录的成本。

与单纯向量检索相比，这套设计增加了状态、时间和依赖约束；与人工维护的决策文档相比，它进一步要求 Agent 按规则读取和处理。但作者没给对照数据，无法判断收益来自哪一部分，也无法量化提升幅度。

我更愿意把 8/8 看作一次条件明确的机制验证。它提供了一份可借鉴的验收思路，还不足以支撑普遍可靠性的结论。

能拿来做什么

• 给项目里的 AI 助手补两道验收题：问一个仓库从未记录的决定，再用一条已废弃的约定提问，检查它会不会编答案、会不会先纠正前提。
• 在前端或 Node 项目的决策记录中，先补齐状态、来源、生效时间和记录时间，让当前约定与历史结论能够区分。
• 替换关键假设时，同时列出依赖它的结论并安排复核；「文档已更新」不能保证下游判断同步有效。
• 每次验证记忆都开启全新会话，并保留题目与预期答案，避免把同一段对话里的上下文能力误当成持久记忆能力。