Copilot Fusion 全面可用：不用再选模型，改选努力程度

选择器里不再有模型名

GitHub 宣布 Copilot Fusion 全面可用。变化看起来小，实际改了交互契约：用户在模型选择器里挑的不再是某个具体模型，而是一套会为每个任务自动路由、编排模型的系统。

它的技术来源有两块。一块是 Project HydraFusion 的多模型编排，另一块是 Copilot 原有的自动选模微调策略，两者合并成一个对外的产品形态。产品分两档：Fusion Standard 面向日常编码，倾向通用模型；Fusion High 面向高难任务，会调用更强的模型并允许更长的推理。管理员可以为团队设定模型可用范围与计费控制。

为什么要把选择权收走：因为大多数开发者根本没在选。真实场景里，改一个变量名的补全和重构一个跨模块的状态机是两类任务，前者用旗舰模型是浪费，后者用轻量模型是自找麻烦。让用户为每个请求手动切模型，结果是所有人都懒得切，然后统一按最贵的那个付费。

60 分这个数字该怎么读

GitHub 给的硬指标是：在 Artificial Analysis Coding Agent Index 上，Copilot Fusion Max 得分 60，与使用 Opus 5.5 Max 的 Claude Code 相差两分以内；但平均每任务 API 成本约为后者一半，token 消耗约一半，耗时少约 40%。

四项指标要分开看。分数差两分以内，意味着能力上基本同档；成本减半，是路由把简单任务分给了便宜模型；token 减半，说明编排层在压缩无效上下文，比如不再把整个文件塞进每一轮；耗时少 40%，是前三项叠加的结果。

这里有个容易踩的坑：成本减半和 token 减半是平均值，不是每个任务都减半。如果你的工作负载集中在高难任务上，路由会把大部分请求送到 High 档，实际成本可能接近甚至超过手动选旗舰模型。反过来，如果你的任务八成是常规改动，收益会非常明显。所以迁移之前先做一件事：把历史会话按任务类型分个类，算一遍分布，再决定要不要切。

选模型这件事正在被选努力程度取代。这句话对个人是便利，对团队是预算纪律——你不再需要一个懂模型的架构师来把关，你需要一条清晰的策略。

迁移时的四个动作

第一，先把评测口径统一。别用感觉快了来判断，用你自己仓库里的真实任务集跑一遍，记录每个任务的通过率、耗时、token 消耗。GitHub 的 60 分是公开基准，你的代码库不是公开基准。

第二，把档位策略写进团队规范。哪些仓库、哪些任务类型默认 Standard，哪些必须 High，什么情况下允许人工强制指定。Fusion 的好处是免去逐个选型，代价是你要接受有时候它会替你选错——所以必须有覆盖机制。

第三，盯住月结单而不是日账单。路由系统的成本曲线是非线性的，某一天高难任务集中，费用会突然跳。按周看趋势，按团队拆维度，比看总额有用。

第四，注意可观测性缺口。自动路由意味着你不一定知道每个请求最终落在哪个模型上。如果这个信息在日志里拿不到，出问题时你没法归因。上线前确认能拿到路由决策记录，这条比省钱重要。

最后说一句定位。Fusion 解决的是选型疲劳，不是能力上限。它不会让弱模型变强，只是让强模型少被浪费在简单任务上。真正的能力突破还是得等模型本身，工具层能做的优化，天花板就在成本结构里。