AI agent Context Compaction、Reset 与 Memory Write:什么时候压缩,什么时候清空重来

HTMLPAGE 团队
16 分钟阅读

不是所有上下文问题都该靠摘要解决。本文讲清 compaction、reset 和 memory write 三种动作各自解决什么问题、什么时候触发,以及怎样避免把关键约束压没。

#AI agent #Context Management #Memory #工程实践

上下文开始变长时,很多系统只有一个默认动作:做摘要。短期看这很合理,毕竟 summary 能立刻把 token 压下来;但真正上线后你会发现,摘要并不是万用修复。它会保住一部分信息,也会重写一部分信息,而最危险的 bug 往往就出在这里。

真实系统里,至少有三种完全不同的动作:compaction、reset、memory write。它们解决的问题不一样,代价也不一样。如果三者不分,结果通常是两头失控:要么上下文越来越脏,要么系统把关键约束越压越平。

建议先结合 AI Agent 记忆淘汰与摘要策略AI agent Session Store 设计AI agent 上下文预算分配AI agent Eval Dataset 构建实战 一起看。

别把 compact、reset 和 memory write 当成一件事

三者最核心的差别,可以先用一张表讲清:

动作它做什么适合什么场景最大风险
compaction压缩当前上下文,保留执行连续性长会话但仍想沿着当前 run 继续做关键约束被摘要抹平
reset清空当前上下文,让新进程拿少量 handoff 重新开始模型已经发散、焦虑或上下文污染严重handoff 信息不够,重新开局失真
memory write把稳定事实写入长期或会话记忆明确可复用的偏好、规则、事实沉淀把临时噪音写成长期事实

如果系统遇到任何上下文压力都只会 compact,说明它根本没有决策层,而只是在做体积压缩。

什么时候 summary 够用,什么时候必须 reset

compaction 适合的信息有一个共同点:它们仍然属于当前任务,而且只是太长,不是太乱。比如:已完成步骤、已验证事实、剩余待办、当前工具限制。

但如果你已经看到这些信号,继续 compact 往往只会越压越糟:

  • 模型开始为了“收尾”而提前结束任务
  • 同一约束在不同轮里反复漂移
  • 任务目标被中间草稿覆盖
  • 工具失败历史太多,当前上下文充满噪音

这时候更合理的动作不是继续写摘要,而是 reset:给新一轮一个干净上下文,再通过一份结构化 handoff 只带走真正必要的状态。

失败案例:摘要保住了目标,却把“不能做什么”压没了

一个写作 agent 曾把 20 轮上下文压成 1 段 summary,只保留了目标、已完成内容和下一步计划。结果下一轮模型重新起跑时,完全忘了用户在第 4 轮明确提出的硬性约束:不能引用未核实数据。

事故的根因不是摘要质量差,而是系统把“用户硬约束”和“任务进度”混在同一个摘要里处理了。目标通常会被模型优先保留,否定性约束反而更容易丢。

更稳的修复方式不是让 summary 写得更长,而是把保留对象分槽:

  • 用户硬性约束单独槽位,不参与普通滚动摘要
  • 当前任务状态独立槽位,可被压缩
  • 已验证证据单独槽位,只保留引用和来源

这样 compaction 就不是“一段话概括全部”,而是按信息类型做保留。

判断该写入 memory,最关键的是“跨 run 是否仍成立”

很多团队把“模型刚刚提炼出的有用结论”直接写进长期记忆,这是另一个常见问题。判断能不能写 memory,最实用的标准不是“看起来有用”,而是:

  • 这个事实跨 run 是否仍成立
  • 它是否已经被验证
  • 它是否值得污染后续任务的默认上下文

比如“用户偏好中文输出”可以写入会话或长期记忆;“本次任务里草稿第二版比较接近目标”就更适合留在当前 run,不应该升级成长期事实。

一个最实用的决策顺序

与其问“上下文太长怎么办”,不如按下面这个顺序判断:

  1. 信息是否仍属于当前 run 且只是过长:优先 compact
  2. 当前 run 是否已经明显发散或污染:优先 reset
  3. 某条事实是否跨 run 仍有效:才考虑 memory write

这个顺序的价值在于,把“减少 token”放回次要目标,把“保留正确决策条件”放回首要目标。

Context 治理 Checklist

  • compaction、reset 和 memory write 是否被当作三种不同动作建模
  • 用户硬约束是否与普通摘要分槽保存
  • 触发 reset 的条件是否明确,而不是等系统彻底跑偏才重开
  • memory write 是否要求验证和跨 run 稳定性
  • 评测里是否专门覆盖“摘要后约束丢失”的回归样本
  • handoff 是否能支撑 reset 后的新进程继续工作,而不是重做全部推理

真正的边界

上下文治理的难点,从来不是“能不能压缩”,而是“该保留哪种连续性”。compaction 保的是当前 run 的延续性,reset 保的是重新获得清晰推理的能力,memory write 保的是跨 run 可复用的稳定事实。三者分清后,系统才不至于把所有问题都粗暴压成一段摘要。

延伸阅读: