Apa itu GPT-5.1-Codex-Max dan bagaimana cara menggunakannya?

2025年11月19日至20日，OpenAI 发布了两项彼此相关但又有所区别的升级：GPT-5.1-Codex-Max，这是面向 Codex 的全新代理式编程模型，强调长时程编码、token 效率，以及通过“compaction（压缩整理）”来维持跨多个上下文窗口的连续会话；以及 GPT-5.1 Pro，这是针对 ChatGPT Pro 层级更新后的模型，专为在复杂、专业工作中提供更清晰、能力更强的回答而调优。

什么是 GPT-5.1-Codex-Max，它试图解决什么问题？

GPT-5.1-Codex-Max 是 OpenAI 推出的一个专门化 Codex 模型，针对那些需要持续、长时程推理与执行的编码工作流进行优化。普通模型在面对超长上下文时往往容易出问题——例如跨多个文件的重构、复杂的代理循环，或持续性的 CI/CD 任务——而 Codex-Max 的设计目标是自动压缩并管理跨多个上下文窗口的会话状态，使其能够在单个项目跨越数千甚至更多 token 时，依然连贯地持续工作。OpenAI 将 Codex-Max 视为让具备代码能力的代理真正适用于长期工程工作的下一步。

什么是 GPT-5.1-Codex-Max，它试图解决什么问题？

GPT-5.1-Codex-Max 是 OpenAI 推出的一个专门化 Codex 模型，针对那些需要持续、长时程推理与执行的编码工作流进行优化。普通模型在面对超长上下文时往往容易出问题——例如跨多个文件的重构、复杂的代理循环，或持续性的 CI/CD 任务——而 Codex-Max 的设计目标是自动压缩并管理跨多个上下文窗口的会话状态，使其能够在单个项目跨越数千甚至更多 token 时，依然连贯地持续工作。

OpenAI 将其描述为“在开发周期的每个阶段都更快、更智能、且 token 效率更高”，并明确表示它旨在取代 GPT-5.1-Codex，成为 Codex 各类使用场景中的默认模型。

功能概览

• 面向多窗口连续性的 compaction： 修剪并保留关键上下文，从而能够在数百万 token 和数小时的工作中保持连贯。0
• 相比 GPT-5.1-Codex 提升了 token 效率： 在某些代码基准上，以相近的推理投入可减少最高约 ~30% 的 thinking tokens。
• 长时程代理式持久性： 据内部观察，可维持数小时到数天的代理循环（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 会话接近上下文上限时，系统会对其进行压缩整理（将较旧或价值较低的 token 进行总结/保留），为代理腾出新的上下文窗口，使其能够持续反复迭代直到任务完成。OpenAI 报告称，在内部运行中，该模型曾连续工作超过 24 小时。

自适应推理与 token 效率

GPT-5.1-Codex-Max 采用了改进的推理策略，使其在 token 使用上更加高效：根据 OpenAI 报告的内部基准，Max 模型在使用显著更少“thinking” tokens 的情况下，能达到与 GPT-5.1-Codex 相当甚至更好的表现——OpenAI 提到，在 SWE-bench Verified 上以相同推理强度运行时，thinking tokens 大约减少了 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 集成到开发者工具链后，提高了内部工程生产力指标（例如使用量和 pull request 吞吐量）。这些是 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 以更高的 token 效率超过了 GPT-5.1-Codex。公司强调，在相同的“medium”推理强度下，Max 模型能给出更好的结果，同时使用大约少 30% 的 thinking tokens；对于允许更长内部推理的用户，xhigh 模式还能以更高延迟为代价进一步提升答案质量。

GPT-5.1-Codex-Max 与 GPT-5.1-Codex 相比如何？

性能与用途差异

• 定位范围： GPT-5.1-Codex 是 GPT-5.1 系列中的高性能编码变体；而 Codex-Max 则明确是一个面向代理式、长时程任务的后继模型，目标是成为 Codex 和类似环境中的推荐默认选择。
• token 效率： Codex-Max 在 SWE-bench 以及内部使用中表现出明显的 token 效率提升（OpenAI 声称约减少 ~30% thinking tokens）。
• 上下文管理： 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）总结改动”）。
• 要求解释和 diff： 同时索要补丁和简短原因说明，以便人工审查者快速评估安全性与意图。

示例提示模板

重构任务

“重构 payment/ 模块，将支付处理提取到 payment/processor.py。保持现有调用方的公共函数签名稳定。为 process_payment() 编写单元测试，覆盖成功、网络失败和无效卡三种情况。运行测试套件，并以 unified diff 格式返回失败测试和补丁。”

Bug 修复 + 测试

“测试 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。开始使用时，可先在 Playground 中探索 CometAPI 的模型能力，并查阅 API 指南获取详细说明。在访问前，请确保你已登录 CometAPI 并获取 API key。CometAPI 提供远低于官方价格的定价，帮助你完成集成。

准备开始了吗？→ 立即注册 CometAPI！

如果你想了解更多关于 AI 的技巧、指南和新闻，欢迎关注我们的 VK、X 和 Discord！

快速开始（实用分步指南）

1. 确认你拥有访问权限： 检查你的 ChatGPT/Codex 产品方案（Plus、Pro、Business、Edu、Enterprise）或开发者 API 方案是否支持 GPT-5.1/Codex 系列模型。
2. 安装 Codex CLI 或 IDE 扩展： 如果你希望在本地运行代码任务，请安装 Codex CLI 或适用于 VS Code / JetBrains / Xcode 的 Codex IDE 扩展。受支持的配置中，这些工具默认会使用 GPT-5.1-Codex-Max。
3. 选择推理强度： 大多数任务从 medium 开始即可。对于深度调试、复杂重构，或当你希望模型进行更深入思考且不在意响应延迟时，可切换到 high 或 xhigh 模式。对于快速小修复，low 也是合理选择。
4. 提供仓库上下文： 给模型一个清晰的起点——例如仓库 URL，或者一组文件加上简短说明（如“将 payment 模块重构为使用 async I/O，并添加单元测试，保持函数级契约不变”）。当接近上下文限制时，Codex-Max 会压缩历史并继续工作。
5. 结合测试进行迭代： 当模型生成补丁后，运行测试套件，并将失败信息作为持续会话的一部分反馈给模型。compaction 和多窗口连续性使 Codex-Max 能保留重要的失败测试上下文并继续迭代。

结论：

GPT-5.1-Codex-Max 标志着代理式编码助手向前迈出了重要一步：它能够以更高的效率和更强的推理能力，持续完成复杂、长时间运行的工程任务。这些技术进步（compaction、推理强度模式、Windows 环境训练）使它非常适合现代工程组织——前提是团队同时配套保守的运行控制、清晰的人类参与策略以及可靠的监控机制。对于那些谨慎采用它的团队而言，Codex-Max 有潜力改变软件设计、测试和维护的方式——把重复性的工程苦活转变为人与模型之间更高价值的协作。