最近一直在折腾 Codex 的子 Agent，主要还是想解决一个很现实的问题：

不同任务，没必要都上最贵的模型。

我现在大概是这么分的：

简单任务 → Terra
常规开发 → Sol
复杂决策 → Astra
比如改个字段名、补个简单测试、生成一点 CRUD，这种如果也直接上 Astra，多少有点大炮打蚊子的感觉。

但反过来，如果所有任务都先丢给便宜模型，也会碰到另一个问题：

有些需求表面看起来很简单，真正进去以后才发现复杂度完全不是一回事。

比如一句：

给订单接口加个字段

实际可能一路牵扯到：

数据库
缓存
MQ
老版本兼容
数据迁移
上下游接口
这时候一开始如果分给低档模型，可能折腾半天，最后还是得切回高级模型重新处理。

这两天看到 Jev 之后，我突然冒出来一个想法：

能不能在真正执行任务之前，先加一层轻量的“任务判断 / 路由”？

大概是这种感觉：

用户任务
│
▼
Jev / 任务判断层
│
┌─────────┼─────────┐
│ │ │
▼ ▼ ▼
Terra Sol Astra
简单任务 常规开发 高难任务
举几个比较直观的例子。

这种：

改个变量名
补 README
找一个文件
跑一下测试
生成简单 CRUD
直接：

→ Terra
这种：

实现一个正常业务功能
修改接口
重构某段代码
补完整单测
走：

→ Sol
再往上的：

系统架构设计
复杂线上问题排查
跨模块重构
数据库结构调整
高风险操作
再交给：

→ Astra
不过我现在想的并不是让 Jev 直接决定：

“这次用 Astra。”

我反而觉得，更合理的方式可能是：

Jev 只负责判断任务属性，真正的模型选择还是走我们自己定义的规则。

比如先输出类似：

{
"complexity": "high",
"risk": "medium",
"task_type": "architecture"
}
然后再自己做路由：

complexity = low
→ Terra

complexity = medium
→ Sol

complexity = high
→ Astra

risk = high
→ Astra + 人工确认
这样有个好处：

以后就算模型换了，也不用重新设计整个判断逻辑。

比如以后不叫 Terra / Sol / Astra 了，只需要改后面的映射关系就行。

另外我觉得这个东西如果真做，最好也不能只判断一次。

例如一开始判断是普通任务：

用户需求
↓
Sol
结果 Sol 执行到一半发现：

涉及 5 个模块
数据库结构需要调整
还要兼容历史数据
存在上线迁移风险
那这时候应该允许它升级：

Sol
↓
发现任务复杂度上升
↓
重新判断
↓
Astra
也就是：

先路由，执行过程中再动态升级。

我感觉这可能比“一开始决定好模型，后面死磕到底”更合理一点。

当然，目前我还有几个问题没想明白。

1. 多这一层判断，到底划不划算？
本来是为了省高级模型额度。

结果每个任务之前又额外跑一次判断，如果判断本身也有成本和延迟，那最后到底有没有省下来，需要实际测。

2. 前置判断会不会经常误判？
这个我感觉很难完全避免。

有些需求描述只有一句话，看起来简单，真正进代码库之后才知道复杂。

所以如果做的话，我觉得动态升级应该是必须有的。

3. 到底应该判断“模型”，还是判断“任务属性”？
我现在个人比较倾向后者。

不是：

这个任务 → Astra
而是：

复杂度：高
风险：中
类型：架构设计
上下文范围：大
再由规则决定到底用哪个模型。

这样整体会更解耦一点。

目前还只是我折腾 Codex 子 Agent 时冒出来的一个脑洞，还没正式实现。

我的最终目标其实挺简单：

简单活别浪费高级模型
复杂活也别让低档模型硬撑
让不同模型干更适合自己的事情。

不知道有没有佬友已经玩过类似的方案：

轻量模型负责判断任务，高级模型负责真正干活。

或者现在已经有比较成熟的多模型路由方案了？

如果这个思路靠谱，我准备后面直接在自己的 Codex 工作流里搓一版试试，看看实际能不能省掉一部分高级模型额度。