GitHub Copilot Fusion 正式推出后模型选择方式有哪些变化

如果你以前要在每个任务开始前手动挑模型，GitHub Copilot Fusion 的变化可以概括为：你选择的是“路由与编排系统”，而不是某一个固定模型。它会按当前任务决定使用哪个模型、采用哪种执行模式，并用 effort level 表达你对质量、成本和延迟的偏好。

官方地址：https://docs.github.com/en/copilot/concepts/models/copilot-fusion

Fusion 适合把“选哪个模型”交给系统，但不等于所有任务都自动使用最强模型，也不等于它会替你启动 subagent。团队仍要关注实际调用、额度消耗和工作区变更。

一、从手动挑模型转向运行时编排

过去的基线很简单：开发者先在模型选择器里选一个模型，再让它完成整段任务。Fusion 把选择动作前移为运行时决策：同一会话里的不同 prompt 可以走不同模式，系统还会结合任务的推理、代码生成、调试和工具使用信号来选路。

这次公告中的性能数字需要带着出处阅读。GitHub 引述 Artificial Analysis Coding Agent Index 称，Copilot Fusion Max 得分为 60，距离 Claude Code with Opus 5.5 Max 不超过 2 分，同时平均 API 成本约低一半、token 约少一半、每个任务耗时约少 40%。这属于 GitHub 公布的对比结果，不是对所有团队代码库的性能保证；自己的任务集仍应单独测量成功率、返工次数、耗时和额度。

二、看懂 Single、Cascade 与 Critique

Single 是最接近传统调用的路径：一个模型直接完成任务，适合边界清楚、无需额外复核的日常工作。Cascade 先让效率更高的模型起草，再由 judge 判断是否接受；如果质量不够，才升级到更强模型重新处理。它的核心是把昂贵调用留给真正需要的任务。

Critique 则让模型先产出草稿，再由一个或多个只读评审者给出意见，最后回到原模型修订。这个模式更适合复杂改动或需要多角度检查的任务，但代价是额外调用和延迟。Fusion 只展示最终响应，中间草稿可能被修改或丢弃，因此不能把最终答案误解为某一个模型单独完成。

三、按任务选择 effort level 和策略边界

我的建议是先按任务分层，而不是一上来固定使用 Max。Standard 用于日常编码和短问题，优先平衡成本、质量与延迟；High 适合跨多个文件的复杂修复或需要更深推理的工作；Max 留给最难的设计、调试和分析任务。Fusion Fast 是 VS Code inline chat 的内部场景，不是用户可自由选择的档位。

管理员还可以控制 Fusion 能从哪些模型中选择。即使某个模型在产品文档中存在，只要不在套餐内、被企业策略禁用，或受到数据驻留与合规策略限制，它就不会进入你的可用池。计费也不是“一次 Fusion 一个固定价格”，而是按实际调用的每个模型按标准费率计算；High 和 Max 可能因为多模型协作消耗更多 AI credits。GitHub 文档显示，付费计划的 30% 模型成本折扣目前是限时政策，使用前应以账号页面为准。

四、给开发团队的一份试用清单

第一步，把任务分成日常修补、跨文件改动和高风险设计三档，分别记录 Standard、High、Max 的完成率、返工次数、响应时间和额度消耗。第二步，在响应详情里查看实际使用过的模型，避免把“Fusion”当成可审计的固定模型名。第三步，给高风险仓库保留人工 review：官方文档明确提醒，被丢弃的草稿如果已经修改了工作区，不会自动撤销。

如果团队想试本地模型，也要把它看作受限预览能力：当前文档说明本地模型只可能从 Fusion Standard 被选择，且需要对应客户端和实验性开关。最后，不要把 Fusion 当作 subagent 调度器；它独立于 subagents，不会自动启动它们。这样落地，Fusion 才是减少模型选择摩擦的工程工具，而不是新的黑盒依赖。

相关问题

Copilot Fusion 每次都会使用多个模型吗？

不会。系统会在任务需要时才增加评审或升级调用，简单任务可以走 Single；具体模型池和模式选择会随任务、策略和产品更新变化。

Fusion 能代替固定模型和 subagent 吗？

它解决的是运行时路由与编排，不保证固定模型的可重复性，也不会自动启动 subagent。需要严格复现或明确代理边界时，仍应使用团队自己的固定模型和代理配置。