企业把智能体投到长流程业务上（工单处理、合规审查、代码改造），很快会遇到同一个问题：任务没做完，窗口先满了。处理方式通常是"压缩"，但做完之后往往出现更麻烦的情况——智能体还在跑，只是它忘了某个前提，仍然一本正经地往下执行。

对生产系统来说，这比报错更危险。这篇从治理的角度，讲清上下文该按什么顺序处理、每个动作的成本与风险，以及怎么审计"丢了什么"。

一、问题定义：窗口是预算，不是容器

先纠正一个普遍的误解：模型支持 128K、200K 上下文，并不意味着装满就能保持同等质量。

公开评测可以佐证这一点。Chroma 在 2025 年做过一组长文本评测，覆盖 18 个模型、194,480 次调用，结论是性能随输入变长持续下降，是斜坡而非断崖，各模型只是斜率不同。同批实验里还有两个对企业场景特别有意义的发现：

• 干扰项的作用被低估了。在一大批材料中掺入一条似是而非的干扰句，准确率立刻下降。这对应到业务上就是：无关的历史记录、过期的政策条款，不只是占空间，还会误导判断。
• 文本顺序被打乱后，18 个模型反而全部答得更准。说明模型对"位置顺序"存在依赖，而这份依赖在长上下文里是负资产。

更直接的一组对照是：同一道题，给约 11.3 万 Token 的完整历史，与给约 300 Token 的聚焦片段相比，后者在所有模型上表现更好。

治理原则由此确立：上下文按信息增益分配，不按剩余容量填充。

二、分层治理：四类动作，风险从低到高

长任务的上下文处理可以拆成四类动作，建议按风险从低到高依次启用，而不是一上来就压缩。

第一层：工具结果清理（低风险，收益最大）。
智能体每次调用工具，返回的正文就挂在对话里，之后每轮都计入输入。哪怕早已用完，仍在持续计费。清理只做一件事：把旧的工具返回替换为短占位串，同时保留"调用过哪个工具、用了什么参数"的记录。模型知道调用发生过，需要原始数据时重新调用即可。

公开的实测运行数据说明了这一层的量级：一个研究型智能体 335,279 Token 的窗口中，文件读取返回内容占 322,946 Token（96.3%），而用户消息、模型推理与调用记录合计仅 12,333 Token。也就是说，清理这一刀能触及窗口的九成六。

第二层：摘要压缩（中风险，必需）。
把窗口前段的历史抽象成一段摘要，用新窗口继续。Claude Code 的取舍可作为基线：保留架构决定、未解决问题、实现细节，丢弃重复的工具输出，并携带最近访问的五个文件。

按事件计数的实现一般带重叠机制。以 Google ADK 为例，compaction_interval 控制间隔、overlap_size 控制重叠：间隔 3、重叠 1 时，依次压缩 1–3、3–6、6–9 三段。重叠 1 的作用是让相邻汇总可延续，代价是后续每份汇总体积递增。同一配置里通常还有按 Token 触发的策略，会保留最近若干事件，以维持指代关系。

第三层：结构化笔记（低风险，易被忽略）。
把必须跨轮保留的状态（待办、里程碑、已验证结论）写到窗口之外的持久介质。这样压缩只作用于可再生的对话历史，不触碰必须留存的状态。在私有化环境中，笔记与轨迹可归档到对象存储（如 OBS），按会话 ID 与版本号管理，便于审计回溯。

第四层：子智能体（中风险）。
主智能体保留高层计划，把窄任务派给在干净上下文中运行的子智能体，只回传摘要。适合并行探索，但会引入调度与结果合并的复杂度。

选择原则可以朴素一些：先做最简单、能解决问题的那一件。多数企业的实际最优解是"工具结果清理 + 少量压缩"，不必全套上齐。

三、参数与基线：把经验值固化成配置

清理动作有三个关键参数，建议写进配置模板而非硬编码：

• trigger：触发清理的输入水位，默认约 10 万 Token
• keep：保留最近几次工具结果，默认 3 次
• clear_at_least：单次清理的地板，一次至少清掉多少

效果有可参照的基线：三份各约 4 万 Token 的文档、keep 设为 1 时，上下文从约 128,740 Token 降至约 43,060 Token，降幅 67%。

但代价必须一并评估：到汇总答案阶段，智能体只剩笔记加最近几次读取。笔记详实则无碍，笔记稀疏则会触发反复重读。重读本地文件成本可忽略，重调有限速的外部接口则是实打实的时间与配额消耗。

四、成本：清理与缓存前缀的冲突

这一节在方案评审时经常被漏掉，但直接决定"压得勤不勤"。

前缀缓存的前提是前缀逐字不变，而清理与压缩默认就在改写前缀。官方文档的表述很明确：清理会使已缓存的前缀失效，需要重新支付写入费用，之后的请求才能复用新前缀。

因此 clear_at_least 的地板不是可选项。只清出几百 Token 却打掉整段缓存重写，是净亏；官方示例把地板设为 1 万 Token，含义是至少能收回这么多才值得动手。

优化对象应是频率而非总量：一次较大的改动可以摊薄重写成本，每轮小幅清理则摊不平。有一类实践是把清理顺序由"最旧优先"改为"最新优先"，使前缀保持不变、仅尾部变动，代价是丢弃近期内容。这种取舍在"上下文超过 75% 才应急触发"的前提下可以接受。

在私有化场景下，若推理服务由自建引擎承担，这部分开销体现为算力占用；若走托管服务，则直接体现在账单上。两种情形都应把命中计数纳入监控，而不是只看开关状态。

五、审计：它丢东西的时候不出声

压缩是有损的，这一点必须写进设计文档。风险在于丢失不产生告警：被丢掉的往往是顺带提过的一条约束，或当时特批的一个例外，丢掉之后智能体按残缺事实继续执行。

反复压缩还会引入第二类问题：摘要的摘要，偏差逐层累积。治理上建议三条同时落地：

• 单一事实源：始终从原始记录压缩，不以上一份摘要为输入；原始记录存放在窗口之外。
• 压缩后校验：增加一次校验调用，核对关键项是否仍在，代价是每次压缩多一次请求。
• 必留项清单：把合规约束、审批例外、关键参数写入压缩提示词的必留项，而不是依赖框架默认值。

需要特别提醒的是，压缩提示词本身长期处于"无人验收"的状态：它通常是框架自带的默认值，装上以后极少有人再改，但它直接决定智能体在后半程还记得哪几条硬约束。

验收方法朴素但有效：取一条跑满窗口的真实轨迹，压缩一次，对照原始记录逐条核对——当时定下的前提还剩几个，缺哪个就补进必留项。判断依据是"例外是否还在"，不是"摘要读起来是否通顺"。

六、落地清单

• 先测量，再优化：拆开窗口构成，确认工具返回占比（常见 90% 以上）。
• 优先做工具结果清理，配置 trigger / keep / clear_at_least 三参数。
• 清理量必须设地板，避免为省少量 Token 而重写整段缓存。
• 需要压缩时，先拉满摘要召回，再逐步收缩，并在真实长轨迹上调提示词。
• 多事件压缩保留重叠，确保相邻汇总可衔接。
• 必须跨轮留存的状态外置到持久存储，不参与压缩。
• 压缩提示词纳入配置评审，维护必留项清单，并接入监控与验收流程。

压缩本身不难，难的是知道丢了什么——压完，对着原始记录把硬约束点一遍。