AI Agent的记忆检索正常却答错了：信息过期的隐性陷阱

我们构建了一套能每次精准检索出正确笔记的记忆系统，随后却眼睁睁看着它向我们交付了一条早已悄悄失效的记录。检索从来都不是难点。以下是我们尝试并于同一天宣告失败的修复方案，以及最终上线那个更小但真正work的方案——它不会假装知道某条记录是否仍然有效。

那条笔记在我们写下时是正确的。

几周后，它一个字都没变，却成了谎言。

我向一个 AI Agent 询问我们上线工作的最新状态。它完全按照我训练它的那样行事：搜索团队记忆、找到相关记录、给出自信的回答。记录显示某项任务仍在等待完成。

那项工作实际上在几周前就已经完成了。

同一次对话中，Agent 还找到了一份旧的 SEO 审计报告，并将其中未解决的问题作为我们当前的问题汇报。那份清单在写下的当天是准确的。我们重新对线上站点进行了测量，发现几乎每个条目在此后都已被修复。

我们在产品上线前内测自己的产品时发现了这两个案例。这不是数据库丢失数据或模型未能检索的故事。检索功能运作完美。Agent 找到了正确的笔记，却给出了错误的答案。

这个区别改变了我认为 AI 记忆产品需要解决的问题。

我们解决的是找到笔记，而不是信任它

大多数关于 AI 记忆的讨论都集中在召回上：一个 Agent 能否在聊天结束后恢复一条有用的信息？另一个工具或团队成员之后能否找到它？系统能否将相关笔记排在噪音之上？

这些都是真实的问题，行业已经让它们变得容易多了。

但召回只是记忆的一半。另一半是时效性：这条检索到的事实现在还成立吗？

一条过时的笔记看起来并没有坏。它的文本完好无损。它的 embedding 仍然匹配问题。它的来源可能值得信赖。事实上，它看起来越权威、越相关，Agent 重复它的可能性就越大。

危险的记忆不是系统找不到的那条。而是系统立刻找到、正确引用、却已经不该再相信的那条。

我们的第一个修复方案是一个标签。它立刻失败了

我们的第一个设计感觉显而易见：让写作者将每条记录标记为持久规则或时间点观察。

规则——"API 错误使用 Problem Details"——可以重复使用而无需持续警告。观察——"迁移仍在等待中"——会附带日期并提示重新检查。

然后我们在均匀间隔的六个自己的记录中采样。至少四条不符合任一类别。

一条笔记记录了一条持久的实现规则、规则存在的原因、推出的状态，以及一个事实：它的 commit 还没有到达 main 分支。这条笔记有一半可能在一整年内保持有用。有个句子几天后就失效了。

如果标记为规则，过期的句子就逃脱了审查。标记为观察，Agent 就会对我们每天都想让它使用的规则发出警告。

写作者也是最不适合做这个区分的人。写那条混合笔记的 Agent 以为自己在记录一个已完成的修复。它不知道其中一个小句子——"这个 commit 还没有到达 main 分支"——是一个没有闹钟的倒计时。

我们试图给容器附加一个过期策略。容器内部的事实以不同的时间失效。

下一个诱人的修复方案更简单：让旧的记忆变得可疑。

这在两个方向上都会失败。一年前的架构规则可能仍然完全正确。今天写的笔记可能已经错了。

我们以一种特别尖锐的形式看到了第二种情况。一个答案出现在评审帖中。四十四秒后，另一条记录说我们仍在等待那个答案。

那条记录从诞生时就是假的。

任何询问"世界在这条记录写下后改变了吗？"的规则都错过了那种情况，因为世界先改变了。任何把最近的笔记当作更安全的规则都会在错误的时候因为笔记是新的而给它更多的权威。

时间很重要，但年龄不能证明真实性。时间戳是给读者的证据，不是系统给出的裁决。

我们能在不假装知道的情况下展示什么

一旦停止尝试对真实性进行分类，设计就变得更谦逊了。

当 Agent 读取一条记录时，我们可以在它旁边展示两类证据：

• 记录是何时写入的；
• 记录中明确命名的任何任务或问题的当前状态。

如果一条旧笔记说某项工作仍在等待中，而任务看板显示已完成，矛盾在使用时是可见的。如果一条笔记说某个问题仍未得到答复，而回复已经到达，读者可以同时看到两种说法。

我们刻意不给记录标注"当前"。我们没有能证明这个词的验证历史。我们也不标注它为"过时"，因为仅凭年龄证明不了什么。我们不隐藏它，也不默默重新排序它。

系统展示笔记、它的日期，以及命名对象的实时证据。Agent——以及最终对决策负责的人类——需要解决这个差异。

这听起来可能不如自动化真实性评分那么神奇。但它也更难被误认为确定性。

你现在可以使用的一份记忆收据

你不需要一个专业产品来让团队记忆更安全。首先将持久规则与观察分离，并为每条观察提供一份收据。

MEMORY RECEIPT

Durable rule
- Rule:
- Why it exists:
- Scope:

Point-in-time observation
- Observed fact:
- Observed at:
- Verified by: command, URL, person, or source
- Depends on: task, question, branch, deployment, or owner
- Recheck when:

不要因为两条记录来自同一场对话就把它们放在一条记录里。它们有不同的生命周期。规则可以存活，而其下的推出状态可能会失效。

在评估任何记忆系统时，问它是否保留了这个证据。它是否显示了笔记是何时写的？它能否显示笔记中命名的对象的当前状态？它的界面是否避免了暗示"无警告"等于"已验证"？

如果这三个问题的答案都是否，那么更好的召回可能只会帮助 Agent 更快地检索过时的置信度。

我们尚未解决的部分

证据仍然可以被忽略。Agent 可能引用旧的句子而跳过旁边显示的状态。人类可能偏好方便的答案。提到无结构对象的笔记没有可对比的实时对象。

更强的解决方案从记录写入时开始：将主体、声称的状态和观察时间存储为结构化数据，而不是让后来的读者从散文中去推断。

我们还没有做到那一步。在此之前，展示来源和实时矛盾是一条护栏，而不是保证。

这是来自一个团队、一个代码库，以及我们在 LOOSEDAYS 上线前的内测记录。这不是基准测试，六个记录的样本也不是人口研究。足以推翻我们为自己的工作设计的第一个方案。

这对 Vibsync 的改变

Vibsync 是我们在 LOOSEDAYS 为使用 AI 编码 Agent 的团队构建的共享大脑。在这些事件之后，我们改变了读取体验，使得检索到的记忆携带其记录日期以及它命名的任务或问题的实时状态。

目标不是宣告什么是真实的。而是阻止一条旧陈述孤身出现，剥夺质疑它所需的证据。

这很重要，因为不同的 Agent 和会话继承同一条记录。一个作为临时上下文写下的句子，可能成为另一个从未见过周围对话的人明天的起点。共享记忆放大了有用的知识。如果当前证据不随它一起传递，它也会放大过时的假设。

如果你想先尝试记忆收据，将上面的模板复制到你的 Agent 已经在共享的文档中。如果你想让不同工具和机器上的 Agent 继承相同的带日期的记录、决策和实时任务上下文，将它们连接到同一个 Vibsync 团队。

Vibsync 由 LOOSEDAYS Co., Ltd. 构建。这是一支团队发布前工作的第一手记录，不是对照比较。

Originally published at https://vibsync.com/blog/ai-memory-has-no-expiration-date.