Project HydraFusion：通过多模型编排实现前沿质量

为开发者提供最适合当前任务的模型一直是我们的目标。今年早些时候，我们通过推出 Auto model selection 简化了这一过程，该功能会分析你的任务并将其匹配到最适合该任务的模型。今天，我们推出 Project HydraFusion，这是一个研究预览版，通过运行时编排（runtime orchestration）提供前沿智能。它会创建一个完整的执行计划，从多个提供商的模型中进行选择，以起草、批评和修订，或级联到更强大的模型来完成你的任务。HydraFusion 在我们实现本地、云端和复合模型之间自动化语义路由的整体战略中扮演着关键角色。对于开发者来说，这种复杂性隐藏在幕后：你像选择任何其他模型一样选择 HydraFusion，它会为每个任务选择一种平衡性能、成本和延迟的工作流。

现在作为研究预览版提供 HydraFusion 可通过 GitHub Copilot CLI 中的 /experimental 命令，供所有 GitHub Copilot 套餐的用户使用。使用量基于 HydraFusion 所用模型消耗的 token 数，按每个模型的标准费率计费。

要在 Copilot CLI 中试用 HydraFusion：

• 运行 /update 安装最新版本
• 运行 /experimental
• 运行 /model，然后选择 HydraFusion (Research Preview)
• 请在 GitHub Community 中提供反馈。

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

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

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

图 1. HydraFusion 架构

每种模式都对应不同的质量-成本权衡。Single 模式在单个模型可以直接解决问题时保持速度和效率。Cascade 模式让高效模型先行尝试，同时在候选模型未通过验收门时保留通往更强推理的路径。Critique 模式为那些审查比另一次独立尝试更有用的任务增加了独立视角。

在三个 agentic 编码 benchmark 的离线评估中，HydraFusion 持续展现出前沿级别的质量，并大幅节省了预估成本。在 TerminalBench 2.1 上，与 Claude Opus 5 相比，它在预估成本降低 67% 的情况下，将验证任务质量提升了 4.9 个百分点。

让我们深入了解方法、结果和 benchmark。

自适应多模型编排 开发者已经在手动协调模型：为任务选择一个模型，请另一个模型审查工作，或将难题升级给能力更强的模型。HydraFusion 将这个熟悉的过程带入了运行时。你只需选择一次 HydraFusion，然后专注于你的任务，而它在后台管理模型和工作流。

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

随着模型前沿的推进，HydraFusion 也随之发展。当 GitHub Copilot 中有新模型可用时，我们可以评估并将其纳入其模型池，将其优势应用于最适合它们的任务。

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

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

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

显示进度而不显示未完成的工作

• 今天：HydraFusion 显示工作流阶段，但在返回一个连贯结果之前会保留中间草稿。
• 原因：这些草稿可能会被审查、修订或丢弃，因此实时显示它们可能会让未完成的工作看起来像是最终结果。
• 我们正在学习：在缺乏足够可见性的情况下等待，对开发者来说是一个实际的权衡。
• 下一步：我们正在根据研究预览版的反馈，积极探索更好的进度更新方式。

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

Benchmarks	成本 vs. Opus 5	质量 vs. Opus 5
TerminalBench 2.1	降低 67%	+4.9 个百分点
DeepSWE	降低 36%	-1.5 个百分点
CheckpointBench	降低 65%	-0.1 个百分点

表 1. 相对于 Opus 5，HydraFusion 在三个 agentic benchmark 上的质量和成本。

这些受控的离线结果特定于所评估的 benchmark 修订版、工作流配置、模型池和定价假设，所有模型都在相同的中等推理水平下进行评估。通过这个研究预览版，我们将验证这些结果如何转化为真实的开发者工作负载，并利用这些发现进一步优化 HydraFusion 的生产质量、延迟、可靠性、缓存效率、成本和安全性。

TerminalBench 2.1 TerminalBench 2.1 在终端环境中评估编码 agent 处理复杂的多步骤任务的能力。图 2 比较了 HydraFusion 和 Opus 5 在验证任务质量和预估工作流成本方面的表现。

[图表代码块省略]

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

[图表代码块省略]

CheckpointBench [图表代码块省略]

CheckpointBench 是一个内部多轮 benchmark，从真实的 GitHub Copilot agentic 编码会话中精选而成。每个对话都锚定到一个特定的公共仓库和不可变的提交，确保每个会话都是可重放的。该 benchmark 在语言、任务类型、难度上保持平衡，并经过质量筛选，形成了一个高度贴近生产 agentic 会话的逼真评估集。在这个 benchmark 上，HydraFusion 与 Opus 5 的差距在 0.1 个百分点以内，同时成本降低了 65%。

[图表代码块省略]

早期的内部测试也印证了这一结果。“到目前为止，[HydraFusion 的]推理和任务解决能力已达到或优于 Opus。”——微软首席软件工程师

攀登 HydraFusion HydraFusion 的路由策略是根据开发者在真实编码任务中使用 GitHub Copilot 的方式塑造的。为了使这些工作流可复现，我们从真实的 Copilot 编码会话轨迹中整理了 CheckpointBench。我们在 CheckpointBench、DeepSWE 和 TerminalBench 2.1 上反复优化 HydraFusion，跨评估集进行优化，而不是针对任何单一 benchmark。

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

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

[图表代码块省略]

这个开发记录显示了策略如何通过反复实验得到改进。TerminalBench 2.1 是开发过程中使用的几个 benchmark 之一。其相对饱和使得更广泛的验证变得重要，因此三 benchmark 评估还包括了 DeepSWE 要求更高的仓库级任务。研究预览版将该学习循环扩展到真实的开发者工作负载。

尝试研究预览版 对于此预览版，首轮、单提示的编码任务是开始的最佳选择。接下来，我们将专注于在更长、迭代的会话中实现强大的多轮性能。此预览版旨在了解哪些任务受益于复合工作流，以及编排在实践中如何影响延迟和成本。

为了获得最佳体验，请从范围明确、定义清晰的实质性编码任务开始，这些任务可以在自动驾驶模式下通过单个提示交给 Copilot。通过 Copilot CLI 中的 /feedback 或在 GitHub Community 讨论中分享你的发现，包括它表现出色的地方、不足之处以及你希望接下来看到什么。

HydraFusion 仍然是一项活跃的研究工作。随着我们从预览版中学习，结果、模型、工作流、可用性、名称和产品行为可能会发生变化。我们相信，编码 agent 的下一个真正进步将来自将前沿智能与运行时编排相结合。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: Frontier quality via multi-model orchestration》最初出现在 The GitHub Blog 上。