那个因无人负责而逃过租户删除清理的智能体记忆库

合规计划是对审计员签字通过当天你公司所拥有系统的描述。你公司今天的系统是另一套完全不同的组合，而这两者之间的差距，就是从那时到现在期间每一个上线了新持久化存储的发布版本的表面积。你向客户承诺的删除保证是针对第一套系统的保证，而最终对此进行询问的监管机构，问的将是第二套。

这种失败模式并非删除代码中的 Bug。删除代码本身是正确的。Saga 流程会扇出到数据清单中命名的每一个存储系统，调用每个系统的删除端点，收集每个系统的回执，并在每个回执都返回已签署状态时报告成功。Saga 正在准确执行其被构建时所承担的任务。问题在于，Saga 迭代的是一份 18 个月前的存储系统列表，而智能体平台团队在 6 个月前上线了一个长期记忆功能，却没有任何人将其添加到该列表中。

这就是摧毁删除保证的鸿沟：“哪些系统存储了租户数据”的权威记录系统与“存在哪些系统”的权威记录系统是不同的产物，由不同的团队维护，且遵循不同的更新节奏。当两者达成一致时，删除 Saga 是完整的。当两者不一致时，删除 Saga 仅针对 清单所描述的世界 是完整的，而非针对现实中存在的那个世界。在监管机构询问之前，这种不一致性是不可见的。

清单是快照，而非实时索引

大多数数据清单都是构建一次、审计一次，然后便被期望通过“社会契约”来保持准确性。合规计划始于一场研讨会，会上每个团队都会梳理其存储系统，由分析师将其录入电子表格或 GRC 工具中。电子表格会根据 Schema 注册表进行审查，审计员对覆盖范围签字确认，清单随即成为“该产品使用了哪些存储系统”的权威答案。更新过程是一个手动工单：当你上线一个新的持久化存储时，你应该向合规团队的 Backlog 提交一个工单，而他们应该在清单中添加一个条目。

更新过程的失败方式与所有跨团队手动流程的失败方式如出一辙。负责上线存储系统的团队有冲刺截止日期。合规团队有任务积压。工单被提交，被列为“日常维护”优先级，并排在本季度审计准备工作的后面。几个月过去了。下一季度的合规审查无法发现这个缺口，因为审查是将清单与上一次审计进行核对，而不是与生产环境核对。清单在内部是自洽的，但在外部却是错误的。

让问题更加复杂的是，在 AI 密集型产品中，最常见的新存储系统恰恰是那些最不可能被申报的系统。带有 tenant_id 列的关系型数据库会立即被列入清单，因为 Schema 审查会强制执行这一点。而一个通过合成的智能体会话 ID（agent-session-id）作为键，并通过另一个单独的表关联到 tenant_id 的向量存储，在审查员看来，更像是一个内部缓存。一个存储智能体状态的 KV 存储，工程师在设计文档中将其描述为“临时工作内存”，实际上却因为逐出策略为了优化检索质量而被保留了六个月。这些都不会被申报，因为它们看起来都不像是个人数据的权威记录系统，而且负责上线的工程师也不具备识别它们属于此类系统的合规词汇量。

Saga 流程针对给定的清单成功执行

删除 Saga 是架构正确性的典范。它读取配置（清单），迭代其条目，使用租户 ID 调用每个系统的删除端点，等待确认，并将回执汇总到最终报告中。该 Saga 是可测试的、可重试的且可观测的。每个步骤都会发出指标。操作手册非常清晰。当 Saga 报告成功时，On-call 工程师可以安心回床睡觉。

Saga 的正确性恰恰是问题所在。由于 Saga 针对其输入是正确的，因此删除操作悄然失败的地方位于该 Saga 负责的任何代码的上游。这里没有异常，没有失败的回执，也没有指标异常。Saga 向审计日志写入了一条干净的记录，显示“租户 X 在所有系统中已删除”。这份审计日志正是法务团队向监管机构出示的内容。监管机构读取日志，看到一条清晰的轨迹，调查便继续进行。多年后，当另一场审计（通常是来自不相关客户的 DSAR，由于偶然在智能体响应中出现了相关租户的片段）暴露了这个缺口时，法务团队的第一个问题是“删除操作运行了吗？”审计日志说是。向量存储说“差不多吧”。而这两个答案之间的对账，正是无人认领的灰色地带。

这就是再次重申的“合约 vs 实现”差距：合约规定“我们根据请求删除”，Saga 实现了“我们调用清单中每个系统的删除操作”，而合约与实现之间的差距正是清单与现实之间的差异。大多数团队并没有一个专门的岗位来消除这一差距。他们会有季度审计来重新认证清单，但审计查看的是清单中 已有的 内容，而不是清单中 本应有却缺失 的内容。审计在结构上无法发现它所不知道的存储系统。

加载中…