上下文管理机制对比：摘要压缩与硬切窗口+外部记忆如何选

一、对比背景：为什么上下文管理方式值得认真比较

在大模型应用尤其是代码生成、长任务代理、多轮工具调用等场景中，上下文窗口是最稀缺的资源之一。当对话或任务执行的 token 不断累积、逼近预算上限时，系统必须做出选择：是“压缩”旧信息继续塞回同一个窗口，还是“切换”到一个全新窗口并依靠外部存储维持连续性。

这两条路线看似只是实现细节，实则深刻影响任务连续性、信息保真度、系统复杂度和运维成本。本文围绕两类机制展开对比：

• 方案A：摘要压缩（Compaction）——上下文接近上限时，将旧对话总结成一段摘要，用摘要替换大量旧消息，继续在同一逻辑上下文中工作。
• 方案B：硬切窗口 + 外部记忆（TokenBudget 新路径）——上下文接近上限时，直接清空旧窗口、创建全新上下文窗口，任务连续性交给工作笔记（notes）与历史记录（history）按需检索。

需要强调的是，二者并非简单的“新旧替代”，而是两种不同的上下文治理哲学：前者把“记忆”压缩进 prompt，后者把“记忆”外置到存储与工具层。

二、对象定义：两类机制各自解决什么问题

方案A：摘要压缩

摘要压缩的核心动作是“总结再回填”。当系统检测到上下文将满，触发一次摘要任务，把旧对话压缩为一段简短摘要，再用该摘要替换原有的大量消息，从而腾出预算继续推进任务。

它解决的问题是：在不引入外部存储、不改变会话结构的前提下，尽可能延长单个上下文窗口的可用时长。其优点是实现相对集中、对模型调用方透明；缺点是摘要本身是有损的，细节丢失后难以恢复。

方案B：硬切窗口 + 外部记忆

硬切窗口的核心动作是“换窗口而非压内容”。在 TokenBudget 管理路径下，系统不再调用本地或远端摘要，而是直接执行一次上下文窗口切换：旧窗口整体退出 prompt，新建一个干净的上下文窗口。任务连续性由两类外部机制承担：

• notes（工作笔记/检查点）：由模型自己维护的私有笔记，用于在窗口切换后保留工作状态，例如当前目标、已完成步骤、待办事项、关键约束。
• history（历史记录）：保存原始历史事实，供后续按需查询，而非一次性塞进 prompt。

它解决的问题是：避免有损摘要带来的信息衰减，把“记住什么”从被动压缩变为主动管理，让模型像操作系统管理内存一样管理上下文——提前检查点、换窗口、按需从长期存储中取回信息。

三、相同点分析

尽管实现路径不同，两类机制在目标和基础逻辑上存在明显共性：

1. 目标一致：都在解决上下文预算有限与任务需要持续之间的矛盾，都是为了让长任务不在窗口耗尽时被迫中断。
2. 都依赖“状态保留”：方案A依赖摘要文本，方案B依赖 notes 与 history，本质上都需要某种形式的状态外化。
3. 都涉及触发时机管理：无论是自动触发还是手动触发，都需要判断“何时该压缩/切换”，这要求系统具备预算感知能力。
4. 都对任务连续性负责：二者都不是简单截断，而是试图在窗口变化后维持任务的可推进性。

四、核心差异分析

1. 技术架构与信息流向

方案A的信息流向是“旧上下文 → 摘要 → 回填 prompt”，系统边界基本停留在单次会话的上下文管理内部。方案B则把信息拆成两条通路：工作状态走 notes，历史事实走 history，prompt 只承载当前窗口内容，系统边界扩展到外部存储与检索层。

2. 信息保真度

摘要是天然有损的：哪些细节被保留、哪些被丢弃，取决于摘要模型的判断，且一旦丢失难以追溯。硬切窗口本身不压缩内容，旧信息以原始形式留在 history 中，需要时可查询，因此细节可按需还原，保真度上限更高。但这也意味着“是否记得”取决于模型是否主动查、查得准不准。

3. 任务连续性的承载方式

方案A的连续性主要依赖摘要是否覆盖了关键信息，属于“一次性打包”。方案B的连续性依赖 notes 的质量与 history 的可检索性，属于“按需取用”。前者实现简单但脆弱，后者更稳健但对模型主动性和工具设计提出更高要求。

4. 接入与改造成本

方案A通常对调用方透明，改造集中在压缩任务的触发与摘要模板上。方案B需要引入 notes 维护、history 存储与查询工具，并调整上下文生命周期管理逻辑，接入改造量更大，对编排层的要求更高。

5. 运维与可观测性

方案B引入外部存储后，需要关注 notes/history 的写入一致性、检索延迟、存储容量与权限隔离；方案A的运维面相对窄，但摘要质量难以量化评估。两者都需要监控上下文预算使用率与切换频率。

6. 成本结构

方案A的成本主要在摘要调用本身，压缩比越高、调用越频繁，成本越明显。方案B省去了摘要调用，但增加了存储与检索开销，以及模型维护 notes 的额外 token 消耗，成本从“计算”向“存储+检索”转移。

五、对比表格

对比维度	方案A：摘要压缩	方案B：硬切窗口+外部记忆
核心动作	总结旧上下文并回填	清空旧窗口，新建窗口
信息保真	有损，细节易丢失	原始记录保留，可按需查询
连续性依赖	摘要覆盖度	notes 质量 + history 检索
改造复杂度	较低	较高，需外部存储与工具
运维关注点	摘要质量、触发频率	存储一致性、检索延迟、权限
成本重心	摘要调用	存储、检索、笔记维护
适用任务	短中期、信息密度低	长任务、细节敏感、可检查点

六、典型场景选择

• 偏向方案A的场景：任务链路较短、对细节回溯要求不高、团队希望以较小改造量快速上线、上下文预算压力主要来自闲聊式历史而非关键事实。
• 偏向方案B的场景：长周期代码任务、多步骤工具调用、需要反复回查历史事实、对摘要丢失关键约束敏感、且具备外部存储与检索能力。

七、选型建议与迁移注意事项

选型时应先评估三点：任务平均长度与细节敏感度、团队对存储与检索链路的掌控能力、以及可接受的改造与运维投入。条件化判断如下：

• 若任务以短会话为主、细节回溯需求弱，方案A的改造成本更低，可优先考虑；
• 若任务长且关键约束多、摘要丢失代价高，方案B的保真优势更明显，但需同步建设 notes 规范与 history 检索能力；
• 迁移时需注意：切换窗口后旧 prompt 不再可用，必须确保 notes 在切换前完成检查点写入；history 查询需设计好索引与权限；同时保留回退路径，避免切换逻辑异常导致任务中断。

八、总结

摘要压缩与硬切窗口+外部记忆的差异，本质是“把记忆压进 prompt”与“把记忆外置并按需取回”的路线差异。前者实现轻、连续性脆弱；后者保真高、连续性稳健但工程投入更大。理解这一差异，才能结合任务特征与团队能力做出合理选择。