北京
如果你正在用ChatGPT的Codex功能跑长会话，最近可能撞上过这样一个报错：“unexpected status 404 Not Found: Unknown error, url: https://chatgpt.com/backend-api/codex/responses”。这不是个例，GitHub上已经有人开了issue跟踪，编号#28756，目前有18.6k的fork关注着这个问题。
报错本身很直白：Codex在会话中途突然失联，返回404。但真正让人头疼的是它的发生时机——不是刚启动时，而是在你精心调教了半天的长会话里，突然给你来这么一下。有用户描述，自己在一个GPT 5.4 xhigh会话中连续三次遇到这个错误，而另一个跑着GPT 5.5 xhigh的会话却毫发无损。这种“选择性罢工”让不少人摸不着头脑。
问题出在长会话的“记忆负担”上
从issue里的描述看，出问题的会话有一个共同特征：都很长。报告者提到，自己的会话经历了多次压缩（compactions），还承担着“编排者”的角色，频繁派发子代理去处理小任务。错误发生在他指挥会话去启动一个新子代理之后不久，大约在压缩后50k token的位置。
这暗示了一个可能的方向：Codex后端在处理超长上下文时，某个环节的响应机制出现了断裂。会话试图继续推进，但后端返回了404，重试5次全部失败，最终只能放弃。用户手动点击“继续”能恢复，但恢复后跑一轮又会再次触发同样的错误——像是会话的“状态”在某个节点上已经和服务器端脱节了。
官方没有回应，但用户自己找到了临时解法
截至issue发布时，OpenAI官方还没有给出正式说明。不过发帖的用户在编辑中补充了一条“自救指南”：解法其实相当简单，按他给出的步骤操作即可。虽然他没有在正文里展开细节，但结合其他用户的反馈，核心思路基本是：新建一个会话，把关键上下文手动带过去，而不是依赖原会话的自动恢复。
这个办法治标不治本，但至少能让你手头的工作不中断。对于依赖Codex做多步骤任务的人来说，这已经是当下最务实的应对方案了。
用户真正想要的是“抗打断”能力
在issue的“期望行为”一栏，报告者写得很直接：“别在会话中途死掉”。他还提了一个更具体的建议——希望重试机制能更抗错，比如用指数退避（exponential back-off）的方式，在10分钟内重试20次，而不是现在这样连续重试5次就放弃。
这个诉求背后，其实是Codex这类代理式工具的一个核心痛点：会话越长，状态越复杂，单点故障的代价就越大。一次404可能只是几秒钟的请求失败，但在一个已经跑了数万token、承载了大量上下文的会话里，它意味着整个工作流的断裂。
我的判断：这是长会话架构的必经之痛
从技术角度看，这个bug大概率不是简单的服务器波动，而是长上下文场景下状态同步机制的缺陷。Codex作为代理，需要持续维护会话的“世界模型”——包括历史消息、子代理状态、工具调用记录。当这个模型膨胀到一定程度，任何一次请求的响应超时或状态校验失败，都可能让整个会话进入不可恢复的“僵尸状态”。
用户建议的指数退避重试是个合理的工程方向，但更根本的解法可能是让Codex具备“断点续传”能力——即使后端请求失败，也能从最近的稳定状态恢复，而不是把整个会话打回原形。这需要OpenAI在架构层面做调整，短期内恐怕等不到。
眼下如果你正被这个问题困扰，最稳妥的做法还是：长会话定期“存档”，把关键决策和中间结果手动记录到外部文档，别把全部赌注押在Codex的会话连续性上。毕竟工具再聪明，也架不住后端一个404。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
