GitHub 公开「HydraFusion」：运行时编排多个 AI 模型，成本较 Opus 5 最多降低 67%

GitHub 公开了名为 Project HydraFusion 的研究预览版，它会在运行时把来自多个供应商的 AI 模型组合起来，最终给出一份答案。它可以把草稿交给另一个系列的模型来评审，也可以在判断难度过高时移交给更强的模型，而这些决定都在开发者看不见的地方自动完成。内部评测显示，它在保持与 Claude Opus 5 相当质量的同时，把预估成本最多压低了 67%。

选的不是模型，而是解题方式

GitHub Copilot 此前已经有 Auto model selection，会根据请求内容分配最合适的模型。HydraFusion 把这个思路又推进了一步，被选择的对象不再是单个模型，而是整个工作流程本身。系统会为每一次请求生成执行计划，并从跨供应商的模型池中分配起草者、评审者，必要时还有接手的更强模型。

用户这边的操作并没有增加。只要在模型列表里选中 HydraFusion，剩下的流程就会在内部按照质量、成本和延迟的平衡自动确定。GitHub 把它定位为一项更大的努力的一部分，目标是在本地模型、云端模型和复合模型之间实现自动的语义路由。

三种执行模式

HydraFusion 把流程选择当作最优化问题来处理，依据推理、代码生成、调试和工具调用等能力信号，挑出能够达到质量标准的最轻方案。目前提供三种模式。

Single 由一个模型直接解决任务。对于简单的请求，不插入多余环节反而更快也更便宜。

Cascade 先让效率较高的模型起草，再由质量门决定是接受结果，还是移交给更强的模型。简单请求便宜处理，困难的情况则留有退路。

Critique 会让另一个系列的模型以只读方式担任评审，随后由起草的模型修改一次。评审模型运行在没有工具的隔离环境中，因此评审过程不会改动代码仓库。

流程中间产生的草稿在结果确定前不会展示给用户。理由是那些可能被丢弃的内容不应该看起来像成品，不过 GitHub 也承认，缺少进度可见性的等待确实是一种取舍，并把改进进度提示列为待办事项。

基准测试：逼近 Opus 5，成本大幅压缩

固定的路由策略在三个智能体式编程基准上接受了评测。对照基线是 Claude Opus 5 和 GPT-5.6 Sol，所有模型都在相同的推理强度下评估，成本统计涵盖起草、评审、修改、移交、重试和回退等每一个环节。

在考察终端环境下多步骤作业的 TerminalBench 2.1 上，HydraFusion 在质量超过基线的同时只花了三分之一的费用。DeepSWE 需要在大型代码库中横向查找并完成端到端修复，这里差了 1.5 个百分点，但如果这点差距能换来 36% 的成本下降，可以选择它的场合并不少。CheckpointBench 则是用真实 Copilot 会话构建的内部评测集，每段会话都绑定到公开仓库和固定提交，可以重放复现。

路由策略本身并非人工调参得来。GitHub 使用集束搜索来探索候选策略。开发记录还提到，8 月 11 日至 25 日之间评测平台出现两次故障，产生了无效运行，剔除这部分之后改进继续推进。

试用范围与使用方法

HydraFusion 面向所有 GitHub Copilot 套餐开放，作为 GitHub Copilot CLI 的实验功能提供。计费按各个模型实际消耗的 token 量，适用各自的标准单价。

/update
/experimental on
/model

最后在列表中选择 HydraFusion (Research Preview) 即可。现阶段最适合的是范围明确、一次提示就能交代清楚的编程任务。对多轮长会话的支持留待下一阶段，GitHub 也表示名称、行为和开放范围都可能随研究进展而变化。

总结

HydraFusion 讨论的不是哪个模型最强，而是把多个模型组合起来能否用更低的成本得到同样的结果。在 TerminalBench 2.1 上一边提高质量一边把费用压到三分之一，说明这个方向还有余地。研究预览阶段的数字未必能原样套用到日常开发中，但可以看出，编程助手的竞争重心正在从单个模型的性能扩展到运行方式的设计。