核心要点
能讲滑窗截断：保留最近 N 轮 + 始终保留 system prompt，丢弃过旧轮次
能讲摘要压缩：把早期对话滚动摘要成短文本，腾出窗口又保留要点
能讲向量记忆检索：历史存向量库，按当前问题相关性召回相关片段
能讲分层记忆：短期（近期原文）+ 长期（摘要/事实/向量）分层组织
标准回答
问题本质（独占一行）
上下文窗口有限且每 token 都计费、增延迟，长对话会超窗。目标是在窗口和成本约束下，把「对当前回合最有用的信息」放进上下文。
滑动窗口截断
最简单：固定保留 system prompt 与最近 N 轮，丢弃更早内容。实现简单但会直接丢失早期关键信息。
摘要压缩
当历史超过阈值，用模型把较早的对话滚动压缩成简短摘要，替换原文进入上下文，既省 token 又保留要点；可分级摘要（越久越粗）。
向量记忆检索
把历史消息/事实切片向量化存入向量库，每轮按当前问题做语义检索，只召回最相关的若干片段拼入上下文——类似对会话历史做 RAG，适合超长、需要回溯的场景。
分层记忆
综合方案：短期记忆保留近期原文，长期记忆存摘要、用户画像/关键事实与向量索引，按需检索。长上下文模型（参考 上下文窗口扩展）能缓解但不替代管理，否则成本与延迟失控。
常见误区
⚠️ 常见踩坑
别以为窗口够大就把全部历史塞进去——既贵又慢，且「中间信息丢失」会让长上下文里的关键内容被忽略；该压缩/检索仍要做。
追问
追问 1：滚动摘要会丢信息，如何缓解？
对关键事实（如用户偏好、已确认的决定、ID/数字）单独抽取存为结构化「长期记忆」，不随摘要泛化丢失；摘要只压缩闲聊与过程性内容，并保留可回溯的原文索引。
追问 2：什么时候该用向量记忆而非摘要？
当历史很长、问题会随机回溯到任意早期内容（如客服查历史工单）时，向量检索按需召回更合适；若对话线性、只需大致背景，滚动摘要更省事且延迟更低。
追问 3：如何控制上下文管理带来的延迟？
摘要与向量检索都引入额外调用，可异步/后台预先生成摘要、缓存 embedding、限制召回 top-k，并对短对话跳过这些步骤，按对话长度分级启用。
延伸学习
与本题相关的知识库文章、术语、工具与行业资讯。