智识花园
博客2026/8/2417 分钟阅读

Codex长任务上下文接力机制配图存档

Codex 长任务中的上下文是如何处理的？

引言

Codex 在目标模式下可以持续执行很长时间，有些任务甚至会运行数小时。

这很容易让人产生一个疑问：

模型的上下文窗口明明是有限的，为什么 Codex 可以持续工作这么久？
除了压缩上下文，它还做了哪些处理？上下文压缩后，就不会溢出了吗？

答案是：

Codex 并不是依靠一个无限大的上下文窗口工作，而是通过上下文压缩、文件系统、工具调用、Git 状态和测试结果等机制，让任务跨越多个上下文窗口继续执行。

Codex 通过压缩任务状态与外部状态锚点跨越多个有限上下文窗口

一、Codex 的上下文不是无限的

Codex 执行任务时，以下内容都会占用上下文：

  • 用户的原始要求
  • 模型的分析和计划
  • 已读取的代码
  • 命令执行结果
  • 编译和测试日志
  • 文件修改记录
  • 后续补充要求
  • 工具调用返回的信息

随着任务持续进行，上下文会不断增长。

当上下文接近模型允许的上限时，Codex 不会一直把所有历史原样保留，而是会对已有内容进行压缩，然后在新的可用上下文中继续工作。

大致流程如下：

用户提出任务
    ↓
Codex 分析、读取文件、修改代码
    ↓
执行命令、编译和测试
    ↓
上下文不断增长
    ↓
接近上下文阈值
    ↓
压缩已有任务状态
    ↓
释放新的上下文空间
    ↓
继续执行任务
    ↓
必要时再次压缩

因此，Codex 的长任务能力本质上是：

使用多个有限的上下文窗口，连续完成同一个任务。

二、上下文压缩并不是简单摘要

上下文压缩并不只是把几十万字概括成几百字。

压缩后的内容通常需要保留：

  • 用户的最终目标
  • 不可违反的约束
  • 已完成的工作
  • 已修改的重要文件
  • 关键技术决策
  • 已排除的错误方向
  • 当前遇到的问题
  • 下一步需要执行的操作
  • 重要测试结果
  • 环境和依赖信息

压缩完成后，Codex 会把这些高价值状态放入新的上下文窗口中，再继续执行。

可以把它理解为：

完整历史记录
    ↓
提取关键任务状态
    ↓
保留近期高价值内容
    ↓
组成新的工作上下文

这类似于一个开发人员整理工作笔记：

登录模块已经修改完成，目前还剩两个测试失败。
项目必须兼容 Java 17，不能修改数据库结构。
下一步需要修复 refresh token 的并发问题。

开发人员不需要记住之前每一条命令和每一句讨论，但需要记住任务状态和关键约束。

三、为什么压缩后还能继续工作？

因为 Codex 的任务状态并不全部保存在上下文里。

真正支撑长任务的，是以下几种机制共同作用。

四、文件系统相当于长期记忆

代码、配置文件、测试文件和构建产物都保存在工作目录中。

例如 Codex 已经完成了以下修改：

修改 src/auth/login.ts
新增 src/auth/token.ts
更新 package.json
修复部分测试

即使这些修改过程已经从上下文中被压缩，文件本身仍然存在。

Codex 可以重新执行：

git status
git diff
cat src/auth/login.ts
npm test

重新获取当前项目的真实状态。

所以：

  • 上下文保存的是“我现在在做什么”
  • 文件系统保存的是“实际已经做了什么”

这也是为什么编程任务特别适合长时间执行。

五、Codex 不需要把整个项目放进上下文

大型项目可能有几十万甚至几百万行代码，不可能全部放入上下文。

Codex 通常会采用按需读取的方式：

搜索文件或类名
    ↓
定位相关模块
    ↓
只读取需要的代码
    ↓
完成修改
    ↓
运行测试
    ↓
根据报错继续读取其他文件

例如，它不需要长期记住整个仓库，只需要在处理登录问题时读取：

AuthController
TokenService
UserRepository
相关测试文件

当任务切换到其他模块时，再重新搜索和读取。

这种方式可以显著减少上下文占用。

六、工具调用形成持续的执行循环

Codex 并不是一次生成几个小时的全部操作。

它通常按照下面的循环执行：

分析当前状态
    ↓
决定下一步
    ↓
调用工具
    ↓
获取执行结果
    ↓
根据结果继续判断

工具可能包括：

  • 搜索文件
  • 读取代码
  • 修改文件
  • 执行 Shell 命令
  • 编译项目
  • 运行单元测试
  • 查看 Git diff
  • 检查日志
  • 查询数据库
  • 调用项目中的脚本

每一次循环只需要处理当前阶段的问题。

因此，Codex 不需要一次性记住未来几个小时的全部步骤。

七、Git 可以帮助恢复任务状态

Git 是长任务中非常重要的外部状态来源。

Codex 可以通过以下命令确认工作进度：

git status
git diff
git diff --stat
git log --oneline

这些命令可以回答：

  • 修改了哪些文件
  • 新增了哪些文件
  • 哪些修改还没有提交
  • 当前分支是什么
  • 最近完成了哪些阶段
  • 是否出现了意外修改

如果任务按阶段提交 Git commit，即使上下文压缩损失了一些信息，Codex 也可以通过提交记录恢复进度。

例如：

feat: add token refresh service
test: add authentication integration tests
fix: handle concurrent refresh requests

这些提交记录本身就是任务检查点。

八、测试和编译结果可以重新计算

很多编程状态不需要永久保存在上下文中，因为可以重新执行得到。

例如：

npm test
mvn test
flutter analyze
pytest
gradle test

重新执行后，Codex 可以知道：

  • 当前有多少测试失败
  • 哪个模块编译失败
  • 哪一行代码存在问题
  • 修改是否破坏了已有功能
  • 问题是否已经解决

所以，即使模型忘记了之前某次测试的完整输出，也可以再次运行测试。

这相当于使用客观结果恢复记忆。

九、上下文压缩后还会不会溢出？

正常情况下，不容易因为历史不断增加而直接溢出

当上下文接近阈值时，系统会触发压缩，释放新的空间。

必要时，这个过程可以重复多次：

上下文窗口 1
    ↓ 压缩
上下文窗口 2
    ↓ 压缩
上下文窗口 3
    ↓ 压缩
继续执行

因此，压缩机制解决的是：

单个上下文窗口无法容纳整个长任务历史的问题。

但这并不代表上下文永远不会出现问题。

十、上下文压缩不是无损的

任何压缩都可能造成信息损失。

比较容易丢失的内容包括：

1. 很早提出的细节约束

例如：

必须兼容 Windows 7，不能调用 Windows 10 才支持的 API。

如果这个约束没有被识别为重要信息，经过多次压缩后可能会被弱化。

2. 技术方案背后的原因

模型可能记得：

最终采用了方案 B。

但可能忘记：

方案 A 会产生线程安全问题，所以不能再使用。

这样后续就可能重新走回已经排除的方向。

3. 临时发现的问题

例如：

某个错误只有在生产环境的特定配置下才会出现。

如果这个信息没有写入文档、代码注释或测试中，压缩后可能被遗漏。

4. 用户中途补充的小要求

长任务中，如果用户不断增加新的要求，一些较小的要求可能在多次压缩后变得不明显。

5. 多次压缩造成的累积偏差

任务持续时间越长，经历的压缩次数越多，早期低优先级信息被淡化的概率越大。

十一、哪些情况下仍可能失败？

即使支持上下文压缩，长任务仍可能因为其他原因中断或偏离目标。

单次工具输出过大

例如一次性输出几十万行日志，可能在系统来得及压缩之前就占用大量上下文。

比较好的方式是：

tail -n 200 app.log
grep -n "ERROR" app.log

而不是直接读取完整日志。

任务主要依赖口头信息

如果关键要求只存在于聊天中，没有写入项目文档、测试或配置，压缩后更容易丢失。

用户频繁改变目标

如果任务不断切换方向，压缩后的状态可能包含互相冲突的要求。

外部环境发生变化

例如：

  • 其他开发人员同时修改代码
  • 依赖版本被更新
  • 数据库数据发生变化
  • 远程接口返回结果变化

这些都可能使之前的判断失效。

模型进入重复循环

Codex 可能出现：

修改代码
→ 测试失败
→ 再次修改
→ 又出现类似错误
→ 重复尝试

上下文压缩可以让它继续执行，但不能保证它一定能找到正确方向。

运行环境或产品限制

任务也可能因为以下原因停止：

  • 网络断开
  • 权限不足
  • 命令执行超时
  • 服务端异常
  • 额度限制
  • 容器或运行环境关闭

因此：

上下文不溢出，不等于任务永远不会中断。

十二、如何提高 Codex 长任务的成功率？

最有效的方法，是把关键状态写入项目文件，而不是完全依赖模型记忆。

可以在项目根目录创建一个 TASK.md：

# 当前任务

## 最终目标

将旧认证模块迁移到 OAuth2。

## 不可违反的约束

- 使用 Java 17
- 不修改数据库表结构
- 保持现有 API 向后兼容
- 必须通过现有全部测试

## 已完成

- 新增 TokenService
- 完成 access token 验证
- 修复 8 个单元测试

## 当前问题

- refresh token 并发测试失败
- Windows 环境路径测试失败

## 下一步

1. 排查 refresh token 的锁机制
2. 修复并发测试
3. 运行完整测试
4. 检查 Git diff

## 验证命令

```bash
mvn test


还可以在提示词中要求 Codex：

> 每完成一个阶段，更新 TASK.md，记录已完成内容、关键决策、剩余问题、下一步和验证命令。

对于特别长的任务，还可以要求：

> 每完成一个独立阶段，创建一次 Git commit，确保提交信息能够说明该阶段完成了什么。

这样，即使上下文被多次压缩，Codex 仍然可以通过：

- `TASK.md`
- Git 提交记录
- 当前代码
- 测试结果
- 构建日志

恢复任务状态。

---

## 十三、可以怎样理解 Codex 的长任务机制？

可以使用下面这个类比：

| Codex 机制 | 类似人类开发者的能力 |
|---|---|
| 当前上下文 | 工作记忆 |
| 上下文压缩 | 整理工作笔记 |
| 文件系统 | 长期存储 |
| Git | 版本记录和检查点 |
| 测试 | 客观验证 |
| 搜索和读取文件 | 重新查资料 |
| 工具调用循环 | 持续执行和反馈 |
| TASK.md | 项目任务清单 |

Codex 并不是把所有信息永久记在“脑子”里。

它更像一个开发人员：

1. 记住当前目标和关键问题；
2. 把代码保存在项目中；
3. 把进度记录在 Git 和任务文档中；
4. 需要细节时重新读取；
5. 通过测试确认结果；
6. 工作记忆满了以后，整理成更短的工作笔记。

---

## 十四、最终结论

Codex 能执行数小时的长任务，并不是因为它拥有无限上下文。

它依赖的是一整套组合机制：

```text
上下文压缩
    +
文件系统
    +
按需读取
    +
工具调用循环
    +
Git 状态
    +
测试和编译结果
    +
任务文档和检查点

其中：

  • 上下文负责保存当前工作状态；
  • 压缩负责释放新的上下文空间；
  • 文件系统保存实际成果；
  • Git 保存修改历史；
  • 测试负责重新验证结果；
  • 工具负责重新获取已经遗忘的细节。

因此，上下文压缩能够显著降低长任务因为历史过长而中断的概率，但它不是完全无损，也不能保证任务永远不会失败。

更准确的说法是：

Codex 不是拥有无限上下文，而是能够利用有限上下文、外部环境和多次压缩，跨越多个上下文窗口持续工作。

参考资料