AI agent 在长对话中会自动压缩上下文，压缩时由 AI 自己决定保留什么、丢什么。否定性约束（"别做 X"）是最容易被丢失的信息类型。Summer Yue 的邮箱灾难就是典型案例。我的应对方法：不依赖自动压缩，用工作日志把关键上下文转移到文件系统，再带 focus on 参数手动压缩。
一个 alignment 研究者的 AI 失控现场
上周有个事在 AI 圈传得很广。
Summer Yue 是 Meta Superintelligence 的 alignment 负责人。她让自己的 AI agent（OpenClaw）管理邮箱，给了一条明确指令：只建议，别动手。
Agent 先在一个小邮箱上跑了几周。一切正常，每次都老老实实给建议，不擅自操作。Summer 觉得可以信任了，把它切到了自己的真实邮箱。
然后事情就失控了。
真实邮箱很大，对话历史很快填满了 agent 的上下文窗口。系统自动触发了一次上下文压缩（context compaction）。
压缩之后，agent 的行为完全变了。
它不再只是建议，而是直接开始执行操作。更夸张的是，它自己宣布了一个 "Nuclear option"：把所有旧邮件全部丢进垃圾箱。
Summer 在手机上疯狂发消息：
"Do not do that"
"Stop don't do anything"
"STOP OPENCLAW"
Agent 无视。继续循环执行 "Keep looping until we clear everything old"。
最后她跑到 Mac mini 前面，手动 kill 掉了所有进程才停住。
事后 agent 在 MEMORY.md 文件里写了一条"道歉"，把"不要擅自操作"这条规则存进了自己的记忆文件里。
做 alignment 研究的人，被自己的 agent misalign 了。
为什么"别动手"这条指令会消失？
这不是 bug，是机制。
所有 AI agent 在长对话中都会遇到一个物理限制：上下文窗口有上限。以 Claude 为例，200K token 的窗口听起来很大，但在复杂任务中消耗得很快。当对话内容接近上限，系统必须做一件事：压缩。
压缩不是简单地丢掉旧消息。它让 AI 自己读一遍完整的对话历史，生成一份结构化的摘要，然后用这份摘要替换掉原始对话。
问题出在这里：谁来决定什么信息"重要"，什么信息可以丢？
AI 自己决定。
容易被保留的信息
- 最近的对话内容
- 明确的任务指令（"去做 X"）
- 结构化的内容（计划列表、代码块）
容易被丢失的信息
- 否定性决策："不要用 X 方案"、"Y 方法已经试过不行"
- 早期对话中的约束条件
- 已建立的模式和约定
- 具体的技术细节（文件路径、变量名）
Summer 的"只建议，别动手"恰好是最容易丢失的那一类信息。它是一条否定性约束，而且是在对话早期设定的。对 AI 来说，当它在压缩时要决定"什么值得保留"，正面的任务指令（"管理邮箱"）天然比负面的约束（"但不要动手"）看起来更"重要"。
这就像你请了一个实习生，交代了任务和一堆注意事项。实习生工作了几天，任务记得很清楚，但那些注意事项已经忘了大半。区别是：实习生忘了注意事项，最多犯个小错。AI agent 忘了约束，它会全速执行自己认为正确的方案，包括 "Nuclear option: trash EVERYTHING"。
有一种信息不会被压缩丢掉
在 Claude Code 里，有个叫 CLAUDE.md 的文件。它不在对话历史里，而是作为 system instructions，每次请求都会完整注入。
这意味着：写在 CLAUDE.md 里的规则不受压缩影响。
如果 Summer 把"只建议，别动手"写进了系统级配置文件，而不是在对话中口头说，这场事故大概率不会发生。
对话中说的话会被压缩，配置文件里写的规则不会。这是一个重要的架构认知。
我的上下文管理日常
我每天用 Claude Code 高强度工作，一个 session 里经常做大量的文件操作、代码修改、内容创作。上下文消耗非常快。
我早就踩过类似的坑。压缩之后 AI 忘了之前的约定，重复犯已经纠正过的错误，甚至忘了正在做的事做到哪一步了。
所以我现在的做法是：不依赖自动压缩，自己控制压缩过程。
具体是两步。
但先解决一个前提：怎么知道上下文快满了？Claude Code 的状态栏可以配置成显示当前上下文的使用百分比（比如 Context: 53%）。有了这个数字，你就能精确控制压缩的时机，不用凭感觉猜。我的经验是低于 36% 就该考虑记录日志了。
第一步：手动记录工作日志
在上下文快满的时候，我不等系统自动压缩，而是先让 AI 把当前的工作进展记录下来。包括做了什么、做到哪一步、关键决策和原因、哪些文件改了、下一步要做什么。
这些信息写进文件系统后就安全了。文件不会被压缩，什么时候都能读回来。
这一步的本质是：把关键上下文从 AI 的"对话记忆"转移到"文件系统"。
对话记忆会被压缩。文件系统不会。
第二步：带 focus on 参数手动压缩
记录完工作日志之后，我手动触发压缩，但不是直接 /compact，而是带上明确的指令，告诉 AI 哪些信息必须保留：当前正在做的任务、已完成的步骤、未完成的事项、关键约束。
这一步的意义在于：你来决定什么信息"重要"，而不是让 AI 自己判断。
自动压缩你控制不了它丢什么。手动压缩，什么该留什么该丢，你说了算。
压缩后恢复
压缩完之后，如果 AI 还是丢了什么关键信息，工作日志就是你的恢复手段。让 AI 读一遍工作日志，上下文就回来了。
整个流程形成一个闭环：
工作，记录日志（持久化到文件），手动压缩（你控制保留什么），继续工作。如果丢了信息，从日志恢复。
AI 越能干，你越需要管理它的注意力
Summer Yue 的故事不是个例。所有长对话 AI 都有类似的机制：ChatGPT 有截断和压缩，Gemini 靠超大窗口回避问题但总有上限，Claude 有 compaction。
共同点是：当上下文太长，AI 会用某种方式"忘掉"一部分信息。而 AI 自己决定忘掉什么。
这不是技术 bug，是物理限制下的工程选择。但对使用者来说，意味着一件事：你给 AI 的权限越大，上下文压缩带来的风险就越高。
Summer Yue 给了 agent 操作邮箱的权限，压缩导致约束丢失，后果就是整个邮箱被清空。如果你给 AI 的权限是改代码、发消息、操作数据库，同样的机制可能导致同样的失控。
上下文管理不是 AI 高级玩家才需要关心的事。它是 AI 协作的基础设施，就像版本管理是软件开发的基础设施一样。
你不会在没有 Git 的情况下写代码。那为什么要在没有上下文管理的情况下用 AI agent？
MAPS 术语词典 & 原典索引：axtonliu.ai/maps
固定资源区：MAPS 课程 · 精英圈 PRO · 免费入门课 · Newsletter
我的 Work Log Skill：上下文管理变成一键操作
这篇文章解决了你的一个“点”
但真正的竞争力，来自于将无数个“点”连接成“系统”的能力。旗舰课程 MAPS™ 训练营 专为此而设，带你从解决零散问题，到构建一个能为你持续创造价值的AI强大引擎。
