Codex 用久了越来越慢？我的上下文管理小技巧

最近用 Codex 做项目时发现一个问题：

一个 Thread 聊久了以后，上下文越来越满。即使进行了 Compaction，没聊几轮又满了，而且模型回复速度也越来越慢。

后来我发现，这其实和 Codex 的 Context 管理机制有关。

1. 为什么压缩完很快又满了

Compaction 并不是“把上下文清空”。

更准确地说，是：

把以前大量的上下文压缩成更小的状态，然后继续带着这些重要信息工作。

可以简单理解成：

压缩前：100%

↓ Compaction

压缩后：50%左右

↓ 继续工作

读取代码
+ grep 搜索
+ git diff
+ 编译日志
+ 测试日志
+ Tool Call
+ Tool Result

↓

上下文很快再次变大

所以压缩以后，并不是重新回到一个全新的 Thread。

---

2. 为什么 Coding 场景特别容易占满 Context

我们表面可能只问了一句话：

帮我看看这个 Bug 为什么报错

但是 Codex 背后可能执行：

读取项目结构
↓
搜索相关代码
↓
读取多个文件
↓
查看日志
↓
执行命令
↓
运行测试
↓
查看测试结果
↓
继续修改代码

这些 Tool Call 和 Tool Result 都可能成为后续模型继续工作的上下文。

所以一次复杂任务产生的 Context，可能远远大于我们看到的聊天文字。

---

3. 为什么越聊感觉越慢

一个 Thread 使用很久以后：

聊天历史
+ 历史压缩内容
+ 代码
+ Tool Result
+ 日志
+ 当前任务

会越来越多。

模型每次工作都需要处理当前 Context，因此 Context 很大时，可能会增加处理负担。

当然，速度还会受到模型、网络、工具执行等因素影响，并不一定全部是 Context 导致的。

---

4. 不要一个 Thread 从项目开始用到项目结束

我现在更推荐：

一个项目
│
├── Thread 1：登录模块
├── Thread 2：首页改版
├── Thread 3：用户管理
├── Thread 4：学生分析
└── Thread 5：Bug 排查

也就是：

一个 Thread 尽量围绕一个相对独立的任务。

这样有几个好处：

• Context 更干净
• 不容易受到旧任务干扰
• Compaction 次数更少
• 新任务目标更加明确

---

5. Thread 太长以后怎么办

如果已经连续 Compaction 几次，并且明显感觉越来越慢，我一般不会继续硬聊。

先让 Codex 做一次“工作交接”：

请把当前任务整理到 .codex/TASK.md，包括：

1. 当前任务目标
2. 已完成内容
3. 未完成内容
4. 关键决策
5. 修改过的文件
6. 测试结果
7. 下一步工作

只保留后续继续开发真正需要的信息。

然后新建一个 Thread：

先阅读 AGENTS.md 和 .codex/TASK.md，
了解项目规则和之前的开发进度，
然后继续完成剩余任务。

这样就相当于：

旧 Thread
大量聊天、代码、日志、Tool Result
        ↓
整理
        ↓
TASK.md
        ↓
新 Thread
        ↓
重新获得比较干净的 Context

---

6. AGENTS.md 和 TASK.md 到底有什么区别

这是我刚开始最容易理解错的地方。

AGENTS.md

AGENTS.md 是 Codex 官方支持的项目指导文件。

可以理解成：

这个项目长期使用的“员工手册”。

例如：

- 修改代码后必须执行测试
- 表格操作列统一固定右侧
- 后端接口统一使用现有返回结构
- 不允许随意修改数据库表结构

这些都是长期规则。

Codex 会识别项目中适用的 AGENTS.md。

---

TASK.md

TASK.md 不是什么 Codex 官方特殊文件。

它只是我们自己创建的一份：

任务交接记录。

例如：

当前任务：用户管理页面优化

已完成：
- 查询区域已经修改
- 操作列已经固定右侧

未完成：
- 新增用户弹窗
- 编辑用户弹窗

下一步：
- 完成两个弹窗
- 执行前端测试

需要特别注意：

TASK.md 默认不会自动读取
TASK.md 默认也不会自动更新

我们需要明确告诉 Codex：

先读取 .codex/TASK.md

或者：

任务完成后更新 .codex/TASK.md

---

7. 可以让 Codex 帮我们维护 TASK.md

如果不想每次都提醒，可以在 AGENTS.md 中增加一条规则：

对于持续时间较长的开发任务：

- 使用 .codex/TASK.md 记录任务进度
- 阶段性任务完成后更新 TASK.md
- 记录已完成、未完成、关键决策和下一步
- 新 Thread 开始工作前先读取 TASK.md

这样：

AGENTS.md
=
长期规定“应该维护工作记录”

TASK.md
=
真正保存“现在工作到哪里了”

这个区别很重要。

---

8. 什么时候应该考虑换 Thread

我现在主要看几个信号：

已经连续 Compaction 多次

回复明显越来越慢

旧任务内容越来越多

当前准备切换到完全不同的模块

Codex 经常被以前的需求干扰

出现这些情况时，与其继续堆 Context，不如：

总结任务
↓
更新 TASK.md
↓
新建 Thread
↓
继续工作

---

最后总结

我现在使用 Codex 的习惯是：

AGENTS.md
=
长期项目规则

TASK.md
=
当前任务进度

一个项目
=
可以有很多 Thread

一个 Thread
=
尽量围绕一个阶段性任务

Thread 太长
↓
总结 TASK.md
↓
新建 Thread
↓
继续开发

一句话总结：

不要把 Codex 的 Thread 当成永远不能换的聊天窗口。长期规则放 AGENTS.md，当前进度放 TASK.md，Thread 太长后及时交接并新开 Thread，通常会更清晰、更稳定。