GitHub 推出 Project HydraFusion：多模型编排实现前沿级编码质量

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

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

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

现已作为研究预览版提供

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

要在 Copilot CLI 中试用 HydraFusion：

1. 运行 /update 以安装最新版本
2. 运行 /experimental on
3. 运行 /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 配置。 

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

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

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