核心要点

  • 长会话/多步任务里历史不断累积，逼近上下文窗口上限并推高成本

  • Context Compaction：在不丢关键信息前提下压缩历史，腾空间、降成本、保质量

  • 主流策略：滚动摘要、按重要性筛选淘汰、工具结果裁剪/外置引用、结构化事实抽取、分层记忆、Token 预算

  • 常与 RAG 式记忆检索配合：压缩负责瘦身，检索负责按需召回

标准回答

为什么需要压缩
在多轮对话或多步 Agent 任务中，历史消息、工具调用与返回结果会不断累积，很快逼近模型的上下文窗口上限。直接截断会丢失关键信息，全部塞入又会推高 token 成本与延迟，而且过长上下文还会稀释注意力、让模型「迷失在中间」（lost in the middle）导致推理质量下降。Context Compaction 就是在尽量不丢关键信息的前提下压缩历史，用更少 token 承载等价的有效信息。

常见压缩策略

  1. 滚动摘要（rolling summary）：把较旧的历史定期总结成一段紧凑 summary，用摘要替换原文，只保留最近若干轮原文。是最常用的基线方案。
  2. 按重要性筛选与淘汰：对历史片段评分（与当前目标的相关性、是否含决策/结论），保留高价值内容，淘汰寒暄与重复，类似有优先级的滑动窗口。
  3. 工具结果裁剪 / 外置引用：工具往往返回大段 JSON 或网页文本，可只保留摘要或关键字段，原文存到外部存储，上下文里只放一个引用句柄，需要时再取回。
  4. 结构化事实抽取：把对话沉淀为结构化事实（如用户偏好、已确认约束、待办），用键值或表格表示，比自由文本更紧凑也更稳定。
  5. 分层（hierarchical）：近期原文作短期工作记忆，旧内容压成摘要作长期记忆，必要时再逐级展开。
  6. 设置 Token 预算：为系统提示、历史、工具结果分别设上限，超额自动触发压缩，使整体始终受控。

与记忆检索的配合
压缩负责「瘦身」，RAG 式记忆检索负责「按需召回」：被压缩或外置的内容并未真正丢弃，而是向量化存储，当后续轮次需要时再检索相关片段注入上下文。二者结合既控制了窗口占用，又保住了长期可追溯性。

实践要点
触发时机（按 token 阈值或轮数）、压缩粒度、以及对关键不可丢信息（如明确指令、已敲定决策、ID/数字）的保护，是落地时最容易出问题的地方，需要专门规则避免被摘要「抹平」。

常见误区

⚠️ 常见踩坑

把上下文压缩等同于「无脑截断最早的消息」。简单截断会丢掉早期已确认的约束、目标或关键 ID，导致 Agent 前后矛盾或遗忘任务；正确做法是先摘要/抽取关键信息再压缩，并对不可丢内容设保护规则。

追问

追问 1：什么时候触发压缩？按 token 还是按轮数？

通常按 token 阈值触发更稳妥，例如当历史占用达到窗口的 70%~80% 时启动压缩，因为不同轮的消息长度差异很大，纯按轮数容易要么过早要么过晚。实践中常结合两者：设硬性 token 预算做兜底，再辅以任务阶段边界（如一个子任务完成时）做语义化压缩。

追问 2：滚动摘要可能丢信息，如何降低风险？

一是对关键信息（明确指令、已确认决策、数字/ID、未完成 TODO）设保护清单，强制保留原文或单独结构化存储，不参与自由文本摘要；二是分层保留，近期原文不压、只压旧内容；三是把被压缩的原文外置到向量库，后续可检索回溯，从而把「不可逆丢失」降为「可召回」。

追问 3：上下文压缩和直接用更大上下文窗口相比，取舍是什么？

更大窗口实现简单，但 token 成本与延迟随长度线性甚至更快增长，且超长上下文存在注意力稀释、lost-in-the-middle 问题，有效信息密度反而下降。压缩用一定的工程复杂度（摘要、抽取、检索）换取更低成本、更稳定的推理质量与近乎无限的会话长度，长会话/长任务场景通常更划算。

🔗 相似问题

同一考点的不同问法，面试官可能换着问，一起刷更稳

没找到想看的面试题？把你想看的告诉我们 →

延伸学习

按主题分类的相关资源，便于系统复习

核心术语

查看更多 →