考察点
这道题出自字节跳动 Agent 开发实习一面（2026 年牛客面经），是 coding agent 长任务场景的必问题。模型上下文窗口再大，一个跑半小时的编码任务也能撑爆，所以面试官想看的是你有没有真的处理过这个问题：压缩策略是不是拍脑袋的一层摘要，还是分层设计；阈值怎么定；以及最难的一问——压缩是有损的，你怎么知道压过头了、压坏了怎么办。这一问答得好，说明你有真实的线上/实验观察，不是纸上谈兵。
参考答案
为什么压缩必须分层
长任务里上下文的增长速度是不均匀的：一次 grep 可能返回几千行，一次测试跑完输出几百行日志，而真正需要长期保留的往往只有任务目标、关键决策和几个文件路径。如果只用一个"快满了就整体摘要"的策略，要么压得太晚（触发时已经丢过请求或报错），要么一刀切把还热乎的细节也压没了。分层压缩的思路是按信息的新鲜度和重要度区别处理，让损失发生在最不值钱的地方。
三层压缩的具体做法
第一层：工具输出的即时处理。 在工具结果进入上下文那一刻就动手，不等。规则是机械的：单条工具输出超过阈值（比如 2000 token）就截断，保留头尾、中间省略；文件读取默认分页而不是全量返回；grep 类结果超过 N 行时改成返回"匹配数 + 文件分布统计 + 前几条样例"。这一层是零模型成本的确定性逻辑，能挡掉 80% 的上下文膨胀。
第二层：阶段性摘要。 每当任务完成一个子目标（比如"定位 bug 原因"完成、准备开始改代码），把刚结束这个阶段的过程性对话压成一段结构化小结：做了什么、结论是什么、留下了哪些待办。过程细节（试错路径、中间报错）丢弃，结论保留。这相当于给上下文做 checkpoint，跨阶段后模型只需要知道"结论"，不需要"怎么得出的"。
第三层：临近上限的整体压缩。 设一个水位线（我用的是窗口容量的 80%），触线后触发一次整体 compaction：保留最近若干轮原文不动，把更早的历史压缩成一个结构化快照——任务目标（用户原话）、当前状态（改了哪些文件、跑到哪一步）、关键决策与约束、待办清单、重要指针（文件路径、错误码、trace ID）。Claude Code 的 auto-compact 也是类似思路。快照用结构化格式而不用自然语言段落，因为结构化内容更抗二次压缩的变形。
压缩过度怎么发现
压缩是有损的，发现"压坏了"主要靠三类信号。一是行为信号：压缩之后 agent 开始重复问已经确认过的问题、重新读已经读过的文件、推翻了之前定好的方案——这些是典型的信息丢失症状，我在 trace 里重点盯着看。二是主动探测：压缩完成后立刻让 agent 用一两句话复述任务目标和当前状态，答不上来或答错了说明关键信息丢了，这一步成本极低但很有效。三是离线评测：固定一组长任务，对比不同压缩策略下的任务成功率，把"压缩"当成一个可调参的模块去测，而不是当成不可见的黑盒。
压坏了怎么处理
补救分事前和事后。事前的核心是关键信息白名单：用户原始需求、明确的约束条件（"不许动这个接口"）、正在修改的文件清单、未解决的错误原文，这些不进压缩管道，要么原文保留在上下文，要么外置到文件里（上下文只留指针，agent 需要时用工具读回来）。实践中"外置到文件 + 指针引用"是最稳的，文件不会丢，模型按需取。事后补救是可回溯：压缩前的完整历史落盘存成日志，发现信息丢失时支持 agent 用搜索工具回查历史，把压缩从"不可逆删除"变成"冷热分层"。
可能的追问
阈值 80% 是怎么定的？ 经验值，留 20% 余量是为了容纳压缩动作本身需要的输入输出和后续几步正常工作；模型输出窗口小的要留更多。本质是 trade-off：触发太早浪费窗口，太晚可能单次压缩输入就放不进去。
为什么不用模型直接判断"哪些重要"来压缩？ 可以，但成本和延迟都高，而且判断本身也会出错。机械规则兜住量大且明显低价值的部分，模型摘要处理需要理解的部分，分工使用最划算。
压缩和 RAG/外部记忆怎么配合？ 压缩管"热"上下文，外部记忆（文件、向量库）管"冷"知识；压缩时把可能要用的细节写入外部记忆并留指针，两者通过指针机制衔接，别搞成两套互不知情的系统。