GitHub 发布 Project HydraFusion：用多模型编排在 Copilot 中实现前沿级质量

为开发者提供最适合当前任务的模型一直是我们的目标。今年早些时候，我们通过推出自动模型选择让这一切变得更简单，它会审视你的任务并为其匹配最合适的模型。

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

HydraFusion 在我们整体战略中扮演着关键角色，即在本地、云端和复合模型之间提供自动语义路由。对开发者而言，这种复杂性始终隐藏在幕后：你像选择任何其他模型一样选择 HydraFusion，它会为每个任务选择一种在性能、成本和延迟之间取得平衡的工作流。

现已作为研究预览版提供

所有 GitHub Copilot 计划的用户均可通过 GitHub Copilot CLI 中的 /experimental 使用 HydraFusion。使用量基于 HydraFusion 所用模型消耗的 token 计算，按每个模型的标准费率计价。

要在 Copilot CLI 中试用 HydraFusion：

运行 /update 以安装最新版本
运行 /experimental on
运行 /model，然后选择 HydraFusion (Research Preview)

请在 GitHub Community 中发布反馈。

HydraFusion 将工作流选择视为一个优化问题。它利用推理、代码生成、调试和工具使用方面的能力信号，选择最高效的执行模式来满足质量门槛。

对于每个请求，HydraFusion 目前会选择三种执行模式之一：

Single（单一）。 由一个选定的模型直接解决任务。
Cascade（级联）。 一个高效模型起草解决方案，质量门决定是接受它还是升级到更强大的模型。
Critique（批评）。 一个模型起草结果，来自不同模型系列的独立只读批评者对其进行审查（遵循与 Rubber Duck 相同的审查模式），起草模型修订一次。

每种模式针对不同的质量与成本权衡。Single 在一个模型能直接解决任务时保持速度和效率。Cascade 让高效模型先尝试，同时保留在候选结果未通过验收门时转向更强推理的路径。Critique 为那些审查比另一次无辅助尝试更有用的任务增加独立视角。

在三个智能体编码基准的离线评估中，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 分

表 1. HydraFusion 在三个智能体基准测试上的质量和成本，相对于 Opus 5。

这些受控的离线结果特定于所评估的基准测试版本、工作流配置、模型池和定价假设，所有模型均在相同的中等推理水平下进行评估。通过这一研究预览，我们将验证这些结果如何转化为真实的开发者工作负载，并利用这些发现进一步优化 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，Code AI 二级研究科学家

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

文章 Project HydraFusion：通过多模型编排实现前沿质量首次发表于 The GitHub Blog。