一、模型路由真正优化的是一个多目标函数#

如果只有一个模型，Agent 的成本估算很简单：输入 token、输出 token、工具调用和运行时相加即可。但当系统拥有多个不同价格、速度和能力的模型时，问题变成了一个动态决策：

1
route(prompt, context, task_state)
2
  -> candidate models
3
  -> estimate quality / latency / cost
4
  -> choose one model

可以把路由器的目标函数粗略写成：

1
score(model) =
2
  wq * expected_quality
3
  - wc * expected_cost
4
  - wl * expected_latency
5
  - wr * failure_risk

这里的 wq / wc / wl / wr 才是 efficiency、balance、intelligence 这类偏好真正可能影响的东西。这个公式是工程抽象，并不是 GitHub 公布的内部算法。

关键点在于，任务难度不是会话级常量，而是 turn 级变量。同一个 Coding Agent 会话可能先让模型读取目录、再修改一个函数、随后分析失败测试，最后处理跨模块架构问题。把整段会话固定在一个昂贵模型上，可能浪费大量简单步骤；固定在一个小模型上，又可能让真正困难的步骤反复失败。

所以更合理的调度粒度不是“这个用户今天用什么模型”，而是“当前这一轮需要什么能力”。

二、为什么最便宜的单次调用可能是最贵的任务#

模型路由最容易犯的错误，是只比较每百万 token 的价格。

假设模型 A 单次调用成本只有模型 B 的三分之一，但在一个复杂重构任务中，A 平均需要 4 次尝试才能得到可接受 patch，而 B 通常 1 次完成。真正应该比较的是：

1
Cost per Accepted Change
2
= Σ(模型调用 + 工具执行 + Sandbox + CI + 人工复核成本)
3
  / 最终被接受的变更数

这也是为什么“efficiency”不能简单翻译成“永远选最便宜模型”。对于补 docstring、解释报错、生成小型测试夹具，较小模型通常很合理；但对跨模块重构、复杂类型错误、并发 bug 或安全边界分析，如果小模型导致更多 retry、更多无效 diff 和更多 CI 失败，总任务成本反而会上升。

团队可以记录四个比 token 单价更有意义的指标：

• First-pass acceptance rate：第一次生成的修改无需重大返工即可接受的比例；
• Retry amplification：一个用户任务最终触发了多少次模型重新推理；
• CI correction count：为了让测试、类型检查和构建通过，需要额外修正多少轮；
• Cost per accepted task：完成一个最终被接受任务的端到端费用。

模型路由器如果只优化“单次请求便宜”，而不看这些指标，很容易做出局部最优、全局更贵的决策。

三、延迟预算应该分成 TTFT 和任务完成时间#

Coding Agent 的“快”也不是一个数字。

对交互式问答，用户最敏感的是首 token 时间（TTFT）；对后台 Agent，用户更关心的是从任务提交到 PR 可审查的总时间。一个模型首字很快，但需要连续三轮修复测试，最终任务仍然可能更慢。

因此建议把延迟拆成：

1
T_total = T_queue
2
        + T_model
3
        + T_tool
4
        + T_sandbox
5
        + T_ci
6
        + T_retry

对“解释这个函数”一类前台请求，可以提高 T_model 的权重；对“把这个 issue 修好并提交 PR”的后台任务，则应该更关注 T_total 和 retry。

这也是动态路由比固定模型更有价值的地方：路由器可以在低风险步骤优先响应速度，在高风险步骤提高质量预算。

四、Coding Agent 需要的是分阶段路由，而不是模型排行榜#

一个成熟的 Agent Harness 可以把任务拆成不同阶段，并给每个阶段不同预算：

1
routing:
2
  explore:
3
    objective: efficiency
4
    max_retries: 1
5
  plan:
6
    objective: balance
7
    max_retries: 2
8
  implement:
9
    objective: balance
10
    escalate_on: [large_diff, cross_module_change]
11
  verify:
12
    objective: intelligence
13
    escalate_on: [test_failure, security_sensitive]

这同样只是可复现的工程示例，不是 GitHub Copilot 的配置格式。

这里最重要的设计是 escalation。不要一开始就把所有请求送到最高能力模型，也不要让小模型无限重试。更好的策略是：低成本尝试一次，如果触发明确的失败信号，再升级模型。

失败信号可以来自确定性系统，而不是让模型自己判断自己是否“想得不够好”：

• TypeScript / Rust / Go 编译失败；
• 单元测试或 Playwright 回归失败；
• diff 超过预设文件数或行数；
• 修改触及认证、权限、支付、密钥等敏感路径；
• 同一个错误连续出现两次；
• reviewer 要求重新设计而不是局部修补。

这样模型路由就从“AI 猜 AI”变成了模型判断 + 确定性反馈的闭环。

五、如何验证 Auto 路由到底有没有价值#

GitHub 没有在这次公告中公开 Auto 内部每个 prompt 的具体模型评分，因此外部测试不应该伪造“路由算法已经被逆向出来”的结论。我们真正能验证的是端到端结果。

可以准备一组固定任务：

1
A. 给已有函数补 docstring
2
B. 修复一个单文件边界条件 bug
3
C. 根据失败测试定位跨模块问题
4
D. 完成包含数据库 + API + UI 的小型功能
5
E. 审查一个包含权限变更的 PR

分别在可用的不同路由偏好下运行，并保存：

1
task,tier,total_time,retries,ci_failures,accepted,cost
2
A,efficiency,...
3
A,balance,...
4
A,intelligence,...

至少重复多轮，并使用同一仓库快照、同一任务描述和同一验收测试。不要只比较一次生成的主观观感，也不要把不同日期、不同代码状态的任务混在一起。

最终可以画出三条 Pareto frontier：成本—成功率、延迟—成功率、成本—总完成时间。只有当某个策略在相同成功率下更便宜，或在相同预算下成功率更高，才能说它对你的工作负载更优。

六、团队真正需要的是“预算策略即代码”#

Auto model selection 的意义不只在 Copilot 本身。随着 Coding Agent 同时拥有模型、浏览器、Shell、MCP、Sandbox 和 CI，团队会越来越需要把“这一类任务最多允许花多少资源”写成可审计策略。

例如：

1
agent_budget:
2
  docs:
3
    max_cost_usd: 0.20
4
    quality_target: standard
5
  bugfix:
6
    max_cost_usd: 1.00
7
    quality_target: balanced
8
  security_review:
9
    max_cost_usd: 3.00
10
    quality_target: high
11
    require_human_approval: true

预算策略应该和权限策略一样进入版本控制。原因很简单：当模型路由完全隐藏在客户端设置里，团队很难解释“为什么本周 Agent 成本突然翻倍”；当预算、升级条件和验收指标被记录下来，成本变化就可以被回溯。

进一步还可以把路由决策写入 telemetry：

1
{
2
  "task": "fix-auth-regression",
3
  "phase": "verify",
4
  "route_policy": "high-quality",
5
  "attempt": 2,
6
  "trigger": "security-sensitive-path",
7
  "result": "tests-passed"
8
}

这里不要求暴露供应商的私有模型评分，只要求记录团队自己的决策原因。

七、真正的变化：模型正在从产品选择变成运行时资源#

过去我们讨论“哪个模型最好”，往往默认一次任务对应一个模型。动态路由把问题改写成：哪一步需要哪种能力，什么失败信号值得升级，以及为了一个最终被接受的结果愿意支付多少。

GitHub 这次三档 Auto 设置仍然是用户层面的产品能力，而且官方没有公开内部路由细节。但它代表的工程方向已经很清楚：Coding Agent 的模型层正在越来越像云计算的调度层——CPU、GPU、内存不会由用户为每个函数手动挑选，模型也可能逐渐从一个显式品牌按钮变成由 Harness 根据任务动态分配的运行时资源。

对个人开发者，最实用的做法不是每天追逐“最强模型排行榜”，而是先记录自己的任务成功率、重试次数、CI 修正次数和端到端成本。对团队，则应该进一步把预算、升级条件和验证门槛变成可版本化策略。

当这些数据建立起来之后，efficiency、balance、intelligence 才不只是三个 UI 标签，而会变成一套可以被测量、比较和治理的工程选择。

已核验资料#

• GitHub Changelog（2026-09-14）：Configure cost and quality in Copilot auto model selection
• GitHub Changelog（2026-09-10）：GitHub Copilot weekly releases — September 7