GitHub Copilot Fusion 正式可用：三种路由模式、三档努力与逐模型计费

GitHub 在 10 月 28 日宣布 Copilot Fusion 正式可用，本站把这项仍属近期的公告编入 11 月 1 日周末技术刊期。选择 Fusion 时，开发者选择的是模型路由与编排系统，而不是锁定某一个模型。它结合先前 Project HydraFusion 的多模型编排与自动模型选择，具体每项任务使用哪些模型由系统决定。正式可用的范围与兼容客户端需要逐项确认，不能把“自动选择”理解成任何客户端都已支持。

用户在模型选择器中选 Fusion，再选 Standard、High 或 Max 努力档位。Standard 面向日常编程，High 面向较难任务，Max 面向最复杂的任务。档位是可用能力和成本的选择，不是固定模型名单。管理员还可以控制 Fusion 能选的模型：它只使用企业或组织政策中启用的模型，管理员能分别设定某模型对 Fusion 的有效状态，也能阻止 Fusion 使用该模型而不把它对所有 Copilot 用户禁用。

GitHub 描述三种执行模式。Single 由一个模型直接完成任务；Cascade 先让较高效率的模型尝试，再由质量检查决定接受还是升级到更强模型重新作答；Critique 则由一个模型起草、另一个只读审阅，原模型再按意见修订。它们是路由系统可能采用的流程，并非每次请求都必定运行多个模型。因此不能把三种模式的成本相加，也不能仅凭一次界面显示推断后台走了哪条完整路径。

厂商给出的性能比较有明确口径。GitHub 称在 Artificial Analysis Coding Agent Index 上，Copilot Fusion Max 得分 60，与 Claude Code 搭配 Opus 5.5 Max 相差两分以内；在该测试中，平均每项任务的 API 成本约为对比方案的一半、使用 token 约一半、耗时约少 40%。这些是 GitHub 报告的特定基准与 Max 档位结果，既非本站实测，也不能外推到所有仓库、模型政策和档位。分母是每项任务的平均 API 成本与 token，而不是 Copilot 订阅费或每个请求的固定收费。

计费规则与基准估算也要分开。正式使用时，Fusion 调用了哪些模型，就按每个模型的标准费率计费。GitHub 同时宣布，付费 Copilot 计划的用户在有限期间可获 Fusion 模型费用的 30% 折扣；“有限期间”没有给出永久价格承诺。管理员应结合组织政策和实际账单评估预算，不能把一次基准的约半成本当作服务级费率保证。选择更高档位还可能改变实际模型组合。

GitHub 列出的当前客户端包括 VS Code、GitHub Copilot app、Copilot CLI 与 JetBrains IDE；其他客户端支持还在后续计划。此前参加预览并选过 auto、HydraFusion 或 HydraFusion Max 的用户会迁移到对应的 Fusion 档位。落地时先更新客户端，在模型选择器里确认 Fusion 和档位，随后核对企业模型政策、账单和输出质量。把这几个步骤分开，才能判断路由带来的收益是否发生在自己的任务中，而不是照搬厂商基准结论。

模型路由在企业环境中首先受政策约束。即使某个模式在理论上能调用多个模型，管理员禁用的模型也不应进入候选集合；项目还要区分代码、提示词与审查意见分别发送给哪些提供者。选择器里的努力档位表示系统如何分配推理与审查预算，不是对每个请求固定运行次数的声明。若团队想比较成本，应从实际账单和请求记录核对调用的模型，而不能仅凭模式名称推断费用。

三种模式适合的问题不同。Single 的路径最短，可能适合明确的小任务；Cascade 在初次回答不足时提升模型能力，关键是升级条件和误判成本；Critique 由另一模型检查后再让原模型修订，适合需要第二视角的任务，但审查模型的意见也可能出错。团队可在自己的仓库收集相同任务集，测任务完成率、人工修正时间、API 成本和响应时长，再决定默认档位。只测生成速度而不检查最终代码，会把质量差异藏起来。

公告给出的 60 分和约半成本属于特定基准。平均每任务成本的分母是该基准中的任务数，不能换算成每月订阅费用；约少 40% 耗时是与指定 Claude Code 加 Opus 5.5 Max 组合相比，不是对所有竞品或所有 Copilot 模式的优势。正式计费仍按实际调用模型的标准费率，有限期折扣也需在购买时核查有效期。本站没有运行这套基准，因而把它作为厂商说法呈现。