GitHub发布HydraFusion研究预览：用多模型动态编排争夺“前沿质量”与成本平衡
· 来源：github.blog
GitHub宣布在Copilot中推出HydraFusion研究预览，通过单模型、级联和跨模型批评三类运行时工作流，尝试以动态编排替代开发者手动挑选“单一最强模型”的方式。
GitHub于2026年9月4日发布Project HydraFusion研究预览，将多模型路由、协作和结果融合引入GitHub Copilot。用户可像选择普通模型一样选择HydraFusion，由系统在任务运行时决定调用哪些模型及采用何种流程；GitHub称，其目标是在质量、成本和延迟之间自动寻找平衡，并逐步实现本地、云端及复合模型之间的语义路由。
这一项目建立在Copilot此前推出的自动模型选择功能之上，但范围更进一步：不只是为单个请求匹配某一模型，而是为任务生成完整执行计划。HydraFusion会参考推理、代码生成、调试和工具使用等能力信号，选择预计能够达到质量门槛的、复杂度最低的工作流；新模型进入Copilot后，也可被评估并纳入候选模型池。
目前，HydraFusion提供三种执行模式。其一是“单模型”，由选定模型直接完成任务，以保持速度和效率；其二是“级联”，先让效率较高的模型生成方案，再由质量门决定接受结果还是升级至能力更强的模型；其三是“批评”，由一个模型起草结果、另一不同模型家族的只读审阅者独立检查，再由起草模型进行一次修订。GitHub将后一模式与其“Rubber Duck”审阅思路相联系。
面向代码仓库任务，GitHub强调了运行控制：系统需完整汇总起草、批评、修订、升级、重试和回退等每一环的成本与用量；每个环节设置超时和取消规则；审阅在隔离且无工具的环境中进行，解决任务的模型则在共享工作区内遵循既有权限感知代理流程。若工作流被取消或未通过验证，系统不会应用补丁；在执行前还会核验工作流定义、模型绑定、回退机制和模型可用性。
GitHub公布的离线评测覆盖TerminalBench 2.1、DeepSWE以及基于真实Copilot会话构建的内部基准CheckpointBench。该公司称，在固定HydraFusion策略下，系统在三项代理式编程基准上实现了“前沿级”质量，并有显著的估算成本节省。其中，在TerminalBench 2.1上，相比Claude Opus 5，HydraFusion的经验证任务质量提高4.9个百分点，估算成本低67%。这些数字来自GitHub自身的离线评测，实际企业环境中的任务分布、模型价格和响应时延仍可能影响结果。
HydraFusion的意义在于将企业采购和使用模型能力的重心，从押注单一旗舰模型，转向按任务动态组合模型与审阅流程。不过，其成本优势依赖路由和质量门的准确性，多次调用也可能带来额外延迟；尽管GitHub称会记录每个环节的角色、结果、成本、延迟和诊断信息，外部开发者最终看到的仍是统一回复和一组变更。因此，路由决策的可解释性、跨厂商评测的公平性，以及在不同仓库和真实生产任务中的可复现表现，仍有待独立验证。
—— 综合整理自：GitHub Blog