上下文压缩实战：长任务Agent不再丢失记忆的四种压缩策略

一个跑了 60 轮的 Agent 任务，往往在第 35 轮开始”变傻”：忘了开头定下的验收标准，忘了用户明确说过的三条约束，开始重复已经做过的动作。很多人第一反应是”换个更强的模型”，但真正的原因通常很朴素——上下文被塞满了，最早、最重要的信息最先被挤掉。

一、先理解”塞满”之后发生了什么

上下文窗口变长不等于理解能力变强。当输入达到窗口容量的七八成，模型会出现三种可观测的退化：

1. 中间遗忘：位于长上下文中部的信息，被调用概率显著低于头尾。系统提示词在第 1 轮很管用，塞到 8 万 token 之后，约束力明显下降。
2. 注意力稀释：工具定义、历史失败尝试、日志输出混杂在一起，模型难以从中提取出”当前该做什么”。
3. 成本与延迟雪球：每轮都重新灌输全部历史，第 40 轮的输入 token 可能是第 1 轮的几十倍，延迟随之上涨，超时重试又进一步放大了消耗。

所以压缩不是”省钱的优化项”，而是长任务能否跑完的正确性问题。

二、四种压缩策略与适用场景

策略一：滚动摘要（Rolling Summary）

把较早的对话轮次交给一个小模型，压缩成结构化摘要：已确认的事实、已完成动作、未解决问题、待决事项。原文丢弃，摘要保留。

• 适用：多轮对话类 Agent，如客服、咨询、需求澄清。
• 要点：摘要必须有固定字段模板，否则小模型会自由发挥，把关键约束写丢。每次压缩后保留最近 3～5 轮原文，避免”摘要摘要再摘要”的信息衰减。
• 风险：一次性压缩有信息损失，不要等到必须压缩时才压。

策略二：结构化留存（State File）

把任务状态显式外化成一份 JSON 或 Markdown，而不是依赖对话历史携带。字段通常是：目标、约束清单、已完成步骤、产出物引用、失败尝试及原因。

• 适用：多步工具调用、代码修改、数据处理等执行类 Agent。
• 要点：状态文件本身就是”真相源”，每一轮只向模型注入状态文件 + 最近一轮结果，而不是全部历史。这能把上下文从线性增长变成近似恒定。
• 收益：这是四种策略里性价比最高的，通常能在半天内实现，并把长任务成本压下一半以上。

策略三：检索式外部记忆（Retrieval on Demand）

历史全部落盘，需要时按当前意图检索片段注入，而不是常驻上下文。

• 适用：知识密集、跨度长、需要回溯早期细节的任务，如代码库级重构、长文档分析。
• 要点：检索质量决定成败。不要用纯向量检索，混合”关键词 + 结构化过滤（文件路径、时间、步骤号）“效果更稳。
• 陷阱：检索失败时 Agent 会”自信地编造过去发生的事”，需要配合”查不到就明确说查不到”的指令。

策略四：分层压缩（Tiered Compaction）

按时间与重要性把上下文分成三层：永久层（目标、约束、验收标准）、工作层（最近若干轮原文）、归档层（可检索的摘要与日志）。每轮只注入永久层 + 工作层。

• 适用：超长任务（数十轮以上）、无人值守的后台 Agent。
• 要点：永久层要极短，控制在几百字内；一旦发现约束被违反，优先怀疑永久层是否被稀释或被摘要改写。

三、触发阈值怎么定

不要按”满了再压”来设计。经验值是：输入占用达到窗口的 50%～60% 就开始压缩，给后续轮次留出余量。同时设三条硬触发：

• 轮次数达到阈值（例如每 8 轮压缩一次）
• 单轮工具返回超过固定字节（大日志先截断再摘要）
• 检测到重复动作（同一工具、同一参数被调用两次）→ 强制重整状态

四、实施顺序建议

如果只能做一件事，先做结构化留存；第二步加滚动摘要兜底历史；第三步再上检索式记忆解决回溯问题；分层压缩最后做，它更像架构收敛而不是新功能。

五、验收：怎么知道压缩真的有效

用同一批长任务跑对照实验，只看三个指标：任务完成率、平均总 token 消耗、关键约束违反率。如果压缩之后完成率没掉、约束违反率下降、成本下降，说明压缩路径是对的。只看成本下降、不看完成率，是这类优化最容易犯的错误。

上下文管理是 2026 年 Agent 工程的基本功。模型能力的提升会让窗口更长，但永远不会让”把最重要的信息留在最显眼的位置”这件事失去意义。