AI 工作流成本优化：选模型不是越贵越好

有一段时间，面对重要的 Codex 任务，我默认的处理方式很简单：选择能力最强的模型，提高 reasoning effort，然后把所有工作都交给它。

这听起来很稳妥，但往往效率低下。

最强的模型可能会重新考虑那些已经批准的决策。机械式修改也会继承一个过于庞大的上下文包。一个微小且确定性的变更，要排在编排步骤之后等待，而编排本身的成本甚至高于实际工作。即使最终的 diff 非常简单，整条执行路径依然会消耗大量 token，并拉长实际耗时。

一个显而易见的反应是——把所有工作都交给最便宜的模型——但这会因为相反的原因失败。存在歧义的工作更容易需要重试，Review 的成本也会随之上升。最终，能力更强的父模型仍然不得不重新构建上下文，并再次完成决策。

真正应该优化的目标，不是成本最低的单次调用，而是成本最低、完整且最终被接受的执行路径。

真正重要的边界

一开始，我把任务分为“简单”和“困难”两类。但这种划分过于主观，没有多少实际价值。更好的问题是：决策和正确性验证机制是否已经冻结。

来看看下面四项任务，它们都可以被描述为“生成一些文件”：

实现九项已经批准的状态映射，并验证每一个值。

协调分散在十四份文档中、彼此冲突的产品规则。

在预期行为已经获得批准、但补丁实现机制仍未确定的情况下，修复一个异步竞态问题。

把已经批准的权限规则编译成真值表，并使用精确集合检查器进行验证。

输出格式并不能告诉我们哪个模型足以胜任，真正决定模型选择的是不确定性。

第一项和第四项任务都有封闭集合、冻结的规则和确定性的验证方式，很适合交给成本较低的模型执行。第二项任务需要跨来源协调信息。第三项任务仍然包含调试层面的决策。把这四项任务全部交给同一档模型，要么浪费 credits，要么增加重试次数。

质量优先的路由策略

最后，我归纳出了四条大致的执行路径：

对于一两个已知的确定性操作，直接由父模型或工具处理。

对于规则已经冻结、上下文范围有限、以机械执行和穷尽检查为主的任务，使用 Luna。

对于跨来源综合、常规集成、更宽广的上下文，以及仍未收敛的调试任务，使用 Terra。

对于模糊的规划任务，以及涉及权限、隐私、资金、合规、科学或生产环境的重大决策，使用 Sol 或当前父模型。

这并不是一份模型排行榜。成本较低的模型可能适合某个阶段，但不一定适合负责整个任务。

Router 会保留用户选择的父模型和 effort。它把工作拆分成带有明确类型的阶段——收集证据、做出决策、执行已经冻结的契约，或者在实现机制仍未确定时执行——然后只把尚未解决的阶段分配出去。

委派同样有成本

便宜的 worker 并不是免费的。一个实用的成本估算应当包括：

task packet
+ worker execution
+ verification
+ probability of fallback × fallback cost
+ duplicated context

这就是为什么一行 CSS 修改通常应该直接处理。也正因如此，即使一个已经冻结的大型映射横跨多个文件，也可能值得委派：task packet 的成本可以被摊薄，而检查器能够验证整个集合。

第一轮回归测试说明了什么——又没有说明什么

我把这套路由策略打包成了一个名为 Adaptive Model Router 的开源 Codex skill，并创建了一组包含 14 个案例的路由回归测试。其中涵盖微小修改、有限映射、跨来源证据、异步竞态、长上下文综合，以及高后果决策。

两次由该 skill 指导的运行，在路由 oracle 上都取得了 14/14 的成绩。两次没有指导的对比运行则分别得到 5/14 和 6/14。

这些数字需要附带一个重要的限定条件：这是一项开发阶段的回归测试。测试案例参与了 Router 的设计。它不是独立的 holdout 测试，也不能证明这套方案在端到端质量、credits、token 或延迟方面具有普遍改进。它只能表明：对于测试所覆盖的任务边界，这套书面策略让路由选择变得更加一致。

仓库中包含 prompts、schema、oracle、scorer 和原始结果，因此任何人都可以检查这些结论，而不必把它们当作营销话术反复传播。

该项目采用 MIT 许可证，并以 Codex plugin marketplace 的形式发布：

codex plugin marketplace add cyc981565058-cpu/adaptive-model-router
codex plugin add adaptive-model-router@adaptive-model-router

源代码与 benchmark：

https://github.com/cyc981565058-cpu/adaptive-model-router

接下来真正有价值的工作，并不是在同一批案例上继续打磨另一个漂亮的 benchmark，而是收集独立任务的证据：验收质量、重试次数、原始 token 数量、credits 或 API 成本，以及不同父模型和 reasoning effort 下的实际耗时。

如果你遇到某项任务，Router 总是选择能力过弱或过强的模型，或者把验证成本计算在内之后反而变得更慢，那么这样的反例，远比泛泛而谈的成功案例更有价值。

披露：我是上述项目的维护者。本文借助 AI 起草，随后依据公开仓库、原始 benchmark 输出以及平台指南进行了审查。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。