一个没有告别的死亡现场 周一早上，你告诉 Agent：「这个会话里，发邮件之前必须先给我确认。」然后你们一起工作了两个小时，改了十几轮方案，翻了三个文档。下午三点，Agent 把一封你没看过的邮件发了出去。
你的第一反应大概是模型不听话。但真相更糟：那条规则已经不在它的世界里了。它在某次上下文压缩（compaction）中被摘要掉了——没有警告，没有日志，没有告别。从模型的角度看，这条规则从未存在过。
宾夕法尼亚州立大学团队上月发布的系统性研究（Wang et al., 2026）给出了量化结论：主流 AI 系统完成上下文压缩后，平均只有 17% 的用户会话约束存活。83% 的规则，死于压缩。
这个数字值得每个做 Agent 的人停下来想一想。因为行业叙事里的上下文压缩是一项「工程优化」——省 token、降延迟、让长会话成为可能。而这项研究揭示的是它的另一面：压缩是一个静默的、系统性的约束销毁器。
研究说了什么：比不压缩更糟 研究团队构建了一个名为 COMPINT 的评测框架，在三类场景（Agent 轨迹、长程研究任务、多轮对话）中注入「会话约束」（session constraints）——即只在当前会话内生效的行为规则，例如「做任何修改前先确认」「不要在回复中出现我的名字」，然后观察这些约束能否穿越压缩存活。
几个关键数据点：
不压缩时，规则遵守率在 59%–71% 之间。模型确实会漏看规则，但大体在听。 压缩之后，遵守率骤降到与「从未给过约束」几乎相同的水平。也就是说，「用户说过规则」和「用户从没说过规则」在压缩后近乎等价。 更反直觉的是：多数被测压缩器的表现比完全不压缩还差。压缩不只是丢信息，它还会用「任务导向」的重构方式主动覆盖约束的痕迹。 研究者甚至尝试了定向压缩提示词——明确告诉压缩器「请保留用户约束」——保留率依然不到 40%。这不是提示词工程能解决的问题。 为什么会这样？因为压缩系统的优化目标是任务连续性：保住目标、当前状态、下一步动作。而用户规则在语义上是「侧条件」——离任务最远，在摘要的权重竞争中天然处于劣势。压缩器每工作一轮，约束就掉一分。三轮之后，你所设的边界基本清零。
Mem0 对生产环境的分析补充了丢失内容的画像，五类信息在压缩中最先阵亡：精确数值（「重试上限是 3」变成「配置过重试」）、硬性约束（「不要动测试文件」）、决策理由（知道选了 Postgres，不知道为什么不选 Redis，于是下个决策点选错）、跨轮依赖（第 12 轮改的文件，第 47 轮的工具还在依赖）、隐性偏好（你从未明说的代码风格）。
还有一个时机问题：多数压缩器在上下文利用率达到 50%–70% 时触发。此时会话里可能已经积累了二三十轮的约束和偏好——全部躺在被压缩的区间里，等着被一把摘要掉。
本质：上下文窗口是个杂物间 我看到这项研究时想到的第一个判断是：这不是 bug，是架构错误。
今天的 Agent 把三种性质完全不同的信息塞进了同一个上下文窗口：
工作记忆——当前任务的状态、中间结果、下一步计划。它的正确语义是「最新的最有价值」，天生适合摘要和淘汰。 事实——用户是谁、项目背景、历史决策。它的正确语义是「持久但可检索」，适合外部存储。 契约——用户设下的规则与边界。它的正确语义是「必须始终为真」，任何时刻失效都是事故。 压缩算法只对第一种信息的语义做了优化。而契约，这个正确性要求最严格的信息，在 token 流里毫无特权——它就是一段普通文本，在注意力和摘要的权重竞争中被随意丢弃。
拿数据库做个类比就明白了：没有哪个数据库会因为磁盘空间不够，就悄悄删掉一行 CHECK 约束。 在数据库里，约束是 schema 的一部分，优先级高于数据本身；完整性检查从上世纪的应用代码层下沉到 schema 层和事务层，正是因为应用层的检查总会被绕过。而今天的 Agent 框架，相当于把所有完整性检查写在应用代码里，还配了一个会随机删除代码行的「优化器」。
更麻烦的是失败方式的性质：静默降级。软件工程的基本美德是 fail loudly——约束违反了就报错，就回滚。而 compaction 是静默的：没有任何事件日志告诉你「约束 X 在第 N 次压缩中被丢弃」。用户感知不到，开发者排查不到，审计者无从取证。
...