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

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

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

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

现已作为研究预览版提供

所有 GitHub Copilot 方案的用户均可通过 /experimental 在 GitHub Copilot CLI 中使用 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 团队，他们克服了重重挑战，将这一研究预览带给我们的客户。