约 8 分钟4 张卡

上下文压缩

上下文压缩在对话或 Agent 任务接近窗口上限时，用更短的表示替换旧内容，让任务能继续执行。压缩一定会丢信息，本文说明几种常见方案、触发时机、必须保留的信息，以及如何检查压缩是否破坏了任务。

1. 面试核心

先记住这几条，再读正文

常见方案有截断、滑动窗口、摘要、工具结果清理、外部存储加检索。它们在信息保留、成本和实现复杂度上不同，长任务通常组合使用。卡 · 压缩方案
压缩时必须保留的是任务目标、用户约束、已做出的决定、已修改的产物位置、未解决的错误和下一步；可以丢弃的是已被后续结果取代的中间输出和冗长的原始工具结果。卡 · 保留什么
触发方式有按 Token 阈值自动触发、按轮次触发和用户手动触发。阈值要给本轮输入和输出留出空间。卡 · 触发时机与合并
工具结果是长任务中增长最快的部分，优先清理已使用过的旧结果，保留调用记录和结论。卡 · 压缩方案
压缩后的事实以实际状态为准：恢复任务时重新检查文件、测试和外部系统，不把摘要中的“已完成”当成验收结果。

2. 压缩方案

卡 · 对话超过上下文窗口时，有哪些处理方案？滑动窗口和动态摘要各有什么优缺点？卡 · Tool Result 如何淘汰或压缩？

方案	做法	优点	缺点
截断	删除最早的消息	简单、无额外调用	早期目标和约束会丢失
滑动窗口	只保留最近 N 轮	成本可控，近期信息完整	窗口外信息全部丢失
摘要	用模型把旧历史总结成一段文字	保留要点，长度可控	多一次模型调用；摘要可能遗漏或改写细节
窗口 + 摘要	旧内容摘要，最近 N 轮保留原文	兼顾远期要点和近期细节	需要设计摘要格式和合并方式
工具结果清理	把旧工具结果替换为占位或简短结论	收益大，不影响对话主线	之后需要时要重新调用工具
外部存储 + 检索	历史写入数据库或文件，按需检索	理论上不丢原文	依赖检索质量，增加延迟

摘要失败的典型表现是“细节被平均化”：用户最初说“不要改公共接口”，摘要写成“用户希望改动尽量小”，后续步骤就可能修改接口。因此摘要提示要指定必须逐字保留的内容类型。

3. 保留什么

卡 · 压缩或摘要一定会丢失信息，如何让信息丢失最小化？

压缩前先把信息分类：

必须保留：任务目标和验收条件；用户明确提出的约束和偏好；已经做出的关键决定及原因；已修改或生成的文件、数据位置；未解决的错误信息和失败尝试；当前进度和下一步。
可以摘要：探索过程中读过的代码和文档，只保留结论和位置；讨论过但被否定的方案，保留“已否定及原因”。
可以丢弃：已经被后续结果覆盖的中间输出、重复的工具结果、寒暄。

结构化摘要比自由文本更不容易遗漏：

## 目标
修复 /api/orders 分页在最后一页返回重复数据的问题。
## 约束
- 不修改响应字段（前端已上线）。
## 已完成
- 定位到 OrderRepository.page()：offset 计算使用了 page 而非 page-1。
- 已修改 src/order/repo.ts:41，单测 order.repo.test.ts 通过。
## 未解决
- 集成测试 orders.e2e 超时，原因未确认。
## 下一步
- 本地启动数据库后重跑 e2e。