导语：GitHub 在旧金山 GitHub Universe 上发布 GitHub Copilot Fusion，将模型选择与编排合并为一个可委托的系统。GitHub 称，Fusion Max 在基准测试中与 Claude Code 搭配 Opus 5.5 Max 表现相当，但平均 API 成本约为后者一半，每个任务耗时约减少 40%。这背后反映出一个更值得关注的趋势：模型路由正在从“可选优化”变成编码智能体的默认能力。

一、Copilot Fusion 是什么：把“选模型”这件事收进系统

依据现有素材，GitHub Copilot Fusion 的定位是一个面向编码任务的模型选择与编排系统。它把 Project HydraFusion 的高级运行时模型编排能力，与 Copilot Auto Model Selection 结合起来，现在可以同时处理“选哪个模型”和“多个模型如何协作”两件事。

对开发者的直接变化是：面对推理、代码生成、调试或工具使用类任务时，不必再自己判断该用哪个模型。GitHub 给出的使用说明是：“选择 Copilot Fusion，让 Copilot 智能地为你路由和编排所使用的模型。”

GitHub 表示，Copilot Fusion 现已正式可用，并被纳入其“让 GitHub 成为全球最全面的软件交付系统”的新愿景之中。同一场大会上还发布了 GitHub Copilot 应用、Copilot Projects 和 Copilot Automations 等产品。

配图建议：GitHub Universe 发布会现场或 Copilot Fusion 产品界面截图，由编辑上传真实素材。

二、三种编排形态：单模型、级联与评审

Copilot Fusion 的价值不只在“选一个模型”，而在于按任务需求编排后续步骤。素材中给出了几种典型形态：

• 单模型完成：分析任务需求并选定模型后，由一个模型完成全部工作。
• 级联工作流：由质量检查评估某个模型的响应，再决定接受还是升级到更强的模型。
• 评审工作流：由一个模型审查另一个模型的产出。

此外，开发者可以在工作流中途策略性切换模型，让系统根据每一步的适配度在模型之间跳转。这一点针对的是一个真实存在的使用惯性：开发者常为复杂任务手动选更强模型，却在日常任务中忘了切回来。AT&T 首席软件工程师 Hari Pokhrel 在给 GitHub 的声明中就描述了这种情形——“以前，开发者常常为复杂任务选择更强大的模型，却忘了在日常活动中切换回来。”

三、开发者保留的控制权：努力级别与企业策略

把模型选择交出去，不等于失去控制。素材显示，Copilot Fusion 的分层方式是“努力级别”：

也就是说，系统决定“用哪些模型、怎么配合”，开发者决定“这次要投入多少算力与推理深度”。

企业侧的控制同样被保留。据 GitHub 说明，企业管理员可以：

• 控制 Copilot Fusion 可从中选择哪些模型；
• 为 Copilot Fusion 禁用某些模型，而不必对整个开发者团队禁用；
• 独立调整每个模型的政策状态；
• 设置 Copilot Fusion 是否作为 Copilot 用户的默认模型。

这套设计回应了企业落地时的常见顾虑：模型准入、成本边界与默认行为需要由管理员统一约束，而不是完全交给个体开发者。

四、性能与成本：GitHub 给出的数字

GitHub 提供的关键数据如下，均来自其官方口径，尚待第三方独立验证：

• 在 Artificial Analysis Coding Agent Index 上，Copilot Fusion Max 得分为 60，与 Claude Code with Opus 5.5 Max 相差不到两分；
• Fusion Max 实现该结果的平均 API 成本约为后者的 一半；
• 使用的 token 数量约为 一半；
• 每个任务耗时 减少约 40%。

GitHub 还表示，自 2026 年 9 月以研究预览版形式推出 Project HydraFusion 以来，系统性能已有提升。AT&T 的 Pokhrel 则在声明中称，Copilot Fusion Standard 提升了其 token 效率，减少了不必要的支出，并为更高价值的工作保留容量。

需要说明的是，上述对比基于 GitHub 自行披露的基准与成本口径，依据现有素材无法判断测试环境、任务分布与计费假设的具体细节。

五、趋势判断：模型路由正在成为默认做法

Copilot Fusion 并非孤立事件。素材中提到两条同类动向：

• 本月，Ramp 描述了将模型选择移入其开源编码智能体 Open SWE 的做法；
• 今年夏天，Replit 将其“智能模型路由”系统设为所有账户的默认设置。

三条线索指向同一个方向：模型路由正从“高级用户的调优手段”变成“产品默认的基础设施”。原因并不复杂——不同任务在能力与成本上的最优解不同，而让开发者逐个任务手动权衡，既增加心智负担，也容易在注意力分散时做出次优选择。

由此带来的角色变化值得技术团队提前准备：开发者的职责重心从“挑模型”转向“定目标、审结果、设边界”。前者是操作，后者是判断。相应地，企业平台团队需要建立的能力也会变化——模型准入策略、成本可观测性、默认路由配置，将逐渐成为与代码规范同等重要的工程治理项。

结论

GitHub Copilot Fusion 的核心主张可以概括为一句话：把模型选择与编排交给系统，把方向与结果留给开发者。它以努力级别作为人机分工的接口，以企业策略作为落地边界，并用“成本约一半、耗时减少约 40%、基准分差不到两分”的口径来支撑其性价比叙事。

这些数字仍需独立验证，但趋势判断相对清晰：当 Ramp、Replit 与 GitHub 先后把模型路由设为默认，编码智能体的竞争焦点就从“接入哪个最强模型”，转向“如何以更低成本、更稳定的方式编排多个模型”。对开发者而言，真正需要重新学习的，可能不是某个模型的使用技巧，而是如何在委托与掌控之间划出合适的那条线。

生成标记：本文由 ITPUB 文章生成平台基于已选素材整理生成。