GitHub Copilot Fusion 怎么用？模型协作、档位与积分详解

本文于 2026 年 10 月 29 日根据 GitHub 当时的在线文档和公告核验，评估依据是官方文档，并非实测基准。

GitHub Copilot Fusion 改变了什么？

**GitHub Copilot Fusion 会代你选择模型，并在有必要时协调多个模型。**可以把它理解为技术负责人：判断一次改动只需快速实现，还是需要审查，或应交给能力更强的配置处理。任务仍由你定义，最终代码是否合格也由你决定。

GitHub 于 2026 年 10 月 28 日正式推出 Fusion，将 Project HydraFusion 的多模型编排与 Auto 模型选择合并。原有的 Auto、HydraFusion 和 HydraFusion Max 选项会迁移到对应的 Fusion 档位。因此，10 月的研究预览是 Fusion 的前身，无需将它当成另一款产品搭配使用。GitHub 的 Fusion 发布公告。

执行模式决定了任务如何分工：

• **Single（单模型）：**由一个模型直接完成任务。
• **Cascade（级联）：**初稿交给评判模型，由它决定接受结果，还是升级处理。
• **Critique（评审）：**初稿先接受独立评审，再由原模型根据意见修改。

这些模式来自 GitHub 的 HydraFusion 研究。当前 Fusion 文档描述了多个评审模型并行工作、再汇总反馈的机制，但这不代表每条提示都会跑遍所有模式。Fusion 的工作机制。

例如，修改一个标签和排查竞态条件，不应一律采用相同的处理方式。Fusion 会在会话内部做出这种分配。模型路由详解介绍了背后的思路：为任务匹配合适的模型能力，再检验这种选择是否有效。

哪些客户端支持 Fusion，如何开启？

**Fusion 可用于 Copilot 应用、Visual Studio Code、Copilot CLI 和 JetBrains IDE。**GitHub 列出了这些客户端，以及 Fusion 在不同 Copilot 套餐中的可用情况。但这不代表每个账号都能使用相同档位：可用模型仍受套餐和策略限制。当前可用范围。

操作前请先更新客户端。HydraFusion 预览阶段的旧开关已不适用于当前 Fusion 的设置流程。

GitHub Copilot 应用

点击提示输入框下方的模型名称，打开 Copilot Fusion，再选择可用档位。如需切回指定模型，关闭开关后选择该模型即可。应用会记住你的选择，并用于后续会话。应用中的模型选择。

Visual Studio Code

在设置中确认已启用 chat.copilot.dynamicAutoTiers.enabled。使用 Copilot harness 新建聊天；harness 是连接模型与智能体工具的运行时。然后在模型选择器中选择 Copilot Fusion，再选一个可用档位。打开设置不会自动授予使用权限：如果账号没有符合条件的 Fusion 档位，选择器仍可能显示 Auto。VS Code 设置说明。

GitHub Copilot CLI

在交互式会话中输入 /model，选择 Fusion 及其档位，然后确认。首次试用可以先限定任务范围。GitHub 文档给出了以下命令结构，这个示例只要求分析，不修改文件：

copilot --model fusion --fusion-tier standard -p "Explain how this repository runs its tests. Do not edit files."

这是当前的 Fusion 选项，不再使用旧的 HydraFusion 实验性标志。CLI 模型选择。

Fusion 会调用哪些模型？

**已公布的 Claude/GPT 模型池只是特定时间的快照，并非永久不变的路由承诺。**GitHub 在 2026 年 10 月 14 日的 HydraFusion 更新中明确列出了：

• Anthropic 的 Claude Opus 5.5。
• OpenAI 的 GPT-6 Astra。
• OpenAI 的 GPT-6.1 Sol。
• OpenAI 的 GPT-6 Luna。

那次更新还推出了 HydraFusion Max，并提高了初稿生成和审查阶段的推理投入。以上是该预览公告中已核验的模型名称。10 月模型池更新。

当前 Fusion 概览没有公布一份固定、完整的云端模型清单。文档说明模型池会变化；将鼠标悬停在回复下方的档位标签上，可以查看实际使用的模型。Copilot 的完整模型目录，不等于 Fusion 承诺会调用其中的每个模型。当前模型池的工作方式。

对工程负责人而言，真正需要关注的是自己账号允许使用的模型池。企业所有者可以打开 AI controls → Copilot → Models → Configure Copilot Fusion models 进行配置。这些选择仍受用户其他模型策略的约束。企业模型管控。

此外，还有独立的本地模型路由预览。它支持在特定配置下，通过 Standard 使用 MAI Code 1.1 Flash 或 Qwen3.8 Flash Next。任意添加一个本地模型，并不意味着 Fusion 就能调用它；本地推理也不意味着 Fusion 可以离线运行，因为路由仍在云端完成。本地模型的适用边界。

先用 Standard，什么情况下再提高档位？

**从 Standard 开始；先明确额外审查要解决什么，再选择 High 或 Max。**GitHub 将 Standard 定位于日常编程，High 用于更有挑战的任务和更深入的推理，Max 则面向要求最高的工作。档位定义。

下表中的任务选择是编辑建议，并非实测性能结论：

“改进整个应用”这类模糊需求不适合拿来试用 Max。如果没有定义成功标准，就无法判断额外推理是否有帮助。应将任务收窄为可观察的问题，例如在保持重试行为不变的前提下，移除重复的请求路径。

**Fusion Max 是推理投入档位，并非必须购买的订阅名称。**另有 Fusion Fast，但用户无法主动选择，而且它仅用于 VS Code 行内聊天。可用档位。

Fusion 的 AI 积分怎么扣？

**费用取决于所选模型实际完成的工作。**输入、输出和缓存 token 按模型定价，适用时还会计入缓存写入费用，最后换算为 AI 积分。目前没有公布每项 Fusion 任务固定消耗多少积分。GitHub 的计费机制。

Fusion 不单独收取编排费。目前，Copilot 付费套餐可享受 Fusion 模型费用减免 30% 的优惠，有效期至 2026 年 11 月 30 日。参见 Fusion 计费说明。各套餐的档次与额度见 GitHub Copilot 价格指南。

生成初稿、评审和修改都会产生用量。推理投入、上下文大小、工具调用和缓存也会影响消耗。因此，即便路由完全按设计运行，多轮处理仍可能比单模型请求消耗更多积分。VS Code 对 AI 积分消耗的说明。

试用时，也要把失败尝试和纠正提示算进去。一份生成成本低、却需要反复修补的初稿，最终可能不如一次成本较高但能交付合格改动的运行划算。反过来，给简单的重命名额外付费做评审，也未必有实际价值。应比较完成整项工作的代价，而非单条回复的最低价格。

GitHub 的基准成绩能说明什么？

**GitHub 公布的结果有吸引力，但不能据此推算你的仓库能省多少。**在 Universe 公告中，GitHub 表示：

该评测名为 Artificial Analysis Coding Agent Index。这是 GitHub 自行公布的基准结果，并非本文进行的独立测试。GitHub Universe 公告。

详细更新日志说明，对比对象是搭配 Opus 5.5 Max 的 Claude Code，成本指标则是每项任务的平均 API 费用。这一说法有明确的适用范围，不能等同于“Fusion 能让 Copilot 账单减半”。GitHub 的基准对比背景。

合理的推论是：相比始终选择高规格配置，编排有可能以更高效率取得出色结果。但“每次修复缺陷都会更快或更便宜”就超出了证据范围。能否在你的工作中复现收益，取决于任务构成、验收标准和返工量。限时计费优惠与基准对比也是两回事，不能将两者叠加成确定的省钱承诺。

开发者、工程负责人和采购方分别该关注什么？

**开发者可以减少选模型的负担。**如果你经常中断工作，纠结下一个任务该交给哪个模型，就值得做一次范围明确的 Fusion 试用。问题描述、预期行为和审查标准仍要写清楚。把模型选择交出去，应当减少干扰，而不是让任务变得含糊。

**工程负责人需要制定档位规则，并记录验收结果。**可以先约定：日常工作用 Standard，需要审查且范围明确的改动用 High，Max 则经过明确判断后再使用。记录提高档位为什么有效。否则，“选最高档”很容易变成习惯，却没有证据表明它改善了最终交付。

**比较 Copilot、Claude Code 和 Cursor 的采购方，应测试团队真正会采用的工作流。**基准成绩可以成为评估某个选项的理由，却不足以支持整个组织迁移。除了积分，还应评估审查负担、与代码仓库的适配程度以及最终完成的工作。Claude Code 与 GitHub Copilot 对比涵盖了更完整的选型问题；Fusion 只改变了其中一部分。

哪些期待被夸大了，什么情况下应关闭 Fusion？

**参与的模型再多，你仍要对代码差异负责。**GitHub 文档指出了一个尤其需要重视的限制：被弃用的草稿仍可能留下文件改动。此外，Fusion 没有属于自己的合并上下文窗口，也不会启动子智能体。Fusion 的限制。

如果你需要指定模型来进行受控对比、可复现的排查，或执行明确获批的工作流，就应关闭 Fusion。固定模型选择，避免让路由再增加一个变量。这不会让语言模型变得确定，只是减少了一个变化来源。

如果你熟悉的指定模型配置已经能完成范围明确的任务，且很少需要纠正，那么在试用证明有实际收益之前，可以继续照常使用，无需为了切换而切换。

如果工作流必须离线运行，或者你还无法定义并审查什么是合格的改动，也应暂缓使用。对于细小的日常请求，更合适的做法可能是保留 Standard，不使用涉及较多编排的高投入档位。“不用 Max”和“不用 Fusion”是两个不同的决定。

GitHub Copilot Fusion 使用教程：本周先试一个仓库

**把试用范围控制在每项结果都能逐一检查的程度。**选择一个熟悉的代码仓库，将 Fusion 与你现有的模型配置进行比较。

本周就可以行动：为这个仓库安排一名开发者和一名审查者，先约定验收检查，再根据实际改动决定默认配置。一份清晰的决策记录，比一张“最快回复”的截图更有用。

订阅通讯，获取 AI 开发工具选型与使用的实用指南。