针对智能体记忆的删除请求

把派生关系图写下来，因为你真正要从中删除的是它。

团队应对删除请求时，针对的是他们心目中"那份数据"所在的存储——对话表。而在一个带记忆的智能体里，那张表只是一棵树的根，它下面的每一个节点都是一份键不相同的独立副本。

• 原始轮次。对话本身，按用户与会话为键。这是最容易的一份，也是多数应急手册唯一覆盖的一份。
• 嵌入向量。由这些轮次派生出来，通常以切片 ID 为键，存在另一套有自己备份的系统里。由个人数据派生出的向量仍然是个人数据；它不是匿名化，而把它当作匿名化，是这个领域里最常见的单一错误。为什么几何并不能把内容洗干净，见嵌入。
• 抽取出来的事实。被蒸馏过的语义记忆——"偏好公制单位""账户在 12 号升级"——由一趟抽取流程写下，在文本上已经不再像它来自的那一轮了。如果人名在归一化中被抹掉，按名字搜是搜不到它的。
• 滚动摘要。把许多轮压缩成一段话的产物。删掉其中一轮贡献者，摘要纹丝不动，仍然在陈述那一轮说过的内容。一个普通智能体到底跑着多少条这样的路径，见记忆写入路径架构。
• 图上的节点与边。关系型记忆把人当作一等实体来存，边上写着关系断言与有效区间——当事人字面意义上就是一个节点，而指向它的那些边，是别人的对话写下的。
• 下游语料。评测黄金集、被提示词优化器挑中的少样本池、微调抽取，以及分析数仓。这些正是逃过每一次删除作业的副本，因为没人把它们当成记忆。

在写入时就给每一件派生产物记下来源键。

这一页里的其余一切都是某一个决定的下游，而在你做这个决定的那天它几乎不花钱：派生流程一跑，就把它是从什么派生来的记下来。写了一年之后再回头补，是一场考古工程；在写入路径上做，就是一个字段。

• 在每条派生记录上存下来源 ID。每个嵌入、每条抽取事实、每段摘要与每条边，都带着生成它的那批轮次 ID——因而也带着当事人 ID。删除于是从一次语义搜索变成一次反向索引查找，这就是"一个真能跑完的作业"与"一个看起来像跑完了的作业"之间的差别。
• 带上当事人，而不只是账户。一通客服对话谈的是某位客户，但可能提到他的配偶、医生或同事。对话里被提及的第三方同样是数据主体，享有同样的权利，却没有属于自己的那一行。至少要给"抽取识别出了账户持有人以外的自然人"的记录打上标记，好让来自那个人的请求至少有得可答。
• 给派生过程本身、而不只是产出打版本。记下是哪个抽取器、哪份提示词产出了某条事实。删除后重建时，你需要复现除被移除来源之外的一切——而一个没有版本的抽取器，意味着重建会悄悄把无关的记忆也改掉。
• 让记忆层的 ID 变成你的 ID。如果某个托管记忆产品分配的是它自己的不透明 ID，就在你自己的数据库里把它们映射到你的来源 ID。否则你的删除能力，就取决于一家厂商的搜索会不会在一份你无法检视其形态的数据上，如你所愿地工作。

让派生状态可重建，然后靠重建来删除。

对派生产物做外科手术式的删除，基本上做不到。你无法从一段摘要里减去某一轮，也无法把一个向量"反平均"回去。可解的做法是别再试：把派生记忆当作原始层之上的一层缓存，从原始层删除，然后重建。

• 重建是原语，打补丁才是例外。把来源集合与被删轮次有交集的每一件派生产物全部丢弃，然后在没有它们的情况下重跑派生。这很枯燥、可验证，并且产生的正是"当事人从未开口过"时本应存在的那个状态。
• 在承诺期限之前先给重建量个规模。法定回应窗口以周计，所以一次要几小时的重建没问题，要一个月的就是合规问题。在生产量级上实测一次，把你的那个数字记住。如果全量重建不可行，就缩小范围：只重建受影响用户的那个分区——这本身就是"一开始就按当事人给记忆分区"的一条论据。
• 接受连带损失，并为它做设计。一段在缺了某位参与者轮次的情况下重建出来的摘要，对所有共享它的人来说都是一段不同的、略差一点的摘要。这是正确的结果，也是"只要产品允许就优先按当事人给记忆划作用域、而不是塞进共享大块"的理由。
• 显式处理共享记忆这种情况。在多个智能体之间共享的记忆块、团队级知识与组织级作用域，装着由一个个可以各自要求删除的个人所贡献的事实。事先决定"一条组织级事实在提供它的那个人离开后是否存续"，把决定写下来，并让答案在产品里可见，而不是在一次请求过程中才发现。
• 绝不指望模型去"忘掉"。指示智能体别提某件事是一句提示词，不是一道控制。只要那个事实还检索得到，一场足够执着的对话就能把它检索出来——这与记忆投毒防御把执行点放在模型之下而非模型之内，是同一个理由。

在时序图谱里，更正与删除是往相反方向拉的。

建立在时序知识图谱之上的记忆系统，为了准确性做了正确的事：某个事实变了，旧的边被标记为历史而不是删掉，于是智能体可以推理"当时什么是真的"。这个性质与"删除"直接冲突，而且很容易在毫无察觉的情况下就这么上线了。

• 在 API 层面区分这两种请求，而不是在应急手册里。"这条错了，改一下"是更正，应当让一条边失效但保留历史。"把我删掉"是删除，必须移除节点、它的边，以及它们的历史版本。一个只有一个 delete 动词的系统，会悄悄用前者去回应后者。
• 墓碑是证据，而关于一个人的证据就是个人数据。一条写着"关于当事人 X 的那个事实已于 3 号删除"的墓碑，恰恰重新识别出了你被要求移除的东西。把删除记录以假名引用放进审计日志里，而不是放进记忆图谱——"运行记录"与"内容"的这条分界线，审计追踪里已经画过了。
• 由别人断言出来的边，描述的仍然是当事人。如果另一位客户的对话生成了一条点名此人的边，删掉当事人自己的轮次，那条边照样立着。删除必须沿入边遍历，而这种遍历只有在第 2 步做过的前提下才可能。
• 图重建默认不是幂等的。在少了一位参与者的语料上重跑实体消解，可能把实体合并或拆分成另一个样子。把消解用的模型与提示词和抽取器一起钉住，理由相同，不做的后果也相同——那一步有多敏感，见 Graph RAG。

记忆厂商手上有你看不见的副本，而 trace 是另一个问题。

多数团队并不自己造记忆层。一个托管记忆产品，是一个按它自己的时间表持有你用户数据派生副本的处理者，而它与你技术栈其余部分之间的那条边界，正是删除作业们去世的地方。

• 要求一个以你的当事人 ID 为键的删除 API，并且实测它。不是提工单，也不是整个命名空间批量清空。然后去验证：为一个合成当事人写入一条事实、删除它，再通过该产品暴露的每一条读路径去查——包括那条不按标识符匹配的语义搜索。
• 问清楚这次删除对他们的派生状态做了什么。一个会抽取、摘要与提升的记忆产品，有着和你一样的派生关系图。"已删除"经常意味着那条记录没了，而吸收了它的那段摘要还在。把答案要成书面的，因为义务仍然在你这边。
• 把备份、副本与厂商自己的日志钉清楚。一个月甚至更长的备份窗口是正常的，只要有文档就站得住——没有文档的那种就是一条发现项。任何跨区域复制同理，那同时也是一个数据驻留问题。
• 把记忆与 trace 放在两条不同的轨道上。trace 是"系统做了什么"的记录，受保全义务、法定下限与法务保全约束；记忆则是智能体明天还要据以行动的内容。它们需要不同的留存答案，而且彼此冲突——trace 那一侧见留存与法务保全，包括"一项保全挡住了你已经受理的删除"这种情形。
• 把每一个记忆存储都登进台账。你忘掉的那个存储，就是让请求失败的那个存储。记忆后端应当和模型、工具一样，带着指名的责任人与有文档的删除路径，出现在智能体台账里。

一次拿不出证据的删除，就是一次没有发生的删除。

监管者的问题，以及客户的问题，都不是"你跑没跑那个作业"，而是"给我看"。删除是少数几项"证明本身就是交付物"的运营能力，而把证明内建进作业里，远比事到临头再去拼凑要便宜。

• 为每次请求输出一份清单。动了哪些存储、每个存储里多少条记录、重建了哪些派生产物、调用了哪些厂商及其返回，都带时间戳。这就是你要交出去的那份产物，而在作业里生成它只需要十行代码。
• 每季度用一个合成当事人做一次端到端演练。把一个假人从真实流程里灌进去，直到他出现在原始轮次、向量、一条抽取事实、一段摘要和一条图上的边里。然后走正门提交一份删除请求，事后把每一个存储都搜一遍。每一家做过这件事的机构，都至少会找出一个没人记得的存储。
• 验证时要做语义搜索，不能只按键搜。这一整页的前提就是：派生产物丢掉了标识符。一份 grep 用户 ID 的验证会顺利通过，而那段摘要里仍然写着这个人的名字。
• 给队列埋点，而不只是给结果埋点。相对于法定窗口的完成耗时、已经超过窗口一半的积压请求，以及按存储分的失败率。一条在某一个存储上静默失败的删除流水线，在审计之前和一条正常工作的流水线是分辨不出来的。
• 在被问到之前，先把做不到的那些情形写下来。如果个人数据进了微调后的权重，删掉源记录并不能移除它的影响；诚实的答案是"在抽取那一步有一道有文档的过滤器"，外加一份针对受影响检查点的处置计划。不可原谅的版本，是在回应过程中才发现这件事。

相关：数据治理讲这一切所依赖的分级，记忆的类型讲每一层到底装着什么，委托访问与同意记录讲当初是什么权限把数据放进去的，以及记忆框架横评讲四个生产级记忆层在这条轴上的差别。