Codex 跑了 4 天突然崩了？遇到上下文溢出该怎么办？

最近在折腾 Codex 的「自动目标（Goal）」任务时，遇到了一个让人头秃的问题。

辛辛苦苦让任务跑了整整 4 天 17 个小时，眼看着就要出成果了，突然屏幕上一红，报错停摆：

Codex 运行四天 17 小时后报错，提示上下文窗口爆满

"Codex ran out of room in the model’s context window. Start a new thread or clear earlier history before retrying."

简单翻译就是：模型的大脑“内存”不够用了。这种时候，很多人的第一反应和我一样，是不是只能无脑输入 /new 开个新对话框，或者用 /clear 一键清空历史记录？

如果你试过发现 /compact（精简指令）根本没用，别急，咱们今天就来深扒一下这背后的逻辑，看看有没有什么「救命」的补救措施。

为什么会爆？

首先，我们要明白这个「上下文窗口」是个啥。

你可以把它想象成 LLM（大语言模型）的「短期记忆区」。不管是你发出的指令，还是 AI 生成的回复，甚至是后台自动执行的 Step，每一条信息都会被塞进这个记忆区里。

对于 Codex 这种需要长时间、多轮迭代执行任务的 Agent 来说，它会在后台不断地自我对话、查资料、写代码、验证结果。虽然你表面上看不到，但在后台，它的对话日志可能已经长得惊人。一旦累积的 Token 数量超过了模型的上限（例如 8k、32k 或 128k），它就无法再读取新的信息，自然也就报错了。

这也是为什么很多长时间运行的 Goal 任务，最后都死在“遗忘”上，而不是“计算错误”上。

进阶排查与解决方案

既然 /compact 指令无效，说明系统判定当前的历史记录已经无法通过简单的算法压缩来释放足够的空间了。这时候咱们得根据具体情况，分三步走：

1. 终极抢救：手动截断与快照（适用于非要保留当前上下文的场景）

如果 /clear 会让前功尽弃，你可以尝试用一种“笨办法”来续命：

• 手动总结：把当前任务最核心的状态、已生成的代码片段、以及下一步的具体计划，复制到一个新的文本编辑器里。让 Codex（或者另一个较短的窗口）“阅读”这段总结，然后在新窗口里基于这些信息继续运行。
• 快照机制：有些高级的 IDE 代码里，其实支持类似“Check Point”的功能。如果你的 Codex 正在写代码，不要试图在同一个对话里让它继续写，把当前的代码保存，开一个新 Thread，直接喂给它代码，把指令改为“Debug 这段代码”或“基于此代码继续开发功能 X”。这相当于手动给它换了一块“内存条”。

2. 接受现实：重启是最好的优化

说实话，对于跑了 4 天的进程，有时候重启反而是最高效的。

• 避免“前文误导”：4 天前的初始指令，可能在现在的执行阶段已经变成了噪音。模型有时候会因为太在意几天前的一句废话，导致当前的逻辑跑偏。新建一个 Thread（/new），用最新的状态重新描述 Goal，往往能跑得更顺滑。
• 清理垃圾数据：中间可能产生过无数次的报错日志、无效尝试，这些东西占满了 Context Window 却毫无价值。重启能让模型只关注当下。

3. 长期预防：目标拆解

为了下次不跑 4 天就崩，建议大家在设定 Goal 时改变一下策略：

• 原子化任务：不要试图让 Codex 一次性完成“开发一个完整网站”这种史诗级任务。把它拆解成“搭建框架”、“写登录页”、“对接数据库”等多个小 Goal。每个小 Goal 独立运行，跑完一个保存一个结果，清空窗口再开下一个。
• 定期 Checkpoint：养成习惯，每过几小时或每完成一个关键里程碑，手动把当前的成果和进度记录下来，并清理一次对话历史。

总结

Codex 遇到 Context Window 溢出，本质上是长文本与有限算力之间的矛盾。

当 /compact 救不了你的时候，不要纠结于那个报红的对话框。手动提取关键信息 -> 结束旧进程 -> 开启新进程，这才是处理复杂任务的正解。毕竟，咱们玩的是 Agent，不是在玩“生存挑战”，没必要死磕那一条命。

下次遇到这种报错，记得先别慌，把“遗产”存好，再重新开始！