在 2025 年 11 月 19–20 日，OpenAI 发布了两个相关但不同的升级：GPT-5.1-Codex-Max，一款面向 Codex 的新型代理型编码模型，强调长时程编码、令牌效率以及“compaction”以支持多窗口会话；以及 GPT-5.1 Pro，更新的 Pro 等级 ChatGPT 模型，针对复杂的专业工作调优以提供更清晰、更强大的回答。
什么是 GPT-5.1-Codex-Max，它试图解决什么问题？
GPT-5.1-Codex-Max 是 OpenAI 的一款专门化 Codex 模型，针对需要持续、长时程推理与执行的编码工作流程进行调优。普通模型在极长上下文中容易出错——例如跨多文件的重构、复杂的代理循环或持续的 CI/CD 任务——而 Codex-Max 旨在通过在多个上下文窗口中自动压缩并管理会话状态，使其在单个项目跨越成千上万（甚至更多）令牌时仍能连贯地继续工作。OpenAI 将 Codex-Max 定位为让具备代码能力的代理在长期工程工作中真正有用的下一步。
什么是 GPT-5.1-Codex-Max，它试图解决什么问题？
GPT-5.1-Codex-Max 是 OpenAI 的一款专门化 Codex 模型，针对需要持续、长时程推理与执行的编码工作流程进行调优。普通模型在极长上下文中容易出错——例如跨多文件的重构、复杂的代理循环或持续的 CI/CD 任务——而 Codex-Max 旨在通过在多个上下文窗口中自动压缩并管理会话状态，使其在单个项目跨越成千上万（甚至更多）令牌时仍能连贯地继续工作。
OpenAI 将其描述为“在开发周期的每个阶段都更快、更智能、令牌更高效”，并明确用于替代 GPT-5.1-Codex，成为 Codex 场景中的默认模型。
功能快照
- 用于多窗口连续性的 compaction： 修剪并保留关键上下文，使其能在数百万令牌与数小时内连贯工作。0
- 与 GPT-5.1-Codex 相比的令牌效率提升： 在部分代码基准上，以相似的推理投入使用多达约 30% 更少的“思考”令牌。
- 长时程代理型耐久性： 内部观察到可维持多小时/多天的代理循环（OpenAI 记录了超过 24 小时的内部运行）。
- 平台集成： 今日可在 Codex CLI、IDE 扩展、云端与代码评审工具中使用；API 访问即将到来。
- Windows 环境支持： OpenAI 特别指出 Codex 工作流首次支持 Windows，扩大了真实世界开发者覆盖面。
与竞品（如 GitHub Copilot、其他编码 AI）如何对比？
与按次请求的补全工具相比，GPT-5.1-Codex-Max 被定位为更自主、能处理长时程协作的伙伴。Copilot 及类似助手在编辑器内的近期补全方面表现突出，而 Codex-Max 的优势在于编排多步骤任务、跨会话维护连贯状态，以及处理需要规划、测试与迭代的工作流程。话虽如此，多数团队的最佳做法是混合使用：用 Codex-Max 进行复杂自动化与持续代理任务，用更轻量的助手完成行级补全。
GPT-5.1-Codex-Max 如何工作？
什么是“compaction”，它如何支持长时间运行的工作？
核心技术进步是 compaction——一种内部机制，能在多个上下文窗口之间对会话历史进行修剪，同时保留关键上下文，使模型能持续连贯地工作。实际效果是，当 Codex 会话接近上下文上限时会进行压缩（将更旧或价值较低的令牌总结/保留），以便代理拥有新的窗口并能反复迭代直至任务完成。OpenAI 报告了模型连续工作超过 24 小时的内部运行。
自适应推理与令牌效率
GPT-5.1-Codex-Max 采用改进的推理策略，使其令牌更高效：在 OpenAI 报告的内部基准中，Max 模型在相同推理投入下相较 GPT-5.1-Codex 达到相似或更好的表现，同时显著减少“思考”令牌——OpenAI 在 SWE-bench Verified 上引用约 减少 30% 的思考令牌。该模型还引入“Extra High (xhigh)”推理投入模式，适用于不敏感于延迟的任务，使其能投入更多内部推理以获得更高质量输出。
系统集成与代理工具链
Codex-Max 正在 Codex 工作流（CLI、IDE 扩展、云端与代码评审界面）中分发，使其能与真实开发者工具链交互。早期集成包括 Codex CLI 与 IDE 代理（VS Code、JetBrains 等），API 访问计划随后推出。其设计目标不仅是更智能的代码生成，更是一个能运行多步骤工作流的 AI：打开文件、运行测试、修复失败、重构并再次运行。
GPT-5.1-Codex-Max 在基准与真实工作上的表现如何？
持续推理与长时程任务
评估显示在持续推理与长时程任务方面具有可测的改进：
- OpenAI 内部评估： 在内部实验中，Codex-Max 能在任务上“工作超过 24 小时”，且将 Codex 与开发者工具集成提升了内部工程生产力指标（如使用率与拉取请求吞吐）。这些是 OpenAI 的内部说法，表明在真实世界生产力上有任务层面的改进。
- 独立评估（METR）： METR 的独立报告测得 GPT-5.1-Codex-Max 的观测到的 50% 时间跨度（一种统计量，代表模型能连贯维持长任务的中位时间）约为2 小时 40 分钟（置信区间较宽），在可比测量中高于 GPT-5 的 2 小时 17 分钟——这是在持续连贯性上的有意义、符合趋势的提升。METR 的方法与置信区间强调可变性，但结果支持 Codex-Max 改善实际长时程表现的叙述。
代码基准
OpenAI 报告在前沿编码评估上取得更好结果，尤其是在 SWE-bench Verified 上，GPT-5.1-Codex-Max 相较 GPT-5.1-Codex 以更好的令牌效率胜出。公司强调在相同“中等”推理投入下，Max 模型使用约少 30% 的思考令牌即可产生更好的结果；对于允许更长内部推理的用户，xhigh 模式可在以延迟为代价的情况下进一步提升答案质量。
| GPT‑5.1-Codex (high) | GPT‑5.1-Codex-Max (xhigh) | |
| SWE-bench Verified (n=500) | 73.7% | 77.9% |
| SWE-Lancer IC SWE | 66.3% | 79.9% |
| Terminal-Bench 2.0 | 52.8% | 58.1% |
GPT-5.1-Codex-Max 与 GPT-5.1-Codex 有何比较？
性能与目的差异
- 范围： GPT-5.1-Codex 是 GPT-5.1 家族中的高性能编码变体；而 Codex-Max 明确是代理型、长时程的继任者，意在成为 Codex 及类似环境的推荐默认模型。
- 令牌效率： 在 SWE-bench 和内部使用中，Codex-Max 展现了实质性的令牌效率提升（OpenAI 声称约少用 30% 的思考令牌）。
- 上下文管理： Codex-Max 引入 compaction 与原生多窗口处理，以维持超过单一上下文窗口的任务；Codex 未在相同规模上原生提供此能力。
- 工具链就绪度： Codex-Max 作为默认 Codex 模型随 CLI、IDE 与代码评审界面发布，标志着生产级开发工作流的迁移。
何时使用哪个模型？
- 在以下场景使用 GPT-5.1-Codex： 交互式编码辅助、快速编辑、小型重构，以及低延迟用例且全部相关上下文可轻松容纳于单一窗口。
- 在以下场景使用 GPT-5.1-Codex-Max： 跨多文件的重构、需要多次迭代的自动化代理任务、类似 CI/CD 的工作流，或当你需要模型在多次交互中保持项目级视角时。
实用提示模式与最佳结果示例？
效果良好的提示模式
- 明确目标与约束： “重构 X，保持公共 API，不更改函数名，并确保测试 A、B、C 通过。”
- 提供最小可复现实上下文： 链接到失败的测试，附上堆栈跟踪与相关文件片段，而非倾倒整个仓库。Codex-Max 会按需压缩历史。
- 复杂任务使用分步指令： 将大型工作拆分为子任务序列，让 Codex-Max 按步骤迭代（例如，“1）运行测试 2）修复排名前 3 的失败测试 3）运行 linter 4）总结更改”）。
- 请求解释与差异： 同时请求补丁与简短理由，以便人工评审快速判断安全性与意图。
示例提示模板
重构任务
“将
payment/模块重构，把支付处理抽取到payment/processor.py。为现有调用方保持公共函数签名稳定。为process_payment()创建单元测试，覆盖成功、网络失败与无效卡。运行测试套件，并以统一 diff 格式返回失败的测试与补丁。”
缺陷修复 + 测试
“测试
tests/test_user_auth.py::test_token_refresh因 traceback 失败。调查根因，提出最小改动的修复，并添加单元测试以防回归。应用补丁并运行测试。”
迭代式 PR 生成
“实现功能 X：新增端点
POST /api/export，以流式返回导出结果且需身份验证。创建该端点，添加文档，编写测试，并打开一个 PR，附上摘要与人工项检查清单。”
对上述多数任务，从 medium 投入开始；当需要模型在跨多文件与多次测试迭代中进行更深入推理时，切换到 xhigh。
如何访问 GPT-5.1-Codex-Max
今日可用范围
OpenAI 已将 GPT-5.1-Codex-Max 集成到 Codex 工具链：Codex CLI、IDE 扩展、云端与代码评审流程默认使用 Codex-Max（你可以选择 Codex-Mini）。API 可用性尚在准备中；GitHub Copilot 提供包含 GPT-5.1 与 Codex 系列模型的公开预览。
开发者可通过 CometAPI 访问 GPT-5.1-Codex-Max 和 GPT-5.1-Codex API。要开始，请在 CometAPI 的 Playground 中探索模型能力，并查阅 API guide 获取详细说明。在访问之前，请确保你已登录 CometAPI 并获得 API 密钥。CometAPI 提供远低于官方价格的报价，帮助你集成。
准备好了吗？→ 今天注册 CometAPI ！
如果你想了解更多关于 AI 的技巧、指南与新闻，请在 VK、X 和 Discord 关注我们！
快速开始（实用分步）
- 确认你有访问权限： 确认你的 ChatGPT/Codex 产品方案（Plus、Pro、Business、Edu、Enterprise）或开发者 API 方案支持 GPT-5.1/Codex 系列模型。
- 安装 Codex CLI 或 IDE 扩展： 若希望在本地运行代码任务，安装 Codex CLI 或 VS Code / JetBrains / Xcode 的 Codex IDE 扩展。该工具链在受支持的设置中默认使用 GPT-5.1-Codex-Max。
- 选择推理投入： 对多数任务从 medium 开始。对于深度调试、复杂重构，或当你希望模型更深入思考且不在意响应延迟时，切换到 high 或 xhigh 模式。对于快速小修复，low 是合理的。
- 提供仓库上下文： 给模型一个清晰的起点——仓库 URL 或一组文件加简短指令（例如，“重构支付模块以使用异步 I/O 并添加单元测试，保持函数级契约”）。Codex-Max 在接近上下文限制时会压缩历史并继续工作。
- 结合测试迭代： 在模型生成补丁后，运行测试套件，并将失败结果作为持续会话的一部分反馈。压缩与多窗口连续性使 Codex-Max 能保留重要的失败测试上下文并迭代。
结论：
GPT-5.1-Codex-Max 代表着迈向能持续处理复杂、长时间运行工程任务的代理型编码助手的重要一步，其在压缩、推理投入模式、Windows 环境训练等方面的技术进步使其非常适合现代工程组织——前提是团队配合保守的运营控制、明确的人在回路策略与健全的监控。对于谨慎采纳的团队，Codex-Max 有潜力重塑软件的设计、测试与维护方式——将重复的工程性琐事转化为人与模型之间更高价值的协作。