Codex上下文窗口溢出问题及解决方案

背景

在 AI 驱动的自动化任务中，频繁调用的 agent 或模型往往面临上下文窗口（context window）限制。OpenAI Codex 等模型在处理长对话历史时，会因累积的消息过多而触发“ran out of room in the model's context window”错误。这一现象在 LINUX DO 论坛的讨论中被具体指出：用户原本将 Codex 的 heartbeat 功能当作简单的定时执行脚本，但运行一段时间后频繁报错。根本原因在于 heartbeat 并非无状态，而是每次执行都会向同一个线程追加消息——包括提示词、回复、工具调用、输出和错误信息。即使设置了 DONT_NOTIFY（不发送提醒），历史记录仍会持续写入，导致线程上下文逐渐膨胀，最终超过模型容量。

核心内容

原文分享了解决 Codex 上下文溢出的实践方案。核心思路是将高频 heartbeat 任务从“定时脚本”重新设计为“会增长的聊天线程”，并采取三项措施：缩短 prompt、状态外置、自动轮换线程。

第一步：缩短 prompt

去掉大段规则，只保留核心指令：执行哪个脚本、无事时输出 DONT_NOTIFY、有事时只输出一两行、不粘贴长日志。业务规则移入外部脚本或配置文件，状态存储在本地文件或数据库中。聊天线程仅作为入口，不再充当数据库。

第二步：状态外置

将任务状态（如上次执行时间、结果等）写入本地文件或数据库，避免在对话历史中重复积累。这样即使线程被轮换，状态也能延续。

第三步：自动轮换线程

每天运行一次维护任务，检查当前线程的 session 文件大小。当大小接近 100MB（实际历史中爆掉的大约在 150MB–200MB，用户设为 100MB 提前预警），或检测到上下文错误时，自动创建新线程，将 heartbeat 绑定到新线程，并归档旧线程。这样高频任务仍在固定项目下，便于查找，且不会每 5 分钟生成一堆聊天记录。

折中方案的原因

用户评估了多种方案：

• 清历史：只能救急，问题会再次出现。
• 改 cron：不撑爆同一线程，但高频时记录仍过多。
• 系统定时任务：最干净，但用户希望继续用 Codex。
• hooks：适合审计，但不能阻止 heartbeat 写历史。

最终采用上述折中，承认 heartbeat 一定会写历史，但通过少写、外置状态、自动轮换，将影响降到最低。

关键要点

• heartbeat 不是无状态脚本，每次执行都会向同一线程追加消息，包括所有提示词、回复、工具调用、输出和错误。
• DONT_NOTIFY 仅关闭通知，历史记录仍然写入，不能避免上下文膨胀。
• 5 分钟一次的任务，一天 288 次，prompt 再包含大量规则，上下文迟早会爆。
• 缩短 prompt 是核心：只保留执行指令，业务规则放在脚本或外部配置中，状态放在本地文件或数据库。
• 自动轮换线程的阈值设为 100MB（实际爆掉约 150–200MB），提前创建新线程，避免错误发生。
• 状态外置后，线程切换不会中断任务，高频任务仍可归属同一项目。
• 该方案并非完美无状态，但能有效降低增长速率，并防止崩溃。

意义与影响

这一实践揭示了 AI agent 自动化任务中一个容易被忽视的陷阱：将无状态脚本的思维套用在有状态聊天线程上。许多开发者最初认为 heartbeat 只是定时触发，却忽略了它持续累积历史的副作用。该方案提供了一种低成本、可落地的平衡策略，尤其适合中小规模场景——无需重构整个系统，仅通过调整 prompt 设计、存储策略和轮换机制，即可显著延长 Codex 自动任务的稳定运行时间。

从更广的视角看，它提醒我们：AI 模型并非无状态，其上下文窗口是有限资源。任何高频调用 agent 的设计都应考虑历史累积问题，并主动采用“外置状态+短对话+定期轮换”的模式。这一思路同样适用于其他大语言模型（如 GPT-4、Claude 等）的持续交互场景，具有普遍的参考价值。