最近一直在折腾 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 工作流里搓一版试试，看看实际能不能省掉一部分高级模型额度。 1 个帖子 - 1 位参与者 阅读完整话题

  • 情报分类：技术学习与提效
  • 分类依据：内容涉及技术、AI、软件工具或工程实践
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/9/20 14:43:23