GitHub 于 2026 年 9 月 4 日宣布推出 Project HydraFusion。这是 GitHub Copilot 内的一项研究预览项目，用于在执行编程任务时协调来自多个供应商的人工智能模型。HydraFusion 不会预先选择单一模型，而是创建执行计划，并确定任务需要直接解决、独立审查，还是升级给能力更强的模型。
此举是在 GitHub 于今年早些时候推出 Auto model selection 功能之后采取的。该功能用于为每项任务选择最合适的模型。但 HydraFusion 将这一理念从模型选择扩展为构建完整工作流，在结果质量、成本和响应时间之间进行权衡；对于选择 HydraFusion 的开发者而言，运营复杂性仍然被隐藏起来，就像在 Copilot 中选择任何其他模型一样。
执行任务的三种路径
系统会评估与推理、代码生成、调试和工具使用相关的信号，然后选择三种执行模式之一：
- Single：当单个模型的能力足够时，由该模型直接处理任务。
- Cascade：由效率更高的模型开始拟定解决方案，然后由质量门决定是否采纳该方案，或将任务转交给更强大的模型。
- Critique：一个模型拟定初步解决方案，随后由来自不同系列、处于只读上下文中的独立模型进行审查，之后第一个模型对解决方案执行一次修订。
GitHub 表示，采用选择性策略的目标，是仅在预计能够改善结果时才使用额外调用。这样，直接路径可以保持速度和效率，而另外两条路径则为能够从中受益的任务增加审查或升级环节。
测试结果
GitHub 在三个编程代理测试中评估了 HydraFusion 的固定策略：TerminalBench 2.1、DeepSWE，以及基于 GitHub Copilot 真实会话构建的内部 CheckpointBench。测试结果与两个基准进行了比较，即 Claude Opus 5 和 GPT-5.6 Sol，并使用了相同的输入、工具、执行限制、定价假设和评估条件。
在 TerminalBench 2.1 中，HydraFusion 在经验证的任务质量方面提高了 4.9 个百分点，同时与 Claude Opus 5 相比，将估算的工作流成本降低了 67%。在 DeepSWE 中，该测试侧重于仓库级软件工程任务以及理解文件之间的依赖关系，系统与 Opus 5 的差距接近至 1.5 个百分点，而成本降低了 36%。至于 CheckpointBench，质量差距仅为 0.1 个百分点，同时成本降低了 65%。
成本核算涵盖执行的所有阶段，包括拟定、审查、修改、升级、重试和回退计划。不过，GitHub 将这些结果描述为离线测试，并指出结果受所使用的测试版本、工作流设置、模型集合和价格假设限制。
运行控制与预览限制
GitHub 围绕多项控制措施设计了 HydraFusion，包括记录每个阶段的成本和使用情况、设定取消和执行超时，以及将审查步骤隔离在既没有工具权限、也不会修改仓库的上下文中。系统还会预先验证工作流定义、模型绑定、备用方案行为和模型可用性；如果操作被取消或验证过程失败，则不会应用任何修正。
GitHub 目前建议先使用大型且定义明确的编程任务进行试验，并在自动运行模式下通过单条提示发送给 Copilot。公司随后将重点改进多轮及耗时更长的会话表现。GitHub 还提醒，在预览期间，模型、工作流、名称、可用性和产品行为可能发生变化。
编辑解读：从模型选择转向工作流设计
这里最重要的变化并不是增加了一个新模型，而是将执行决策从开发者转移到协调层，由该层决定一次尝试何时足够，以及任务何时值得承担审查或升级的成本。如果测试结果能够反映到实际使用中，这可能让开发者在部分任务中获得接近更强模型的质量，而无需为每个请求都支付其成本。
但这些数据尚未证明 HydraFusion 在所有编程模式中都具有普遍优势；它们与特定测试、受控策略和离线结果相关。响应时间、可靠性、系统在长会话中的行为、缓存效率和安全性等问题仍然悬而未决，而 GitHub 表示将在预览期间对这些方面进行测量。