7 月 10 日，OpenAI Codex 团队在 Reddit 举办了一场 AMA（Ask Me Anything，在线问答活动）。
整场 AMA 的评论区呈现出一种颇为微妙的气氛：一半用户认真提问 Codex、GPT-5.6 和 ChatGPT Work 的使用方法，另一半用户则集中吐槽额度消耗、桌面应用体验以及不同平台之间长期存在的功能差距。
虽然官方没有正面回答所有尖锐问题，但在模型选择、推理强度、长任务设计、MCP 工具接入和权限管理方面，还是给出了不少具有实际参考价值的信息。
其中最核心的结论可以概括为一句话：
官方讲清楚了 Codex 应该怎么用得更省，却仍然没有解释为什么 GPT-5.6 用起来更费。
不同模型与 Effort 应该怎么选
这次 AMA 中最实用的部分，是 Codex 团队成员分享了不同模型和 Effort 推理强度的选择经验。
官方给出的日常默认组合是：
Sol + Medium Effort
这一配置适合大多数普通开发任务，在速度、质量和额度消耗之间相对均衡。
对于不同场景，则可以进一步调整。
Sol：日常开发和前端任务的首选
Sol 适合作为 Codex 中的默认主力模型，尤其适合：
- 常规代码编写
- Bug 修复
- 跨文件修改
- UI 与前端开发
- 根据参考图还原界面
官方特别提到，UI 和前端能力本身就是 GPT-5.6 的重点训练方向之一。
如果任务中能够提供截图、设计稿或参考页面，Sol 的表现通常会明显优于只给出文字描述。
Terra：额度敏感任务的性价比选择
如果任务相对轻量，同时比较在意额度消耗，可以优先尝试 Terra。
按照官方成员的说法，Terra 在部分任务上的表现可以接近 GPT-5.5，但资源消耗更低，比较适合：
- 小范围代码修改
- 简单脚本生成
- 格式调整
- 重复性开发工作
- 已经明确实现路径的任务
也就是说，并不是所有任务都需要直接交给最强模型。
当需求本身足够清晰时，使用更轻量的模型反而可能获得更高的整体效率。
Luna：适合低成本探索
对于一些不确定是否值得深入的探索性任务，可以先交给 Luna。
例如：
- 快速浏览项目结构
- 初步寻找相关文件
- 调查某个功能的实现位置
- 尝试生成几个可行方向
- 判断问题是否值得升级到更强模型
Luna 更适合作为一个低成本的“侦察兵”，而不是最终负责复杂修改的主力模型。
High：模糊 Bug 和跨模块修改
当问题描述比较模糊，或者修改涉及多个模块时，可以将 Effort 调整到 High。
常见场景包括：
- 无法稳定复现的 Bug
- 多个模块之间的状态异常
- 大范围重构
- 跨前后端联调
- 涉及复杂调用链的问题
这类任务往往不仅需要生成代码，还需要模型建立完整的问题假设，并逐步排除错误方向。
Ultra：只用于真正不能出错的任务
官方并不建议将 Ultra 作为常规配置。
更适合使用 Ultra 的场景包括：
- 数据库迁移
- 安全相关修改
- 生产事故修复
- 权限系统调整
- 大规模基础设施变更
- 一旦出错就可能造成严重损失的任务
Ultra 的意义不是让所有任务都“更聪明”，而是在高风险任务中换取更多检查、推理和验证。
xhigh 的收益已经开始递减
对于最高级别的 xhigh，官方也明确表示，在评测中已经出现明显的收益递减。
它更适合以下情况：
- 任务执行时间很长
- 修改范围非常大
- 错误成本极高
- 需要多轮验证
- 用户特别担心模型遗漏边缘情况
对于普通任务，直接提高到 xhigh 并不一定划算，反而可能带来更慢的速度和更高的额度消耗。
觉得 GPT-5.6 慢，可能是 Effort 设得太高
不少从 GPT-5.5 升级到 GPT-5.6 的用户，仍然沿用了之前较高的推理强度设置。
Codex 团队建议，如果觉得 GPT-5.6 运行速度过慢，可以先检查当前 Effort 是否仍然保持在 GPT-5.5 时期的配置。
GPT-5.6 在更低 Effort 下，往往已经能够完成过去需要更高推理强度才能完成的任务。
换句话说，升级模型后，不应机械地保留原有配置。
更合理的方法是从 Medium 开始，根据任务难度逐步增加，而不是一开始就使用 High、Ultra 或 xhigh。
官方还提到，Fast mode 可以进一步提升大约 1.5 倍的速度。
因此，一套比较实用的选择顺序是：
- 先尝试 Sol Medium；
- 简单任务切换到 Terra；
- 模糊问题再提高到 High；
- 高风险任务才使用 Ultra；
- 只有极少数长任务需要 xhigh。
长任务不要只给目标，还要给停止条件
在长时间运行的 Agent 任务方面，官方推荐使用 /goal 来描述任务目标。
但仅仅给出目标还不够。
如果没有清晰的边界和停止条件，Agent 很容易持续探索、反复修改，最终消耗大量 token，却未必能够产生更好的结果。
官方建议在长任务中明确加入限制条件，例如：
- 只允许修改指定目录；
- 不允许改变公开 API；
- 最多验证三个假设；
- 每个假设完成后必须运行测试；
- 如果所有假设都失败，则停止修改并输出总结；
- 不允许添加新的依赖；
- 不允许修改数据库结构；
- 达到指定时间或尝试次数后结束。
例如，一个比“修复登录 Bug”更合适的任务描述可以写成：
1 | 修复用户偶尔无法登录的问题。 |
这类停止条件能够避免 Agent 陷入无限尝试，也可以降低模型在长任务中不断扩大修改范围的风险。
MCP 工具不一定要全部常驻上下文
MCP 为 Codex 提供了调用外部工具和服务的能力，但如果直接挂载大量 MCP 服务，也会带来明显的上下文开销。
几十个工具定义长期驻留在上下文中，会占用 token，并增加模型选择错误工具的可能性。
Codex 团队提出了两个更节省上下文的思路。
把常用操作封装成 CLI
第一种方式，是将外部服务操作封装成命令行工具，再通过 Skill 教会 Codex 如何使用。
例如，不直接加载一整套部署平台的 MCP 工具，而是提供：
1 | deployctl status |
然后在 Skill 中描述这些命令的用途和参数。
这样做的优势是：
- 工具定义更短；
- 上下文占用更低；
- 调用方式更稳定；
- 更容易进行权限控制；
- 可以直接复用现有 Shell 工作流。
对于原本就支持命令行操作的服务，这通常比长期挂载完整 MCP 更高效。
将专业 MCP 放到专用子 Agent
第二种方式，是创建一个专用子 Agent，并只为它配置特定 MCP。
例如可以创建：
- Unreal Engine 专用 Agent
- 数据库运维 Agent
- Kubernetes Agent
- 浏览器自动化 Agent
- 内部文档检索 Agent
主 Agent 平时不需要加载这些工具，只有遇到对应任务时，才将工作委托给专用 Agent。
这种模式既可以减少主上下文中的工具数量，也能降低不同工具之间的干扰。
权限优先使用 Auto Review
在 Codex 权限设置上，官方建议多数情况下使用 Auto review，而不是直接开启 Full access。
Full access 虽然能够减少执行过程中的确认步骤，但也意味着 Agent 可以更自由地执行命令、修改文件和访问环境。
对于日常开发任务，Auto review 通常已经能够在效率与安全之间取得较好的平衡。
官方尤其提醒 Windows 用户，应更加谨慎地使用 Full access。
Windows 环境中的 Shell、权限系统、路径处理和脚本行为更加复杂，一些看似普通的命令可能产生超出预期的影响。
因此，更稳妥的做法是：
- 默认使用 Auto review；
- 仅在可信项目中临时开启更高权限；
- 限制 Agent 可修改的目录；
- 对删除、安装和系统级命令进行人工确认；
- 不要在包含重要个人文件的目录中直接运行高权限 Agent。
Codex、ChatGPT Work 和普通聊天的额度如何计算
这次 AMA 也对不同功能的额度分类做出了解释。
按照官方的划分：
- Codex 计入 Agentic 额度；
- ChatGPT Work 计入 Agentic 额度；
- 普通 ChatGPT 对话不计入 Agentic 额度；
- 图像生成有独立额度；
- 文件上传与处理有独立额度；
- 语音功能也有独立额度。
这意味着，不能简单地将 ChatGPT 中的所有功能都视为共享同一个额度池。
用户看到某一类功能额度下降，并不一定代表其他功能也会同步受到影响。
不过具体到单个 Codex 任务，其消耗并不是固定值。
任务长度、上下文规模、模型、Effort、工具调用次数、测试次数以及是否发生重试，都会影响最终消耗。
为什么 Pro mode 没有进入 Codex
不少用户询问，既然 ChatGPT 中提供了 Pro mode，为什么 Codex 中没有同样的选项。
官方给出的解释是，Pro mode 的运行机制对于 Agentic 编程任务的提升相对有限。
它通常具有以下特点：
- 响应速度更慢；
- 消耗额度更多；
- 更偏向一次性深度推理；
- 对连续工具调用和代码执行的帮助没有想象中明显。
因此，Pro mode 更适合：
- 搜索
- 数学推理
- 长文写作
- 文档分析
- 复杂研究任务
而 Codex 的核心场景是读取代码、执行命令、修改文件、运行测试并根据结果继续行动。
在这种 Agentic 工作流中，模型本身的单次推理强度并不是唯一决定因素，工具使用和反馈循环同样重要。
AMA 没有回答的几个关键问题
虽然官方分享了许多使用技巧，但用户最关心的一些问题仍然没有获得明确答案。
GPT-5.6 为什么比 GPT-5.5 更耗额度
整个 AMA 中呼声最高的问题，仍然是 GPT-5.6 的额度消耗。
大量用户反馈，GPT-5.6 在实际使用中的额度下降速度明显快于 GPT-5.5。
这与官方此前强调的“更高 token 效率”形成了明显反差。
官方对此只解释称：
每个任务的消耗并不是固定的。
这句话本身并没有错。
复杂任务、更多工具调用、更长输出以及更高 Effort，确实都会增加消耗。
但它没有正面回答用户真正关心的问题：
- 相同任务下，GPT-5.6 是否平均消耗更多额度？
- 是否因为内部推理 token 增加？
- 是否因为工具调用和验证次数更多？
- Agentic 额度是否采用了不同于文本 token 的权重换算？
- Fast mode 与普通模式的额度计算是否相同？
- 官方宣传中的 token 效率，是否不等于用户看到的额度效率？
这些问题在 AMA 后依然没有答案。
1M 上下文窗口仍然没有明确计划
用户同样频繁询问 Codex 是否会提供 1M 上下文窗口。
官方对此仅表示会认真查看用户反馈，没有给出明确的产品计划或上线时间。
对于大型代码仓库来说，更大的上下文窗口确实具有吸引力。
但在实际 Agentic 工作流中，上下文越大，也可能意味着：
- 更高的处理成本；
- 更慢的首次响应；
- 更多无关代码进入上下文；
- 更复杂的信息筛选；
- 更快的额度消耗。
因此，1M 上下文是否能够真正改善 Codex 体验，仍然取决于检索、压缩和上下文管理能力，而不只是数字本身。
在价格方面，官方也明确表示无法承诺长期稳定。
新版 ChatGPT 桌面应用遭到集中吐槽
新版 ChatGPT 桌面应用是 AMA 中另一个争议集中的话题。
不少用户认为，新应用更偏向 ChatGPT Work 和 Agent 操作，而传统 Chat 功能则被压缩成了一个附属面板。
用户集中反馈缺失或体验退步的功能包括：
- Projects
- 完整历史记录
- 常用快捷键
- 录音功能
- 原有聊天工作流
- Classic 应用中的部分导航体验
官方承认新版应用仍在改进。
但目前给出的短期方案，基本上仍然是同时保留并使用两个应用：
- 需要传统聊天功能时使用 Classic；
- 需要 Agent 和 Work 功能时使用新版应用。
这显然称不上理想的解决方案。
Linux 没有时间表，Windows 仍是二等公民
对于 Linux 桌面版，官方确认相关工作正在进行，但没有提供具体时间线。
而 Windows 用户长期存在的体验差距，也在 AMA 中再次被提及。
官方事实上承认，Windows 版本在过去长期处于相对次要的位置。
这种差距不仅体现在桌面应用，也体现在 Agent 开发环境中：
- Shell 行为与 macOS、Linux 不一致；
- 路径和权限处理更复杂；
- 部分开发工具优先适配 Unix 环境；
- 沙箱能力存在差异；
- 自动化脚本的兼容性更差；
- 部分功能在 Windows 上更晚推出。
对于将 Codex 作为主要开发工具的 Windows 用户来说，这仍然是一个现实问题。
Reward Hacking 问题被礼貌绕开
还有用户追问了 METR 报告中提到的 reward hacking 问题。
问题主要集中在：
- 基准成绩提升中有多少来自 reward hacking；
- 模型是否学会针对评测环境优化行为；
- GPT-5.6 的训练中做了哪些针对性修改；
- 官方如何区分真实能力提升和评测策略优化。
Codex 团队没有给出具体数据，也没有详细解释训练层面的改动。
这类问题涉及模型训练、内部评估方法和安全研究，官方选择谨慎回应并不意外。
但从用户角度看，这也意味着外界仍然难以判断：
模型在基准上的提升，有多少能够稳定转化为真实开发环境中的可靠性。
怎么用更省已经讲清楚，为什么更费仍然悬而未决
总体来看，这次 Codex 团队 AMA 的价值主要集中在实际使用方法上。
官方给出的建议相当明确：
- 日常默认使用 Sol Medium；
- 轻量任务优先尝试 Terra；
- 探索性工作可以委托给 Luna；
- 模糊 Bug 和跨模块任务使用 High；
- Ultra 只留给高风险任务；
- xhigh 不应成为日常默认；
- 长任务必须设置停止条件；
- 不要让大量 MCP 工具长期常驻上下文；
- 优先使用 Auto review，而不是 Full access；
- GPT-5.6 不一定需要沿用 GPT-5.5 的高 Effort 设置。
这些建议的共同目标都是降低不必要的模型调用、上下文占用和推理消耗。
但另一方面，用户最关心的问题依然没有获得正面回应：
为什么 GPT-5.6 明明宣传 token 效率更高，实际使用时却更快消耗 Codex 额度？
如果 Agentic 额度并不直接等于输入输出 token，那么官方就需要更清晰地解释其计算方式。
如果 GPT-5.6 由于更频繁的工具调用、更长的内部推理或更主动的验证而消耗更高，也应该让用户能够看到这些差异。
否则，用户最终只能通过反复试验来猜测每种模型和 Effort 的真实成本。
这场 AMA 讲清楚了 Codex 应该“怎么用更省”。
至于它为什么“变得更费”，仍然是一个没有被回答的问题。
评论