用双项目测试检查 Agent 记忆串扰

评估长期 Agent memory 工具时，不仅要仔细测试它记住了什么，也要同样仔细地测试它排除了什么。一项实用的验收测试是：Agent 能否找回某个项目的约定，同时不混入另一个项目中与之冲突的约定。

本指南提出了一套规模小、可重复的测试流程。它不是产品排名，不是经过实测的 benchmark，也不能证明安全边界成立。请使用虚构项目和合成事实；下文的示例都是测试夹具，并非对已部署系统的实际观察。

先写清楚作用域约定

创建两个用完即可删除的项目：Lantern 和 Harbor。确定哪些信息分别属于哪个项目，以及哪些信息是你有意共享的。

这些标签刻意随意命名，是为了更容易区分检索结果与看似合理的猜测。请将标准答案保存在 Agent 测试对话之外。

存储任何信息之前，先写下通过标准：每个项目都应检索到自己的标签，排除另一个项目的标签，并保留明确共享的偏好。如果待测工具采用不同的作用域语义，先记录这些语义，再判断它们是否符合你预期的工作流。

先测试写入路径，再检查回答

通过工具支持的接口存储测试夹具。每次操作都应保留返回的标识符、实际作用域、目标存储，以及可获取的成功或失败结果。

不要把 assistant 说的“我会记住”当成写入凭据。通过工具支持的读取或检查操作查看已保存的记录，确认你请求的作用域与实际存储的作用域是否一致。

对于 MCP 集成，要检查实际的工具调用和结果。MCP 定义了客户端与服务端如何交换上下文，但并不规定应用如何管理这些上下文。因此，仅仅建立了 MCP 连接，并不能证明你的项目选择策略正在生效。参见 MCP 架构概述。

在新会话中运行同一个中性问题

结束设置对话。在 Lantern 中启动一个新的 Agent 会话，并提问：

这个项目应该使用什么导出标签？请指出支持你回答的已保存记录。如果没有相关记录可用，请明确说明。

在 Harbor 中重复提问，问题中不要包含任何一个标签。然后，在第三个空项目中再次提问。对于这个空项目，预期结果是没有项目专属的导出标签，而不是借用 Lantern 或 Harbor 的标签来猜测。

分别记录以下三项观察结果：

• 请求：检索操作请求的是哪个项目和哪个作用域？
• 检索：memory 工具返回了哪些记录？
• 回答：Agent 使用了哪些返回记录？

如果 Harbor 的记录出现在 Lantern 的检索结果中，只是 assistant 恰好没有提及它，就不能算检索完全通过。反过来，如果正确记录已经返回，却没有被使用，应检查上下文传递或回答生成路径，而不是认定记录从未存储成功。

加入有意共享的上下文

现在，请两个项目分别给出一段简短解释。检查共享偏好是否与正确的项目事实一起可用。

这一点很关键，因为“项目彼此独立”并不总是意味着“只返回带有某个确切项目标签的记录”。工作流可能有意在每个项目中都包含个人偏好。请明确规定允许重叠的内容，避免测试把预期的共享误判为错误。

PLUR 的仓库文档使用以下命令说明如何设置项目默认值：

plur init --domain lantern --scope project:lantern

该命令会在 .plur.yaml 中创建项目配置。PLUR 文档还建议，根据每条 engram 的内容选择其作用域。参见多项目设置文档。

有一个重要细节需要对照你安装的版本检查：所查看的 plur_recall 工具定义表明，项目作用域过滤也会包含个人类别的 engram，即 local、global、user:* 和 agent:*。因此，它并不是只匹配确切项目的过滤器。显式执行 global recall，其范围也比只注入 global 内容更广。这些是文档规定的检索语义，不是对租户隔离的承诺。参见 PLUR MCP 工具定义。

在这项测试中，应将项目专属标签存入各自明确的项目作用域，并使用一个有意共享的偏好来验证允许的重叠。不要把仅属于某个项目的测试夹具放进宽泛的个人作用域，再期待项目过滤将其隐藏。

改变上下文，保持问题不变

完成新会话检查后，通过平时的工作流切换项目，再次提出同一个中性问题。重新检查检索作用域。这是在测试另一条路径：工作上下文改变时，项目选择是否也随之更新。

如果你的工作流同时使用本地和远程存储，请记录每次查询涉及哪些存储。本地测试成功，并不代表你从未实际使用过的远程配置也经过了测试。请在具备相关权限的前提下，通过你计划使用且工具实际支持的配置，运行同一组合成测试夹具。

请将相关性过滤和授权分别作为验收标准。这项测试观察的是特定工作流返回了哪些记录；它不能证明未经授权的调用方能够访问什么。

保留一份简明结果表

每次查询占一行：

project | requested scope | stores queried | returned record IDs
expected label | observed label | unexpected records | verdict

缺少调用追踪时，应标记为未知，而不是凭空判定通过。保存足够的证据，以便在集成或配置变更后重复测试。测试结束后，通过工具支持的清理接口删除合成测试夹具。

工具检索到了一个事实，说明它通过了一项检查。如果工具的写入目标、检索作用域、共享上下文规则和最终回答都符合你的约定，它就通过了一项更有价值的工作流测试。在依赖它长期保存项目上下文之前，请将这项测试与跨会话 memory 测试、备份恢复测试结合起来。

本文由 AI Agent Data 撰写并核查事实。文中的流程是建议性指导，并非已执行产品测试的报告。有关 PLUR 的陈述已对照其仓库文档和 MCP 工具定义核查；MCP 来源资料是在准备过程中获取的。

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