上下文压缩

问题：压缩之后，Agent 忘了自己改过什么

当一次调试会话跑到 178 轮、上下文逼近窗口上限，常见做法是截掉前半段或整体摘要重生成。问题在于：摘要器"自觉"保留的信息往往不含工件轨迹——文件路径只写到目录、函数名被抹成「改了配置」、错误码消失。下一个会话因此要重新 grep、重新读文件，甚至复现同一个 bug。

真正该优化的目标不是最小 token，而是每任务 token：完成任务消耗的总 token，含压缩丢关键信息后的重新获取成本。

工作流：先定路线，再保工件，最后用探针验收

1. 选压缩路线

- anchored 锚定迭代摘要：维护带固定章节的结构化持久摘要，触发时只摘要新截断段并合并，避免每轮整体重生成丢细节。长会话、需追踪文件时首选。
- opaque 不透明压缩：压缩比可达 99%+，但完全不可解释、无法验证保留了什么，调试与工件追踪关键时禁用。
- regenerative 再生式全摘要：摘要可读性优先、会话有明显阶段边界时使用，弱点是跨轮累积丢细节。

1. 先解决工件轨迹：在压缩循环里显式保留创建/修改/只读文件的全路径、函数名与变量名、错误码与错误信息。最好用独立工件索引或文件状态追踪，而不是指望摘要器自己捕获。
2. 强制章节结构化：intent、files_modified、decisions、next_steps 每节作为摘要器必填清单，使遗漏可见而非静默。可按领域加节，如调试 Agent 加「根因/错误信息」，迁移 Agent 加「源/目标 schema」。任何显式 schema 都优于自由文本。
3. 选触发策略：固定阈值（70–80% 利用率）简单但可能过早；滑动窗口让上下文大小可预测；重要性打分保信号但复杂；任务边界摘要干净但时机不可预测。编码 Agent 默认用「滑动窗口 + 结构化摘要」，有明显阶段切换（调研→实现→测试）时用任务边界。
4. 用探针而非指标评估：ROUGE 与嵌入相似度抓不住功能质量。压缩后直接提问：召回型（「原错误信息是什么？」）、工件型（「改了哪些文件？」）、延续型（「下一步该做什么？」）、决策型（「关于 Redis 我们决定了什么？」）。答错或幻觉即视为丢失。
5. 六维打分：准确性、上下文感知、工件轨迹、完整性、连续性（能否不重取就续做）、指令遵循。

输出与互操作

下游消费的是 HandoffSummary 工件：路线、强制章节、触发策略与 probe_checks 校验结果。配套的 context-degradation 处理退化诊断、context-optimization 提供其他降本手段、evaluation 复用探针式测试、memory-systems 承接长期记忆。

适用边界

本技能只做「摘要 / 压缩 / 交接」。通用降本手法（遮蔽、前缀缓存、分区）请用 context-optimization；若长上下文本身在失败，先诊断退化原因再考虑压缩；不摘要直接写文件走 filesystem-context；跨会话长期语义记忆属于 memory-systems。