21Compaction vs Reset

这是 2025-11 之后 Anthropic 工程文档的关键澄清:summarization-as-compaction is insufficient for very long tasks; the harness must tear down context(原文)。两套机制必须分清。

Compaction(摘要式压缩):

· 机制:让模型把历史 messages 摘要成短版本,在同一 context 里继续推进

· 触发:SDK 自动,~95% context 时

· 优点:连续性好,模型不会突然"切片",体验流畅

· 缺点:信息漂移——多次压缩后关键决策模糊,模型可能"误以为做过某事";摘要质量看模型水平

Context Reset(撕掉重启):

· 机制:整个 context 撕掉,从 progress.md / plan.md 等共享文档重新加载必要状态,fresh start

· 触发:harness 主动判断(任务 phase 切换、token 用量 ≥ 60-70%),或显式由用户/上层 agent 决定

· 优点:context 干净无漂移,模型不会"记错"

· 缺点:必须有完备的 note-taking(见 #20 支柱 2),否则 reset 等于丢信息

本质对比:

何时用哪个(决策树):

任务有完备共享文档 + 任务 phase 切换    → Reset
                                          (例:写完前端切到后端模块)
长任务跨多 session                       → Reset(配合 #17 Long-Running)
连续探索、共享文档不完备                 → Compaction
单 session 中等长度、信息可摘要          → Compaction(SDK 自动)
不确定要不要 reset                       → 加 PreCompact hook 拦截后判断

场景:用户让 agent 重构 50 个文件的 auth 模块,任务跑了 3 天。

方案 A:纯 Compaction
─────────────────────────
Day 1:context 渐涨 → 95% → compaction (摘要 50K → 10K)
      继续 → 95% → compaction 2 (摘要 50K → 10K,但 10K 历史已压过一次)
      继续 → compaction 3 ...
Day 2:agent 开始"觉得"自己改过某个文件,实际没改
      用户发现 bug:验证逻辑被改了两次(模型忘了上次改过)
Day 3:agent 重复劳动,用户失去信任

方案 B:Reset + Note-taking
─────────────────────────
Day 1:context 涨到 60% → harness 触发 reset
      → 把当前状态 dump 到 progress.md(结构化:已改文件、待改、阻塞)
      → 撕 context → 新 session 读 progress.md 继续
Day 2 早上:用户回来,新 session 启动
      → 读 plan.md + progress.md → 知道继续从哪里做
Day 3:任务完成,progress.md 显示完整流水线

差异核心:Compaction 假设"摘要无损",实际多轮压缩后信息漂移;Reset 通过 note-taking 持久化,把"记忆"从 context 移到 文件,无漂移。