Codex 长对话 Context 压缩与最佳实践
一、为什么会出现 Token 爆炸
在 Codex、Claude Code、Cline、RooCode 等 Agent 工具中，真正消耗 Token 的通常不是用户输入，而是：
- 历史对话
- 系统 Prompt
- 工具 Schema
- RAG 检索内容
- 代码扫描
- XML / SQL / 日志
- Reasoning 推理
尤其是以下开发场景：
- Spring Boot
- 达梦数据库（DM8）
- Oracle
- Vue3 + TypeScript
- 大型 SQL
- Mapper XML
- 长日志排错
这些都属于高 Token 密度内容。
二、为什么输入很少，累计 Token 很大
例如：
累计 Token：852.1M 输入：76.8M 输出：4.0M
原因：
- 模型会重复发送历史消息
- Agent 会重新扫描代码
- 工具调用会返回大量 JSON
- Reasoning 模型会产生隐藏推理 Token
- 长上下文会不断重复进入 Attention
因此：
真实内部 Token 可能是用户可见 Token 的 5~20 倍
三、真正正确的做法
不要依赖无限长对话。
最佳实践：
短 Session + 阶段性总结 + AGENTS.md 永久规则 + SESSION.md 状态恢复
四、最佳 Context 压缩时机
推荐阈值
| Context 使用率 | 状态 | 建议 |
|---|---|---|
| 0% ~ 50% | 安全 | 正常开发 |
| 50% ~ 70% | 开始变重 | 准备压缩 |
| 70% ~ 85% | 风险区 | 立即 compact |
| 85% 以上 | 高危 | 容易降智 / 遗忘 |
五、如何判断模型已经开始“失忆”
1. 开始重复读文件
Reading UserService.java... Reading UserService.java... Reading UserService.java...
说明模型已经装不下旧上下文。
2. 忘记之前的约束
例如：
你刚说： 达梦不能用 limit
结果模型又生成：
LIMIT 10
说明重要上下文已经被挤出。
3. 重新分析整个项目
我先分析一下项目结构...
说明模型已经忘记架构。
4. Tool Call 明显变慢
通常是 Context 已经过长。
5. 开始输出大量废话
为了确保系统稳定性，我们可以进一步优化...
但没有真正代码。
说明有效上下文已经严重稀释。
六、最重要：不要依赖自动 compact
自动 compact 会：
- 丢失细节
- 丢失 Tool Output
- 丢失架构决策
- 多轮 compact 后质量明显下降
因此：
不要一直聊到 95% 再 compact
正确做法：
60% ~ 70% 主动生成阶段摘要
七、正确工作流（非常重要）
Step 1：阶段结束后生成状态摘要
例如：
- 修完 Redis
- 修完 SQL
- 修完 CORS
- 修完分页
让 Codex 输出：
当前工作状态摘要
Step 2：保存为 SESSION.md
project/ ├── AGENTS.md ├── TASK.md ├── SESSION.md ├── TODO.md └── docs/
Step 3：开启新 Session
/new
Step 4：恢复上下文
请先阅读： 1. AGENTS.md 2. TASK.md 3. SESSION.md 然后继续开发。
八、AGENTS.md 的真正用途
AGENTS.md 用于保存：
- 架构规则
- 代码规范
- SQL 规范
- 数据库兼容性
- 接口约束
示例：
# SQL Rules - 禁止 select * - 达梦兼容优先 - LISTAGG 替代 GROUP_CONCAT - 分页统一 ROW_NUMBER() # Backend Rules - Controller 不写业务逻辑 - Result<T> 统一返回
九、SESSION.md 的真正用途
SESSION.md 不是聊天记录。
而是：
可恢复工作状态
推荐内容：
- 当前目标
- 已完成内容
- 修改过的文件
- 当前 Bug
- 架构决策
- 下一步计划
十、推荐的 Context 压缩 Prompt
请生成“可恢复工作状态摘要”，用于新 Session 恢复上下文。 保留： 1. 当前任务目标 2. 已完成内容 3. 关键架构决策 4. 修改过的文件 5. 未解决问题 6. 下一步计划 7. 关键错误日志 要求： - 使用 markdown - 使用 checklist - 不要解释过程 - 不要自然语言总结 - 保留精确路径 - 保留关键 SQL - 控制在 1200 token - 输出必须适合 AI 继续接手开发
十一、真正最省 Token 的技巧
不是压缩聊天。
而是：
限制扫描范围
错误：
分析整个项目
正确：
只分析： - UserMapper.xml - UserService.java 不要扫描其他目录
这个通常能节省几十倍 Token。
十二、推荐 Session 时长
| 任务类型 | 建议时长 |
|---|---|
| 普通聊天 | 2~3小时 |
| SQL 排错 | 30~60分钟 |
| 大型重构 | 1小时 |
| Debug | 30分钟 |
十三、最终推荐工作流
AGENTS.md ← 永久规则 TASK.md ← 当前目标 SESSION.md ← 阶段状态 TODO.md ← 待办事项 ARCHITECTURE.md ← 架构说明
每次新 Session：
请先阅读： 1. AGENTS.md 2. TASK.md 3. SESSION.md 理解后继续开发。
十四、核心结论
长对话的问题，不是 Token 贵。
而是：
模型会逐渐失忆
因此：
短 Session + 阶段摘要 + 文件化状态 + 限制扫描范围
才是目前 Agent 编程最稳定的方案。
