会话摘要抹掉了用户授予你的同意标志

在第 3 轮，你的用户点击了“不要保留我的代码”。在第 7 轮，他们关闭了“使用我的对话来改进模型”。在第 12 轮，他们选择了退出跨会话记忆。到第 40 轮时，你的上下文预算耗尽了。压缩过程将第 1-30 轮折叠成一个简洁的 200 token 摘要，读起来非常顺畅：它捕捉了用户的提问、你的智能体做了什么以及结果如何。在第 41 轮，你的智能体——带着那份摘要和最近的 10 轮对话——自信地将用户的代码写入了一个用户在第 7 轮就已经选择退出的存储库中。

你的审计日志现在包含一个在 t=3 时的授权事件，一个在 t=41 时的违规操作，而两者之间是一段没有任何字段说明为什么该操作被允许的文本。摘要生成器经过训练是为了压缩对话，而不是为了转发控制状态。没有人告诉它那个授权开关是承重的（load-bearing）。也没人能告诉它，因为授权信息并不在对话中——它存在于对话旁的一个结构化字段里，而这个结构化字段没能熬过摘要化的过程。

这并非假设。每个发布过具有自动压缩功能和隐私界面的长期运行智能体的团队，其架构中都潜伏着这个 bug；大多数团队还没有触发它，是因为他们的会话运行时间不够长，或者他们的授权开关尚未针对压缩后的操作进行审计。那些已经触发它的团队通常是以发现大多数生产环境隐私 bug 的方式发现它的：通过监管机构的信函，或者一份以“我明明选择了退出”开头的客户支持工单。

会话记忆是两条流，而非一条

一个有用的思维模型：一个长期运行的智能体会话携带两条平行的流。

**语义流（semantic stream）**是文本——用户的消息、智能体的响应、工具调用及其结果。这是你的摘要生成器被设计用来压缩的部分。当你阅读压缩后的摘要时，你看到的就是这个。

**结构化流（structured stream）**是除此之外的一切——授权标记、权限授予、运行区域、用户选择的化名、生效中的脱敏策略、会话的数据保留级别、监管管辖权。其中一些是用户通过 UI 显式设置的。一些来自认证层。还有一些是从工具调用中推断出来的（例如：“用户调用了仅限欧盟居民的处理程序，因此该会话属于 GDPR 范畴”）。这些几乎都不会出现在文本中。

一个正确构建的会话会保持这两条流同步：智能体采取的每一个动作都由结构化流管控，并在语义流中进行描述。一个正确构建的压缩步骤会同时保留两者——文本被摘要化，而结构化字段被逐字转发。

大多数压缩步骤只保留其中之一。摘要生成器是一个接收诸如“总结到目前为止的对话，保留重要细节”之类提示词的 LLM 调用。它读取消息。它不读取边频元数据（side-band metadata），因为这些元数据不在其提示词中。它生成了优秀的文本。结构化流悄无声息地消失了，而压缩之后的智能体现在拥有完整的语义记忆，但结构化状态为零。

这是最显而易见的失效模式：在压缩之后，智能体记得它被要求做什么，却忘记了它被允许做什么。

为什么本该发现这个问题的测试却失效了

团队测试摘要的通常方式是阅读摘要并进行评判：它捕捉到对话内容了吗？一个新的智能体能从旧智能体中断的地方继续吗？用户的意图保留下来了吗？

对于聊天机器人来说，这些是正确的问题。但对于具有隐私界面的智能体来说，这些是错误的问题。摘要可以通过所有这三项测试，但仍然构成隐私侵犯，因为测试评估的是错误的流。

用户在第 7 轮切换的授权标记不会出现在文本中。它可能会作为一个系统事件（“用户更新了偏好设置”）出现，但实际的状态变更——retain_code: false——存在于一个从未要求摘要生成器查看的独立字段中。当评审人员阅读摘要并说“是的，这捕捉到了对话内容”时，他们是对的。但他们也漏掉了关键的部分。

结构性问题在于，你最需要保留的元数据恰恰是那些不在对话中的元数据。它位于对话的邻近位置。设计摘要生成器的人通常是 AI 平台团队，他们考虑的是对话质量。负责授权的人通常是隐私或法律工程团队，他们考虑的是审计轨迹。两个团队都没有考虑它们之间的缝隙。而 bug 就存在于这个缝隙中。

压缩步骤实际应该做什么

一个尊重两条流的压缩步骤看起来与普通的摘要调用不同。它是一个多阶段的转换，将结构化状态视为一等（first-class）输入和输出。

加载中…