AREX Feed Article
Nadella 官宣 GitHub Copilot 新功能 HydraFusion，称多模型编排最多降本 67%
UTC 时间 9 月 4 日 16 时 29 分（北京时间 5 日 0 时 29 分），微软董事长兼 CEO GitHub Copilot 推出 HydraFusion：把多个模型组合起来，让它们分别承担规划、构建、评审并完成编码任务，就能把交付同样结果的开销最多降低 67%。他称这体现开发工具从“模型选择（model selection）”转向“模型编排（model orchestration）”，是异构模型生态价值的例证，也代表微软在“成本-成果（cost-to-outcome）前沿”上的推进；随后他发出“Try it out”试用邀请，链接指向 GitHub 官方博客。
这条官宣并非 Nadella 首发。约 25 分钟前，，把 HydraFusion 定义为 Copilot 的一个“研究预览（research preview）”：用户不再挑一个最强模型，而是在运行时让系统为每次请求编排多家供应商的模型。给出同一组关键数字：在受控离线评测中，相对 Claude Opus 5，HydraFusion 在 TerminalBench 2.1 上把已验证任务质量提高 4.9 个百分点，同时估算成本降低 67%。功能形态、可用范围与 67% 的数字目前都出自微软和 GitHub 自己的发布口径，属于公司对自家评测结果的声明，并非独立第三方验证。
67% 只属于三个离线基准里最亮的一行
GitHub 博客用一张表给出 HydraFusion 相对 Claude Opus 5 的成绩，全部来自公司自己组织的受控离线评测：同样的任务输入、工具、执行上限与定价假设，所有模型统一在 medium reasoning 档，成本按完整工作流估算，计入起草、评审、修订、升级、重试和回退每一个环节，且结果取最优调参配置。
| 基准 | 估算成本（相对 Opus 5） | 已验证任务质量（相对 Opus 5） |
|---|---|---|
| TerminalBench 2.1 | 低 67% | 高 4.9 个百分点 |
| DeepSWE | 低 36% | 低 1.5 个百分点 |
| CheckpointBench | 低 65% | 低 0.1 个百分点 |
Nadella 推文里的“最多降低 67%”，对应的是三行中最好的一行：TerminalBench 2.1 衡量终端环境里的复杂多步编码任务，这里 HydraFusion 在质量领先的同时成本砍掉三分之二。另外两个基准没有那么亮眼：DeepSWE 考察需要跨文件改动的仓库级工程任务，HydraFusion 成本低 36%，质量比 Opus 5 低 1.5 个百分点；CheckpointBench 是 GitHub 内部基准，成本低 65%，质量基本打平（低 0.1 个百分点）。把三行放在一起看：官方口径里“成本大降”在三个基准上都成立，“质量超过 Opus 5”则只在 TerminalBench 2.1 上出现；另两组是以不到 2 个百分点的质量差距，换三分之一以上的成本降幅。
一次请求如何在运行时拆给多个模型
博客介绍，HydraFusion 把工作流选择当成一个最优化问题：系统用推理、代码生成、调试、工具调用四类能力信号评估每次请求，再挑一条预计能满足质量要求、又最省的执行路径。开发者感知不到这些决策——像选任何其他模型一样选中 HydraFusion，之后由它自己决定“谁来写、谁来审、要不要升级”。
目前每次请求只会在三种执行模式中选一种：Single 由一个模型直接求解，适合单模型能搞定的任务；Cascade 让高效模型先起草，一道质量闸门决定直接接受还是升级到更强的模型；Critique 由一个模型起草，另一个模型族的独立评审者只读检查（沿用与 Rubber Duck 相同的评审模式），起草模型再修订一次。博客称评审环节跑在隔离、无工具的环境里，评审者改不了仓库，只能评估。
这套流程的出发点是把开发者已经在做的事搬进运行时：现实中程序员会自己挑模型、让另一个模型复查、把难题升级给更强的模型，HydraFusion 把这一串手动协调自动化。选择性是核心：预计多调一次模型无益于结果时就不调。
五个运行原则与 91.8% 的内部调优顶点
跨多家供应商、跨多个环节执行，失控风险随之而来。博客列出了 HydraFusion 的五个运行原则：完整记账（聚合每个工作流环节的成本与用量）、有界执行（每环节有明确超时与取消行为）、隔离评审、故障安全应用（工作流被取消或校验失败时不应用补丁）、路由校验（执行前验证工作流定义与模型可用性）。每条请求的每个环节都会记录角色、结果、成本、延迟，便于事后复盘。
调优过程也一并公开：为了让路由策略可复现，团队用真实 Copilot 会话整理出内部基准 CheckpointBench，每条会话锚定一个公开仓库和不可变提交；路由策略用 beam search 自动搜索，而不是手工调阈值。GitHub 披露，8 月 11 日至 25 日期间评测框架出现过两次运行故障，相关无效结果被剔除后继续迭代，到 8 月 25 日 HydraFusion 在 TerminalBench 2.1 上达到记录序列里的最强点——91.8% 的 best-of-2 等价水平。博客还引用一位未具名的微软首席软件工程师的内部评价：“到目前为止，HydraFusion 的推理和任务求解能力与 Opus 持平或更好。”
从 Auto 模型选择到自动语义路由
HydraFusion 不是 Copilot 第一次做模型层面的自动化。博客回顾，今年早些时候 GitHub 上线了 Auto 模型选择，由系统审查任务并匹配最合适的模型；HydraFusion 被定位为这套策略的下一环：在本地、云端和复合模型之间做自动语义路由。官方明说当 Copilot 引入新模型时会评估并把它们纳入 HydraFusion 的模型池。
多供应商并置是这次发布的显眼特征：评测同时以 Anthropic 的 Claude Opus 5 和 OpenAI 的 GPT-5.6 Sol 为对比基线，执行模式里还要求评审模型与起草模型来自不同模型族。Nadella 把这一点上升为公司立场：异构模型生态本身有价值，微软的下一步是继续压低取得同等成果的成本。对 Copilot 用户而言，这意味着模型选择器的意义正在变化：以前是“哪个模型最强”，现在变成“哪个模型组合、哪条执行路径最划算”。
研究预览的试用边界与社区的分歧
GitHub 团队把 HydraFusion 限定为研究预览，并划出试用边界：现阶段最适合“第一轮、单个 prompt”的编码任务，建议在 autopilot 模式下把规模可观、边界清晰的任务一次性交给 Copilot，多轮长会话是下一阶段的重点。反馈渠道是 Copilot CLI 里的 /feedback 和 GitHub Community 讨论区。博客文末团队名单中的 ，该研究预览出现在 GitHub Copilot CLI 中，通过自适应多模型编排在质量、成本与延迟之间取平衡。
内部先行者的反馈偏正面。，他已测试 HydraFusion 数周，“对中大型任务来说非常出色，它把整个编排过程自动化了”。社区里也有质疑：在中，用户 ValentineC 认为主打与 Opus 5 对比的图表呈现不具说服力，称 Opus 5 在实践中不是好基线、没对比 Fable 或 Sol，用“前沿质量”宣传“有点不诚实”；用户 doomroot13 反驳说评测同样对比了 Sol、结果依然有利，只是相对 Opus 5 的成本优势最突出。GitHub 博客正文写明的确是 Opus 5 与 GPT-5.6 Sol 双基线，图表以 Opus 5 为参考线。
博客在结尾给这次发布定了性：这些是特定基准版本、工作流配置、模型池和定价假设下的受控离线结果，研究预览的目的就是把它们放到真实开发者工作负载上验证；结果、模型池、可用范围乃至 HydraFusion 这个名字都可能随预览反馈而变。67% 能不能变成真实账单上的降幅，要等预览把离线结果搬到真实负载上之后才有答案；多轮长会话的表现，排在官方路线图的下一站。