别再手动切模型：Fusion 的 3 种自动路由

卷心菜技术创作者 2026-10-31 15 阅读

很多开发者的模型选择器使用史，都绕不开同一件小事：复杂任务开了一个强模型，写完核心逻辑后忘记切回日常模型，再过几天看账单又高了一截。模型选择器给了控制力，但控制力也附带一个隐藏成本——每个请求都得做一次决定，而人做决定的稳定性并不高。10 月 28 日，GitHub 在 Universe 发布里把 Copilot Fusion 转为 generally available，给这个老问题提供了一个新的官方答案：不用再选具体模型，选 Copilot Fusion，让系统按任务决定用哪些模型、以什么方式协作。

这不是一个突然冒出来的实验功能。官方 changelog 写明，Copilot Fusion 合并了 Project HydraFusion 的多模型编排和 Copilot auto model selection 的微调选模型能力，把两者合成一个面向用户的入口。简单说，以前你可能要理解 HydraFusion 的编排逻辑，或者依赖 auto model selection 在后台替你挑模型；现在它们被统一成 Fusion，用户只需要选一档 effort level，剩下的交给系统。

官方给了一组对比很强的数字

GitHub 在发布说明里很直接地给了外部基线：在 Artificial Analysis Coding Agent Index 里，Copilot Fusion Max 得了 60 分，官方说法是「within two points of Claude Code with Opus 5.5 Max」—— 也就是差距在 2 分以内。官方没有给出对方的具体分数，所以别去反推一个数字出来。两者差距不大，但官方真正想强调的是成本表现：以这个分数为基准，Fusion Max 的平均 API 成本约为对方的一半，token 用量约为对方的一半，每任务耗时少约 40%。

这组数字的原文来自 GitHub Changelog，属于官方转引的第三方指数数据。可以这样理解：在同一个评测口径下，Fusion Max 用约五成成本、约五成 token、约六成时间，拿到了接近头部得分的位置。这个换算关系可以用下面这张表复算：

官方转引 Artificial Analysis Coding Agent Index，2026-10-28：
Fusion Max                  score = 60
Claude Code + Opus 5.5 Max  官方只说 "within two points"，未给具体分数

相对值（官方用 "about" 表述）：
平均 API 成本 ≈ 0.5x
token 用量    ≈ 0.5x
每任务耗时   ≈ 0.6x

如果你愿意把”差距 2 分”当成一个假设（官方并没有给对方的分数），那么单位成本差大约就是 2 倍上下 —— 这是我基于官方那两个 about 做的推算，不是官方结论。值得记住的是官方那半成本、半 token 的比例本身：它不是拿 Fusion 跟某个低价小模型比，而是跟一个强基线比。

它不是“自动选模型”，而是三种编排流程

如果只把 Fusion 理解成“自动挑一个模型”，会漏掉一半重点。它真正做的是编排：一个模型起草、另一个模型审核、再决定是否升级。官方在 changelog 中列出了三种工作流：

Single：一个模型直接解决任务。这是最简单路径。
Cascade：一个高效模型先起草回答，然后经过质量检查，质量通过就接受，不通过就升级到更强模型。这条路线对成本和延迟最敏感，也是 Fusion 降低成本的关键设计之一。
Critique：一个模型起草，另一个模型审阅，再由原来的模型根据意见修订。相当于给答复加了一道内置 review，质量优先于速度。

这三种不是用户在界面上手动选择的模式，而是 Fusion 根据任务特征自行组合的方式。官方 changelog 没有完全展开触发条件，只说明在需要时通过以下工作流编排多个模型。因此，如果你在看到某个任务时说不清它走了 Cascade 还是 Critique，这很正常——系统不会把每次内部路由都摊开给用户看。对开发者而言，真正可感知的是 effort level，而不是内部流程。

三档 effort 怎么读：Standard / High / Max

官方文档给 Fusion 的用户入口是模型选择器里的三个档位：

Fusion Standard：优先使用通用型模型，对应日常编码。
Fusion High：优先使用能力更强的模型，对应困难任务和更深推理。
Fusion Max：优先使用最强模型，对应最苛刻的任务和复杂推理。

这三个档位描述可以在 GitHub Docs 的 Copilot Fusion 页面查到。它们本质上是把“这次该用哪一类模型”的选择从具体模型名降维成难度等级。对个人用户来说，日常写脚本、改 CRUD 选 Standard；做跨模块重构、排查并发问题选 High；啃分布式一致性或者复杂算法时再考虑 Max。这个选择逻辑是本文给出的使用建议，不是官方要求；官方只定义了每档的优先倾向。

值得一提的是，如果你之前参与过 research preview，并且启用过 auto、HydraFusion 或 HydraFusion Max，GitHub 会自动把你的旧选项迁移到对应的 Fusion effort level。这意味着不少用户可能某天打开编辑器，发现自己的模型选择已经变了个名字，但背后行为有继承关系。

企业管理员手里有四个开关

Fusion 对企业不是全有或全无。官方在 changelog 和文档里都强调了管理面：

管理员可以控制 Fusion 能使用哪些模型，而不是放任它调用所有模型。
管理员可以查看 Fusion 当前从哪些模型里挑选。
管理员可以对某个模型单独设置 effective policy state，即使这个模型对企业其他用户正常开放，也可以单独对 Fusion 关闭。
管理员可以通过 Enterprise managed settings 把 Fusion 设为默认模型，包括具体到某档 effort level。

这些能力在 Manage availability of default models 文档里有专门小节。对团队来说，这比普通用户看到的三档 effort 更重要：你可以让 Fusion 只使用成本更低的模型池，避免某个任务自动升级到最贵模型；也可以先开放给部分项目试用，再决定是否推广。Fusion 背后的模型策略是个可治理对象，而不只是个人偏好。

便宜不是订阅费降价，是“按调用的模型计费”

这里有一个容易被误读的地方。Fusion 的省钱效果不等于你的订阅费突然打七折。官方计费说明是：使用 Fusion 时，你按它实际调用的每个模型、按这些模型各自的标准费率计费。限时优惠是模型成本部分 30% 折扣。

换句话说，如果一次任务只走了 Single 到一个便宜模型，账单增量可能很小；如果任务触发了 Cascade 而且质量检查没过，多开了一个强模型，这次任务的成本就是两个模型的费用。GitHub 官方给出的一半 API 成本，是跨任务平均后的结果；单次请求的成本仍然取决于 Fusion 当时选中了谁、升级了谁。

AT&T 的工程师 Hari Pokhrel 在官方 changelog 的引述里提供了一个现实注脚：过去开发者常给复杂任务选强模型，之后忘记切回日常任务；Fusion Standard 通过自动选择正确模型，减少了不必要支出，并保留了高价值工作的容量。他还提到，他们观察到 Fusion 的决策随时间改进。这从一个侧面说明，Fusion 的价值有一部分在“消磨人肉切换成本”，而不是单纯在模型单价上做了魔法。

它适合什么，又不适合什么

从官方数据和工程逻辑看，Fusion 最受益的是那些日常任务里频繁手动切换模型、却容易忘记切回来的人。对这类用户，把选择压力交给系统，获得的是时间一致性和单位成本下降。对团队，管理员可以划定模型池，让成本更容易被约束。

但它也有明显代价。第一，可复现性：如果你需要每个请求固定用某个模型、固定温度、固定策略，Fusion 的路由黑盒会让结果更难追踪。第二，成本预估：因为内部可能一个任务触发多个模型，单次账单的波动比固定模型大。第三，客户端覆盖：官方说目前支持 VS Code、GitHub Copilot app、Copilot CLI 和 JetBrains IDEs，其他客户端还要等后续支持。

最后一条边界来自官方发布：Fusion 只使用企业或组织模型策略里启用的模型。如果你所在的企业把某些模型禁用，Fusion 不会绕过策略去调用它们。这是企业评估 Fusion 时应该先确认的管理前提。

参考来源

# AI # 知识

评论区

0 条评论

登录后可评论。