Project HydraFusion: Frontier quality via multi-model orchestration

为开发者提供最适合当前任务的模型一直是我们的目标。今年早些时候，我们通过推出自动模型选择，让这一目标更容易实现。该功能会分析你的任务，并匹配最适合该任务的模型。

今天，我们推出 Project HydraFusion，这是一个通过运行时协同实现前沿智能的研究预览版本。它会创建完整的执行计划，从多个提供商的模型中选择模型进行草案编写、批评修订，或级联到更强大的模型以完成任务。

HydraFusion 在我们的整体战略中扮演关键角色，该战略旨在实现本地、云端和复合模型之间的自动语义路由。对开发者而言，这些复杂性将隐藏在后台：你只需像选择其他模型一样选择 HydraFusion，它会为每个任务选择一个在性能、成本和延迟之间取得平衡的工作流程。

HydraFusion 将工作流程选择视为一个优化问题。它使用推理、代码生成、调试和工具使用的能力建议，选择最有效的执行模式以满足质量标准。

目前，HydraFusion 为每个请求提供三种执行模式中的一种：

• 单模型。一个选定的模型直接解决任务。
• 级联。一个高效模型起草解决方案，质量门决定是否接受该方案或升级到更强的模型。
• 批评。一个模型起草结果，来自不同模型家族的独立只读批评者进行审查（遵循与Rubber Duck相同的审查模式），起草模型随后进行一次修订。

图1。HydraFusion架构

每种模式针对不同的质量与成本权衡。单模型在单一模型能直接解决问题时保持速度和效率。级联让高效模型率先尝试，同时在候选方案未通过接受门时保留升级到更强推理能力的路径。批评为需要审查比另一次独立尝试更有价值的任务增加独立视角。

在三个代理编码基准的离线评估中，HydraFusion 一致展现出前沿级别的质量，并带来显著的成本节约。在 TerminalBench 2.1 上，与 Claude Opus 5 相比，其验证任务质量提升了4.9个百分点，估计成本降低了67%。

让我们深入探讨方法、结果和基准测试。

自适应多模型协同

开发者目前需要手动协调模型：为任务选择一个模型，让另一个模型审查工作，或将困难问题升级到更强大的模型。HydraFusion 将这一熟悉的过程引入运行时。你只需选择一次 HydraFusion，即可专注于任务，而它会在后台管理模型和工作流程。

关键在于选择性。某些编码任务可以直接解决，而其他任务则需要通过审查、修订或升级来处理。HydraFusion会评估每个请求，并选择预期能满足其需求的最简单工作流程，仅在额外模型调用可能提升结果时才使用。这种自适应方法在模型之间平衡了质量、成本和延迟。

随着模型前沿技术的进步，HydraFusion也在持续进化。当GitHub Copilot上出现新模型时，我们可以评估并将其纳入模型池，使其优势应用于最适合的场景。

构建HydraFusion

将自适应多模型编排转化为可靠的编码体验，需要对执行、审查、成本和仓库状态进行精细控制。HydraFusion基于五个操作原则构建：

• 完整核算。汇总每个工作流程环节的成本和使用情况，包括起草、批评、修订、升级、重试和回退。
• 有界执行。为每个环节设置明确的超时和取消行为，确保执行和成本在定义范围内。
• 隔离审查。在隔离且无工具的环境中运行审查步骤，而求解步骤则使用共享工作区和正常权限感知代理循环。这使模型能够在不修改仓库的情况下独立评估工作。
• 安全应用。当工作流程被取消或验证失败时，不应用任何补丁，防止不完整的更改进入仓库。
• 验证路由。在执行开始前验证工作流程定义、模型绑定、回退行为和模型可用性。

这些原则共同使多模型编排在仓库级别工作成为可能。内部运行时会记录每个环节的角色、结果、成本、延迟和诊断信息，以便在执行后理解工作流程。外部开发者则会收到一个连贯的响应和一个权限感知的更改集。

基准测试结果

固定HydraFusion策略在三个代理编码基准测试中进行了评估——TerminalBench 2.1、DeepSWE以及基于真实GitHub Copilot会话的内部基准测试CheckpointBench，使用Claude Opus 5和GPT-5.6 Sol作为比较基线。每种策略使用相同的任务输入、工具、执行限制、定价假设、评分条件和缺失结果处理方式。评估测量了经过验证的任务质量（即确认正确回答的任务占比）和完整的预估工作流程成本。成本核算包括所有调用环节，如起草、批评、修订、升级、重试和回退。下表显示了经过最佳调整的HydraFusion配置结果。

| 基准测试 | 成本 vs Opus 5 | 质量 vs Opus 5 | | --- | --- | --- | | TerminalBench 2.1 | 67%更低 | +4.9分 | | DeepSWE | 36%更低 | -1.5分 | | CheckpointBench | 65%更低 | -0.1分 |

表1. HydraFusion在三个代理基准测试中相对于Opus 5的质量和成本表现。

这些受控离线结果特定于所评估的基准版本、工作流配置、模型池和定价假设，所有模型均在相同的中等推理级别进行评估。通过本研究预览，我们将验证这些结果如何映射到实际开发人员的工作负载，并利用这些发现进一步优化HydraFusion的生产质量、延迟、可靠性、缓存效率、成本和安全性。

TerminalBench 2.1

TerminalBench 2.1在终端环境中对编码代理进行复杂、多步骤任务的评估。

图2比较了HydraFusion和Opus 5在验证任务质量和预估工作流成本方面的表现。

TerminalBench 2.1 - GitHub Copilot CLI

DeepSWE

DeepSWE评估具有挑战性的仓库级软件工程任务，这些任务需要导航大型代码库、理解跨文件依赖关系并生成端到端修复。在此基准上，HydraFusion与Opus 5的差距仅为1.5个百分点，同时将成本降低了36%，展示了复杂现实工程任务中引人注目的质量-成本权衡。

DeepSWE - GitHub Copilot CLI

CheckpointBench

CheckpointBench包含的内容：真实开发人员的检查点

按编程语言、任务难度和开发人员工作类型分布

难度分布

简单

中等

困难

42.0%

38.8%

19.2%

编程语言

Python家族

33.3%

TypeScript

17.4%

C/C++

9.8%

JavaScript

7.6%

未知

7.6%

HTML/CSS

5.1%

C#

4.7%

Shell

4.7%

Go

2.5%

Java

1.4%

Rust

1.4%

任务类型

错误修复/调试

32.6%

功能实现

26.4%

代码解释/Q&A

15.9%

构建/配置/部署

8.0%

规划/文档

6.9%

未解决

4.7%

重构/维护

2.9%

测试/验证

1.1%

其他

1.1%

数据/机器学习/分析

0.4%

CheckpointBench是从真实的GitHub Copilot代理编码会话中整理的内部多轮基准测试。每个对话都锚定到特定的公共仓库和不可变提交，确保每次会话都可以重放。该基准在语言、任务类型和难度上保持平衡，并经过质量筛选，形成了一个与生产代理会话高度相似的真实评估集。在此基准上，HydraFusion在成本降低65%的情况下，与Opus 5的差距仅为0.1个百分点。

HydraFusion - Checkpoint Bench - GitHub Copilot CLI

早期内部测试结果印证了这一结论。

迄今为止，HydraFusion的推理和任务解决能力与Opus相当或更优。

微软首席软件工程师

Hill-climbing HydraFusion

HydraFusion的路由策略由开发人员在真实编码任务中使用GitHub Copilot的方式塑造。为了使这些工作流可复现，我们从真实的Copilot编码会话轨迹中整理了CheckpointBench。我们在CheckpointBench、DeepSWE和TerminalBench 2.1上反复优化HydraFusion，通过评估集进行优化而非针对单一基准。

HydraFusion的每项能力得分提供了比较候选路由策略的一致基础。我们没有手动调整阈值，而是使用束搜索构建最优决策策略。每个候选方案都与冻结的基准在质量、成本和失败模式上进行对比，因此改进是在稳定的基础上进行评估的。

TerminalBench 2.1 提供了最完整的运行序列，使其成为观察这种迭代改进最清晰的视角。进展并非线性。8 月 11 日至 8 月 25 日期间，评估框架发生了两次操作故障，导致运行结果无效。这些故障被排除在性能趋势之外，随后进行了修复，并在 HydraFusion 配置中继续取得进展。到 8 月 25 日，HydraFusion 在记录的系列中已达到最强的运行状态。

HydraFusion 从两次操作中断中恢复，并于 8 月 25 日继续攀升至 91.8% 的最佳 2 次运行等效值。

8 月 25 日完成 28 个测试点。HydraFusion 的填充方块在整个观察周期内使用相同的编码方式，稳健趋势包含最终结果。

HydraFusion 框架 - 无效运行与稳健趋势

该开发记录展示了策略如何通过重复实验得到改进。TerminalBench 2.1 是开发过程中使用的多个基准之一。由于其相对饱和度，更广泛的验证变得尤为重要，因此三基准评估还包括 DeepSWE 更具挑战性的仓库级任务。研究预览将这种学习循环扩展到真实的开发者工作负载中。

尝试研究预览

在本次预览中，建议从单次提示的首次交互编码任务开始。接下来我们将重点关注多轮交互中的强性能表现和更长的迭代会话。

本次预览旨在探索哪些任务能从复合工作流中获益，以及实际场景中编排对延迟和成本的影响。为了获得最佳体验，建议从具有明确范围的实质性编码任务开始，这些任务可以通过单次提示在 Copilot 自动驾驶模式下完成。请通过 Copilot CLI 的 /feedback 或 GitHub Community 讨论 分享您的发现，包括其表现优异之处、不足之处以及您希望看到的下一步改进。

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，Code AI 研究科学家 II

Andy Salerno, 首席软件工程师, GitHub Copilot

Written by

GitHub 是全球最佳的开发者体验平台，也是唯一将安全机制融入每个环节的 AI 驱动平台，让您能够自信地进行创新。