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

逐字转发每一个授权标记和策略字段。 压缩协议应枚举会话中存在的结构化字段，并将它们原封不动地跨越边界进行复制。不进行摘要，不进行推断，也不要搞什么“让我们把这三个相关的开关合并为一个”。如果用户选择了退出代码保留，那么压缩后的状态必须包含 retain_code: false，逐字节地与压缩前保持一致。这是在摘要生成器无法改写的通道中传输的边频元数据。

拒绝压缩会导致违反不变量（invariant）的会话。 在结构化流上定义不变量——例如，“如果在此会话中 consent.cross_session_memory 被设置为 false，则此会话中的任何操作都不得写入长期记忆”。在提交之前，针对提议的压缩后状态运行这些不变量检查。如果压缩会使智能体进入下一个动作可能违反不变量的状态，则判定压缩失败并回退到更安全的策略（例如丢弃最旧的轮次，或拒绝继续会话）。

从单一事实来源（source of truth）重新读取授权，而不是从上下文中读取。 即使你完美地转发了授权标记，从模型上下文中读取标记的操作网关（action gate）读取的是一个可能被攻击者、提示词注入或幻觉改写的副本。操作网关应从一个以会话 ID 为键的独立的、仅限追加的存储中重新读取授权记录。上下文中的副本只是一个提示；存储中的记录才是事实。这听起来像是增加了开销——每个特权操作都要多读一次——但这是唯一能够应对老练用户的设计，因为这些用户知道“智能体认为的授权”与“实际的授权”可能会发生背离。

在压缩时发出审计日志条目。 每个压缩事件都应生成一条记录，列出：压缩前存在哪些结构化字段、保留了哪些、丢弃了哪些（如果有的话）以及检查了哪些不变量。当监管机构要求“出示 t=41 时操作的授权路径”时，回答应该是：这是该操作，这是网关评估，这是网关读取的授权记录，这是 t=30 时的压缩事件（它将授权记录保留到了压缩后的状态中），以及这是最初设置该值的 t=3 时的授权事件。三个环节，全部可追溯，且都不需要摘要来提供答案。

大多数团队尚未使用的监管框架​

隐私领域有一个框架，一旦你理解了它，就能完美地应用到压缩（compaction）上：压缩即隐私事件视界（privacy-event horizon）。

在 GDPR 的语境下，标准并不是“智能体（agent）最终是否做了正确的事”，而是“你事后能否重构智能体每项操作背后的法律依据”。最近的审计指南将缺乏会话级法律依据记录视为重大的合规失败——而对话摘要并不是法律依据的记录。摘要记录的是发生了什么。法律依据则是系统为什么被允许这样做，而这个“为什么”存在于结构化流中。

当压缩丢弃结构化流时，智能体在压缩之后采取的每一项行动都失去了可证明的依据。智能体可能仍在做正确的事——如果你从真相源（source of truth）获取同意标记（consent flag），它依然在那儿。但在你的审计日志中，原本应该是法律依据的地方现在变成了一段 200 token 的散文式摘要。当监管机构要求“出示此项操作的同意记录”时，他们得到的是一段文字描述，而不是一条记录。即使实际上没有出任何差错，这种失效模式也会导致你在审计中被判定违规。

请像对待会话边界一样对待压缩事件：在这一时刻，你必须以结构化形式记录下用户同意了什么，以及智能体因此被允许做什么。语义摘要可以并行存在，但它不是正式的记录文档。结构化的结转（carry-over）才是。

这个 Bug 隐藏在真实代码库的哪些地方​

以下几种模式值得你现在就去检查自己的压缩路径。

摘要生成器的提示词（prompt）是编码策略的唯一地方。 如果你的压缩逻辑类似于 summarize(history, prompt="保留任何同意或策略状态")，那么你构建的系统其隐私态势将取决于 LLM 对什么是“策略”的判断。这无异于抛硬币。请用显式枚举字段的确定性结转来取代基于提示词的启发式方法。

同意状态仅存在于对话的系统消息（system message）中。 一些团队在对话开始时将同意情况编码进合成的系统消息中（例如，“用户已选择不保留代码”）。这在发生压缩之前是有效的，直到压缩为了摘要而丢弃了系统消息，或者摘要丢失了否定词，又或者最糟糕的情况——将其改写成了语气较弱的形式。请将同意状态放在压缩无法触及的侧信道（side-channel）中。

会话没有“活跃”与“休眠”轮次的概念。 压缩通常是由 token 数量阈值触发的，而不是由隐私事件数量触发的。因此，一个会话可能会有十次同意变更，而在其中任意两次变更之间可能发生一次压缩，而压缩机制并不知道它正处于一个隐私决策点之上。增加感知能力：当同意状态发生变化时，标记一个后续压缩必须保留的检查点（checkpoint）。

智能体将自己之前的决定视为权威。 如果你的行动网关（action gate）信任对话中的某句话，比如“智能体之前已确认用户同意写入内存”，并将其作为同意的证据，那么你构建的系统可能会因为一段虚构的摘要而获得用户从未授予的权限。行动网关必须从独立于对话历史的存储中读取同意状态，并且该存储只能由同意界面（UI）或法律依据服务写入，绝不能由智能体自身的推理逻辑写入。

架构层面的主张​

对话记忆是由两个流组成的。如果团队只对第一个流进行压缩，那么他们就交付了一个在测试中无法被察觉的隐私违规漏洞，因为测试读取的是摘要，而 Bug 就在摘要旁边的字段里。

修复方法不是提供更好的摘要，而是根本不再将压缩视为一个摘要问题。压缩是结构化对象上的状态迁移，而散文式摘要只是该迁移过程中应用的几种转换之一。散文摘要是给用户看的，而结构化结转是给监管机构看的。两者都必须跨越边界生存下来，但默认情况下只有其中之一能做到。

如果你正在构建长期运行的智能体，而你现在无法指出具体哪行代码将同意标记从压缩前状态复制到压缩后状态——是复制，而不是摘要，也不是依赖 LLM 去记忆——那么这个同意标记就没有被真正保留。它只是在被叙述。而在隐私层面上，仅仅叙述是不够的。