别再让最强模型干所有活：Codex 多模型路由中的四个成本陷阱

使用 AI 编程 Agent 时，一个很常见的策略是：重要任务直接选最强模型，再把推理强度开高。

这个策略不容易犯“模型能力不足”的错，却会制造另一类浪费：已经冻结的规则被重新分析，机械执行携带了过量上下文，简单修改等待复杂规划，最终速度和成本都不理想。

反过来，把所有任务切换到便宜模型也不是优化。只要任务里还存在未解决的业务判断、跨来源冲突或调试假设，低模型一次通过率下降，父模型复核时还要重新加载上下文。省下的一次调用，很可能在返工中加倍付回去。

陷阱一：只看模型单价，不看完整路线

一次委派至少包含五部分成本：

 复制代码任务包 + worker 执行 + 验证+ 失败概率 ×（回退执行 + 额外复核）+ 重复上下文

因此，“用更便宜的模型”并不自动等于“整个任务更便宜”。一行 CSS 修改如果已有唯一 diff 和 checker，父模型直接改通常最快；为它创建 worker、重述背景再复核，反而扩大成本。

陷阱二：用文件数量判断难度

两百个 locale 文件上的同一个机械替换，看起来工作量很大，却可能非常适合低成本模型：规则完全一致、脚本可批量执行、全量 checker 能确定验证。

相反，一张只有几十行的权限表，如果角色、workspace、默认拒绝、404/403 和脱敏边界仍有冲突，就不能交给低模型“整理一下”。那不是表格生成，而是生产政策决策。

判断模型能力的核心不是输出规模，而是不确定性位于哪里。

陷阱三：把“行为已确认”误当成“实现已冻结”

以 React 搜索竞态为例。产品已经确认“旧请求不能覆盖新请求、卸载后不能更新”，并不代表补丁机制已经冻结。到底使用取消、递增序列、状态所有权还是其他方案，仍需要调试和设计判断。

如果连补丁合同也已经批准，例如明确规定只有最新 sequence token 可以写入 data/error/loading，并且隐藏测试覆盖所有分支，那么任务才从开放式调试变成冻结执行。

这两种情况表面上都是“修一个异步 bug”，适合的模型却不同。

陷阱四：强模型既当裁判，又做所有体力活

更合理的分工是保留一个清晰的决策 owner：

1. 当前父模型或 Sol：负责含糊规划和权限、隐私、资金、合规、生产等关键决策；
2. Terra：负责跨来源协调、常规集成、长上下文整理和开放式调试；
3. Luna：负责规则冻结、上下文有界、可机械执行、可穷举验证的工作；
4. 直接工具：负责很小的确定性动作。

强模型的价值应集中在“哪里还需要判断”，而不是覆盖每一次文件写入。

把判断写成可复用技能

我将这套方法整理成了 Adaptive Model Router，一个 MIT 开源的 Codex skill。它不会修改用户选择的父模型，而是把任务拆成证据收集、决策、冻结执行和开放执行四类阶段，再选择预计一次通过的最低能力路线。

项目内置了一组 14 项路由回归。两轮带技能结果均为 14/14，两轮无技能对照分别为 5/14 和 6/14。回归覆盖单行修改、有限状态映射、证据冲突、长上下文、异步竞态、权限和资金决策。

这组数据不能被解读成“所有任务都能节省固定比例”。它是开发期回归，不是独立盲测；测的是路由一致性，不是端到端实现质量。仓库公开了 prompt、oracle、schema、scorer 和四份原始输出，方便复查。

安装：

 复制代码codex plugin marketplace add cyc981565058-cpu/adaptive-model-routercodex plugin add adaptive-model-router@adaptive-model-router

源码与公开基准：

github.com/cyc98156505…

下一阶段我希望补齐独立任务的实测：验收质量、返工次数、原始 tokens、credits/API 成本和耗时分开记录。相比“哪个模型最强”，这些数据更可能回答真正有用的问题：对某一类任务，哪条完整路线最早通过验收？