怎么考「多轮历史越来越长你怎么压缩？compaction 时什么必须保真？」
谁在问：大厂二三面·压力面；Agent 团队必问
开场怎么问
对话跑到几十轮，上下文快满了，你怎么处理？
换个问法
- 压缩的时候什么必须留住？你怎么保证它不被摘要摘掉？
- 你多久压一次？为什么是这个频率？
五层追问链
左边照着问，右边对着听。最后一层是压力面，不必每个候选人都问到。
什么时候触发压缩？阈值怎么定？
- 期望
- 按输入 token 数触发，阈值尽量贴近窗口上限而不是「保险起见调低」。理由是每次压缩都要付固定开销（额外采样 + 前缀重建）并损失一次信息，压得越勤付得越多。加分项：知道官方阈值下限是 5 万，本身就是一种指引。
- 信号
- 答「每 N 轮压一次」的通常没算过账；按 token 阈值触发并能说清理由的，是做过的。
压缩时哪些信息必须保真？
- 期望
- 五类里能说出三类以上，尤其是「已踩过的失败路径」——这条最能证明真跑过长任务，因为它是被摘要丢掉后代价最高的一类（Agent 会原地重试同一条死路）。
- 信号
- 只答「保留重要信息」的，没做过；能点名失败路径和不可逆动作的，做过。
压缩会影响 prompt 缓存吗？
- 期望
- 会——摘要是新内容，会重写会话前缀。但可以把损失限制住：在系统提示词末尾单独打一个缓存断点，压缩发生时系统提示词那段缓存仍然有效、照常读取，只有摘要那一小段需要新写入。所以准确的表述是「击穿的是会话前缀，不是全部」。
- 信号
- 知道这个和解方案的，一定读过一手文档；只会说「压缩会让缓存失效」然后当无解的，停在二手总结。
频繁小压和少次大压，哪个更好？
- 期望
- 少次大压。两条理由：固定开销（额外采样 + 前缀重建）按次数付，压得越勤越贵；信息经多次转述是复利失真，不是线性。反向条件也要说清：如果上下文膨胀的主因是工具结果而不是对话历史，那该做的是清理而不是压缩——用错手段，压多少次都治不好。
- 信号
- 能给出「先看膨胀主因是历史还是工具结果」这个前置判断的，是有诊断习惯的。
你的 Agent 在一次长任务里被压缩了 4 次，最后交付的结果漏掉了用户在第 2 轮提的一个硬性约束。复盘。
- 期望
- 定性要定对：这不是「压缩没做好」，是架构把关键约束放错了地方。约束被放在对话历史里，而历史是有损介质。只在摘要提示词上打补丁，下次换个约束还会再丢；
- 根治动作：把硬性约束提到结构化状态块，每轮原样重新注入，不参与压缩；
- 其次修配置：摘要指令要显式列出必须保真的清单——默认提示不知道你的业务什么重要；注意自定义指令是完全替换，要把「继续任务所需的状态、下一步、已试过的失败路径」一并写进去；
- 再次修边界：用「压缩后暂停」把最近若干条原样保留，防止最新信息刚产生就被摘要走样；
- 4 次压缩本身就是信号：先拆上下文构成——如果膨胀主因是工具结果，正确动作是清理而不是把阈值继续调低；
- 补一道确定性检查：压缩后做「约束回读」自检，把结构化状态里的约束和当前草案逐条比对。这是能用代码判的，不该靠模型自觉；
- 说清为什么没被发现：这类失败在最终答案层面很隐蔽——交付物看起来是完整的，只是少了一条。必须靠约束级断言和轨迹评测才能捞出来，只看「答案对不对」永远发现不了。
- 信号
- 优秀回答的第一句是「这是架构问题不是压缩问题」，并且会补上「为什么最终答案看不出来」。差的回答是「把摘要提示词写得更详细一点」——治标，下次换个约束照样丢。
危险信号
听到这些话，基本可以判定是背题而不是做过。
评分卡
- 知道压缩是额外采样并单独计费
- 知道压缩会重写前缀、影响 prompt 缓存
- 主张少次大压，并能给出成本与失真两条理由
- 能列出三类以上必须保真的信息
- 能把「关键约束提到结构化状态」讲成架构判断
- 知道自定义摘要指令是完全替换而非追加
- 会先判断膨胀主因是历史还是工具结果，再选手段
- 有压缩后的确定性自检，而非依赖模型自觉
参考答案与考察意图面试中途别看这一段
考察意图
这是第 1 章里最像「真做过」照妖镜的一题。区分度在三处：
- 你知不知道压缩本身要花钱、而且会动前缀；
- 你有没有一份保真清单，还是笼统地说「保留重要信息」；
- 面对「压完之后丢了关键约束」这类事故，你归因到压缩没做好，还是归因到架构把东西放错了地方——这是本题最高的那一档。
参考答案
60 分答案（及格线）
常见做法有几种：滑动窗口（只保留最近 N 轮）、摘要压缩（把早期历史总结成一段摘要接着用）、重要性过滤（挑出关键轮次保留）。实践中一般是组合使用：最近几轮保留原文，更早的做摘要。
压缩时要保住的是关键结论、用户明确提过的要求、以及当前任务进行到哪一步了。
90 分答案（有生产经验的回答）
补三层：
第一，压缩不是免费的，它有三笔成本。 截至 2026-08，压缩已经是一等公民 API：按输入 token 阈值触发（默认 15 万，最低只能设到 5 万——这个下限本身就在提示不要频繁小压），它是一次额外采样、单独计费；生成的摘要会重写前缀，把 prompt 缓存作废；而且信息每被转述一次就丢一点，是复利式失真。所以正确的策略是少次大压，阈值尽量贴近窗口上限。我们踩过反面案例：每 10 轮压一次，结果账单不降反升 40%，还老忘事。
第二，必须保真的有五类：已确认的关键决定与硬性约束、未完成的待办与下一步、已经踩过的失败路径（不留就会重复踩，这类最容易被摘要丢、代价又最高）、外部世界已发生的不可逆动作、用户明确的偏好与口径。
第三，但更根本的判断是：关键约束根本不该活在对话历史里。 历史是会被有损转述的介质，把不能丢的东西放在会被转述的地方，本身就是设计错误。我们的做法是把约束提到一个每轮原样重新注入的结构化状态块，让它压根不参与压缩。压缩只用来处理那些「丢了也只是少点上下文」的叙述性内容。
配套的三个配置动作：摘要指令要写全（自定义指令是完全替换默认提示，不是追加，只写自己关心的那条会把通用要点一起删掉）；指令里明确禁止在摘要步骤调用工具（否则模型可能跑去调工具，返回空摘要）；用「压缩后暂停」把最近几条消息原样接在摘要后面，避免刚说完的东西立刻走样。