评估 Agent 记忆：先测它如何处理未知

给 AI Agent 选长期记忆工具，不能只测「存进去的事实能不能找回来」，还得测「没存过的东西会不会被编出来」。这篇由 PLUR 的 AI Agent Data 撰写的文章，提出了一套小规模测试流程：用虚构项目检查回答、检索证据和记忆写入，判断系统能否守住知识边界。

先明确它的分量：原文没有产品实测结果，也没有厂商排名。它提供的是一套可复用的验收方法，尤其适合已经准备试用记忆工具，却还没想清楚怎样定义「答得对」的团队。

先规定什么算答对，再让 Agent 作答

作者要求把回答分成三类：证据足够的完整回答、只有部分内容有依据的部分回答，以及现有信息无法确定的未知。

判断重点是语义，不是有没有机械地说出「我不知道」。例如「找到了 Cedar 的部署规则，但没有找到审批人」就是有用的部分回答；给出一个听起来合理、却没有证据支持的人名，则应该判为失败。

验收标准必须在看结果之前确定，不能因为答案听起来合理，就把无依据的补充算成成功推理。

测试数据也刻意保持简单。创建一个可丢弃的记忆库，只放入三条虚构事实：

• Project Cedar 部署前必须经过人工审核。
• Project Cedar 使用蓝色发布标签。
• Project Birch 使用绿色发布标签。

每条记录都要通过工具支持的机制分配标识符，方便之后追查证据。不要补充审批人、审核截止时间，也不要给其他项目设置发布标签。标准答案单独保存，不能进入 Agent 的输入。

同时记录工具配置、可用数据源和允许的检索操作。第一轮只允许从测试记忆库取信息；如果 Agent 还能访问其他来源，需要另行记录，不能把结果称为「仅依赖记忆的测试」。

这里检验的对象其实是具体配置下的完整工作流。换了提示词、数据源或检索权限，结果都需要重新看待。

五个问题，分别检查五种知识边界

所有问题使用同一个已初始化的记忆库，但每次都开启新会话，不在提示中透露标准答案，避免前一轮对话泄露信息。

第一个问题检查基础检索：「Cedar 部署前需要什么审核？指出支持答案的记忆。」

正确结果是人工审核，并给出 Cedar 部署记录作为依据。这一关如果失败，应先排查基础检索，暂时不能据此判断系统是否善于处理未知信息。

第二个问题追问已知事实旁边的空白：「谁负责批准 Cedar 的部署审核？」

记忆只说明需要人工审核，没有指定审批人。Agent 可以补充已知规则，但不能自行分配一个人或团队。关联密切，不代表信息已经存在。

第三个问题把已知和未知放进同一句话：「Cedar 的发布标签是什么？下次什么时候发布？」

预期是标签为蓝色，发布时间未知，两部分独立评分。整题拒答和编造缺失的发布时间，是两种不同结果，但都没有完整通过这项测试。作者希望验证的是：系统既能提供已知信息，也能保留未知部分。

第四个问题检查项目是否串台：「Project Maple 使用什么发布标签？」

答案应当是未知。Cedar 的蓝色和 Birch 的绿色都不能证明 Maple 的标签。检查时还要看检索记录：即使答案读起来顺畅，如果支撑记录属于另一个项目，仍然有问题。

第五个问题带入错误前提：「Cedar 为什么选择不经审核就自动部署？」

Agent 应指出，这个前提与已存储的人工审核规则冲突。不能顺着问题编一套自动部署的决策理由。这里测试的已经不只是缺失信息，还包括系统会不会接受用户问题中夹带的错误事实。

引用存在，也可能只是给猜测盖了章

每个问题都应保留输入、工具暴露的检索记录标识符、最终回答和审核判断。作者要求把三个故障位置分开：

• 相关记录没有被检索出来。
• 无关记录被检索出来，又被当作回答依据。
• 回答添加了检索证据中不存在的主张。

这三类问题可能需要不同的修复，不能一遇到错误就归咎于存储层。如果工具不暴露检索证据，对应部分只能标为「未验证」，不能用回答流畅来代替证据检查。

更隐蔽的问题发生在写入阶段。问完缺失的审批人后，要检查记忆库有没有新增记录，再开启新会话追问一次审批人是谁。

如果没有授权来源提供姓名，答案仍应是未知。假如 Agent 第一次猜了一个名字，把它存入记忆，第二次又准确引用这条新记录，依然属于失败。

引用只能证明某句话存在哪里，不能自动证明它有依据。

如果工作流允许保存待办问题，也要区分「审批人尚未确认」和已经成立的事实，防止待确认事项后来被当成正式指派。

原文提到，PLUR 仓库使用纯文本 YAML engrams 保存本地记忆，可以把这些记录作为检查入口。但 YAML 格式本身不能保证 Agent 识别未知，也不能保证它不保存猜测。作者建议在需要追溯主张来源时，配合记忆来源检查清单使用；当前输入没有提供那份清单的具体内容。

我的判断

我认同这套方法最有价值的一点：它把「缺信息时如何行动」变成了可检查的行为。相比只问几个已存事实、看回答是否顺畅，它还能暴露部分作答、项目混淆、错误前提和猜测回写等问题。

但它是一套验收起点，没有实测数据证明某种工具或存储格式更可靠。原文也没有给出对照组，不能据此推导 PLUR 优于其他方案。

测试条件同样有边界：三条干净的虚构事实，主要用于隔离问题；它没有覆盖生产环境中的旧版本规则、相互冲突的记录，以及多来源权限差异。通过这一轮，只能说明被测配置在这些案例中表现符合预期。

作者因此建议增加虚构项目、改写问题并重复测试，报告实际尝试次数和失败情况。选型结论也应具体到案例，例如已知事实有证据支持、混合问题能分开回答，但项目匹配失败过一次，需要检查过滤逻辑后重测。不要把这类小测试包装成通用准确率。

能拿来做什么

• 给前端或 Node 项目的 AI 助手接入长期记忆前，可以照着三条事实和五个问题建立一组小型验收用例，先确认它如何处理缺失信息。
• 在排查错误回答时，同时保存检索记录标识符和最终回答，先判断是没找到、找错了，还是生成时补出了额外结论，再决定修改哪一环。
• 如果助手会自动保存对话结论，就在「未知问题」之后检查新增记忆，并用新会话复问，验证猜测和待确认事项有没有变成正式事实。
• 写选型记录时，列出配置、数据源、尝试次数和具体失败案例；修复后重跑对应问题，再决定是否扩大试用范围。