考察点
这道题是 Agent 长程任务落地的核心难题。面试官想确认三件事：你知道有哪些压缩手段、各自的取舍是什么；你理解「压缩是有损的」、过度压缩的症状是什么；你有发现和兜底的工程方法，而不是压完就不管。追问常往「摘要 prompt 怎么写」「KV cache 和成本」「具体阈值怎么定」走。
参考答案
为什么必须压缩
长程 Agent 跑几十轮循环，每一轮都会往上下文里追加工具返回——一个网页抓取结果可能几千 token，十轮下来轻松冲破 100K。就算模型支持长上下文，问题也有三个：token 成本线性甚至超线性增长，长上下文下模型注意力稀释、中间信息丢失（lost in the middle），以及 KV cache 命中率下降推高时延。所以压缩不是可选项，是长程 Agent 的标配。
主流压缩手段
按无损到有损排个序：
1. 工具结果掩码（observation masking）：性价比最高的一招。工具返回原文只在它被消费的那一两轮有用，之后就可以替换成一句话占位（如「[已抓取 36氪 页面，提取到融资金额 2 亿美元]」），原文归档到外部存储，需要时可以再调回来。 Claude Code 这类产品对较早的文件读取结果就是这么处理的。这招能砍掉长程任务里的大头，因为工具返回通常占上下文 60% 以上。
2. 分层截断：系统提示和任务目标永远保留，最近的 N 轮原文保留，中间的做处理。丢也要有优先级，不能简单先进先出——用户开头说的约束条件往往是全文最重要的信息。
3. 摘要压缩：超阈值后把早期历史交给模型压成摘要。摘要 prompt 是关键，要要求模型保留：已确认的事实、用户明确表达的需求和约束、已完成步骤及结论、未解决的待办。写成流水账的摘要等于没压。
4. 学习型压缩：LLMLingua 这类方法用小模型在 token 级别删冗余词，压缩率高且不需要目标模型参与，但对结构化内容（代码、JSON）效果不稳，生产上用得没前三招多。
5. 结构性外置：釜底抽薪的做法——中间产物（代码文件、调研笔记）写进文件系统或 scratchpad 工具，上下文里只留路径和摘要，Agent 需要时按需读回。这其实是把「压缩」变成「分页」。
压缩过度的症状与发现
压缩是有损的，压过头会出现几个典型症状：
- 目标漂移：跑着跑着偏离了原始需求，开始做自己发明的任务——因为任务目标被压没了。
- 失忆性重复：重新调用已经调过的工具、重新问用户答过的问题——已完成的步骤记录丢了。
- 约束违背：用户开头说「预算 500 以内」，后面推荐了 800 的方案——约束在摘要里被抹掉。
发现手段分三层。离线回归：攒一批长程任务的评测集，每次改压缩策略跑一遍，盯任务成功率，这是最可靠的防线。在线指标：监控压缩触发后的错误率变化，比如重复工具调用率、用户纠正率（「我刚才说过了」出现频率），这些指标异动往往先于成功率下降暴露问题。错误归因：失败 case 复盘时专门检查「模型决策所需的信息是否在压缩时被丢弃」，把这类失败单独归类统计——如果「压缩丢信息」类失败占比上升，就是压过头了。
压过头怎么处理
短期止血：调保守参数——提高触发压缩的 token 阈值、保留更多最近轮数、把用户原始需求固化到系统提示里永不被压缩（这是性价比最高的单点修复）。结构修复：从「全文摘要」改成「滚动摘要 + 结构化状态」，把任务目标、已确认约束、待办清单抽成结构化字段单独维护，摘要只负责叙述性内容；关键工具结果不做语义摘要，做字段级提取（保留金额、日期、结论，丢掉正文）。兜底机制：原始内容归档到外部存储，Agent 发现信息不足时可以通过工具「回忆」——把不可逆压缩变成可逆的换出。
经验法则是：压缩策略的 aggressiveness 要和任务容错度匹配。闲聊随便压，代码和数据分析这类精确任务要保守，宁可多花钱也别丢信息。
可能的追问
追问：压缩阈值怎么定？
不拍脑袋，按模型有效上下文能力定，而不是按标称窗口定。很多模型标称 128K，实际在 32K-64K 之后注意力就明显衰减。从窗口的 50%-70% 开始触发渐进式压缩是常见起点，再用离线评测集调优。
追问：摘要导致的信息丢失怎么量化？
做「探针测试」：在长上下文里埋入若干关键事实，压缩后逐一提问验证还在不在。丢失率高的摘要 prompt 迭代优化。生产上也可以抽样跑这个检查作为质量监控。
追问：上下文压缩和 RAG 有什么关系？
互补。压缩解决的是「已经在上下文里的东西太多」，RAG 解决的是「需要的东西不在上下文里」。成熟架构两者结合：上下文里保持精简的工作状态，历史和外部知识都外置成可检索存储，按需拉取——本质上把整个上下文管理变成一个内存分页系统。