深入理解 GitHub Copilot HydraFusion：从选模型到编排工作流

题图来自 GitHub Blog 的 Project HydraFusion。

9 月初 GitHub 放出了 HydraFusion，一个在 Copilot 模型选择器里排着的"模型"，但它其实不是模型。我把官方博客、Changelog、社区讨论帖、HyDRA 论文和 Rubber Duck 的两篇文章放在一起读了一遍，想弄清楚三件事：它到底在每一轮里做了什么，那组"成本降 67%、质量还更高"的数字能信到什么程度，以及现在值不值得切过去用。

先说明一下：这篇文章里的所有数字都来自官方材料和社区帖子，我没有自己跑过评测。我能做的是把材料对齐、把推导补上，并且指出哪些地方我觉得证据还不够。

一句话版本

Auto 回答的问题是"这个请求该交给哪个模型"。HydraFusion 回答的是"这个请求该用什么流程来做，流程里需要几个模型"。从选模型到选工作流，抽象层级上了一层，后面所有的设计取舍都是从这一点推出来的。

它是怎么一步步演变过来的

官方在社区 FAQ 里给了一条很清楚的时间线：

另一条线是 Critique 这个模式的来源。2026 年 4 月 Copilot CLI 上线了 Rubber Duck，让另一个模型家族的模型充当只读评审，5 月又扩展成双向配对。HydraFusion 的博客明确写了 Critique"遵循与 Rubber Duck 相同的评审模式"。

所以 HydraFusion 不是凭空冒出来的新东西。它把 HyDRA 的"路由"和 Rubber Duck 的"评审"装进了同一个运行时，再加上"升级"这一手。这个来龙去脉，官方博客里一句带过，我觉得挺值得拆开讲。

三种执行模式

每个请求进来，HydraFusion 目前在三种模式里挑一种：

• Single：选定一个模型，直接解决。
• Cascade：一个高效模型先起草，质量闸门判断是接受还是升级给更强的模型。
• Critique：一个模型起草，另一个模型家族的独立只读评审员审查，起草模型据此修订一次。

1
2
3
4
5
6
7
8

请求
 └─ 能力信号打分（推理 / 代码生成 / 调试 / 工具使用）
     ├─ Single   ：模型 A ──────────────────────► 结果
     ├─ Cascade  ：高效模型起草 ─► 质量闸门
     │                              ├─ 通过 ─────► 结果
     │                              └─ 不通过 ─► 强模型接手 ─► 结果
     └─ Critique ：模型 A 起草 ─► 模型 B 评审（只读、无工具）
                                  └─► 模型 A 修订一次 ─► 结果

官方对三者的定位是这样的：Single 在一个模型就能搞定时保住速度和效率；Cascade 让便宜的模型先试一次，同时留一条升级通道；Critique 用在"评审比再试一次更有价值"的任务上。

官方有一句话我很认同：选择性是关键。有些任务直接做就行，有些需要评审、修订或升级。HydraFusion 会选"预期能满足需求的最简单工作流"，只在额外调用很可能提升结果时才多花一次模型调用。

另外还有一点容易被忽略。官方说随着前沿模型推进，新模型进入 Copilot 之后会被评估并纳入 HydraFusion 的模型池。这意味着你选的是一个会自己换零件的东西，每次用到的实际模型组合不是固定的，官方也明确说不公布固定名单。

路由的底座：HyDRA

决定"用哪种工作流"靠的是能力信号，这套信号来自 HyDRA。HyDRA 的论文是 2026 年 5 月上 arXiv 的，作者里 Aashna Garg 和 Shengyu Fu 同时出现在 HydraFusion 的团队名单里，两者的继承关系很直接。

论文的做法是这样的：

• 用一个 ModernBERT 编码器，后面接 K=4 个相互独立的 sigmoid 头，对每个查询分别预测推理、代码生成、调试和工具使用四个维度的能力需求。
• 模型池里每个模型的能力画像写在配置里，路由时做"缺口匹配"（shortfall matching），选出能力满足预测需求的最便宜模型。
• 预测器和模型目录完全解耦。增删模型只改配置，不用重新训练。线上预测器的 CPU 推理延迟中位数是 86 毫秒。

我觉得"与模型目录解耦"是整套体系里最实用的一点，也解释了为什么 HydraFusion 敢说新模型一上线就能纳入。如果路由器的参数绑定了具体模型，每次换模型都得重训，这个迭代节奏根本跟不上现在的发布速度。

为了帮自己理解缺口匹配，我写了一段示意代码。它不是官方实现，只是把"满足需求的最便宜模型"这句话翻译成代码：

1
2
3
4
5
6
7
8
9

# 示意：按能力缺口选模型，threshold 越大越激进（省钱）
def route(required, pool, threshold=0.0):
    def shortfall(m):
        return max(max(0.0, required[k] - m.cap[k]) for k in required)

    ok = [m for m in pool if shortfall(m) <= threshold]
    if ok:
        return min(ok, key=lambda m: m.cost)
    return min(pool, key=shortfall)  # 没有满足的就选缺口最小的

论文里 SWE-Bench Verified 的结果对应这个阈值的三个档位。模型池是 5 个模型：GPT-5.4-mini、Claude Haiku 4.5、GPT-5.3 Codex、Claude Sonnet 4.6 和 GPT-5.4。

图：HyDRA 的三个工作点（来自 Getting more from each token）。

图：保守档与 OpenRouter Auto 的解决率持平（70.8%），节省是 3.3 倍。

6 月那篇 Auto 博客还透露了几个落地细节，我觉得对理解 HydraFusion 同样重要：

• 缓存感知路由。在一段对话里频繁换模型会破坏提示词前缀缓存，省下的钱可能不够补缓存失效的损失。Auto 只在自然的缓存边界做路由：第一轮（本来没有缓存），以及上下文压缩之后（前缀本来就要重置）。HydraFusion 的 FAQ 里也提到了"缓存感知的工作流"。
• 跨语言一致。路由模型用 16 个语系的对话训练，评估里各语言组的路由准确率与英文基线相差不超过 4 个点，质量没有统计上显著的差距。评估集取自生产环境 VS Code 聊天遥测，覆盖 19 种语言。
• 学习"什么时候升级才有用"。不是把任务简单标成难或易，而是对每条训练查询，比较弱模型和强模型的回答在多个质量维度上的差异，让路由器学会强模型到底在哪里更好。

图：智能路由与英文基线的差距在 4 个点以内。

Critique 的前身：Rubber Duck

HydraFusion 的 Critique 模式沿用了 Rubber Duck 的评审模式，所以有必要看看 Rubber Duck 的设计理由。

4 月那篇文章的出发点是：编码代理早期做的决定，尤其是规划阶段的决定，会变成后面所有工作的地基，错误的假设和低效的做法会变成依赖。让模型自查是有效的老办法，但自查受限于同一套训练数据和技术，盲区也是同一批。所以 Rubber Duck 让另一个家族的模型当评审。

几个数字值得记下来：

• 在 SWE-Bench Pro 上，Claude Sonnet 4.6 搭配运行 GPT-5.4 的 Rubber Duck，补上了 Sonnet 与 Opus 4.6 之间 74.7% 的性能差距。
• 在跨 3 个以上文件、通常要 70 多步的难题上，Sonnet 加 Rubber Duck 比 Sonnet 基线高 3.8%；在三次试验中识别出的最难问题上高 4.8%。

文章还举了三个被抓出来的例子，我读着觉得很能说明评审的价值所在：

• 调度器会启动后立刻退出、一个任务都不跑（OpenLibrary 的异步调度器），就算修好，其中一个任务本身还是死循环。
• 循环里每次迭代都覆盖同一个 dict 键，导致四个 Solr 分面类别里有三个从每次搜索里消失，而且不报任何错误。
• 三个文件都在读一个 Redis 键，而新代码已经不再写它，部署后确认界面和清理路径会静默失效。

复杂任务里，Copilot 会在回报最高的几个检查点自动寻求评审：规划完成后，复杂实现之后，写完测试但执行之前。代理卡住时也会主动求助，用户随时可以手动要求评审。设计上刻意"少用"，只在信号最强的时刻调用。

5 月的 Changelog 把它扩展成双向：选 GPT 作为编排者时，评审员换成 Claude；选 Claude 时，评审员升级为 GPT-5.5。这就是 HydraFusion 里"来自不同模型家族的独立评审员"的工程基础。

有了这个背景再看 Critique 模式：起草 → 异家族评审 → 起草者修订一次。只修订一次，评审成本有明确的上限，这和下面要讲的"有界执行"原则是对得上的。

运行时设计：五条原则

多模型编排听上去很美，真正难的是让它在一个会修改仓库的编码代理里可靠地工作。官方列了五条运行原则：

• 完整计量：汇总工作流每一段（起草、评审、修订、升级、重试、回退）的成本和用量。
• 有界执行：每一段都有明确的超时和取消行为，把执行时间和成本控制在边界内。
• 隔离评审：评审在隔离的、没有工具的上下文里运行，求解步骤使用共享工作区和正常的权限感知代理循环。评审模型能独立判断，同时碰不到仓库。
• 故障安全应用：工作流被取消或验证失败时，不应用任何补丁，避免未完成的修改进入仓库。
• 验证路由：执行前先校验工作流定义、模型绑定、回退行为和模型可用性。

内部会记录每一段的角色、结果、成本、延迟和诊断信息，事后能复盘。对外则只给开发者一个连贯的回答和一份带权限感知的变更集。

我觉得其中最关键的是"隔离评审"和"故障安全应用"。前者保证评审员不会一边审一边改，后者保证半途而废的结果不会留在仓库里。多模型流水线里最怕的就是中间态泄漏，这两条正好堵住了。

看一次真实的 Cascade 交接

社区帖子里有位用户贴出了会话日志里的一条事件，能看到 Cascade 升级时发生了什么。下面是帖子里可见的字段，内容被截断的部分我用省略号表示：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

{
  "type": "session.fusion_handoff",
  "data": {
    "fusionId": "fusion-2d2a6f1d-…",
    "sourcePhaseId": "fusion-2d2a6f1d-…:judge",
    "targetPhaseId": "fusion-2d2a6f1d-…:repair",
    "targetModel": "gpt-5.6-sol",
    "message": {
      "role": "user",
      "content": "HydraFusion Cascade escalation.\nComplete the original
        task in the current workspace. The workspace may contain an
        incomplete prior attempt; inspect it independently, preserve
        correct work, …"
    }
  }
}

这条记录有几处信息量很大。阶段 ID 以 :judge 和 :repair 结尾，说明 Cascade 里有专门的"裁判"阶段和"修复"阶段。升级给 GPT-5.6 Sol 的指令明确写着：工作区里可能有上一次未完成的尝试，请独立检查、保留正确的部分。也就是说，强模型接手时看到的是一个"可能有半成品的工作区"，而不是一张白纸，这样能省下重做的成本。

这位用户的完整流程是：先用 claude-sonnet-5 读记忆库文件，规划阶段跑了 Cascade，实现阶段按 Single 走，测试由 claude-haiku-4.5 执行（他自己判断这更像是子代理而不是 HydraFusion 的选择），最后的代码审查用 gpt-5.6-sol。

基准测试

评测设置

官方在三个智能体编码基准上评估固定的 HydraFusion 策略，对比基线是 Claude Opus 5 和 GPT-5.6 Sol：

• TerminalBench 2.1：终端环境里复杂的多步任务。
• DeepSWE：需要在大型代码库里跨文件理解依赖并给出端到端修复的仓库级任务。
• CheckpointBench：GitHub 内部的多轮基准，取自真实的 Copilot 智能体编码会话。每段对话锚定在一个公开仓库的不可变提交上，保证可回放，并且按语言、任务类型和难度平衡、做过质量清洗。

CheckpointBench 的构成：难度分布是简单 42.0%、中等 38.8%、困难 19.2%；语言里 Python 系占 33.3%，TypeScript 17.4%，C/C++ 9.8%；任务类型里 Bug 修复与调试占 32.6%，功能实现占 26.4%，代码解释与问答占 15.9%。

所有比较使用相同的任务输入、工具、执行限制、价格假设、评分条件和缺失结果处理方式，所有模型都在同一个中等推理级别下评估。衡量的是"经验证的任务质量"（确认答对的任务占比）和完整的预估工作流成本，成本包含每一个被调用的环节。

相对 Opus 5 的结果

这里展示的是调优后最好的 HydraFusion 配置。

完整数据

我把官方散点图里标注的数值整理成了下面三张表，方便横向看。

TerminalBench 2.1（pass@1 解决率，每任务平均成本）：

DeepSWE：

CheckpointBench（平均会话得分）：

我读这些数字的几点想法

TerminalBench 上最有意思的一行是 GPT-5.6-Sol：成本和 HydraFusion 一样是 $0.30，解决率 73.3%，比 HydraFusion 低 11.4 个点。同样的钱，编排让结果好了一大截。这是我觉得 HydraFusion 论点最有说服力的地方，它比"便宜模型随便凑合"强，也比"贵模型全程在线"划算。

DeepSWE 就没那么漂亮了。HydraFusion 比 Opus 5 低 1.5 个点，成本低 36%，但它花的 $2.70 其实比 Sol 的 $2.40 还多一点，解决率只高 2.2 个点。仓库级任务看起来是 HydraFusion 的短板。官方没有拆解这里的成本构成，我猜是难题更常触发升级和评审，多出来的调用把成本抬了上去，但这只是我的推测。

CheckpointBench 的纵轴范围只有 74% 到 79%，六个模型挤在 3.25 个点里。最便宜的 Luna 每任务 $0.30，得分 74.35%，只比 HydraFusion 低 3.15 个点，而成本是它的 1/28。从这张图看，更该问的是这个基准区分度够不够，而不是 HydraFusion 比 Opus 5 省了 65%。官方自己也承认 TerminalBench 的"相对饱和"，所以才补了 DeepSWE。

还有一点，团队自己讲得很坦诚：这些是受控的离线结果，对应特定的基准版本、工作流配置、模型池和价格假设，是否能迁移到真实开发负载，要靠这次研究预览来验证。官方引用了一位微软主任软件工程师的早期反馈：“HydraFusion 的推理和任务解决能力达到或优于 Opus”，我把它当成一条轶事看，不算证据。

策略是怎么"爬山"调出来的

HydraFusion 的路由策略是在真实 Copilot 使用方式的基础上塑造的，所以才有 CheckpointBench。团队在三个基准上反复改进，目标是整体表现，不是某一个基准。

调参方式也有意思：不手工调阈值，而是用束搜索（beam search）来构造最优决策策略。每个候选策略都跟一份冻结的基线对比质量、成本和失败模式，保证每次改进都站在稳定的参照上。

TerminalBench 2.1 的运行序列最完整，所以拿它作为迭代过程的例子。官方说这个进程不是线性的：8 月 11 日到 8 月 25 日之间，评测框架出现两次运行故障，产生了无效运行，这些被排除在性能趋势之外，修复后 HydraFusion 的配置继续提升，到 8 月 25 日达到记录系列里最强的工作点，best-of-2 等效 91.8%。

官方图里还标了几个节点：8 月 11 日是回退失败（0/89 到 89/89 个代理错误），8 月 14 日是第二次框架故障（11 次重跑，±7.3 个任务的噪声）。图表以 89 道任务为分母，趋势约为每天多解决 0.7 道题。这提醒我，在这个规模上单个任务就占约 1.1 个百分点，几个点的差距要谨慎对待。

怎么用

HydraFusion 目前是研究预览，三个入口：

Copilot CLI：

1. 运行 /update 安装最新版
2. 运行 /experimental on
3. 运行 /model，选择 HydraFusion (Research Preview)

VS Code（1.140 或更高版本，或 Insiders）：在 Copilot Chat 模型选择器里选 HydraFusion。没出现的话打开设置 chat.copilot.hydraFusion.enabled。通过组织或企业获得 Copilot 的话，可能需要管理员在组织或企业设置里允许预览功能。

GitHub Copilot 应用：更新到最新版，打开设置搜索 “HydraFusion” 并打开，然后在模型选择器里选它。

可用范围方面，9 月 4 日的博客说 CLI 上所有 Copilot 方案都可以用；9 月 30 日的 Changelog 写的是 Copilot Pro、Pro+、Business 和 Enterprise，Business 和 Enterprise 需要管理员开启预览功能。两处措辞有出入，我以最新的 Changelog 为准。

计费是按实际调用的模型用 标准费率 计，没有单独的 HydraFusion 收费，一轮的成本是各阶段之和。

最适合的任务是官方建议的：首轮单提示的编码任务，也就是边界清晰、有一定分量、能在自动驾驶模式下一次交给 Copilot 的任务。多轮迭代的长会话性能是接下来才要重点做的方向。

和 Auto 的区别

9 月 30 日的 Changelog 把这个区别又讲了一遍：Auto 为每个请求选一个模型；HydraFusion 探索 Copilot 怎样既能选工作流，又能在一轮之内协调多个模型。官方说两者最终会合并成一个体验，具体形态还在评估。

社区在说什么

官方发布帖下面有二十多条评论，我挑了几类有代表性的。

用起来的感受大多是正面的。有人说质量"相比全程 Opus 5 不算差"，但额度消耗大约只有平时的 10%；另一位在项目起步阶段发现，便宜的 mai-code-1.1-flash 大约承担了 30% 的轮次。也有人把它当作"非前沿任务的默认选择"。

成本方面并非一边倒。一位用户让它规划并实现一个电影搜索小应用，规划约 500 AIC，实现约 2300 AIC，他说合计占了 Pro+ 额度的 40%。他自己也怀疑超支更多来自带子代理的长会话（他为此另外提了一个关于提示缓存失效的 Issue）。我觉得这个例子说明一件事：HydraFusion 的"省"是相对的，会话结构会影响缓存命中，缓存命中又直接影响费用。

最集中的抱怨是看不到中间过程。官方 FAQ 的解释是：中间产物可能被评审、修订或丢弃，实时展示会让没做完的东西看起来像最终结果，所以现在只展示工作流阶段，把草稿压住直到返回一个连贯的结果。但用户反馈的实际问题是：

• 研究型任务看不到分析内容，只能看到最后的提问"你想怎么处理"。
• 要求确认审批时，看不到被审批的计划是什么。
• 取消不够及时，会继续跑一段才停。
• 实现阶段选了哪个模型不显示，希望有斜杠命令能看各模型的占比，这样才能建立信任。

官方在 9 月 30 日的 Changelog 里回应了一部分：VS Code 和应用里加了更多进度更新和更清晰的状态。官方也承认"等待却看不到足够信息"是一个真实的权衡。

还有一批问题到我写这篇文章时在帖子里没看到官方回答，我觉得对企业用户尤其关键：

• 内部路由是否严格遵守企业层面禁用模型的策略，包括评审、裁判、回退、升级各阶段的模型？使用的模型是否在已有的数据处理协议覆盖范围内？
• 是否尊重企业启用的模型列表？（有人说 Auto 不尊重，所以一直在用过时的旧模型。）
• 能不能和 BYOK 一起用？
• 模型池更新多快？有用户发现它还在选 GPT-5.6 Terra，而按他的判断，新发布的 GPT-6 Luna 和 GPT-6.1 Sol 在性价比上已经胜出。

社区里还出现了一些使用层面的小坑：计划模式下切换到 HydraFusion 会被弹回之前的模型（官方确认像是 bug）；有人发现用 copilot --model hydrafusion 启动会报模型不可用，社区里流传的一个绕法是先设置环境变量 COPILOT_CLI_ENABLED_FEATURE_FLAGS=HYDRAFUSION_ROLLOUT。这个是用户之间互相分享的做法，不是官方文档里的，用之前请自己判断。

Microsoft 365 里的同构做法

HydraFusion 不是微软体系里唯一的多模型编排。Microsoft 365 的这篇文章讲到 Researcher 的 Auto 模式：先由 GPT 生成报告，再由 Claude 做第二遍推理复核，这和 HydraFusion 的 Cascade 与 Critique 是同构的两阶段流水线。Model Council 则让多个深度推理代理并行运行，高亮一致和分歧之处。

Microsoft Mechanics 的视频帖把这两种形态拆开演示：Critique 让生成模型和独立评审模型分离，强调来源可靠性与证据接地；Model Council 把同一个提示并行发给 GPT 和 Claude，并排比较完整的推理。拿它们和 HydraFusion 的三种模式对照看，能发现一个共同的思路：评审和并行比对，都是在用模型之间的差异补足单一模型的盲区。

我的几点判断

我自己的看法是，HydraFusion 值得认真试，但不要被"67%“这类数字带着走。

它的核心价值是把"开发者手工做的事"放进运行时：挑模型、找另一个模型复核、难题升级。这些事现在很多人都在手工做，有位社区用户就说自己一直在用编排器加子代理拼类似的东西。把它产品化的收益很实在，尤其是"我不想每次都想该用哪个模型"这类省心。

保留意见主要有四点：

• 基准是官方自己调的。策略在 CheckpointBench、DeepSWE 和 TerminalBench 上反复爬山，之后又在这些基准上报告结果，虽然官方强调是跨评估集优化而非针对单个基准，但这仍然是需要真实负载来验证的地方。
• 成本口径是"预估成本”，而且前提是所有模型都在中等推理级别。如果你平时对 Opus 开高推理，这个比较的参照物就不同了。
• 可观测性不够。你不知道某一轮用了哪几个模型，也就很难判断钱花在哪、什么时候该手动换模型。社区有人建议公开结构化的执行遥测，比如选了哪种策略、哪些模型家族参与、是否发生升级、评审是否否决了初稿，我觉得比公开原始推理过程更现实。
• 企业合规问题没有答案。模型池不公布、不能自选或排除，对有严格模型白名单和数据处理要求的团队，目前基本是阻塞项。

我计划的用法是：先把它用在那些边界清楚、可以一次性交给自动驾驶的中等规模任务上，用 /session id 记下会话，再回头对照模型占比和花费。如果你在 Copilot CLI 里试，反馈时带上调试日志或会话 ID，官方明确要这个。

官方的最后一段话给了一个判断：编码代理的下一步收益，会来自把前沿智能和运行时编排结合起来，HydraFusion 是第一次下注，目标是从"选最好的模型"转向"为每个任务动态构造最好的解法"。我基本认同这个方向，至于这次下注赢多少，要看预览期之后的真实数据。

参考资料

• Project HydraFusion: Frontier quality via multi-model orchestration（GitHub Blog，2026-09-04）
• HydraFusion in VS Code and the GitHub Copilot app（GitHub Changelog，2026-09-30）
• GitHub Copilot weekly releases: September 7（GitHub Changelog，2026-09-10）
• HydraFusion 研究预览发布与 FAQ（GitHub Community）
• HydraFusion 官方文档
• Getting more from each token: How Copilot improves context handling and model routing（GitHub Blog，2026-06-17）
• HyDRA: Hybrid Dynamic Routing Architecture for Heterogeneous LLM Pools（arXiv:2605.17106）
• GitHub Copilot CLI combines model families for a second opinion（GitHub Blog，2026-04-06）
• Rubber Duck in GitHub Copilot CLI now supports more models（GitHub Changelog，2026-05-07）
• Evaluating performance and efficiency of the GitHub Copilot agentic harness across models and tasks（GitHub Blog，2026-06-25）
• Choosing the right AI model in Microsoft 365（Microsoft Tech Community，2026-06-25）
• Claude + GPT | Multi-model intelligence in Copilot（Microsoft Tech Community，2026-04-09）