长任务 Agent 的上下文治理：窗口是预算，不是容器

企业把 Agent 投到长流程业务上——工单处理、合规审查、代码改造——很快会遇到同一个问题：任务没做完，窗口先满了。常见的处理方式是“压缩”，但压缩完往往出现更麻烦的情况：Agent 还在跑，只是它忘了某个前提，仍然一本正经地往下执行。对生产系统来说，这比报错更危险。

先纠正一个普遍的误解：模型支持 128K、200K 上下文，并不意味着装满就能保持同等质量。Chroma 在 2025 年做过一组长文本评测，覆盖 18 个模型、194,480 次调用，结论是性能随输入变长持续下降，是斜坡而非断崖。同批实验里还有两个对企业场景特别有意义的发现：干扰项的作用被低估了——在一大批材料中掺入一条似是而非的干扰句，准确率立刻下降，对应到业务上就是无关的历史记录和过期政策条款不只是占空间，还会误导判断；文本顺序被打乱后，18 个模型反而全部答得更准，说明模型对“位置顺序”存在依赖，而这份依赖在长上下文里是负资产。更直接的一组对照是：同一道题，给约 11.3 万 Token 的完整历史，与给约 300 Token 的聚焦片段相比，后者在所有模型上表现更好。治理原则由此确立：上下文按信息增益分配，不按剩余容量填充。

长任务的上下文处理应该拆成四层，按风险从低到高依次启用，而不是一上来就压缩。

第一层，工具结果清理。 风险最低，收益最大。Agent 每次调用工具，返回的正文就挂在对话里，之后每轮都计入输入，哪怕早已用完，仍在持续计费。清理只做一件事：把旧的工具返回替换为短占位串，同时保留“调用过哪个工具、用了什么参数”的记录。模型知道调用发生过，需要原始数据时重新调用即可。一组公开的实测运行数据说明了这一层的量级：一个研究型 Agent 的 335,279 Token 窗口中，文件读取返回内容占 322,946 Token（96.3%），而用户消息、模型推理与调用记录合计仅 12,333 Token。清理这一刀能触及窗口的九成六。

第二层，摘要压缩。 风险中等，但必需。把窗口前段的历史抽象成一段摘要，用新窗口继续。Claude Code 的取舍可以作为基线：保留架构决定、未解决问题、实现细节，丢弃重复的工具输出，并携带最近访问的五个文件。按事件计数的实现一般带重叠机制：间隔 3、重叠 1 时，依次压缩 1–3、3–6、6–9 三段，重叠的作用是让相邻汇总可延续，代价是后续每份汇总体积递增。一篇 2026 年 6 月的论文在 Microsoft Dynamics 365 Finance and Operations 的酒店费用场景中给出了更直接的对比：保留完整历史能把完成率从 8.0% 的基线拉到 71.0%，但消耗 148 万 Token、14.56 小时；剪枝到最近 5 次工具调用，完成率反而升到 79.0%，Token 降到 53.5 万，运行时间降到 5.39 小时；再加上摘要，完成率达到 91.6%，平均金额项完整度 99.64%。更多的上下文没有带来更好的结果，选择性保留反而同时提升了可靠性和效率。

第三层，缓存地板。 摘要压缩的摘要本身如果也要重新计算，成本会随轮次递增。一个实用的做法是给摘要设一个“地板”——摘要的摘要不再继续压缩，而是保留一份固定大小的锚点，包含不可丢失的约束、否决理由和关键实体。锚点之外的摘要可以继续滚，锚点本身只在显式变更时才更新。

第四层，信息丢失审计。 压缩不是无损的，所以必须能回答“丢了什么”。审计不需要重建完整历史，只需要在关键决策点记录“当时依赖了哪些事实、这些事实在压缩后是否仍然可达”。一个可操作的方法是：对每个最终被否决的方案，记录否决理由和被引用的事实 ID；在后续轮次中如果这些事实 ID 不再出现在任何摘要或锚点里，就标记为“不可追溯”。这比等到 Agent 重复犯错之后再回溯便宜得多。

同期的另一条路线是“上下文作为工具”。Cat 范式把上下文维护提升为 Agent 可以主动调用的工具，让 Agent 在合适的里程碑主动把历史轨迹压缩成可操作的摘要，而不是等系统被动触发压缩。这条路线的前提是 Agent 本身有能力判断“什么时候该压缩”，对模型能力要求更高，但它把压缩从系统层的一次性动作变成了决策循环的一部分。

一个务实的落地顺序是：先做工具结果清理，确认窗口占用下降、成本可量化；再加摘要压缩，用评估集验证“压缩后任务完成率”没有退化；然后设缓存地板，防止摘要滚雪球；最后补审计，确保关键事实在被丢掉之前有人知道。上下文治理的目标不是“让窗口永远不溢出”，是“让溢出发生在信息增益最低的地方”。