一个 Codex 多模型路由的脑洞:Jev → Terra / Sol / Astra

AIGC嘭嘭嘭 2026-09-20 14:43 1

最近一直在折腾 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 工作流里搓一版试试,看看实际能不能省掉一部分高级模型额度。

最新回复 (13)
  • LingEasy 09-20 14:45
    1

    不建议jev来切换模型和思考强度。

    gpt从来最贵的都是输入。你一个20wtoken上下文几次切换 全是新增缓存未命中。jev是偏移。一次模型全新输入缓存 你扛得住么? 你目的是降本 但是实际可能升本

  • Magentic 09-20 14:45
    2

    单任务还是不要中途切换模型,找回上下文同样要消耗

  • Ricardo. 09-20 14:46
    3

    想法是好的,但是会话中切换模型要考虑缓存问题,如果频繁切换频繁掉缓存的话(尤其是 Astra),那资费会暴涨

  • 气雾剂 09-20 14:49
    4

    主进程保持对话上下文,subagent派发时自动决策模型和思考程度,怎么说

  • Atoz 03 09-20 14:56
    5

    这个 不是而是 ai 味有点重,模型路由、意图识别和分类器本身就有这个概念了而且已经应用了 事实证明 OpenAI 做的不是很好,除开这些中途换还是不建议的

  • AIGC嘭嘭嘭 楼主 09-20 14:57
    6

    感谢几位佬提醒,缓存和上下文复用这块确实是我之前没考虑周全。

    看下来感觉“主 Agent 保持上下文,只在派发 subagent 时决定模型/思考强度”会更合理一些,这个方向我再琢磨琢磨。

    学到了,感谢补充。

  • 朱慧月 09-20 14:58
    7

    多模型路由大家都做的烂完了你现在又加个jev 感觉没啥用啊

  • AIGC嘭嘭嘭 楼主 09-20 14:59
    8

    确实 还得沉淀沉淀 就是Astra 用太快了 ^-^

  • aeatho 09-20 15:00
    9

    没啥用,缓存命不中,更费token

  • 天则则 09-20 15:01
    10

    jev 并不清楚哪些是高难度任务

  • Ares 09-20 15:05
    11

    jev这模型就现在来看并不能做很高深的决策。。这类模型以前就有,而且有比jev做的好的,现在只是突然被炒起来大家才关注到的

  • Leo 09-20 18:43
    12



    别随便乱切,简单点就走多 agent 模式。

    这个问题openai 提供的解决方案就是 agent role 配置。

    可以看一下我之前的回复:



    看一下官方文档,让 ai 配置一下就行,动态加载的,甚至在会话里使用提示词进行声明也行。
    不过有一个前提,你需要把所有的 model 聚合到一个 provider里。
    不过我自己搓了一个 app,把这些 ui化了~
    在目录~/.codex/agents新增 agent role配置即可,这样可以持久化你常用的 agent role。比如 gemini 来写页面等需求,可以配置模型、思考等…
  • Butterl 09-20 18:47
    13

    是不是有点像啥都不懂的PM来瞎指挥,万一他觉得他上也行而且真上了不是麻烦了么

* 帖子来源Linux.do
返回