上下文工程：窗口守卫、卫生、压缩与恢复
这一章关注一个目标：会话越长，系统越容易被“上下文”拖垮。要做到长期可用，你需要把上下文当成一条可恢复的状态机来做。
总公式（工程视角）
上下文稳定 ≈ 窗口预检 + 历史卫生 + 配对修复 + 压缩重试 + 超时快照 + 溢出恢复
相关概念入口：
1) 运行前窗口守卫：明知会炸就别进 attempt
关键点：
- 窗口过小应在
run层直接阻断（避免昂贵调用） - “警告阈值”与“硬下限”要同时存在：既提示风险，也能强制阻断
你在排障时能看到的信号：
- 直接返回“窗口不足/上下文过小”类错误
- 这类错误不应进入回退或重试循环
2) 历史卫生：固定顺序，避免 provider 400
要点不是“做什么”，而是“顺序”：
- 先清洗与校验转录（按 provider 约束）
- 再做 turn 限额（避免无限增长）
- 最后修复
tool_call/tool_result配对（避免截断后留下孤儿结果）
入口：
3) 压缩重试：不要在压缩未稳定时判定完成
要点：
- 订阅层需要显式暴露
waitForCompactionRetry语义 - “压缩中超时”要能选到可用快照，而不是把半压缩状态返回给用户
4) 溢出恢复路径：压缩 → 截断 → 可读错误
当遇到上下文溢出（overflow）时，恢复顺序建议固定：
- 先尝试压缩（有限次）
- 再尝试裁剪超大工具结果（降损）
- 仍失败就返回可读错误（提示 reset 或更大窗口模型）
验收清单（建议你按会话压力测试）
- 长会话多轮后仍可稳定回复（messages 增长受控）。
- 不存在孤儿
tool_result（截断与修复配对正确）。 - 压缩重试期间不会提前返回“完成”。
- 压缩中超时仍能返回一致快照，而不是空响应或脏状态。
- 窗口过小会在 run 前被阻断。