上下文窗口是 AI 模型一次能装下的对话内容总量，它有上限。长任务推进中历史越攒越多，满了之后会发生什么？多数实现选择压缩：把旧对话摘要化，腾出空间继续。这本是工程上的权宜之计，但压缩有代价——旧决策可能在摘要里被悄悄丢掉，于是出现重复劳动、重新讨论已经定过的事。这篇把压缩机制讲透，给出三类遗忘表现的识别方法，再讲用 HANDOFF.md 主动交接代替被动压缩的做法；窗口容量的基础概念见上下文窗口一篇打底。
压缩机制：摘要替换原文
压缩的运作方式可以概括成摘要替换：上下文接近上限时，系统把较早的对话轮次浓缩成一段摘要，放进上下文开头，原始对话被替换掉。摘要保住的是主干——任务目标、近期的重要决定；让位的是细节——具体的代码片段、中间的报错、被否掉的方案。问题就出在这：哪条信息重要，由摘要算法判断，不由你判断。它觉得不重要的早期设计决定，可能正是你后面要依赖的前提。机制上这与上下文污染同源：留在上下文里的内容持续影响后续输出，被丢掉的则彻底失去影响力，两者的差别只是信息去留的方向相反，污染的机制见上下文污染一篇。
| 信息类别 | 压缩后的去向 | 后续影响 |
|---|---|---|
| 任务目标、近期的重要决定 | 写进摘要，放在上下文开头 | 主线还接得上 |
| 具体代码片段、中间报错 | 随原始对话一起被替换掉 | 要复用时在上下文里找不回 |
| 被否掉的方案 | 归入细节，让位给主干 | 可能被重新摆出来讨论一遍 |
| 早期设计决定 | 去留由摘要算法判断 | 后面要依赖的前提可能已不在 |
遗忘的三类表现
表现一，重开决策：你明明在前面定过方案，它又把几个选项摆出来重新讨论一遍，好像那次决定没发生过。表现二，重复提问：交代过的背景信息——项目结构、依赖版本、命名约定——它再次来问，或者干脆用错。表现三，风格漂移：早期约定的代码风格、目录规范，越往后越不遵守，改着改着回到它自己的默认习惯。三类表现的共同根子是：相关内容在压缩中被摘要掉了，模型手里只剩一段不含这些信息的概要。判断是不是压缩导致，有个简单办法：/status 看一眼上下文占用，近期刚发生过大幅下降，基本可以对上号，命令用法见会话命令一篇。
表现出现后的补救
表现确认了，补救按三步走。第一步，把丢掉的决策补回去：在当前对话里用一段话重新声明关键约定，越具体越好——补的是决定本身，不用复述全部讨论过程。第二步，防止再丢：把反复需要的信息移出对话历史，写进 AGENTS.md 或交接文档这类每次会话都会加载的地方，长期约定不靠上下文长期记住。第三步，评估要不要换场：表现频繁出现，说明任务历史已经长到摘要保不住主线，另起会话带上交接文档，比在旧会话里打补丁便宜。持续撞上下文上限的超长任务，容量边界的讨论见开发场景上下文上限一篇。
HANDOFF.md：主动交接代替被动压缩
被动压缩是系统替你决定留什么，主动交接是你自己决定留什么。做法是在项目里维护一份 HANDOFF.md：每完成一个阶段，把当前状态写进去——完成了什么、定了哪些决策、下一步是什么、有哪些坑。开新会话时让 agent 先读这份文件，上下文从第一轮就是浓缩的精华，不需要靠压缩去换空间。它与压缩的分工很清楚：压缩处理必须连续的会话，交接处理可以分段的任务；能分段的任务优先分段，把压缩留给真正连续的长活。交接文件的通用组织方法见交接文档一篇。想让这套机制在团队里跑起来，可以让 DeepSeek 按你们的任务类型起草一份 HANDOFF.md 模板，再让 Kimi 扮演新会话的 agent 挑出模板里缺信息的条目，两轮迭代就能用。
压缩与遗忘速查
- 压缩即摘要替换原文，留什么由算法判断，早期决策可能被丢
- 三类表现：重开决策、重复提问、风格漂移
- /status 看占用骤降，可对上压缩发生的时点
- 补救三步：补声明、移出历史、评估换场
- 能分段的任务优先 HANDOFF.md 交接，把压缩留给连续长活
关于上下文压缩的三问三答
- 压缩是自动发生的吗？上下文接近上限时会自动触发，也可以用 /compact 主动触发；两处的具体时机与行为随版本有差异，以官方更新日志为准。
- 被摘要掉的代码还能找回来吗？对话上下文里找不回；已落盘的改动用 git 记录查，未落盘的只能把需求重新描述一遍让它再做。
- HANDOFF.md 和 AGENTS.md 什么关系？AGENTS.md 放稳定的长期约定，HANDOFF.md 放当前任务的进展状态，一个像员工手册，一个像值班日志。
