GPT-5.6进入Codex以后，一个非常明显的变化是：

模型选择越来越不像“选最强的那个”这么简单。

现在Codex主要提供三档GPT-5.6模型：

GPT-5.6 Sol
GPT-5.6 Terra
GPT-5.6 Luna

同时还可以继续调整Reasoning：

Low
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
+
Medium

OpenAI当前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
检查Backend

Agent B
检查Frontend

Agent 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按钮。

现在随着：

Skills；

Scheduled Tasks；

Subagents；

Automations

越来越多，

模型选择开始变成：

Workflow Configuration。

例如：

Explorer
→ Luna

Implementer
→ Terra

Architecture 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会员订阅渠道。