成本感知AI路由策略：按任务难度自动选免费或最强模型

在上一篇文章中，我搭建了一个用于探测 AI 编程助手实际能力边界的测试框架。本文要讨论的问题是紧接其后的：一旦你了解了某个助手能做什么，仍然需要决定由哪个模型来执行任务——把所有任务都扔给最贵的模型，是一笔悄悄流失的预算。

强大且便宜的模型不断推出，前沿模型在难题上的表现也持续提升。真正的问题不是"哪个模型最好"，而是"我日常中的哪些任务真正需要最好的模型"。本文介绍我使用的路由方案，包含一个小型的、可直接复用的代码片段供你适配。

起始的观察

我记录了两周内自己使用助手辅助编程的任务，并对每个任务事后做了标注：这个任务是否真的需要深度推理，还是任何具备能力的模型都能完成？大致分布如下：

机械转换（重命名 + 修复 import、生成样板测试、转换配置格式）：中档模型几乎每次都能成功。

本地推理（解释这个函数、找出这个测试为何 flaky）：大多数时候中档模型也够用。

跨领域设计或隐蔽 bug（竞态条件、API 契约决策、涉及多个文件的重构）：这是较弱模型产生"看起来对但实际错"输出的地方——审查它们花的时间比节省的时间还多。

所以优化目标不是模型质量，而是审查成本。机械任务上的错误答案很容易发现（测试套件会捕获它）。设计问题上的错误答案则很难发现（你就是那个测试套件）。

三层路由规则

我遵循的规则是：任务从最便宜的层级开始，只有在失败检测器是"人"的时候才升级。如果测试套件、类型检查器或 linter 能捕获一个错误的答案，就没有理由为此支付前沿模型的价格。

可复用的部分：预检分类器

不是在 prompt 时凭感觉做决定，而是先运行一个极简分类器。它故意做得很"笨"——用启发式规则，而不是 ML——因为我想让它可审计：

# route.py — 在把任务发给 agent 之前决定用哪一层
import re

TIER3_SIGNALS = [
    r"race|deadlock|concurren|async.*order",
    r"auth|token|secret|permission|inject",
    r"migrat|schema change|breaking",
    r"refactor.*(across|all|whole)",
]

def tier(task: str, files_touched: int, has_tests: bool) -> int:
    t = task.lower()
    if any(re.search(p, t) for p in TIER3_SIGNALS):
        return 3
    if files_touched > 3 and not has_tests:
        return 3          # 没有安全网 + 影响范围大
    if files_touched <= 1:
        return 2
    return 1 if has_tests else 2

if __name__ == "__main__":
    print(tier("rename getUser to fetchUser and fix imports", 6, True))   # 1
    print(tier("explain why this parser drops trailing commas", 1, True)) # 2
    print(tier("possible race in the retry logic", 2, True))              # 3

输入参数（files_touched、has_tests）来自任务脚手架——在我的场景中，agent 框架会在执行前报告这些数值。关键不在于具体的阈值，而在于路由决策是明确的、可记录的、可调整的。一周后你可以统计每层输出需要返工的比例，用真实数据收紧或放宽信号规则。

在这个架构中免费层的位置

第 1 层和第 2 层需要一个始终可用且零成本的模型，因为这是我日常流量最大的部分。披露：本文是 MonkeyCode 产品推广的一部分。我将第 1/2 层任务路由到 MonkeyCode，因为它提供免费模型访问和免费服务器选项，这与高流量、低风险层级正好对应——当路由器把一个样板生成任务下发时，我无需考虑每次调用的成本。第 3 层任务（审查成本占主导的那些）仍然发给我当前信赖的前沿模型处理设计工作；免费层不改变这部分决策。

关于免费层的一个诚实警告：预期会有波动。延迟、可用性以及提供的模型都可能会变化，所以路由器将免费端点视为默认选项而非保证——如果第 1 层任务失败或超时，它会重试一次，然后升级一层，而不是循环重试。

局限性，以及谁不应该这样做

分类器的好坏完全取决于它的信号规则。任何未被正则列表覆盖的内容默认落入较低层级。缓解措施是"失败时升级"的行为加上日志记录，但如果你跳过日志记录，就是在盲目飞行。

第 3 层误分类是代价最高的失败模式。一个并发 bug 被路由到弱模型，可能产生自信满满的废话。拿不准的时候，往上路由——表格的最后一列是需要保守对待的那个。

如果你的任务几乎全是第 3 层（安全关键系统、全新算法工作），路由不会为你节省任何成本，直接用最好的模型。

如果你无法机械地验证第 1 层输出（没有测试、没有 linter、没有类型检查器），整个前提就不成立。先把测试框架写好。

如果你想尝试这个方案，从日志记录开始：在路由之前，先手动标注一周的任务，了解你实际的任务层级分布，然后才自动化这个拆分。路由器是最简单的部分——了解你自己的工作负载才是真正有价值的产出。