GitHub 发布 Project HydraFusion 研究预览，用多模型运行时编排降低 Copilot 成本

为开发者提供最适合当前任务的模型，始终是我们的目标。今年早些时候，我们推出了 Auto 模型选择功能，让这一过程变得更加简单——它会分析你的任务，并将其匹配到最适合该任务的模型。

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

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

现以研究预览形式提供

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

要在 Copilot CLI 中试用 HydraFusion：

运行 /update 安装最新版本

运行 /experimental on

运行 /model，然后选择 HydraFusion（研究预览）

请在 GitHub Community 中发布反馈。

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

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

单一模式（Single）。一个选定的模型直接解决任务。

级联模式（Cascade）。一个高效的模型先起草解决方案，然后由质量门控决定是接受该方案，还是将其升级到更强的模型。

批判模式（Critique）。一个模型起草结果，来自不同模型家族的独立只读批判者对其进行审查（遵循与 Rubber Duck 相同的审查模式），然后起草模型再进行一次修订。

图 1. HydraFusion 架构

每种模式都对应不同的质量与成本权衡。单一模式在单个模型能直接解决任务时，保留了速度和效率。级联模式让高效模型先行尝试，同时在候选方案未通过接受门控时，保留通往更强推理的路径。批判模式则为那些审查比再次独立尝试更有用的任务，增加了独立视角。

在三个智能体编码基准的离线评估中，HydraFusion 始终展现出前沿级质量，同时带来可观的预估成本节省。在 TerminalBench 2.1 上，与 Claude Opus 5 相比，它在预估成本降低 67% 的情况下，将经核验的任务质量提升了 4.9 个百分点。

下面我们来深入探讨其方法、结果与基准。

自适应多模型编排

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

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

随着模型前沿不断推进，HydraFusion 也随之演进。当 GitHub Copilot 中有新模型可用时，我们可以对其进行评估并将其纳入其模型池，让它们的优势发挥在最适合的任务上。

构建 HydraFusion

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

完整核算。汇总每个工作流环节的总体成本与用量，包括起草、评审、修订、升级、重试和回退。

受限执行。为每个环节设定明确的超时和取消行为，使执行与成本保持在既定限制之内。

隔离审查。在隔离、无工具的上下文中运行审查步骤，而求解步骤则使用共享工作区和常规的权限感知智能体循环。这样模型可以独立评估工作成果，而不会修改仓库。

故障安全应用。当工作流被取消或未通过验证时，不应用任何补丁，防止不完整的更改进入仓库。

验证路由。在执行开始前，验证工作流定义、模型绑定、回退行为以及模型可用性。

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

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

目前：HydraFusion 会展示工作流各阶段，但在返回一个连贯的最终结果之前，会先保留中间草稿。

原因：这些草稿可能会被审阅、修改或丢弃，因此实时展示它们可能会让未完成的工作看起来像是最终结果。

我们的发现：在缺乏足够可见性的情况下等待，对开发者来说确实是一种取舍。

下一步：我们正在根据研究预览阶段的反馈，积极探索更好的进度更新方式。

基准测试结果

我们使用 Claude Opus 5 和 GPT-5.6 Sol 作为对比基线，在三个智能体编码基准——TerminalBench 2.1、DeepSWE 以及我们基于真实 GitHub Copilot 会话构建的内部基准 CheckpointBench——上评估了固定 HydraFusion 策略。每个策略都使用相同的任务输入、工具、执行限制、定价假设、评分条件以及对缺失结果的处理方式。评估衡量了经核实的任务质量（即被确认为正确回答的任务占比）以及完整的估算工作流成本。成本核算涵盖了所有被调用的环节，包括草稿生成、批判、修订、升级、重试和回退。以下结果展示了调优后的最佳 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 的按能力评分（per-capability scores）为比较候选路由策略提供了一致的基础。我们没有手动调优阈值，而是使用束搜索（beam search）来构建最优决策策略。每个候选方案都对照一个冻结的基线，在质量、成本和失败模式三个维度上进行衡量，因此改进效果是在稳定的基础上进行评估的。

TerminalBench 2.1 提供了最完整的运行序列，因此能够最清晰地呈现这一迭代改进过程。但进展并非线性。在 8 月 11 日至 8 月 25 日期间，评估框架中出现了两次操作故障，导致产生了无效运行。这些失败已被排除在性能趋势之外，经过修正后，HydraFusion 配置继续取得进展。到 8 月 25 日，HydraFusion 在记录序列中达到了其最强的运行点。

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

试用研究预览版

对于这个预览版，首轮、单提示词的编码任务是很好的起点。接下来，我们将重点放在更长的、迭代式的多轮对话中的强多轮性能表现上。

本次预览旨在了解哪些任务适合复合工作流，以及编排在实际中如何影响延迟和成本。为获得最佳体验，建议您从规模较大、边界清晰的编码任务入手，通过单条提示词以自动模式（autopilot mode）将任务交给 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 二级研究科学家

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