最近在使用 Codex 时，一直被一个问题困扰：长时间连续执行任务后，上下文很容易 “爆掉”，导致任务中断。尝试了各种脚本方案都不太理想，直到我想到用 AI 监督 AI 的思路 —— 让 Claude Code 当监工，盯着 Codex 干活。没想到这个方案不仅解决了上下文问题，还意外地灵活，今天就把完整思路和操作步骤分享给大家。
核心痛点：为什么 Codex 连续工作会 “掉链子”？
在聊解决方案前，先明确下核心问题。Codex 作为代码生成模型，每次执行任务都会依赖上下文（包括历史指令、生成的代码、执行结果等）。当任务链条较长时：
- 上下文会不断累积，超过模型的 token 限制后就会 “爆掉”，直接中断任务；
- 即使没爆，过长的上下文也会让模型响应变慢，甚至出现逻辑混乱；
- 手动拆分任务又太麻烦，每次都要重新输入指令、衔接上下文，效率极低。
之前尝试过用 Shell 脚本监控 Codex 进程，虽然能实现 “完成一个任务就重启”，但遇到任务执行结果异常、需要动态调整指令时，脚本就无能为力了 —— 毕竟脚本只能按固定逻辑执行，没法像人一样 “判断情况、灵活应对”。
解决方案：让 Claude Code 当 “监工”，Codex 当 “工人”
既然脚本的灵活性不够，那不如换个思路：用另一个 AI（Claude Code）来承担 “监工” 的角色，负责管理 Codex 的执行流程。核心逻辑很简单：
- 工人（Codex） ：只负责执行单个具体任务，每次任务用新的 Session 启动，避免上下文累积；
- 监工（Claude Code） ：负责拆分任务、启动 Codex、监控执行状态、完成后重启，同时通过 “子 Agent” 避免自己的上下文爆掉。
整个流程就像工厂里的生产线：监工先把大任务拆成一个个小步骤，然后让工人按步骤干活，工人做完一个步骤就休息（重启 Session），监工则全程盯着，确保流程不中断。
完整实现步骤：3 步让 AI 协作跑通 8 小时任务
接下来是最关键的实操部分，整个方案不需要复杂的代码开发，只要按步骤配置提示词和指令即可，新手也能快速上手。
第一步：给 Codex 搭好 “任务框架”——TODO List + Agents 引导
要让 Codex 每次重启后都知道 “该做什么、怎么做”，必须先给它搭好两个核心文件，相当于给工人准备好 “任务清单” 和 “操作手册”：
1. 生成可分步执行的 TODO List
先让 Codex 自己生成一个详细的任务清单，要求必须是 “可拆解、可验证” 的步骤，比如我要让它处理一个数据清洗 + 可视化的任务，TODO List 大概长这样：
# 数据处理任务TODO List
1. 读取当前目录下的data.csv文件，检查数据结构（输出列名、数据类型、缺失值数量）；
2. 针对缺失值进行处理（数值列用均值填充，分类列用众数填充），生成处理后的clean_data.csv；
3. 对clean_data.csv进行描述性统计（均值、中位数、标准差），输出统计报告；
4. 绘制数据分布直方图（按“用户年龄”“消费金额”两列），保存为histogram.png；
5. 生成数据处理总结文档，包含步骤、结果、异常说明。
这里的关键是 “每个步骤都有明确的输入输出”，比如 “生成 clean_data.csv”“保存为 histogram.png”，这样 Claude Code 才能清晰判断 “这个任务是否完成”。
2. 更新 Agents.md 文件，添加 “continue” 引导
光有 TODO List 还不够，Codex 重启后需要知道 “我现在要继续之前的任务”，所以要在 Agents.md（Claude Code 的配置文件）里添加引导逻辑，核心是告诉 Codex：当收到 “continue to next task” 指令时，自动读取 TODO List，执行下一个未完成的任务，并更新 TODO List 状态。
Agents.md 里需要包含的关键内容：
# Codex任务执行引导
1. 当接收到指令“continue to next task”时，首先读取当前目录下的TODO.md文件；
2. 检查TODO List中未标记“已完成”的第一个任务，执行该任务；
3. 任务执行完成后，在TODO.md中标记该任务为“已完成”（例：[√] 读取data.csv文件...）；
4. 若执行过程中遇到错误（如文件不存在、代码报错），输出详细错误信息后停止，等待进一步指令。
这个引导相当于给 Codex 定了 “工作规则”，让它每次重启后都能按规则继续干活，不需要人工干预。
第二步：让 Claude Code 启动 “监工模式”—— 执行监控指令
配置好 Codex 的 “工作规则” 后，就该让 Claude Code 上岗了。我们需要给 Claude Code 一个明确的 “监工指令”，让它知道要做什么、怎么做：
1. 核心监控指令
直接在 Claude Code 中输入以下指令，这行指令包含了监工的全部职责：
帮我在当前目录下，新开一个agent，使用 export TERM=xterm && codex exec "continue to next task" --full-auto 命令开启一个 codex 进程。注意观察任务执行情况：
1. 如果当前任务完成（任务运行时间较长，可以多等一会，通过检查输出文件/日志判断），就结束当前codex进程；
2. 结束后，重新开一个新的agent，运行相同的codex指令，让它继续执行TODO List中的下一个任务；
3. 每次打开codex和监控它运行，都必须调用一个新的agent（Task Tool）来执行，避免主agent的上下文太长。
2. 指令拆解：为什么要这么写？
export TERM=xterm：这是为了确保终端环境正常，避免 Codex 执行时出现终端兼容问题；codex exec "continue to next task" --full-auto：给 Codex 传递 “继续下一个任务” 的指令，并开启全自动模式（不需要手动确认）；- “每次都开新 agent” ：这是避免 Claude Code 自己上下文爆掉的关键 —— 主 Agent 只记录 “子 Agent 完成了哪个任务”，子 Agent 负责具体的启动和监控，每个子 Agent 的上下文独立，用完就释放，主 Agent 的负担极小。
第三步：验证效果 —— 上下文不爆，任务连续跑
指令输入后，Claude Code 就会开始工作：
- 先启动一个子 Agent，用新 Session 打开 Codex，执行 TODO List 的第一个任务（比如读取 data.csv）；
- 子 Agent 监控 Codex 的执行状态，看到输出 “已生成数据结构报告”“TODO List 已更新” 后，判断任务完成，杀掉当前 Codex 进程；
- 自动启动第二个子 Agent，再次用新 Session 打开 Codex，执行 “填充缺失值” 的任务；
- 重复这个过程，直到 TODO List 中的所有任务都完成。
我测试时，用这个方案跑了一个包含 12 个步骤的数据处理任务，每个步骤平均耗时 20-30 分钟，全程 6 个多小时，Codex 的上下文始终保持在较低水平（每次只加载当前任务的信息），Claude Code 的主 Agent 也只记录了 “完成步骤 1、完成步骤 2...” 的简单状态，完全没有爆上下文的问题。
关键细节：避免踩坑的 3 个核心要点
虽然方案看起来简单，但有几个细节如果没注意，很容易出问题，这里特别提醒大家：
1. Worker（Codex）的 “任务引导” 必须明确
- TODO List 不能太模糊，比如 “处理数据” 这种描述不行，必须是 “处理缺失值并生成 clean_data.csv” 这种有明确输出的步骤；
- Agents.md 里的 “continue” 逻辑要写死，确保 Codex 每次收到 “continue to next task” 都知道该读哪个文件、该更新哪里，不需要额外思考。
2. Manager（Claude Code）必须用 “子 Agent” 监控
这是避免 Claude Code 自己上下文爆掉的关键。如果让主 Agent 直接启动和监控 Codex，那么每次 Codex 的输出信息都会累积到主 Agent 的上下文里，用不了几次就会爆掉；而用子 Agent 的话，每个子 Agent 只负责一次监控，用完就释放，主 Agent 只需要记录 “子 Agent 完成了任务 1”，上下文占用极小。
3. 任务执行时间要预留缓冲
有些任务（比如大数据量的处理、模型训练）执行时间较长，Claude Code 的子 Agent 可能会因为 “等太久” 误判任务卡住，提前杀掉进程。所以在指令里一定要加上 “任务运行时间较长，可以多等一会” 的提示，让子 Agent 有足够的耐心等待任务完成。
为什么用 AI 监工，而不是脚本？
很多人可能会问：“用 Shell 脚本也能实现进程监控和重启，为什么非要用 AI？” 其实我一开始也试过脚本，但用下来发现 AI 有两个不可替代的优势：
| 对比维度 | AI 监工（Claude Code） | 脚本监控（Shell/Python） |
|---|---|---|
| 灵活性 | 能根据任务结果动态调整，比如遇到报错时输出详细排查建议 | 只能按固定逻辑执行，遇到异常直接中断 |
| 易用性 | 不需要懂编程，直接用自然语言写指令即可 | 需要编写代码，还要处理各种边界情况（如文件不存在、权限问题） |
| 扩展性 | 可以随时修改指令，比如临时加一个 “检查日志” 的步骤 | 要修改脚本逻辑，重新测试，成本高 |
当然，AI 监工也有缺点 —— 费 Tokens，毕竟每次启动子 Agent、监控任务都需要消耗 Tokens。但对于需要灵活处理的任务来说，“省时间、少踩坑” 比省 Tokens 更重要。
目前的小遗憾：Claude Code 会 “偷懒”
虽然方案能解决上下文问题，但目前还有一个小 bug：Claude Code 执行一段时间后会自行中断，即使上下文还没满，也没遇到错误。我猜测可能是 Claude Code 的 “会话超时” 机制导致的，目前还没找到完美的解决办法。
不过这个问题影响不大，毕竟中断后只需要重新输入一次监工指令，Claude Code 就能接着之前的进度继续跑，比之前上下文爆掉后要重新梳理任务流程强多了。如果大家有解决这个 “偷懒” 问题的思路，欢迎在评论区交流！
延伸思路：把这个方案用在其他 AI 上
这个 “Manager+Worker” 的思路不局限于 Codex 和 Claude Code，其实可以套用到任何支持 CLI（命令行）的 AI 模型上，比如：
- 用 Gemini 当 Manager，Claude Code 当 Worker；
- 用 Anthropic 的其他模型当 Manager，CodeLlama 当 Worker。
核心逻辑都是一样的：让一个 AI 负责 “管理流程”，另一个 AI 负责 “执行具体任务”，通过 “子 Agent / 新 Session” 避免上下文爆掉。大家可以根据自己常用的 AI 工具灵活调整。
总结
用 AI 监督 AI 的思路，看似 “多此一举”，但实际上解决了长时间任务中 “上下文爆掉” 和 “灵活性不足” 的核心痛点。整个方案不需要复杂的技术栈，只要做好 “任务拆解” 和 “指令引导”，新手也能快速上手。
如果你也被 Codex 的上下文问题困扰，或者需要让 AI 长时间连续执行任务，不妨试试这个方案。如果在使用过程中发现新的优化点，也欢迎留言分享，一起把这个思路打磨得更完善！
