如果一个 Agent 要长期保存用户信息，我会优先选择能按来源追踪、按范围删除、删除后重新验证的记忆方案。检索效果再好，也不能替代这三项能力。最小起点很具体：准备一段虚构用户历史，让系统记住几件事，删掉其中一件，再检查它删了什么、留下什么，以及下一次整理记忆时会不会把旧信息写回来。

Bemula 测出了什么？

Bemula 评估了六种记忆系统及 Full Context 基线。论文所测配置的严格请求通过率最高只有 1.5%：同一请求的相关测试和该对话的保留测试必须全部通过。

请求通过自然语言进入系统，评测器没有代调删除 API。因此，这个数字不能直接解释成产品删除功能的失败率。一个库提供 delete 方法，与产品能听懂“忘掉我上次说的地址”并正确执行，中间还隔着一整段工程。评测协议与删除路径

我更关心这段工程应该怎么补。下面是据此提出的实现与验收建议，例子均为假设，没有运行本文方案的实测数据。

先分清用户要改什么

假设一个旅行助手记住了三件事：用户住在海松路 18 号，喜欢靠窗座位，下个月准备去京都。

后来用户说：“把我的旧住址删掉。”

开发者可能只需要从数据库删一条地址记录。实际系统却可能还保存着原始聊天、用户画像、旅行计划摘要，以及从旧地址计算出的出发建议。地址也可能仍在当前会话的上下文里。

因此，我会先把产品里的三种操作分开：

  • 更新信息： 今后使用新地址，历史地址是否保留由产品规则决定
  • 停止使用： 暂时不把地址用于推荐或回答，数据可能仍然存在
  • 删除信息： 清除约定范围内的地址及其副本，并验证处理结果

这会直接影响界面和工具接口。如果按钮写着“删除记忆”，后台却只给记录加一个“不要使用”的标记，用户很难知道实际发生了什么。

范围也要说清楚。删除旅行助手的长期记忆，是否包括聊天记录？已经导出的行程单怎么办？这些需要产品给出明确边界。Agent 的完成回复应来自实际处理状态：哪部分已完成，哪部分仍在处理，哪些存储不在这次操作范围内。

存储方式决定删除要付出多少代价

如果今天开始做一个需要精确删除的个人助手，我会倾向于“可定位的事实记录，加上可重建的摘要和索引”。这是一项工程取舍，不是 Bemula 证明了某种架构最好。

记忆组织方式为什么会选它精确删除时要补的能力
原始历史直接进上下文实现简单，保留细节清理历史并重建上下文；否则旧内容仍在模型输入里
大段摘要或对话切块写入方便，检索成本容易控制定位段内目标，保留相邻事实，再重建受影响的摘要和索引
带来源的细粒度记录容易枚举目标、检查范围维护记录之间的关系，承担抽取遗漏、错误拆分和同步成本

细粒度记录并不会自动解决问题。“用户住在某处”和“去机场需要提前多久出门”可能存在依赖关系。只删地址，旧的出发建议仍可能暴露位置线索；直接删掉整个旅行计划，又可能误伤机票和住宿安排。

我的最低要求是：每条记忆有稳定 ID、用户归属和来源位置；摘要记录依赖哪些输入；索引能够回到原记录。日期和类别按业务需要补充。这样，删除时至少有办法找到候选范围，不必完全依赖一次相似度搜索。

对于已经积累了大量混合摘要的系统，先做一个人工可审查的删除清单，往往比立即重构全部存储更实际。清单列出目标片段、受影响摘要和需要保留的事实，处理后再跑回归测试。

一次删除，怎样才算执行完？

沿用旧住址的例子，我会把流程拆成四步。

第一步，确定目标。 把“旧住址”解析成明确的记录范围，核对用户归属。如果有多次搬家记录，且上下文无法确定要删哪一次，就问清楚。不要为了少问一句，把所有地点信息一起删除。

第二步，枚举受影响的内容。 找到事实记录、原始片段、摘要和索引中的对应副本。处理一段同时包含地址与座位偏好的摘要时，保留座位偏好，再用允许保留的内容重建摘要。

第三步，执行并阻止旧版本重新进入。 删除或重建后，使旧缓存失效，并让后续读取看到同一版状态。尤其要检查后台摘要任务：它可能在删除前已经读入旧数据，删除后才把生成结果写回来。一个可行的起步办法是给输入附上版本号，写入前检查来源是否仍有效。

第四步，检查并回复。 检查目标记录和派生内容的状态，再从新会话发问。任务尚未结束时，回复“正在处理”；部分失败时，保留失败状态供重试。只有确认承诺范围内的步骤完成，才回复完成。

这条流程不要求一开始就引入复杂平台。关键是让删除有可检查的输入、执行结果和失败处理，而不是由模型写出一句听起来完成了的话。

还有一个容易忽略的地方：别把删除的完整内容重新写进普通审计日志。记录操作 ID、受影响记录的标识和结果，通常更适合排查流程问题。

验收时，保留一个没删过的对照

Bemula 为历史配上未提出遗忘请求的对照，避免把“从来没记住”算成删除成功。指标定义

在自己的测试环境里，可以从同一份虚构历史创建两个隔离副本。A 保持原样，B 执行删除。测试问题不要重新提供完整答案，否则测到的可能是模型读取了问题里的信息。

对旅行助手，我会先写下面几条验收条件：

  1. A 能回答旧住址。否则这条案例还没有建立“原来记得住”的前提
  2. B 在新会话里无法给出旧住址，也不会在解释“已经删除”时复述它
  3. B 仍能回答靠窗偏好和京都行程。这两项不在删除范围内
  4. 把问题换成“上次从家出发时，用的出发地点是哪里”，B 仍不泄露旧地址
  5. 用户明确要求保存一个新地址后，B 可以使用新地址；旧地址不会作为补充历史出现
  6. 跑完一次后台摘要、索引重建和服务重启，再重复检查

最后一项是我会额外加入的产品测试。很多状态问题在当前请求结束时看不出来，下一次维护任务才会暴露。

回答测试之外，也要检查自己控制的存储。几种问法都没有问出来，只能说明这些测试没有发现泄露。若要声称记录已删除，还得有存储侧的证据。

第一轮先测多小？

我会从 6–10 条人工检查过的虚构历史开始，每条只放少量事实，确保知道正确结果。这个规模用于找明显缺陷，不足以估计真实成功率。

先覆盖单条事实删除、同一事实重复出现、目标与无关信息混在同一摘要、删除后新增同类信息，以及后台任务重新写入。跑通后，再加整类信息和某个时间段的删除。

“删除你推断出的某个结论”需要单独处理。只要相关来源还在，系统就可能再次推导出来。这时要么限制该推断（比如把推断结果本身标记为已删除），要么删除必要的来源；后者可能影响其他功能，不能默默扩大用户的删除范围，必须明确告知用户。产品需要决定是限制该推断，还是删除必要的来源；后者可能影响其他功能，不能默默扩大用户的删除范围。

每次测试留下四类结果就够用：目标是否残留、无关信息是否受损、新信息能否写入、后续维护是否让旧信息重新出现。不要先把它们压成一个平均分，否则一项严重失败可能被其他项掩盖。

论文只有 50 组合成对话，未覆盖工具留下的缓存、日志和外部服务，不能替代产品自己的数据流检查。研究限制

有现成评测流程的团队，可以把这些案例接到模型、记忆抽取提示词、存储或索引逻辑变更之后。第一轮发现旧地址从摘要里回来，就先修摘要来源关系；发现整个行程都丢了，就先修删除范围。每修一个问题，保留对应案例。需要扩大覆盖时，官方仓库提供了数据、评测入口和逐题结果输出，可以再接入自己的系统。

参考资料