标准回答
一、先讲为什么需要上下文压缩
在长会话或者多步 Agent 任务里，历史对话、工具调用、网页内容和中间结论会越堆越多。全塞进上下文，成本高、延迟高，还可能让模型抓不住重点；直接截断，又可能把早期约束、关键数字和决策丢掉。所以我理解的上下文压缩，就是把历史变瘦，但保住真正影响后续决策的信息。
二、再讲常见压缩做法
最常见的是滚动摘要：把旧对话总结成短摘要，只保留最近几轮原文。更稳一点会做重要性筛选，把用户明确要求、已确认决策、关键 ID 和未完成事项单独保留。工具结果也要处理，不能把一大坨 JSON 全塞进去，通常只留关键字段和引用，原文放外部存储。
三、然后讲结构化和检索
对 Agent 来说，自由文本摘要还不够，最好把历史沉淀成结构化状态，比如“用户偏好是什么、当前目标是什么、已完成哪些步骤、还剩哪些未完成事项”。被压缩掉的原文可以进向量库，后面需要时再检索回来。也就是压缩负责省窗口，检索负责按需找回证据。
四、最后讲风险
压缩最怕把重要信息摘要没了，尤其是数字、权限边界、用户明确否定过的方案、已经确认的决策。所以生产里可以设置 token 阈值触发压缩，同时给这些不可丢信息加保护规则，而不是简单把最早的消息删掉。
常见误区
⚠️ 常见踩坑
误区一：把上下文压缩等同于删除最早消息。 简单截断会丢掉早期约束、目标或关键 ID。误区二：只做自由文本摘要。 更稳的做法是摘要 + 结构化状态 + 外部检索，并对不可丢内容设保护规则。
追问
追问 1：什么时候触发压缩？按 token 还是按轮数？
可以优先按 token 阈值触发，比如历史占到窗口 70%～80% 时压缩，因为每轮消息长度差别很大，单纯按轮数不稳定。但实际会结合任务阶段：一个子任务完成时也适合压缩，因为那时可以把过程收敛成结论和状态。
追问 2：滚动摘要可能丢信息，如何降低风险？
可以做三件事：第一，给明确指令、已确认决策、数字/ID、未完成待办设保护清单，必要时保留原文；第二，近期内容先不压，只压旧内容；第三，把被压缩的原文放到外部存储或向量库里，后面可以检索回来。这样压缩不是“永久删除”，而是“默认收起来，需要时能找回”。
追问 3：上下文压缩和直接用更大上下文窗口相比，取舍是什么？
大窗口的好处是简单，先不用设计复杂记忆系统。但问题是成本和延迟都会上去，而且上下文太长时模型不一定真能抓住中间的关键信息。压缩方案工程复杂一点，但长期任务更划算：成本低、信息密度高，还能配合检索做长期记忆。
🔗 相似问题
同一考点的不同问法，换着练更稳
没找到想看的面试题？把你想看的告诉我们 →
延伸学习
按主题分类的相关资源，便于系统复习
