历史截断怎么选
上下文超出预算时的删减方式直接影响体验：按时间滑窗简单稳定但会丢早期约束，按重要性保留更贴近需求但要标注重要度，摘要替换省 token 但有信息损耗。无论选哪种，都要守住两条底线：系统提示与输出契约永不裁剪，最近一轮完整保留。
基本信息
| 策略 | 时间滑窗、重要性优先、摘要替换、规则加摘要 |
|---|---|
| 保底规则 | 系统约束不裁、最近一轮不裁、更正说明随更正一起留 |
| 可观测 | 裁剪动作记日志：裁掉了哪一段、多少条 |
| 触发时机 | 提前触发，留出安全余量，避免临界点抖动 |
| 选择依据 | 任务对早期约束的依赖程度，比 token 成本更关键 |
典型使用场景
- 客服会话：早期确认过的退换条件必须保留，适合规则加摘要
- 代码助手：技术选型与接口约定属高重要度，按重要性保留
- 文档问答：检索片段随轮次替换，历史问答压缩成摘要即可
- 长流程任务：未决事项单独留存，避免被滑窗裁掉
- 评测复现：固定截断策略后再比较版本效果，变量才可控
保底规则
保底规则
1 系统提示与输出契约永不裁剪
2 最近一轮完整保留，不做压缩
3 被更正的信息连同更正说明一起保留
4 未决事项单独存字段，不依赖历史原文
5 裁剪动作记日志: 裁剪段范围、条数、触发原因
# 提前触发: 在达到预算上限前留出一段安全余量截断策略对比
| 策略 | 做法 | 取舍 |
|---|---|---|
| 时间滑窗 | 只保留最近若干轮 | 实现简单；早期约束会丢失 |
| 重要性优先 | 约束、结论、未决项优先保留 | 需要标注重要度，实现更复杂 |
| 摘要替换 | 旧轮压缩成摘要 | 省 token；存在信息损耗 |
| 规则加摘要 | 约束白名单加其余摘要 | 兼顾稳定与成本；维护两套逻辑 |
裁剪不记日志时，用户说“刚才明明提到过”将无从查证；问题会以模型健忘的形式被反复归因错误。