GitHub 一直希望为开发者的每个任务提供最合适的模型。今年早些时候的 Auto model selection 已经能让 Copilot 根据请求自动匹配模型；今天发布的 Project HydraFusion 则把这一目标向前推进了一步：它不再只挑选一个模型，而是在请求到达时生成一个完整的执行计划，从多个提供商的模型池中选择模型，让它们起草、评审、修改解决方案，或在必要时将任务级联给更强的模型。开发者看到的是一个普通模型选项，HydraFusion 会在后台根据质量、成本和延迟进行平衡。
HydraFusion 把工作流选择视为优化问题。它会根据推理、代码生成、调试和工具使用等能力信号，选择最可能满足质量要求的高效执行模式。目前，每个请求会从三种模式中选择：Single（单个模型直接解决）、Cascade（高效模型先起草，质量门决定接受还是升级到更强模型）、Critique（一个模型起草，来自不同模型家族的独立只读评审者按 Rubber Duck 的类似模式检查，然后起草模型修改一次）。每种模式对应不同的质量成本取舍。
在 TerminalBench 2.1、DeepSWE 和 CheckpointBench 三个 agentic 编码基准的受控离线评估中，固定 HydraFusion 策略的表现优于或接近 Claude Opus 5 基线。以 Opus 5 为基准：TerminalBench 2.1 经核实任务质量提高 4.9 个百分点，估算成本降低 67%；DeepSWE 质量仅低 1.5 个百分点，成本降低 36%；CheckpointBench 质量仅低 0.1 个百分点，成本降低 65%。评估还以 GPT-5.6 Sol 作为对照，所有模型均使用相同的中等推理等级、输入、工具、执行限制与定价假设。
HydraFusion 的设计围绕五个原则：完整核算（统计每一条工作流的起草、评审、修改、升级、重试和回退成本）、有界执行（显式超时与取消）、隔离评审（评审步骤在无工具上下文运行，而解决步骤使用共享工作区）、故障安全应用（工作流取消或验证失败时不打补丁）以及经过验证的路由（执行前验证工作流定义、模型绑定、回退和可用性）。执行过程中，内部会记录每个步骤的角色、结果、成本、延迟和诊断，但开发者最终只收到一个连贯的响应和一组权限感知的变更。
基准细节显示，TerminalBench 2.1 主要衡量终端环境中的复杂多步任务；DeepSWE 需要跨文件依赖和大型代码库端到端修复，HydraFusion 在此以接近 Opus 5 的质量换取显著成本下降；CheckpointBench 是 GitHub 内部从真实 Copilot 会话构建的可回放多轮基准，HydraFusion 的成本优势明显。微软的一位首席软件工程师在早期内部测试中评价：“到目前为止，HydraFusion 的推理和任务解决能力达到或优于 Opus。”
HydraFusion 的策略也经过反复调优。团队从真实 Copilot 会话轨迹构建 CheckpointBench，并在三个基准上使用束搜索优化路由策略，而不是手工调整阈值。TerminalBench 2.1 的运行序列显示，8 月 11 日至 25 日评估工具曾出现两次操作故障，相关无效运行被排除并修正后，配置继续改进，8 月 25 日达到最强运行点。
目前研究预览最适合第一轮、单提示编码任务，GitHub 表示下一步会主攻更长的多轮迭代会话。官方建议开发者从范围清晰、内容充实的单提示任务开始，使用 Copilot 的自动模式试用，并可通过 /feedback 或 GitHub Community 讨论反馈。HydraFusion 仍是活跃研究项目，模型、工作流、可用性和产品行为都可能随预览学习而改变；GitHub 相信，编码代理的下一个真实进展来自前沿智能与运行时编排的结合。