不用再挑模型了：GitHub Copilot Fusion 正式可用，选模型的活交给系统

2026 年 10 月 28 日，GitHub 在 Universe 大会上宣布 Copilot Fusion 正式可用。这不是又一个新模型，而是一个选模型的系统：你在模型选择器里不再挑某个具体模型，而是选 Copilot Fusion，再选一档投入程度，剩下的事——这个任务用哪个模型、要不要换一个更强的、要不要让第二个模型来挑毛病——由它在任务进行中决定。

这个变化值得认真看，因为它标志着 AI 编程工具的竞争重心正在转移。过去一年，各家比的是模型本身：谁的上下文更长、谁的基准分更高、谁的价格更低。现在 GitHub 换了一个打法：模型可以有很多个，关键是谁来替你选，以及选错的代价由谁承担。Fusion 就是 GitHub 对这个问题的回答。

先说清楚 Fusion 是什么

按 GitHub 官方 changelog 的说法，Fusion 把两样东西合在了一起：一是此前以 HydraFusion 为名做研究预览的多模型编排，二是 Copilot 自动选模型功能里打磨过的模型选择。合起来之后，它在每个提示词层面做决策：分析任务需要什么样的推理、代码生成、调试和工具使用能力，再决定用一个模型还是组合多个模型。

使用方式很简单：在模型选择器里选 Copilot Fusion，然后选一档投入程度。Standard 优先用通用模型，适合日常编码；High 优先用能力更强的模型，适合有挑战性、需要更深推理的任务；Max 优先用最强的模型，适合要求最高、最复杂的任务。你选的是“愿意为这个任务花多少力气”，而不是“用哪家哪款模型”。

此前参加过研究预览的用户会被自动迁移：原来选了 auto、HydraFusion 或 HydraFusion Max 的，会对应过渡到 Fusion 的各档。JetBrains 版本的 changelog 还补了一句：Fusion 会逐步取代现在的 Auto 选项，面向全部 Copilot 用户 rollout。

三种执行方式：单模型、级联、互评

Fusion 在任务内部有三种工作模式。Single 是最直接的：一个模型从头做到尾。Cascade 是先让一个效率较高的模型起草，再由质量检查判断接受还是升级到更强模型重做。Critique 是让一个模型先出初稿，另一个模型审读并提出修改意见，原模型再修订。

这个三分法比“自动选模型”这个说法本身更重要。它承认了一个现实：不同任务的失败方式不一样。有的任务是模型能力不够，需要更强的模型；有的任务是初稿里藏着小错，需要第二双眼睛；有的任务根本不需要折腾，一个模型直接做完最省钱。把“选模型”从用户手里拿走，交给一个能在任务中途换档的系统，省掉的是用户在强弱模型之间反复横跳的心智负担。

GitHub 引用了 AT&T 一线工程师的说法来佐证这一点：以前开发者常常为复杂任务选了强模型，做完日常任务却忘了切回来，白白多花钱；Fusion 消除了这种摩擦，决策质量还在随时间变好。这句话听起来像客户证言，但它点出了 Fusion 真正的卖点：它卖的不是更高的分数，而是更少的浪费。

官方给出的数字：怎么读才不被带偏

GitHub 在 changelog 里给了一组基准数字：在 Artificial Analysis 的 Coding Agent Index 上，Fusion Max 得 60 分，比用 Opus 5.5 Max 的 Claude Code 低 2 分，但平均每个任务的 API 成本大约只有一半，token 用量大约只有一半，耗时大约少 40%。在另一项 DeepSWE 评测里，Fusion High 和 Max 的任务完成率比同类前沿模型高出最多 8.7 个百分点，预估成本最多降低 77%。

读这组数字要分三层。第一层，分数本身：低 2 分但便宜一半，这笔账对大多数团队是划算的，前提是你的任务分布和基准任务分布差不多。第二层，成本口径：GitHub 说 Fusion 按实际使用的每个模型、以各自标准价计费，付费计划用户在限时内享受模型费用 7 折——也就是说，基准里的“便宜一半”已经包含了编排带来的节省，7 折是额外的限时优惠，到期后账单会变。第三层，也是最容易被忽略的一层：这些都是厂商选定的基准，不是你仓库里的任务。真正决定 Fusion 值不值的，是你自己的任务：跑一周，对比同一批任务在固定模型和 Fusion 下的通过率、返工率和账单，再下结论。

管理员的控制权：企业用户最该看的一段

changelog 里专门留了一段给管理员，而且这段可能比基准数字更重要。Fusion 只使用企业和组织模型策略里启用的模型；企业管理员可以看到 Fusion 会从哪些模型里选，可以单独设置每个模型对 Fusion 的有效策略状态，可以在不给所有人禁用的前提下、只对 Fusion 禁用某个模型。管理员还可以通过企业托管设置，把某个档位的 Fusion 设为用户的默认模型。

这意味着 Fusion 不是一个“黑盒选模型”。在企业场景里，模型选择从来不只是技术问题：哪些模型被允许接触代码、哪些模型的数据处理条款合规、哪些模型的成本中心归属哪里，都是要落到策略上的。GitHub 把 Fusion 的选模型范围绑在已有的模型策略上，等于告诉企业客户：你们现有的管控不用推倒重来，Fusion 在你们画好的圈里选。

对个人开发者，这个设计的影响是间接的：你能用到的 Fusion 档位和模型范围，取决于你所在组织的策略。如果你发现 Fusion 的效果不如预期，先别急着怪系统，查一下组织策略里是不是只给它留了很少的模型可选。

它改变了什么，又没改变什么

Fusion 改变的是“选模型”这个动作的归属。以前，开发者要在模型下拉框里做一道选择题，而且这道题的正确答案随任务而变；现在，开发者只做一道判断题：这个任务值得花多少力气。省下来的注意力可以回到任务本身：需求说清楚没有、验收标准定下来没有、改动能不能回滚。

但它没有改变的，是更底层的东西。第一，评审仍然是你的：Fusion 交出来的代码，不管经过几个模型之手，合并之前都要过你这一关。第二，成本仍然是你的：按模型标准价计费意味着账单随用量波动，7 折优惠结束后的价格才是长期价格。第三，调试的责任仍然是你的：当 Fusion 的某个任务结果不好时，你需要判断是任务描述不清、档位选低了，还是模型组合本身的问题——而 changelog 并没有承诺给你看每一步的选模型记录。

所以最务实的上手方式是：先在非关键任务上用 Standard 跑一周，记录三组数字——任务一次通过率、需要人工返工的比例、每周账单；再在复杂重构类任务上试 High 和 Max，对比同样的三组数字。如果 Standard 在你的任务上已经够用，就不要为了“Max”这个名字多花钱；如果 High 的返工率明显低于 Standard，那多花的模型费用可能反而是省的。

为什么这件事放在 Universe 讲

Fusion 是在 GitHub Universe 2026 上发布的，同场还有 Copilot app、跨仓库的 Copilot Projects 等一系列智能体交付产品。放在这个背景里看，Fusion 的定位就更清楚了：GitHub 想把自己从“代码托管 + 聊天助手”变成“智能体交付系统”，而 Fusion 是这个系统里的成本与质量调节器——没有它，智能体规模越大，模型账单和选型混乱就越失控。

对 vibe coding 的个人开发者来说，这件事还有一层更直接的意义：你以后可能越来越少直接“选模型”，越来越多地“选投入程度”。这对新手是友好的——不用先搞懂十几个模型的名字就能开工；但对有经验的开发者，它也意味着一种控制权的让渡：你把选模型的判断交给了平台，换取的是更低的决策成本。划算不划算，取决于平台的判断在你的任务上准不准。而这一点，只有你自己的任务记录能回答。

一句话总结：Fusion 不是来告诉你哪个模型最强的，它是来替你承担“选错模型”这个成本的。值不值，看你自己的账本。

上手前先问自己的三个问题

决定要不要开 Fusion 之前，有三个问题值得先想清楚，答案因团队而异，没有标准答案。

第一，账单怎么对。Fusion 按实际使用的每个模型、以各自标准价计费，这意味着一张任务的账单可能由好几个模型分摊。如果你现在的成本归集是按“模型”记账的，Fusion 会让这本账变复杂：一个任务的成本不再属于某一个模型，而属于一次编排。动手之前，先确定你们是按任务、按项目还是按人归集成本，再决定要不要开；否则月底对账时，省下来的钱和多出来的解释成本可能正好抵消。

第二，效果怎么归因。Fusion 的好处只有在对比中才能显现：同一批任务，一半走固定模型、一半走 Fusion，比一次通过率、返工率和账单。如果没有这组对比数据，所谓“感觉变快了”或“感觉变贵了”都只是感觉。建议把对比期定为两周，任务类型尽量覆盖日常编码和复杂重构两种，不要只拿最简单的任务去验证一个为复杂任务设计的系统。

第三，什么时候不该用 Fusion。三种情况建议先别开：一是合规要求写明“必须使用指定模型”的场景，编排带来的不确定性本身就是风险；二是需要严格复现的场景——同一提示词在不同时间可能走不同模型组合，结果的可复现性天然弱于固定模型；三是任务高度单一的场景，比如整条流水线只做一类格式转换，固定一个便宜模型就是最优解，编排省不下什么，反而多一层变量。这三种情况不是 Fusion 的缺点，而是任何“自动选择”类系统的适用边界。

三档怎么选：不是越强越好，是越贴合越好

Standard、High、Max 三档的说明书只有一句话之差，但选错的代价是真实的。Standard 优先用通用模型，适合日常编码：修一个小 bug、补一段样板代码、给函数写注释、把一段逻辑改个名字。这类任务的特点是成功标准清晰、失败容易发现，用强模型属于大材小用——不是不能做，而是账单上多花的钱换不来可感知的质量提升。很多团队的模型开支就是这样被“默认选最强”一点点吃掉的，AT&T 工程师提到的“选了强模型忘了切回来”正是这个机制。

High 适合需要多想一步的任务：跨文件的重构、带边界条件的算法实现、涉及多个模块的接口改动。这类任务的失败方式往往不是“写不出来”，而是“写出来但漏了一种情况”；更强的模型在这里的价值不是速度，而是少返工一次。判断该不该上 High 的标准可以定得很具体：如果一个任务你预计自己 review 时要重点检查边界情况，那就值得上 High；如果 review 时只需要扫一眼格式和命名，Standard 就够了。

Max 留给最难啃的任务：复杂推理链条长、约束条件多、改错了代价大的工作，比如核心链路的重构、并发与一致性相关的改动、牵一发而动全身的架构调整。Max 的正确用法是“少而精”：一周里真正值得上 Max 的任务可能只有一两个；如果一个团队所有人每天都在用 Max，那不是任务都难，而是档位选择已经失灵了——要么是大家不知道 Standard 够用，要么是绩效与流程在变相鼓励“用最贵的”。

还有一个容易被忽略的选档维度：任务的“可验证性”。测试覆盖好、验收标准明确的任务，适合交给 Fusion 自由发挥，因为结果好不好一测便知；验收标准模糊、主要靠人眼判断品味的任务（比如界面文案、命名风格），档位高低带来的差异本身就难以衡量，这时更应该把精力放在把需求写清楚，而不是把档位调高。档位解决的是能力问题，不是需求不清的问题。

三种执行方式：分别在什么时候划算

Single 最适合目标单一、步骤短的任务：一个模型从头做到尾，没有交接成本，也没有第二个模型引入新偏差的机会。它的风险是单点失败——模型一旦在某个环节想偏了，没有纠错机制。所以 Single 的适用前提是任务本身容错率高：错了能立刻发现、改了成本低。

Cascade 适合“先便宜试试，不行再升级”的任务。效率模型先起草，质量检查决定接受还是升级到更强模型重做。这个模式的精髓在质量检查那一关：检查标准定得太松，等于没检查；定得太严，几乎每次都升级，Cascade 就退化成“先浪费一次便宜模型再上强模型”。用 Cascade 的团队应当定期看一个数字：升级率。升级率长期接近零，说明检查太松或任务太简单；长期接近百分之百，说明起草模型选弱了，不如直接上 High。

Critique 适合“错误代价高、但错误可被同行发现”的任务：一个模型起草、另一个模型审读、原模型修订。这种模式的价值不在于第二个模型更强，而在于视角不同——审读者的任务不是重做，而是挑毛病。但它也有代价：多一轮模型调用就多一份延迟和成本，而且审读意见本身也可能出错（把对的改错）。所以 Critique 不适合抢时间的热修复场景，更适合有 review 预算的常规开发任务。

三句话总结这三种模式的取舍：Single 省在交接成本为零，Cascade 省在“好钢用在刀刃上”，Critique 贵在“多一双眼睛”。Fusion 的意义，就是让这道取舍题不必由用户在每次提示词之前都重做一遍——但用户仍然应当知道系统在替自己做什么取舍，否则出了问题连从哪里查起都不知道。

与已发 Copilot 模型退役篇的划界：策略层与执行层

本站 cycle118 刚发过一篇 GitHub Copilot 资讯，讲的是 2026 年 10 月 19 日的两件事：六个模型退役，以及模型策略 REST API 同日 GA。读者可能会问：Fusion 这篇是不是同一件事换个说法？不是。两篇的分工是一条线：上一篇讲的是“规则怎么定”，这一篇讲的是“规则定了之后，系统怎么在规则里选”。

具体说，10 月 19 日的模型策略 API 给了管理员制定规则的工具：哪些模型可用、哪些组织或团队能用、默认策略是什么。Fusion 则是消费这些规则的执行层：changelog 明确写着，Fusion 只使用企业和组织模型策略里启用的模型，管理员可以单独设置每个模型对 Fusion 的有效状态。换句话说，策略 API 决定了 Fusion 的“可选范围”，Fusion 在这个范围内做任务级的选择。没有策略层，Fusion 的选择就没有边界；没有 Fusion，策略层管住的只是一个静态的模型列表，而不是一次次任务中的实际用量。

这个划界对读者还有一个实际意义：如果你所在组织的模型策略还没有更新（比如退役模型的替代品还没在策略里启用），Fusion 的表现会先受策略拖累，而不是系统本身的问题。排查顺序应当是先查策略、再看档位、最后才怀疑编排本身。本篇刻意不重复上一篇的退役全表与端点清单，需要那张表的读者请看 cycle118 的模型退役篇；本篇只讲 Fusion 这一层的新东西。

成本读法的第二层：折扣、归集与复核节奏

前面已经提醒过，付费计划用户的 7 折是限时优惠——按 JetBrains 篇 changelog 的说法是首 30 天。这里再补一层：折扣期的真正作用不是省钱，而是给你一个低成本的试用窗口。正确的用法是在这 30 天里跑完前面说的对比实验（固定模型 vs Fusion，两周、两类任务、三组数字），而不是把折扣当成长期价格去做预算。预算应当按折扣结束后的标准价做，折扣期内省下的钱是实验补贴，不是利润。

归集方式也要提前定。Fusion 的账单是按实际使用的每个模型拆分的，一个任务的成本可能横跨两三个模型的价格档。如果团队现在的成本报表是按“人”或按“项目”归集的，要确认报表工具能不能把一次 Fusion 任务的拆分账单合并回任务归属；如果不能，月底就会出现“钱花了但不知道花在哪个任务上”的窟窿。这不是 Fusion 独有的问题，任何多模型编排都会带来同样的归集复杂度，但它是在开通之前就应当确认的事，而不是月底对账时才发现的事。

复核节奏建议定为每月一次：看三个数——Fusion 任务占比、各档位占比、单位任务成本。Fusion 占比持续走高但单位任务成本没降，说明编排没有带来预期的节省，要回头看是档位选高了还是任务本身不适合编排；Max 占比持续走高，要问是任务真的变难了，还是大家把 Max 当成了默认。数字本身不会给结论，但没有数字，连问题都问不出来。

待验证清单：这篇没有替你验证的事

有几件事值得诚实地列为“待验证”，而不是在文章里含糊带过。第一，基准数字是厂商选定的：Artificial Analysis Coding Agent Index 和 DeepSWE 都是公开基准，但“选哪两个基准来公布”是 GitHub 的决定，你自己的任务分布与之不同，结果就可能不同——前文建议的自跑对比不是客套话，是唯一的校准办法。第二，选模型过程的透明度：changelog 没有承诺向用户展示每一步选了哪个模型、为什么选，排查“为什么这次结果差”时，你能拿到的信息可能比固定模型时代更少；这对需要审计的团队是一个真实的取舍。第三， rollout 节奏：JetBrains 篇的说法是“逐步面向全部用户推出”，这意味着不同客户端、不同时间点看到的 Fusion 可能不完全一致，遇到“别人有我没有”时先确认客户端版本与 rollout 状态，不要直接断定是账号问题。第四，7 折的适用范围以官方计费说明为准：changelog 说的是付费计划用户限时 7 折，具体到你的计划档位是否在内，以账单为准，不要按传闻做预算。