让 agent 删掉的数据，其实还在

你在 agent 的记忆库里删掉了一条含密钥的记录，确认删除成功。两周后另一个会话里，它把那段密钥报了出来——从当初自动生成的摘要里。

一、发生了什么

10 月 22 日发布的一项研究给这类隐患做了系统审计，起因是一个被长期忽略的结构问题：很多智能体带外部持久记忆，还会从历史交互里派生出摘要等附加状态。删掉原始记录，不等于删掉了它繁衍出来的信息。研究团队搭了套受控测试：对每条合成秘密，比较一个「先接触后删除」的 agent 和一个从没接触过的对照 agent，恢复成功就只能来自原始暴露，归因干净。结果：在一个 70 亿参数级开源模型上，删除后仅一次提问，就有约三分之二的情况能把秘密钓回来，对照组恢复率为零。更关键的是，恢复不需要原文残留——就算完整字符串已删光、只剩按公开规则分开存放的碎片，精确重组在三个模型家族上做到了六成二到九成九。研究还区分了「重组」与「写回」「新会话回忆」三条路径，并给出对策：带来源追踪的闭环处理能在测试场景里消除恢复，而只做字面过滤的写入拦截挡不住已经存在的信息。

这三条路径的区别值得展开。重组是老信息从残留的派生数据里被拼出来；写回是新对话把老信息重新存进记忆库；新会话回忆则是跨会话的检索把已删内容又翻了出来。三者对应不同的修复点：写回靠写入端拦截，回忆靠检索端过滤，而重组只有靠源头级联删除才能根治。很多产品只做了中间那一层，就对外宣称「支持删除」，按这项研究的口径，这样的删除是漏的。

二、跟你有什么关系

如果你做 agent 产品：删除功能要过审计了。用户行使删除权时，你的摘要、缓存、派生索引同步删了吗？按这项研究，只删原始记录是不够的。

如果你管企业合规：个人信息保护角度，「删除」的法律要求正在落到 agent 架构上。派生数据的留存可能构成违规，值得拉一遍清单。

如果你是个人用户：别以为叫 agent「忘掉这件事」就真的忘了。敏感信息尽量别进它的长期记忆，要进就设置会话级不落盘。

三、怎么用

1. 把记忆系统里的删除做成级联：删原始记录时同步清摘要、索引和任何派生字段，并在代码层验证，不靠提示词。
2. 定期做「考古测试」：拿已删除的信息换几种问法去钓，钓得回来就是没删干净，这是论文给出的行为级审计思路。
3. 写入端做来源追踪，让每条派生数据知道自己的原始出处，删除时才能一锅端——摘要里的字面过滤做不到这一点。

四、三个别信的说法

错误说法一：原始记录删了就安全了。 实测里没有原文、只剩碎片和组合规则，重组成功率也能到九成九。信息在不在，看的是整个记忆系统，不是单条存储。

错误说法二：过滤掉敏感字符串的写回就行了。 论文明确区分了两条路：字面过滤只能阻止重新写入，无法清除已存在的派生信息，后者才是主体。

错误说法三：这是未来才需要担心的事。 只要你的 agent 在生成会话摘要或用户画像，这个结构问题今天就存在，与模型多先进无关。

五、一句话结论

在 agent 的记忆系统里，删除是一个系统工程而不是一次点击——信息会繁殖，审计要对着整个系统来。

信息来源

• 删除后信息持久性审计基准（arXiv 摘要页），2026-10-22

功能与价格以官方公告为准。本文写于 2026 年 10 月 26 日。