GitHub Copilot Fusion:60 分、Token 减半与三档编排

一句话结论:GitHub 把多模型编排从研究预览推成正式产品 Copilot Fusion,Artificial Analysis 编码智能体指数得分 60,比 Opus 5.5 Max 驱动的 Claude Code 低 2 分,单任务平均 API 成本约为一半,Token 消耗减半,耗时少约四成。

10 月 28 日的 Universe 2026 大会上,GitHub 宣布 Copilot Fusion 正式可用。它把两件事合到了一起:Project HydraFusion 的多模型编排能力,以及 Copilot 自动模型选择(auto model selection)的细粒度调优。开发者不再需要在模型下拉框里手动挑模型,选中 Copilot Fusion,再选一个努力等级,剩下的交给系统。

这个产品形态的意义不在分数,而在决策权的转移。Copilot 过去的多模型策略是手动切换,选错档位就是账单上的浪费。Fusion 把选择权收进系统内部,代价模型从「你选了什么」变成「它替你选了什么」。

60 分背后的成本账

GitHub 官方给出的数字来自 Artificial Analysis 的 Coding Agent Index。Copilot Fusion Max 拿到 60 分,比使用 Opus 5.5 Max 的 Claude Code 低 2 分。关键的差异不在那 2 分:它达成这个分数时,单任务平均 API 成本约为 Claude Code 的一半,Token 消耗约为一半,每任务耗时少约 40%。

这个换算关系可以直接落到企业预算上。假设一个团队原本把全部编码任务都交给最高配档位,Fusion 意味着同样效果下账单接近腰斩,同时等待时间下降四成。对按 seat 计费的企业,收益体现在配额可用性上;对按量计费的团队,收益体现在成本曲线上。

AT&T 的反馈印证了这条逻辑。AT&T Billing 首席软件工程师 Hari Pokhrel 的说法是,Copilot Fusion Standard 通过自动选择合适模型提升了 AT&T 的 Token 效率,减少了不必要开销,同时把配额留给更高价值的活计。此前开发者经常为复杂任务选一个更强的模型,完成后忘了切回去处理日常活计,Fusion 消除了这类摩擦,而且它的决策随使用时间持续改善。

三档努力等级与三种编排工作流

在模型选择器里选中 Copilot Fusion 之后,用户唯一要做的决定是努力等级。Fusion Standard 面向日常编码,优先选择通用的多面手模型;Fusion High 面向有挑战的任务与更深推理,优先使用能力更强的模型;Fusion Max 面向最苛刻的任务和复杂推理,启用最强模型。

模型如何协作,由三种工作流决定。

  • Single:单个模型直接完成任务,不做额外往返。
  • Cascade:高效模型先起草,一次质量检查决定是接受草稿还是升级到更强的模型。
  • Critique:一个模型起草初始答案,另一个模型审阅,原模型据此修订。

Cascade 与 Critique 的差别在于升级时机。Cascade 是一次性质量门禁,通过就收工;Critique 是带审阅环节的多方协作,理论上更贵也更慢,但是否触发由系统按任务复杂度判断,用户看不到编排过程。

管理员能控制什么

Fusion 的模型池继承企业既有的模型策略。管理员可以查看 Copilot Fusion 实际选用了哪些模型,可以单独设置每个模型的策略状态,也可以只对 Fusion 禁用某个模型而不影响该模型对全公司的可用性。

更深一层的控制是用 Enterprise managed settings 把 Copilot Fusion 在任意努力等级上设为 Copilot 用户的默认模型。这条路径意味着组织可以把编排策略作为默认配置推下去,开发者不需要在个人设置里做任何事。

这一点对已经在做多模型路由的团队有参考价值。路由逻辑从各家产品的配置项下沉成了平台默认,智能体层也在做同样的事。两边的方向一致:把模型选择从使用者的日常决策里拿走。

计费方式与 30% 折扣

使用 Copilot Fusion 时,你按它实际调用的每个模型、每个模型的标准费率计费。这个设计保留了多模型并行的成本可见性,同时在有限时间内给付费 Copilot 计划的用户提供模型成本 30% 的折扣。

30% 是一个值得记住的对照点。它意味着短期实际成本大约是原生模型的七折左右,考虑到 Fusion 本身已经把 Token 用量压到约一半,两项叠加后的实际支出接近原生的三分之一到四成区间。这个区间是估算,具体比例取决于任务构成和所选努力等级。

支持范围与本地模型

Copilot Fusion 在所有 Copilot 计划上可用,覆盖 Visual Studio Code、GitHub Copilot app、GitHub Copilot CLI 与 JetBrains IDE,其他客户端支持在后续推出。原先在研究预览阶段启用 auto、HydraFusion 或 HydraFusion Max 的用户,选项会自动迁移到对应的 Copilot Fusion 努力等级,无需手动调整。

同一天,GitHub 还单独发布了 Copilot Fusion 支持选择本地模型的更新,包含 Windows 上的托管下载安装与自带本地模型两条路径。编排层开始把本地模型也纳入路由范围,这一步的意义在于把「哪些任务值得走云端、哪些必须留在本地」的判断也交给系统,企业侧则通过模型策略去约束 Fusion 能选到什么。

编排层下沉之后,工具链变成什么样

同一场大会还发布了几项配套更新。GitHub 团队开发的 Copilot harness 已经赋能 Copilot Studio、VS Code 等多款产品,并通过 Microsoft Foundry 向开发者开放。Copilot app 的 Projects 进入公开预览,可以把跨仓库的规格、设计稿、Slack 讨论与会议笔记收进同一个上下文,Copilot 在后台协调工作,只在需要人介入时回来。Computer use 在 macOS 与 Windows 上进入公开预览,Copilot 可以读取应用内容、点击控件、输入文本并跨应用导航,包括没有 API、命令行接口或 MCP 集成的应用,操作前会请求批准,组织侧可通过托管设置禁用。

把这些放在一起看,形态已经清楚了:模型由编排层挑选,harness 由 GitHub 统一提供,跨应用操作交给 computer use,跨仓库上下文由 Projects 承载。开发者面对的界面越来越简单,底层的复杂度越来越集中。

Copilot Fusion 与其他编码智能体的关键差异

维度 Copilot Fusion Claude Code 配 Opus 5.5 Max 手动切换单模型
Coding Agent Index 得分 60 62 随所选模型变动
模型选择方式 系统按任务复杂度自动编排 由用户在 CLI 内指定 用户在模型选择器内手动指定
单任务平均 API 成本 约为对照组一半 对照组基准 取决于所选模型
Token 消耗 约为对照组一半 对照组基准 取决于所选模型
单任务耗时 比对照组少约 40% 对照组基准 取决于所选模型
协作模式 Single / Cascade / Critique 三种 单模型为主 单模型
管理员控制粒度 模型池策略、单模型禁用、设为默认 由用户自行决定 由用户自行决定
本地模型 支持纳入路由 需自行配置 需自行配置

小结:编排正在变成基础设施

这一版更新里,60 分只是最不重要的部分。差 2 分可以靠换更强模型补上,成本减半和 Token 减半则改变的是团队用同一份预算能跑多少任务。

更值得留意的是同一天发布的多项更新指向同一个方向:Copilot harness 跨产品赋能,Projects 收拢跨仓库上下文,computer use 打通桌面应用,本地模型进入路由池。编排从各家产品的配置项变成基础设施,模型选择这个决策正在从开发者手里移走。

对企业采购者来说,这带来一个新的评估维度。以前比的是单个模型的能力分,现在要比的是平台在保留九成以上能力的前提下能把成本压到什么位置。对独立开发者来说,简单任务不再被高配模型吃掉预算,这一条更实际。

常见问题

Copilot Fusion 和直接用 Claude Code 怎么选

看两件事。一是任务构成,如果任务高度集中在需要最强推理的复杂编码上,直接用 Opus 5.5 Max 驱动 Claude Code 能多拿 2 分,差距不致命。二是成本纪律,Fusion 在 Token 和耗时上各省一半,在 token 预算或并发受限的场景里这个优势更实际。混合使用也是合理选择,把 Fusion 设为默认,个别硬骨头手动切到指定模型。

Copilot Fusion 支持哪些模型,管理员能限制到什么程度

Fusion 只使用企业与组织模型策略中已启用的模型。管理员可以查看 Fusion 实际选用了哪些模型,单独设置每个模型的策略状态,可以只对 Fusion 禁用某个模型而不影响该模型对全公司的可用性,还可以通过 Enterprise managed settings 在任意努力等级上把 Fusion 设为默认模型。

使用 Copilot Fusion 到底怎么计费

按它调用的每个模型的标准费率计费,编排过程不额外收费。同时付费 Copilot 计划用户在有限时间内可获得模型成本 30% 的折扣。需要注意,多模型协作会调用多个模型,因此实际账单取决于任务触发了哪种工作流,单模型直接完成的任务费用最低。

相关阅读