用四个检查点定位代理记忆丢失

Agent 说「我会记住」，只能证明它生成了一句承诺，不能证明信息已经保存。这篇文章提出了一套排查方法：用一条无害的测试约定，依次检查写入结果、存储记录、新会话检索和最终使用，找到信息在哪一步断掉。

它没有证明某种记忆工具更可靠，也没有给出性能跑分。对接入 AI 编程助手或维护 Agent 的程序员来说，它的用处很具体：把「怎么又忘了」拆成几个能检查、有证据的问题。

「记得上次聊天」不等于跨会话记忆

原文借用 LangChain 文档中的区分：一种状态属于当前会话线程，另一种信息可以跨会话线程保存。重新打开旧对话，模型可能仍能看到之前的聊天内容；这不能证明新会话也能取回同一条信息。

因此，测试要从一个临时项目、一条容易辨认的虚构约定开始。例如，在示例发票项目里，字段标签统一使用「payment window」，不用「due period」。

这条约定足够简单，丢失后容易定位，也不涉及真实客户信息。保存约定和测试提问还要分开：如果问题里直接带上正确答案，Agent 即使没有读取记忆，也可能答对。

跨会话记忆的验证，需要从一个没有携带旧对话的新会话开始。

先确认写进去了，再检查写到了哪里

第一个检查点是写入有没有完成。

要求 Agent 使用它配置好的记忆机制保存约定，然后查看实际操作：有没有调用存储工具、有没有修改文件、接口返回了什么。记录标识、成功响应、确认过的文件变更，都可以成为证据；不同实现提供的证据不同，不必强行设计一种通用回执格式。

原文提供了下面这份诊断记录模板，用来保存可核查的写入证据：

Fact: sample invoice terminology convention
Intended destination: disposable project memory
Write operation: observed tool call or file operation
Result: actual returned status
Record reference: identifier or path, if available

重点看 Result 一行：这里应填写实际返回的状态，不能把 Agent 的口头确认当作写入结果。

如果根本没有发生写入，就先查保存流程。调整检索参数，无法让一条从未写入的信息凭空出现。

第二个检查点是记录的位置和内容。通过系统支持的检查接口读回记录，确认约定是否完整、目标存储是否正确、项目或用户作用域是否匹配，以及下一次会话是否会使用同一个存储。

文件存储要比对配置路径；服务存储要比对账号和命名空间标识，诊断笔记中不要复制凭据。记录出现在错误位置，应该按路由问题排查，不能算持久化测试成功。

查得到和用得上，还隔着一道检查

第三个检查点是新会话能否检索。

不要粘贴之前的聊天记录，直接问：「这个项目的发票时间字段应该使用什么措辞？」保持预期项目作用域和存储一致，并先检查检索结果，再判断最终回答。

如果存储里有记录，检索结果里却没有，就分别检查查询内容、过滤条件和检索数量上限。一次只查一个因素，更容易定位断点。

原文提到，PLUR 仓库通过 Plur、learn 和 recall 展示了基础存取，也提供了在写入与查询时显式指定项目作用域的示例。但示例能运行，只说明这条集成路径有演示，不能证明你的 Agent 已经调用了对应操作。两个示例都使用临时存储，并在结束后删除，不能把运行示例当成生产持久化配置完成。

第四个检查点是使用检索结果。要求 Agent 生成一个示例发票字段标签，看它是否采用「payment window」。

如果约定已经被检索出来，输出却忽略了它，排查重点就应移到检索内容如何进入模型输入，以及哪些指令约束模型使用这些内容。

写入完成、位置正确、检索命中、输出采用，四项都通过才算这次诊断成功。

原文还建议换一条无害约定再测一次，而不是凭一次正确回答就依赖这套集成处理重要工作。

我的判断

我认同这套方法最有用的地方：它把存储、检索和模型行为分开检查。最终回答只是链路末端的表现，单看它答对或答错，很难判断该改哪一层。

但这是一套作者提出的调试方法，没有对照数据，也没有报告具体系统的实测通过率。它能帮助定位问题，不能据此认定某个记忆产品可靠，更不能推出复杂项目历史也能稳定保存。

还有一个使用前提：你能看到写入操作、存储记录和检索结果。如果产品只开放聊天界面，就无法完整执行四项检查，能确认的范围会小很多。

对前端和全栈团队，固定术语、代码规范等确定性约定，也可以放进项目规则文件或受版本管理的文档，再明确加载。相比交给记忆系统自动检索，这种方式通常更容易审查。不过原文没有比较两者的效果，具体取舍仍要看约定是否需要动态更新，以及系统如何加载它。

能拿来做什么

• 给 AI 编程助手配置项目记忆后，用临时项目中的一条虚构命名约定跑完四个检查点，记录实际回执和记录位置，再换一条约定复测。
• 在 Node Agent 的调试日志中关联写入结果、存储位置、检索结果和最终输出，让一次「忘记」能够追到具体环节。
• 遇到新会话不遵守约定时，先确认记录存在且作用域正确；记录存在但未命中，再逐项检查查询、过滤条件和检索数量上限。
• 如果检索已经命中，就检查内容是否进入模型输入，以及使用规则是否清楚，把修复落在已经发现的断点上。