多轮历史越来越长你怎么压缩?compaction 时什么必须保真?

Q1-13上下文压缩高频新增compaction压缩保真结构化状态prompt缓存

谁在问:大厂二三面·压力面;Agent 团队必问

口语化问法

  • 对话跑到几十轮,上下文快满了,你怎么处理?
  • 压缩的时候什么必须留住?你怎么保证它不被摘要摘掉?
  • 你多久压一次?为什么是这个频率?

考察意图

这是第 1 章里最像「真做过」照妖镜的一题。区分度在三处:

  1. 你知不知道压缩本身要花钱、而且会动前缀;
  2. 你有没有一份保真清单,还是笼统地说「保留重要信息」;
  3. 面对「压完之后丢了关键约束」这类事故,你归因到压缩没做好,还是归因到架构把东西放错了地方——这是本题最高的那一档。

参考答案

图 2 · 60 分与 90 分差在哪:代价、演进、怎么验证

60

60 分答案(及格线)

常见做法有几种:滑动窗口(只保留最近 N 轮)、摘要压缩(把早期历史总结成一段摘要接着用)、重要性过滤(挑出关键轮次保留)。实践中一般是组合使用:最近几轮保留原文,更早的做摘要。

压缩时要保住的是关键结论、用户明确提过的要求、以及当前任务进行到哪一步了。

90

90 分答案(有生产经验的回答)

补三层:

第一,压缩不是免费的,它有三笔成本。 截至 2026-08,压缩已经是一等公民 API:按输入 token 阈值触发(默认 15 万,最低只能设到 5 万——这个下限本身就在提示不要频繁小压),它是一次额外采样、单独计费;生成的摘要会重写前缀,把 prompt 缓存作废;而且信息每被转述一次就丢一点,是复利式失真。所以正确的策略是少次大压,阈值尽量贴近窗口上限。我们踩过反面案例:每 10 轮压一次,结果账单不降反升 40%,还老忘事。

第二,必须保真的有五类:已确认的关键决定与硬性约束、未完成的待办与下一步、已经踩过的失败路径(不留就会重复踩,这类最容易被摘要丢、代价又最高)、外部世界已发生的不可逆动作、用户明确的偏好与口径。

第三,但更根本的判断是:关键约束根本不该活在对话历史里。 历史是会被有损转述的介质,把不能丢的东西放在会被转述的地方,本身就是设计错误。我们的做法是把约束提到一个每轮原样重新注入的结构化状态块,让它压根不参与压缩。压缩只用来处理那些「丢了也只是少点上下文」的叙述性内容。

配套的三个配置动作:摘要指令要写全(自定义指令是完全替换默认提示,不是追加,只写自己关心的那条会把通用要点一起删掉);指令里明确禁止在摘要步骤调用工具(否则模型可能跑去调工具,返回空摘要);用「压缩后暂停」把最近几条消息原样接在摘要后面,避免刚说完的东西立刻走样。

追问链

图 1 · 五层追问树:面试官会往哪儿挖
问的不是压缩方法,是「不能丢的东西该放在哪」

  1. 什么时候触发压缩?阈值怎么定?

    期望按输入 token 数触发,阈值尽量贴近窗口上限而不是「保险起见调低」—— 每压一次都付固定开销(额外采样 + 前缀重建)并损失一次信息,压得越勤付得越多。默认 15 万、下限只能设到 5 万,这个下限本身就是指引
    信号答「每 N 轮压一次」→ 通常没算过账;按 token 阈值触发且说得清理由 → 做过
  2. 压缩时哪些信息必须保真?

    期望五类里说出三类以上:已确认的关键决定与硬性约束、未完成的待办与下一步、已踩过的失败路径、外部世界已发生的不可逆动作、用户明确的偏好与口径。失败路径最见功力 —— 被摘要丢掉后 Agent 会原地重试同一条死路,代价最高
    信号只答「保留重要信息」→ 没做过;点名失败路径和不可逆动作 → 做过
  3. 压缩会影响 prompt 缓存吗?

    期望会 —— 摘要是新内容,会重写会话前缀。但损失能限住:在系统提示词末尾单独打一个缓存断点,压缩发生时那段缓存仍然有效、照常读取,只有摘要那一小段需要新写入。准确表述是「击穿的是会话前缀,不是全部
    信号说得出这个和解方案 → 一定读过一手文档;只说「压缩会让缓存失效」然后当无解 → 停在二手总结
  4. 频繁小压和少次大压,哪个更好?

    期望少次大压。固定开销按次数付,压得越勤越贵;信息每被转述一次丢一点,是复利失真不是线性 —— 我们每 10 轮压一次的反面案例,账单不降反升 40%,还老忘事。反向条件:膨胀主因若是工具结果而非对话历史,该做的是清理,压多少次都治不好
    信号给得出「先看膨胀主因是历史还是工具结果」这个前置判断 → 有诊断习惯
  5. Agent 一次长任务里被压了 4 次,交付结果漏掉用户第 2 轮提的硬性约束,复盘

    期望第一句必须定性对:这不是压缩没做好,是架构把关键约束放错了地方。根治顺序:① 硬约束提到结构化状态块,每轮原样重注入、不参与压缩 → ② 摘要指令显式列保真清单,注意自定义指令是完全替换不是追加 → ③ 用「压缩后暂停」把最近若干条原样保留 → ④ 压了 4 次本身是信号,先拆构成,主因是工具结果就该清理 → ⑤ 补一道代码判的「约束回读」自检
    信号第一句是「这是架构问题不是压缩问题」并补上「为什么最终答案看不出来」→ 顶档;答「摘要提示词写详细点」→ 治标,换个约束照样丢
本章最像「真做过」照妖镜的一题:前四层考成本与保真清单,第 5 层看你把事故归因到压缩没做好,还是归因到架构把东西放错了地方。

评分要点

  1. 知道压缩是额外采样并单独计费
  2. 知道压缩会重写前缀、影响 prompt 缓存
  3. 主张少次大压,并能给出成本与失真两条理由
  4. 能列出三类以上必须保真的信息
  5. 能把「关键约束提到结构化状态」讲成架构判断
  6. 知道自定义摘要指令是完全替换而非追加
  7. 会先判断膨胀主因是历史还是工具结果,再选手段
  8. 有压缩后的确定性自检,而非依赖模型自觉

常见错误

认为压缩就是「让模型总结一下前面的对话」,没有成本意识。
按固定轮次压缩,说不出频率是怎么定的。
保真清单只有「保留重要信息」这一句。
出了丢约束的事故,只想到把摘要提示词写得更详细。
不知道上下文膨胀可能主要来自工具结果而非历史。
含糊标志词:「框架自带压缩功能」「让它总结得全面一点」「一般不会丢关键信息」。

关联学习