直接答案：Codex 变慢时先区分首字延迟、完整生成耗时和本地工具耗时，再检查模型、上下文、任务范围与并发。适合长会话和大代码库优化；通常先缩小任务与上下文，比盲目提高超时更有效。
1. 先判断 Codex 慢在哪里
| 表现 | 优先检查 |
|---|---|
| 很久没有任何输出 | 首字延迟、模型排队、网络连接和请求是否进入流式模式 |
| 连续 Reconnecting 1/5 到 5/5 | 查看Codex WebSocket 与代理排查，确认是否回退到 HTTP |
| 开始输出但完成很慢 | 输出长度、上下文大小、模型推理复杂度 |
| 模型响应快但整体任务慢 | 本地搜索、测试、构建等工具执行时间 |
| 偶发卡住或 429 | 并发、密钥额度、重试循环和批量任务队列 |
记录模型代号、任务描述、输入文件范围、首字时间和完整耗时，才能比较优化前后的变化。
2. 按任务匹配模型
- 复杂代码理解：选择推理和上下文能力更强的模型，减少反复纠错。
- 简单重命名和摘要：使用响应更快、成本更低的模型。
- 批量检查：控制单次输入大小，优先选择吞吐稳定的模型。
- 长任务：先用强模型制定计划，再用轻量模型执行重复步骤。
模型名称、可用分组和倍率会变化，使用前从模型广场和 API 密钥页面核对。
3. 控制上下文长度
- 只把当前任务涉及的目录和文件交给 Codex。
- 先提供错误日志和相关函数，不要一次性粘贴整个仓库。
- 完成一个阶段后，用简短摘要替代已经解决的长对话。
- 明确验收条件、不可修改的目录和测试命令。
- 重复运行时只提交变更文件和新增错误。
上下文不是越多越好无关文件会增加 Token 消耗，也会让模型在约束之间分散注意力。
4. 把大任务拆成可验证的小任务
推荐采用四步循环：
1
理解
让 Codex 只阅读结构并输出计划。
2
修改
一次只处理一个模块或一个明确目标。
3
验证
运行最小测试并记录失败信息。
4
总结
确认变更后再进入下一个模块。
5. 控制并发和重试
- 批量任务放入队列，设置每个项目的并发上限。
- 429、502、503 只做有限次数指数退避，不要无限重试。
- 为每个任务设置业务 ID，避免超时后重复执行。
- 将交互式 Codex 任务和批处理任务使用不同密钥，便于隔离额度。
- 出现连续故障时暂停请求，查看API 错误码排查指南。
6. 推荐的 Codex 高效工作流
- 在Codex API 配置页面完成提供方和模型设置。
- 让 Codex 先输出项目结构、风险点和执行计划。
- 按模块逐步修改，每一步都运行对应测试。
- 将长日志压缩为“现象、复现命令、关键堆栈、期望结果”。
- 在控制台查看 Token 用量，根据结果调整模型和上下文。
对电商文案、办公摘要、短剧漫剧素材等批量任务，建议在应用侧增加队列和失败重试，而不是让单个 Codex 会话承担全部调度。
7. 常见问题
Codex 响应慢首先检查什么？
先区分首字慢、完整响应慢和本地工具执行慢，再检查模型、上下文、任务范围和并发。
上下文越长 Codex 就越好吗？
不是。只保留当前任务相关信息通常更快，也更容易得到稳定结果。
如何降低 Codex API 成本？
使用任务匹配的模型、缩短重复上下文、拆分大任务，并设置密钥额度与并发上限。