上下文快满了：滑动窗口 / 摘要压缩 / 重要性过滤怎么选？压缩丢了关键决定怎么办？
谁在问：二面追问重灾区；做过长会话或长任务 Agent 的面试官会一路追到「压缩丢了约束怎么办」
口语化问法
- 跑长了上下文放不下，你们怎么处理？
- 摘要压缩听起来挺好，它会丢什么？丢了你怎么知道？
- 压缩之后模型忘了用户一开始说的预算上限，这种事怎么防？
考察意图
这是第 3 章追问最凶的一题，因为它有一个几乎所有人都会踩的坑：把压缩当成省 token 的手段。面试官在验四层：
- 知不知道压缩的目的是保决策质量。 就算窗口塞得下，长上下文本身也会让模型变笨（context rot），所以压缩不是等窗口满了才做的事。
- 说不说得出每种策略丢的是什么。 三个方案的名字谁都会背，能讲清"滑动窗口丢的恰好是用户最初的目标"才算想过。
- 有没有"该保真的东西不该活在对话历史里"这个认知。 这是本题的分水岭。
- 算不算得清压缩本身的成本。 压缩会重写上下文前缀，直接击穿 prompt 缓存——压得太勤反而更贵。
参考答案
60 分答案（及格线）
三种策略各有取舍：
| 策略 | 怎么做 | 代价 / 丢什么 |
|---|---|---|
| 滑动窗口 / 截断 | 只保留最近 N 轮 | 最便宜、零额外调用；但丢掉的恰好是最开始的用户目标和约束——那通常是整个任务里最重要的一条消息 |
| 摘要压缩 | 把旧对话交给模型压成一段摘要 | 保住语义主干；代价是多一次调用与延迟，而且有损且不可控——具体丢了什么你不知道 |
| 重要性过滤 / 结构化提取 | 按类型抽取该留的（目标、约束、已确认参数、已执行动作、待办），其余丢弃 | 可控性最好；代价是要设计 schema 和提取器，实现最复杂 |
实际生产里三者是混用的分层结构：锚定区（系统提示、用户原始目标与约束，永不压缩）+ 近窗（最近若干轮原样保留）+ 中间区（摘要或结构化提取）+ 外部化（大块内容落盘，上下文里只留一个引用句柄）。
90 分答案（有生产经验的回答）
补四层。
1. 压缩的目标不是最大压缩率，是"保住决策所需的最小充分信息"。 判断一次压缩好不好，唯一标准是：压完之后模型还能不能做出同样正确的下一步决策。所以我会先定义必须保真的五类信息，它们不参与任何有损压缩：
- 用户的原始目标与硬约束（预算上限、截止时间、不能用某方案）
- 已经确认过的参数与决定（是 3 月不是 4 月，选的是方案 B）
- 已执行的写操作清单（不然会重复下单、重复发邮件）
- 尚未解决的待办项
- 已经失败过的路径（漏了这条，模型会兴致勃勃地把刚试过的错误方案再试一遍——这是最容易被忽略的一类）
2. 一句分水岭级的判断：这五类信息不该活在对话历史里，应该活在状态里。 把它们放进一份结构化的任务状态（slot 表 / 约束清单），每次重建上下文时原样注入，压缩只作用于对话历史那一部分。指望"摘要的时候记得把预算带上"是靠运气；把预算放进状态、并且在动作执行前用代码校验，才是工程。
3. 触发时机和边界很关键。 不要等窗口满了才压——那时模型已经在低质量区跑了一阵了。按预算阈值主动压（经验上到窗口的六七成就该动手，具体看模型，需自测）。压缩点要选在自然边界：一个子任务结束后、工具结果消化完之后，而不是在一段推理链中间切一刀。
4. 压缩的成本坑：prompt 缓存。 压缩重写了上下文前缀，缓存直接失效，之后几轮都要按未命中计费。所以压得太频繁可能比不压还贵——正确姿势是"少次、大幅、在自然边界压"，而不是每轮修修补补。这一条能答出来，基本可以确认是真在长会话上算过账的。
5. 有损但可恢复。 压缩前把原文归档，摘要里保留指向原文的句柄，模型需要细节时能取回来（这正好对上 MCP 2026-07 无状态化之后"工具返回显式 handle"的范式，截至 2026-08）。这样压缩从"不可逆丢失"变成"降精度 + 可回取"，风险大幅下降。
追问链
具体说说你的分层方案，阈值怎么定？
期望系统提示 + 任务状态（约束、slot、已执行动作）常驻不压 → 最近 3–5 轮原样保留 → 更早的进摘要区 → 大体量工具结果与文档一开始就外部化成句柄。阈值按占用比例触发而不是按轮数（单轮体量差异极大），留余量别压到刚好塞下；稳定块放前面吃 prompt 缓存，易变块放后面信号给得出分区 + 比例触发 + 缓存友好布局 → 实现过；只答「保留最近 N 轮，其余摘要」→ 通用方案，没针对 Agent 的状态特性设计压缩后模型忘了早前说的预算上限，推荐了超预算方案，怎么防？
期望根本不该靠记忆守约束。三层防线：① 约束在识别到那一刻就提取进结构化状态，不参与压缩，每次重建上下文原样注入；② 关键动作执行前用代码校验（金额超限直接拦，不问模型）；③ 输出层比对推荐价格与状态里的预算，不合规就重生成或拒答。核心：模型可以忘，系统不能忘信号把约束从对话搬进状态、并强调用代码校验 → 工程思维；答「摘要提示词里强调保留约束」→ 还在靠模型自觉，这题就废了会话很长要反复摘要，对摘要再摘要会怎样？
期望会有复印机效应——每代都在上一代的有损结果上再有损，细节逐代漂移变形，最后模型手里的「事实」和原文对不上，还没人发现。① 摘要基于归档原文重建而不是叠加；② 限制摘要代数，到数就重建；③ 关键结论一旦结构化就不再进摘要循环；加分：拿状态槽位定期与原文核对信号能命名这个累积失真现象并提出「基于原文重建」→ 遇到过；答「多摘要几次没什么问题」→ 没跑过真正的长会话什么时候触发压缩？窗口满了再压有什么问题？成本上有什么坑？
期望等满了再压有两个问题：之前若干轮已经在长上下文低质量区做决策；满的那一刻往往在任务中途，被迫在坏边界切。所以阈值触发 + 边界对齐。成本坑是 prompt 缓存——压缩重写前缀让缓存全失效，短期反而更贵，「少次大压」优于「频繁小压」。摘要调用的延迟可做异步预压缩信号主动提 prompt 缓存击穿并给出「少次大压」结论 → 算过账；只答「快满了就压」→ 及格但没有区分度客服 Agent 压缩后反复索要已提供过的手机号和订单号，用户投诉，怎么救？
期望先分清成因：看 trace 状态快照——有但还问 = 注入位置或提示词；状态里没有 = 提取漏了，两种修法完全不同。止血：已收集信息做成 slot 表常驻不压 → 提问前加代码层检查，slot 已填不许再问。根治：已确认信息迁进任务状态，提取器覆盖必填 slot 加单测 → 评测集加「重复索取率」。真要再问就说明原因（「记录的是尾号 1234，请确认」）信号先分「丢了」还是「没抽到」、把提问判断权从模型移交给代码、给出重复索取率 → 处理过真投诉；只答「优化摘要提示词」→ 治标
prompt 缓存账，再筛掉一批。评分要点
- 三种策略的机制与各自代价说得清（尤其滑动窗口丢开头目标）
- 明确压缩目的是保决策质量，不只是省 token
- 给得出分层方案：锚定区 + 近窗 + 摘要区 + 外部化
- 列得出必须保真的信息类别（含"已失败路径"这类易漏项）
- 核心判断：关键约束应活在结构化状态里，而非对话历史里
- 关键动作执行前用代码校验约束，不依赖模型记忆
- 阈值触发 + 自然边界压缩，而不是等窗口满
- 加分：知道压缩击穿 prompt 缓存，"少次大压"优于"频繁小压"
- 加分：摘要基于原文重建，避免多代累积失真
- 加分：压缩有损但可恢复（原文归档 + 句柄回取）