GPT-5.6进入Codex以后一个非常明显的变化是模型选择越来越不像“选最强的那个”这么简单。现在Codex主要提供三档GPT-5.6模型GPT-5.6 Sol GPT-5.6 Terra GPT-5.6 Luna同时还可以继续调整ReasoningLow Medium High Extra High Max Ultra于是很多人会产生一个最直接的想法Sol最强那我一直用Sol不就行了或者Reasoning直接拉到Max、Ultra结果肯定最好。实际上这种用法反而很容易让Codex变得更慢、更重而且很多任务根本得不到对应收益。OpenAI目前对三款模型的定位非常清楚Sol面向复杂、开放式和高价值任务Terra是日常工作的主力模型Luna更适合边界明确、重复性高的任务。官方同时建议Reasoning应该使用“能够达到所需结果的最低级别”再根据任务复杂度逐级提高。所以真正应该建立的不是最强模型优先。而是Task → Model → Reasoning这套任务路由逻辑。一、先分清Model和Reasoning解决的不是同一个问题很多人会把Sol / Terra / Luna和Low / Medium / High理解成同一条性能滑杆。其实不是。模型更接近选择什么级别的执行引擎。Reasoning更接近这次任务让它投入多少推理资源。可以简单理解成Model ↓ 基础能力与任务定位Reasoning ↓ 本次任务思考深度所以完全可能出现Terra High比Sol Low更适合某一个具体任务。真正需要判断的是任务本身。二、Sol不要拿旗舰模型去做所有小任务目前Codex官方把GPT-5.6 Sol定位为三款模型里能力最强的一档尤其适合复杂代码修改、深度研究、Computer Use以及需要更多判断和打磨的开放式工作。什么叫开放式任务例如分析为什么这个大型项目最近接口延迟突然增加并提出修改方案。这里并没有明确告诉Agent哪个文件有问题应该改哪段代码Root Cause是什么。它可能需要读取架构 ↓ 搜索代码 ↓ 检查调用链 ↓ 分析日志 ↓ 提出假设 ↓ 验证假设 ↓ 修改多个模块这种任务最大的难点不是写代码。而是判断应该做什么。这种情况下Sol更有价值。三、哪些任务更适合Sol可以归纳成4类。1. Root Cause不明确例如偶发内存泄漏帮我找原因。Agent需要自己探索。2. 修改范围可能跨多个模块例如API ↓ Service ↓ Database ↓ Frontend需要同时理解多个系统关系。3. 需要大量权衡比如重新设计权限系统但是不能破坏旧接口。这里不是简单实现。而是要在兼容性安全性能维护成本之间做判断。4. 错误成本较高例如核心架构重构复杂Migration安全问题高风险代码Review。这种任务值得让模型投入更多分析。所以Sol真正适合的是Ambiguous Complex High Value四、Terra才更像大多数开发者的日常主力如果Sol负责解决最困难的问题Terra更像Everyday Workhorse。官方目前把Terra定位为日常工作的平衡型模型在保持较强推理和工具能力的同时不需要每个任务都使用Sol的完整深度。比如修一个明确Bug新增一个API补测试修改数据库查询重构一个模块这些任务通常已经具备清楚的Goal有限的Scope明确的Done Condition。Agent不需要先研究半天我到底应该干什么更多是在执行已经比较清楚的工程任务。这种情况下Terra往往更合理。五、很多Codex任务其实不用Sol比如任务是users接口返回字段里增加avatarUrl并补相关测试。任务结构已经非常明确Goal 增加字段 Scope users API Verification 测试通过真正的工作可能只有找Schema ↓ 修改返回值 ↓ 调整Type ↓ 补测试 ↓ 运行验证这种情况下最主要的问题是稳定执行。而不是深度研究。直接使用Sol并不一定会让这个任务产生明显更好的结果。这也是为什么模型路由非常重要。六、Luna不要理解成“能力弱的模型”很多人看到Luna的定位偏速度和效率就会自然认为那它只能做简单问答。这也不准确。官方把Luna定位在clear、repeatable、high-volume这类任务上。核心并不是任务必须特别简单。而是任务规则足够明确。例如按照固定格式整理Commit扫描日志并分类错误把一批接口信息转换为统一JSON给200个文件检查同一种规则这些任务可能数量非常大。但单个任务不需要大量开放式判断。这种情况下Luna反而非常合适。七、Luna特别适合和Skills、Scheduled Tasks组合昨天我们讲Skills的时候提到过一个真正稳定的Skill应该已经把Input Process Output定义清楚。Scheduled Task同样适合边界稳定可以重复能够验证的任务。这两类任务天然很适合Luna。例如每天09:00 ↓ Scheduled Task ↓ 调用CI Triage Skill ↓ Luna ↓ 读取失败记录 ↓ 分类 ↓ 生成结构化报告这里真正值钱的不是模型自己重新思考整个Workflow。而是可靠执行已经定义好的Workflow。所以可以记住一句话任务越标准化越有机会把模型往Luna方向下沉。八、选完模型以后第二步才是Reasoning很多人真正浪费额度和时间的地方其实不是模型。而是Reasoning一直开太高。Codex目前建议根据任务难度选择Reasoning并明确指出更高Reasoning可能改善复杂任务结果但会增加执行时间和Token使用。官方默认建议从合适的较低级别开始再根据结果提高。可以把Reasoning简单理解成Low 快速执行 Medium 执行 一定规划 High 更多分析与检查 Extra High 复杂长任务 Max 单任务最大推理深度 Ultra 多Agent自动拆分任务但这里最重要的是Ultra已经不仅是“再多想一点”。九、Low适合什么Low最适合任务已经非常清楚。例如把这个变量名改成userId并更新相关引用。或者修复这个已经定位好的TypeScript类型错误。这里Agent几乎不需要探索。流程就是Understand ↓ Modify ↓ Verify如果这种任务也一直用High或者Max增加的推理并不一定产生明显收益。所以Small Scope Clear Goal Clear Verification → Low十、Medium其实应该成为很多人的默认起点Medium的价值在于速度和推理深度比较平衡。比如给订单接口增加分页并补测试。Agent需要理解现有接口找到相关代码修改检查影响运行测试。需要一点计划但不是复杂架构问题。这种任务非常适合Terra MediumOpenAI当前Codex默认Power配置使用Sol搭配Medium同时官方最佳实践也把Medium视为需要一定规划任务的常用区间。所以不确定Reasoning的时候Medium通常是一个很好的基线。十一、什么时候应该升High或者Extra High出现以下信号就可以考虑提高Reasoning。Root Cause不明确需要Agent自己排查。修改文件明显增多例如十几个文件形成一条调用链。存在多个方案需要比较Trade-off。任务持续时间比较长需要保持计划和状态。Verification比较复杂不仅跑一个测试还需要Unit Test Integration Test Lint Type Check Diff Review这种情况下可以从Medium ↓ High再根据实际表现增加。十二、Max真正适合的是“一个特别难的问题”Max最容易被误解。很多人会认为Max就是日常High的增强版。其实更适合理解成让当前模型对一个非常困难的任务投入更多推理。官方当前建议Max主要用于最困难、以深度和质量优先的任务。例如一个分布式系统出现很难复现的数据一致性问题。这时候你希望Agent不断分析建立假设检查多个证据推翻错误方向深入验证。这就是Max适合的场景。所以Hard Single Problem ↓ Max十三、Ultra和Max其实不是一回事这是最值得注意的地方。当前Codex的Ultra模式并不是简单Max再增加一点Reasoning。官方说明非常明确Ultra会使用Subagents把复杂任务中的不同部分进行并行处理。结构更接近Main Agent ↓ ┌────┼────┐ ↓ ↓ ↓ A B C ↓ ↓ ↓ 结果汇总所以Max Single-Agent Deep Reasoning而Ultra Reasoning Automatic Delegation Subagents这两者解决的是不同问题。十四、什么任务适合Ultra最重要的判断不是任务难不难而是任务能不能真正拆成相对独立的子问题例如对一个大型项目做完整升级评估。可以拆成Agent A 检查BackendAgent B 检查FrontendAgent C 分析测试体系最后主Agent整合结果。这种工作天然可以并行。Ultra就有意义。十五、什么任务不适合Ultra例如找出这个函数为什么产生Race Condition。它真正的问题只有一个。后面的每一步强依赖前面的推理理解状态 ↓ 找到竞争条件 ↓ 定位触发顺序 ↓ 验证这种任务即使派5个Subagents也未必比一个Agent深度思考更有效。更可能适合Sol Max而不是Ultra所以记住复杂 ≠ 一定适合并行。十六、真正实用的是建立一张任务路由表日常使用Codex可以直接按照任务类型做第一轮选择。类型1小而明确例如改变量修明确报错简单格式调整。建议Luna / Terra Low类型2普通开发任务例如实现API修常规Bug补测试小范围重构。建议Terra Medium类型3复杂调试例如Root Cause不明确跨模块Bug性能问题。建议Terra / Sol High类型4复杂架构任务例如系统迁移核心模块重构安全分析。建议Sol Extra High / Max类型5大型可拆任务例如多个模块同时分析大规模Repository Review多个独立方向并行调查。建议Sol Ultra这套表不是绝对规则。但它至少比所有任务Sol Max合理得多。十七、判断模型是否选对不要只看“答案好不好”真正进入Codex工作流以后建议同时看4个指标。Quality结果是否正确Latency完成任务花了多久Usage消耗是否合理Intervention中间需要人工纠正多少次最终我们真正优化的是Task Quality ────────────── Time × Usage × Human Intervention而不是单独追求Maximum Intelligence。十八、什么时候应该“降模型”这是很多人很少主动做的一步。如果一个Workflow已经连续跑了几十次而且Prompt稳定Skill稳定输入结构固定输出格式固定Verification明确。那么应该开始问这个任务是不是还需要Sol例如原来Sol High跑CI错误分类。随着Workflow越来越成熟可能逐步测试Terra Medium再到Luna Low如果最终质量仍然稳定说明真正成熟的不是模型越来越强。而是Workflow越来越确定。这其实才是Agent工程效率提升最重要的一种方式。十九、为什么“越高越好”最终一定会失效因为真实工程不是Benchmark。真实工程需要平衡质量 速度 消耗 稳定性 并发假设任务A需要30秒完成。使用更高Reasoning以后变成3分钟但结果完全一样。那么更高Reasoning没有创造价值。如果企业每天运行1000 Tasks这种差别会迅速放大。因此Agent规模越大越需要Routing。未来真正成熟的Agent系统不应该让所有任务都流向旗舰配置。而应该Task Classification ↓ Model Routing ↓ Reasoning Routing ↓ Execution ↓ Verification二十、模型选择其实正在变成Agent架构的一部分过去Model Picker只是一个UI按钮。现在随着SkillsScheduled TasksSubagentsAutomations越来越多模型选择开始变成Workflow Configuration。例如Explorer → LunaImplementer → TerraArchitecture Reviewer → Sol同一个Agent系统里不同角色完全可能使用不同模型。所以真正值得优化的已经不是Codex应该使用哪个模型而是这个系统里的每一种任务分别应该交给哪个模型这就是Model Routing。最后GPT-5.6 Sol、Terra、Luna真正带来的变化并不是让用户每天纠结到底哪个最强更合理的使用方式是复杂开放任务 → Sol 日常工程任务 → Terra 清楚重复任务 → Luna再根据任务难度选择Low Medium High Extra High Max Ultra其中最重要的两条原则是第一不要用最强模型解决所有任务。第二不要把Reasoning越高理解成结果一定越好。官方当前的建议其实非常接近这个思路使用能够达到目标的最低Reasoning级别需要更多计划、分析和检查时再逐渐提高。所以真正成熟的Codex工作流应该越来越接近Task ↓ Model ↓ Reasoning ↓ Execution ↓ Verification而不是所有任务 ↓ Sol ↓ Max当我们开始按照任务特点分配模型和Reasoning以后Codex优化的就不再只是单次回答有多聪明。而是整个工程系统的效率、稳定性和任务吞吐量。这才是GPT-5.6时代真正值得建立的Model Routing思维。持续更新Codex、大模型开发相关技术内容。长期使用各类代码大模型整理了稳定的AI会员订阅渠道。
GPT-5.6进入Codex以后一个非常明显的变化是模型选择越来越不像“选最强的那个”这么简单。现在Codex主要提供三档GPT-5.6模型GPT-5.6 Sol GPT-5.6 Terra GPT-5.6 Luna同时还可以继续调整ReasoningLow Medium High Extra High Max Ultra于是很多人会产生一个最直接的想法Sol最强那我一直用Sol不就行了或者Reasoning直接拉到Max、Ultra结果肯定最好。实际上这种用法反而很容易让Codex变得更慢、更重而且很多任务根本得不到对应收益。OpenAI目前对三款模型的定位非常清楚Sol面向复杂、开放式和高价值任务Terra是日常工作的主力模型Luna更适合边界明确、重复性高的任务。官方同时建议Reasoning应该使用“能够达到所需结果的最低级别”再根据任务复杂度逐级提高。所以真正应该建立的不是最强模型优先。而是Task → Model → Reasoning这套任务路由逻辑。一、先分清Model和Reasoning解决的不是同一个问题很多人会把Sol / Terra / Luna和Low / Medium / High理解成同一条性能滑杆。其实不是。模型更接近选择什么级别的执行引擎。Reasoning更接近这次任务让它投入多少推理资源。可以简单理解成Model ↓ 基础能力与任务定位Reasoning ↓ 本次任务思考深度所以完全可能出现Terra High比Sol Low更适合某一个具体任务。真正需要判断的是任务本身。二、Sol不要拿旗舰模型去做所有小任务目前Codex官方把GPT-5.6 Sol定位为三款模型里能力最强的一档尤其适合复杂代码修改、深度研究、Computer Use以及需要更多判断和打磨的开放式工作。什么叫开放式任务例如分析为什么这个大型项目最近接口延迟突然增加并提出修改方案。这里并没有明确告诉Agent哪个文件有问题应该改哪段代码Root Cause是什么。它可能需要读取架构 ↓ 搜索代码 ↓ 检查调用链 ↓ 分析日志 ↓ 提出假设 ↓ 验证假设 ↓ 修改多个模块这种任务最大的难点不是写代码。而是判断应该做什么。这种情况下Sol更有价值。三、哪些任务更适合Sol可以归纳成4类。1. Root Cause不明确例如偶发内存泄漏帮我找原因。Agent需要自己探索。2. 修改范围可能跨多个模块例如API ↓ Service ↓ Database ↓ Frontend需要同时理解多个系统关系。3. 需要大量权衡比如重新设计权限系统但是不能破坏旧接口。这里不是简单实现。而是要在兼容性安全性能维护成本之间做判断。4. 错误成本较高例如核心架构重构复杂Migration安全问题高风险代码Review。这种任务值得让模型投入更多分析。所以Sol真正适合的是Ambiguous Complex High Value四、Terra才更像大多数开发者的日常主力如果Sol负责解决最困难的问题Terra更像Everyday Workhorse。官方目前把Terra定位为日常工作的平衡型模型在保持较强推理和工具能力的同时不需要每个任务都使用Sol的完整深度。比如修一个明确Bug新增一个API补测试修改数据库查询重构一个模块这些任务通常已经具备清楚的Goal有限的Scope明确的Done Condition。Agent不需要先研究半天我到底应该干什么更多是在执行已经比较清楚的工程任务。这种情况下Terra往往更合理。五、很多Codex任务其实不用Sol比如任务是users接口返回字段里增加avatarUrl并补相关测试。任务结构已经非常明确Goal 增加字段 Scope users API Verification 测试通过真正的工作可能只有找Schema ↓ 修改返回值 ↓ 调整Type ↓ 补测试 ↓ 运行验证这种情况下最主要的问题是稳定执行。而不是深度研究。直接使用Sol并不一定会让这个任务产生明显更好的结果。这也是为什么模型路由非常重要。六、Luna不要理解成“能力弱的模型”很多人看到Luna的定位偏速度和效率就会自然认为那它只能做简单问答。这也不准确。官方把Luna定位在clear、repeatable、high-volume这类任务上。核心并不是任务必须特别简单。而是任务规则足够明确。例如按照固定格式整理Commit扫描日志并分类错误把一批接口信息转换为统一JSON给200个文件检查同一种规则这些任务可能数量非常大。但单个任务不需要大量开放式判断。这种情况下Luna反而非常合适。七、Luna特别适合和Skills、Scheduled Tasks组合昨天我们讲Skills的时候提到过一个真正稳定的Skill应该已经把Input Process Output定义清楚。Scheduled Task同样适合边界稳定可以重复能够验证的任务。这两类任务天然很适合Luna。例如每天09:00 ↓ Scheduled Task ↓ 调用CI Triage Skill ↓ Luna ↓ 读取失败记录 ↓ 分类 ↓ 生成结构化报告这里真正值钱的不是模型自己重新思考整个Workflow。而是可靠执行已经定义好的Workflow。所以可以记住一句话任务越标准化越有机会把模型往Luna方向下沉。八、选完模型以后第二步才是Reasoning很多人真正浪费额度和时间的地方其实不是模型。而是Reasoning一直开太高。Codex目前建议根据任务难度选择Reasoning并明确指出更高Reasoning可能改善复杂任务结果但会增加执行时间和Token使用。官方默认建议从合适的较低级别开始再根据结果提高。可以把Reasoning简单理解成Low 快速执行 Medium 执行 一定规划 High 更多分析与检查 Extra High 复杂长任务 Max 单任务最大推理深度 Ultra 多Agent自动拆分任务但这里最重要的是Ultra已经不仅是“再多想一点”。九、Low适合什么Low最适合任务已经非常清楚。例如把这个变量名改成userId并更新相关引用。或者修复这个已经定位好的TypeScript类型错误。这里Agent几乎不需要探索。流程就是Understand ↓ Modify ↓ Verify如果这种任务也一直用High或者Max增加的推理并不一定产生明显收益。所以Small Scope Clear Goal Clear Verification → Low十、Medium其实应该成为很多人的默认起点Medium的价值在于速度和推理深度比较平衡。比如给订单接口增加分页并补测试。Agent需要理解现有接口找到相关代码修改检查影响运行测试。需要一点计划但不是复杂架构问题。这种任务非常适合Terra MediumOpenAI当前Codex默认Power配置使用Sol搭配Medium同时官方最佳实践也把Medium视为需要一定规划任务的常用区间。所以不确定Reasoning的时候Medium通常是一个很好的基线。十一、什么时候应该升High或者Extra High出现以下信号就可以考虑提高Reasoning。Root Cause不明确需要Agent自己排查。修改文件明显增多例如十几个文件形成一条调用链。存在多个方案需要比较Trade-off。任务持续时间比较长需要保持计划和状态。Verification比较复杂不仅跑一个测试还需要Unit Test Integration Test Lint Type Check Diff Review这种情况下可以从Medium ↓ High再根据实际表现增加。十二、Max真正适合的是“一个特别难的问题”Max最容易被误解。很多人会认为Max就是日常High的增强版。其实更适合理解成让当前模型对一个非常困难的任务投入更多推理。官方当前建议Max主要用于最困难、以深度和质量优先的任务。例如一个分布式系统出现很难复现的数据一致性问题。这时候你希望Agent不断分析建立假设检查多个证据推翻错误方向深入验证。这就是Max适合的场景。所以Hard Single Problem ↓ Max十三、Ultra和Max其实不是一回事这是最值得注意的地方。当前Codex的Ultra模式并不是简单Max再增加一点Reasoning。官方说明非常明确Ultra会使用Subagents把复杂任务中的不同部分进行并行处理。结构更接近Main Agent ↓ ┌────┼────┐ ↓ ↓ ↓ A B C ↓ ↓ ↓ 结果汇总所以Max Single-Agent Deep Reasoning而Ultra Reasoning Automatic Delegation Subagents这两者解决的是不同问题。十四、什么任务适合Ultra最重要的判断不是任务难不难而是任务能不能真正拆成相对独立的子问题例如对一个大型项目做完整升级评估。可以拆成Agent A 检查BackendAgent B 检查FrontendAgent C 分析测试体系最后主Agent整合结果。这种工作天然可以并行。Ultra就有意义。十五、什么任务不适合Ultra例如找出这个函数为什么产生Race Condition。它真正的问题只有一个。后面的每一步强依赖前面的推理理解状态 ↓ 找到竞争条件 ↓ 定位触发顺序 ↓ 验证这种任务即使派5个Subagents也未必比一个Agent深度思考更有效。更可能适合Sol Max而不是Ultra所以记住复杂 ≠ 一定适合并行。十六、真正实用的是建立一张任务路由表日常使用Codex可以直接按照任务类型做第一轮选择。类型1小而明确例如改变量修明确报错简单格式调整。建议Luna / Terra Low类型2普通开发任务例如实现API修常规Bug补测试小范围重构。建议Terra Medium类型3复杂调试例如Root Cause不明确跨模块Bug性能问题。建议Terra / Sol High类型4复杂架构任务例如系统迁移核心模块重构安全分析。建议Sol Extra High / Max类型5大型可拆任务例如多个模块同时分析大规模Repository Review多个独立方向并行调查。建议Sol Ultra这套表不是绝对规则。但它至少比所有任务Sol Max合理得多。十七、判断模型是否选对不要只看“答案好不好”真正进入Codex工作流以后建议同时看4个指标。Quality结果是否正确Latency完成任务花了多久Usage消耗是否合理Intervention中间需要人工纠正多少次最终我们真正优化的是Task Quality ────────────── Time × Usage × Human Intervention而不是单独追求Maximum Intelligence。十八、什么时候应该“降模型”这是很多人很少主动做的一步。如果一个Workflow已经连续跑了几十次而且Prompt稳定Skill稳定输入结构固定输出格式固定Verification明确。那么应该开始问这个任务是不是还需要Sol例如原来Sol High跑CI错误分类。随着Workflow越来越成熟可能逐步测试Terra Medium再到Luna Low如果最终质量仍然稳定说明真正成熟的不是模型越来越强。而是Workflow越来越确定。这其实才是Agent工程效率提升最重要的一种方式。十九、为什么“越高越好”最终一定会失效因为真实工程不是Benchmark。真实工程需要平衡质量 速度 消耗 稳定性 并发假设任务A需要30秒完成。使用更高Reasoning以后变成3分钟但结果完全一样。那么更高Reasoning没有创造价值。如果企业每天运行1000 Tasks这种差别会迅速放大。因此Agent规模越大越需要Routing。未来真正成熟的Agent系统不应该让所有任务都流向旗舰配置。而应该Task Classification ↓ Model Routing ↓ Reasoning Routing ↓ Execution ↓ Verification二十、模型选择其实正在变成Agent架构的一部分过去Model Picker只是一个UI按钮。现在随着SkillsScheduled TasksSubagentsAutomations越来越多模型选择开始变成Workflow Configuration。例如Explorer → LunaImplementer → TerraArchitecture Reviewer → Sol同一个Agent系统里不同角色完全可能使用不同模型。所以真正值得优化的已经不是Codex应该使用哪个模型而是这个系统里的每一种任务分别应该交给哪个模型这就是Model Routing。最后GPT-5.6 Sol、Terra、Luna真正带来的变化并不是让用户每天纠结到底哪个最强更合理的使用方式是复杂开放任务 → Sol 日常工程任务 → Terra 清楚重复任务 → Luna再根据任务难度选择Low Medium High Extra High Max Ultra其中最重要的两条原则是第一不要用最强模型解决所有任务。第二不要把Reasoning越高理解成结果一定越好。官方当前的建议其实非常接近这个思路使用能够达到目标的最低Reasoning级别需要更多计划、分析和检查时再逐渐提高。所以真正成熟的Codex工作流应该越来越接近Task ↓ Model ↓ Reasoning ↓ Execution ↓ Verification而不是所有任务 ↓ Sol ↓ Max当我们开始按照任务特点分配模型和Reasoning以后Codex优化的就不再只是单次回答有多聪明。而是整个工程系统的效率、稳定性和任务吞吐量。这才是GPT-5.6时代真正值得建立的Model Routing思维。持续更新Codex、大模型开发相关技术内容。长期使用各类代码大模型整理了稳定的AI会员订阅渠道。
创建与使用全攻略)
