GitHub Copilot 推出多模型编排研究预览 Project HydraFusion
Project HydraFusion: Frontier quality via multi-model orchestration
GitHub 在 Copilot CLI 推出研究预览 Project HydraFusion，运行时按任务在单模型直接求解、高效模型起草后升级，以及跨模型家族独立评审再修订三种模式间编排多个提供商的模型。
它把换模型、独立评审和必要时升级交给运行时选择，读者可对照三项智能体编程基准看相对 Claude Opus 5 的质量与估算成本。
为开发者提供最适合当前任务的模型，一直是我们的目标。今年早些时候，我们通过推出 自动模型选择，让这一过程更加轻松：它会审视你的任务，并将其匹配到最适合该任务的模型。
今天，我们推出 Project HydraFusion，这是一项通过运行时编排提供前沿智能的研究预览。它会创建完整的执行计划，从多家提供商的模型中进行选择，用以起草、评审并修订，或级联到更强大的模型来完成你的任务。
HydraFusion 在我们实现本地、云端与复合模型之间自动化语义路由的整体战略中发挥着关键作用。对开发者而言，这种复杂性始终留在幕后：你像选择其他任何模型一样选择 HydraFusion，它会为每项任务选择兼顾性能、成本与延迟的工作流。
现已作为研究预览版提供
HydraFusion 现已通过 GitHub Copilot CLI 中的 /experimental 向所有 GitHub Copilot 计划的用户提供。用量基于 HydraFusion 所用模型消耗的 token，按各模型的 标准费率 计费。
要在 Copilot CLI 中试用 HydraFusion：
- 运行
/update以安装最新版本 - 运行
/experimental on - 运行
/model，然后选择HydraFusion (Research Preview)
请在 GitHub Community 中发布反馈。
HydraFusion 将工作流选择视为一个优化问题。它利用推理、代码生成、调试和工具使用方面的能力信号，选择最高效的执行模式以达到质量标准。
对于每个请求，HydraFusion 目前会选择以下三种执行模式之一：
- 单一。 由一个选定模型直接解决任务。
- 级联。 由一个高效模型起草解决方案，并由质量门控决定是接受该方案，还是升级到更强的模型。
- 评审。 一个模型起草结果，来自不同模型系列的独立只读评审者对其进行审查（遵循与 Rubber Duck 相同的评审模式），随后起草模型修订一次。
每种模式针对不同的质量与成本权衡。单一在一个模型即可直接解决任务时保持速度与效率。级联让高效模型先进行尝试，同时在候选结果未通过接受门控时保留转向更强推理的路径。评审则为审查比再次进行无辅助尝试更有用的任务增加独立视角。
在三项智能体编程基准的离线评估中，HydraFusion 持续展现出前沿级质量，并带来可观的预估成本节省。在 TerminalBench 2.1 上，与 Claude Opus 5 相比，它将已验证任务质量提高了 4.9 个百分点，预估成本降低 67%。
让我们深入了解这一方法、结果与基准测试。
自适应多模型编排
开发者已经在手动协调模型：为某项任务选择一个模型、请另一个模型审查工作，或将难题升级到能力更强的模型。HydraFusion 将这一熟悉的流程带入运行时。你只需选择一次 HydraFusion，并继续专注于自己的任务，而它会在幕后管理模型与工作流。
关键在于选择性。有些编程任务可以直接解决，而另一些则能从审查、修订或升级中受益。HydraFusion 会评估每个请求，并选择预期能满足其需求的复杂度最低的工作流，仅在额外的模型调用有望改善结果时才使用它们。这种自适应方法在各模型之间平衡质量、成本与延迟。
随着模型前沿不断推进，HydraFusion 也随之演进。当新模型在 GitHub Copilot 中可用时，我们可以对其加以评估并纳入其模型池，把它们的优势带到最适合它们的任务上。
构建 HydraFusion
要将自适应多模型编排转化为一种可靠的编程体验，需要审慎控制执行、审查、成本与仓库状态。HydraFusion 围绕五项运行原则构建：
- 完整核算。 汇总每个工作流环节的成本与用量，包括起草、评审、修订、升级、重试和回退。
- 有界执行。 为每个环节设定明确的超时与取消行为，使执行和成本保持在既定范围内。
- 隔离审查。 在隔离的、无工具的上下文中运行审查步骤，而求解步骤则使用共享工作区以及常规的权限感知代理循环。这使得模型能够独立评估工作，而无需修改仓库。
- 故障安全应用。 当工作流被取消或验证失败时不应用任何补丁，防止不完整的更改进入仓库。
- 已验证路由。 在执行开始前验证工作流定义、模型绑定、回退行为以及模型可用性。
这些原则共同使多模型编排能够切实用于仓库级工作。在内部，运行时会记录每个环节的角色、结果、成本、延迟和诊断信息，以便在执行后理解工作流。在外部，开发者会收到一份连贯的响应以及一组权限感知的变更集。
在不展示未完成工作的情况下显示进度
- 现状： HydraFusion 会显示工作流阶段，但会保留中间草稿，直到返回一个连贯的结果。
- 原因： 这些草稿可能会被审查、修订或丢弃，因此实时展示它们可能让未完成的工作看起来像是最终结果。
- 我们正在了解的： 在可见性不足的情况下等待，对开发者来说是一种真实的权衡。
- 下一步： 我们正在积极探索更好的进度更新，并以研究预览版的反馈为指导。
基准测试结果
固定的 HydraFusion 策略在三项智能体编程基准上进行了评估——TerminalBench 2.1、DeepSWE 以及 CheckpointBench（我们基于真实 GitHub Copilot 会话的内部基准）——并以 Claude Opus 5 和 GPT-5.6 Sol 作为对比基线。每项策略使用相同的任务输入、工具、执行限制、定价假设、评分条件以及对缺失结果的处理方式。评估衡量了已验证的任务质量（即被确认为正确作答的任务占比）以及完整的估计工作流成本。成本核算包括每一个被调用的环节，例如起草、评审、修订、升级、重试和回退。以下结果展示了调优效果最佳的 HydraFusion 配置。
| 基准测试 | 成本 对比 Opus 5 | 质量 对比 Opus 5 |
|---|---|---|
| TerminalBench 2.1 | 67% 更低 | +4.9 分 |
| DeepSWE | 36% 更低 | -1.5 分 |
| CheckpointBench | 65% 更低 | -0.1 分 |
这些受控的离线结果仅针对所评估的基准版本、工作流配置、模型池和定价假设，且所有模型均在相同的中等推理级别下进行评估。通过此次研究预览，我们将验证这些结果如何转化到真实的开发者工作负载中，并利用这些发现进一步优化 HydraFusion 的生产质量、延迟、可靠性、缓存效率、成本与安全性。
TerminalBench 2.1
TerminalBench 2.1 评估编程智能体在终端环境中完成复杂、多步骤任务的能力。
图 2 从已验证任务质量与预估工作流成本两方面比较 HydraFusion 与 Opus 5。
DeepSWE
DeepSWE 评估具有挑战性的仓库级软件工程任务，这些任务需要浏览大型代码库、理解跨文件依赖并产出端到端修复。在该基准上，HydraFusion 与 Opus 5 的差距在 1.5 个百分点以内，同时将成本降低 36%，为复杂的真实世界工程任务展现出极具吸引力的质量—成本权衡。
CheckpointBench
CheckpointBench 是一项内部多轮基准，整理自真实的 GitHub Copilot 智能体编程会话。每段对话都锚定到特定的公开仓库和不可变提交，确保每个会话均可重放。该基准在语言、任务类型和难度上保持均衡，并经过质量筛查，从而形成一套密切反映生产环境智能体会话的真实评估集。在该基准上，HydraFusion 与 Opus 5 的差距在 0.1 个百分点以内，成本降低 65%。
早期内部测试也印证了这一结果。
到目前为止，[HydraFusion 的]推理与任务求解能力达到或优于 Opus。
Principal Software Engineer at Microsoft
爬山优化 HydraFusion
HydraFusion 的路由策略是根据开发者在真实编码任务中使用 GitHub Copilot 的方式形成的。为使这些工作流可复现，我们从真实的 Copilot 编码会话轨迹中整理出 CheckpointBench。我们在 CheckpointBench、DeepSWE 和 TerminalBench 2.1 上反复优化 HydraFusion，在各评估集上进行优化，而不是针对任何单一基准。
HydraFusion 的按能力划分的得分提供了比较候选路由策略的一致依据。我们没有手动调整阈值，而是使用束搜索来构建最优决策策略。每个候选方案都在质量、成本和失败模式上对照冻结基线进行衡量，因此各项改进是在稳定基础上评估的。
TerminalBench 2.1 提供了最完整的运行序列，因而最清晰地呈现了这一迭代改进。进展并非线性。在 8 月 11 日至 8 月 25 日期间，评估框架中的两次运行故障产生了无效运行。这些失败被排除在性能趋势之外并得到修正，随后 HydraFusion 配置继续取得提升。到 8 月 25 日，HydraFusion 已达到所记录序列中的最强工作点。
这份开发记录展示了策略如何在反复实验中得到改进。TerminalBench 2.1 是开发期间使用的若干基准之一。它的相对饱和使得更广泛的验证变得重要，因此这项三基准评估还包括 DeepSWE 要求更高的仓库级任务。该研究预览将这一学习循环扩展到真实的开发者工作负载。
试用研究预览
对于此次预览，首轮、单提示的编码任务是最佳起点。接下来，我们将聚焦于在更长的迭代式会话中实现强劲的多轮表现。
此预览旨在了解哪些任务能从复合工作流中受益，以及编排在实践中如何影响延迟和成本。为获得目前的最佳体验，请从实质性、范围明确的编码任务开始，你可以在单条提示中将其交给处于 autopilot 模式的 Copilot。请通过 Copilot CLI 中的 /feedback，或在 GitHub 社区讨论中分享你的发现，包括它的出色之处、不足之处，以及你接下来希望看到的内容。
HydraFusion 仍是一项活跃的研究工作。结果、模型、工作流、可用性、名称和产品行为可能会随着我们从该预览中学习而改变。我们相信，编码智能体的下一次真正提升将来自将前沿智能与运行时编排相结合。HydraFusion 是我们在这一理念上的首次押注：从选择最佳模型，转向动态构建解决每项任务的最佳方式。
致谢
衷心感谢 GitHub 和 Microsoft 的研究人员、工程师、产品经理和设计师，他们整理了训练数据，并构建了训练流水线、评估套件、客户端体验和服务栈。我们特别感谢 GitHub Copilot CLI、Copilot API 和 VS Code 团队克服了诸多挑战，将这一研究预览带给我们的客户。
认识团队
Aashna Garg，首席应用科学家，Code AI
Shengyu Fu，合伙人应用科学经理，Code AI
Carlos Castro，合伙人架构师，GitHub Copilot
Siddharth Singha Roy，研究科学家 II，Code AI
Andy Salerno，首席软件工程师，GitHub Copilot
来源：GitHub Blog · AI & ML · github.blog