Evergreen 工具站
|
← 返回AI工具

GitHub Copilot Fusion：不再选模型，改选「这一题交给谁做」

GitHub 在 2026 年 10 月 28 日的 Universe 大会上把 Copilot Fusion 正式开放：它是一个运行时的模型路由与编排系统，你只选努力档位（Standard / High / Max），它替你决定每一段任务用哪个模型、或者哪几个模型分工。官方说它脱胎于 Project HydraFusion 的约 6 万次路由会话和 Copilot 自动选模型的线上经验，并且只在你企业和组织策略允许的模型池里挑

官方入口

GitHub Changelog · Docs · Artificial Analysis

功能特点

  • ✓ 把一次编码任务拆成步骤，逐步骤决定模型与执行模式：可以一个模型起草、另一个模型复核，也可以不同步骤用不同模型
  • ✓ 使用前不需要在模型选择器里点名：选 Copilot Fusion 就等于选了一套运行时路由系统，再自己定努力档位
  • ✓ 遵守企业模型策略：管理员能看到 Fusion 会从哪些模型里挑，能单独把某个模型对 Fusion 关掉，而不影响其他人继续用这个模型
  • ✓ 运行过程中能看到每一步的进度和当前使用的模型；中间草稿可能被改写或丢弃，最终只呈现结果
  • ✓ 官方给出的背景数据：2026 年 9 月付费 Copilot 开发者一共用过 47 个不同模型，没有任何一个模型承担超过四分之一的请求

使用步骤

  1. 先确认你的 Copilot 版本和计划支持 Fusion，并检查企业或组织层面的模型策略里，哪些模型是允许被 Fusion 调用的
  2. 在模型选择器里选 GitHub Copilot Fusion，然后按任务难度选努力档位：日常改动用 Standard，复杂重构或跨文件调试往上升
  3. 在 Copilot CLI 或 IDE 里跑一个你熟悉的老任务做对照，把结果和成本、耗时跟以前手工指定模型的做法比一比
  4. 如果是团队场景，让管理员先看 Fusion 的模型池构成，再决定哪些模型对 Fusion 开放、哪些只留给手工指定

常见问题

Copilot Fusion 到底解决什么问题？

按照 GitHub 官方 changelog 的说法，过去你要为每个任务挑一个模型，现在选 Fusion 就行，由 Copilot 在运行时智能路由和编排模型，在性能与成本之间做平衡。官方还给了动机数据：2026 年 9 月付费 Copilot 开发者用了 47 个不同模型，没有一个模型处理超过四分之一请求——也就是说「哪个模型最好」这件事已经没有统一答案了。文档见 https://docs.github.com/copilot/concepts/models/copilot-fusion ，更新日志见 https://github.blog/changelog/2026-10-28-route-and-orchestrate-models-with-github-copilot-fusion

它和之前的自动选模型（Auto）有什么区别？

官方口径是：Fusion 把 Project HydraFusion 的多模型编排能力和 Copilot 自动选模型里那套微调过的选择逻辑合到一起。Auto 是挑一个最优模型，HydraFusion 是挑一条最优工作流、可能用多个模型。Fusion 就是两者合体后的正式产品，已经 GA。GitHub 也提到这两套体验未来有可能会并成一条路径，所以写团队规范时最好把两种都覆盖到

效果和成本有公开数据吗？

Artificial Analysis 在 2026 年 10 月 28 日的评测里用 Coding Agent Index v2.0 测了 Fusion 的 Max 档：分数比 Claude Code 里的 Opus 5.5 低约 2 分，但每个任务成本大约只有一半、耗时少约 40%；Terminal-Bench 4.0 上 Fusion 拿到 71 分居首，FrontierCode 51 分排第三，SWE-Atlas-QnA-AA 57 分。注意这是第三方评测机构的公开结果，具体见 https://artificialanalysis.ai/articles/github-copilot-fusion-orchestrates-anthropic-and-openai-models-to-balance-performance-and-cost 。GitHub 自己在 Universe 上也引用了这类结论，但你自己任务上的表现仍然要实测

企业环境里怎么管控？

官方文档写明 Fusion 只会使用你企业和组织模型策略里已启用的模型。管理员可以看到 Fusion 的候选模型池，可以独立设置每个模型对 Fusion 的有效状态，也能单独把某个模型从 Fusion 里禁掉，而不必对所有人关掉这个模型。换句话说，治理入口还是原来那套模型策略，不需要额外造一套权限体系

适合什么团队先用？

如果你的团队已经在多个模型之间来回切、或者经常为「这活儿该给谁」争论，Fusion 的价值最直接：把选择权收进系统，人只管方向和努力档位。如果你们只需要一个稳定模型跑固定流水线、对可预测性要求极高，那手工指定模型反而更透明，可以先小范围试点 Fusion，用同一批任务做 A/B 再决定铺开