来源说明（热点来源）： GitHub Blog -《Project HydraFusion: Frontier quality via multi-model orchestration》（https://github.blog/ai-and-ml/github-copilot/project-hydrafusion-frontier-quality-via-multi-model-orchestration）
大多数应用在「给任务选模型」这件事上只有两招：固定一个最强模型，或者按任务类型写死路由。前者把简单任务也按贵模型计价，成本与延迟都压不住；后者依赖人对模型的静态印象，模型一更新规则就失真。GitHub 9 月初发布的 Project HydraFusion（研究预览）走的是第三条路：把模型选择变成运行时的工作流编排——同一个任务，系统在 Single、Cascade、Critique 三种执行模式里挑一条最省的链路，目标是达到或超过单一最强模型（对照基线 Claude Opus 5）的质量，同时显著压低成本。这篇按知识点拆开讲：多模型编排要解决什么问题、三种模式各自的机制、运行时怎么选、五大工程原则，以及它对 Agent 开发者的迁移价值。
一、先看问题：为什么「最强模型」和「写死路由」都不够
- 任务是异质的：改一个拼写错误和跨文件重构不是一个难度，用同一个模型硬扛，必然有一端浪费；
- 固定最强模型的问题：简单任务也按高价模型计费，Token 成本和响应延迟双重失控；
- 写死路由的问题：规则基于「我印象里 A 模型擅长什么」，模型一升级、任务描述一变，映射就失效，还得人工重新调；
- HydraFusion 的解法：把「选模型」升级成「选工作流」，在运行时根据任务的能力信号（推理、代码生成、调试、工具使用）挑一条复杂度最低、预期又能达标的工作流；只有「多一次模型调用可能改进结果」时才升级。
- 和 token 级加速（如投机解码：小模型起草、大模型验证每个 token）不同，HydraFusion 编排的粒度是整个任务：一次起草、审查、修订、升级的完整链路。
二、HydraFusion 是什么
一句话：GitHub Copilot 里的一个研究预览功能，把「一个任务配一个模型」换成「一个任务配一条多模型协作的执行工作流」。
- 用户感知：它看起来就是一个普通模型。在 Copilot CLI 里选中 HydraFusion 后，内部由系统自己选模型、选模式、跑流程，使用者拿到的是一个连贯响应外加一个权限感知的变更集，看不到中间那些可能被丢弃的草稿；
- 模型池：来源不限于一家（文中对照基线是 Claude Opus 5 与 GPT-5.6 Sol），Copilot 每新增一个模型，HydraFusion 会评估后把它纳入池子，让新模型去接最适合它的任务；
- 现状：研究预览，通过 Copilot CLI 的实验命令开放给所有 Copilot 计划用户，计费按实际用到的模型各自的标准费率累加。
三、三种执行模式：Single / Cascade / Critique
| 模式 | 工作机制 | 设计意图 |
|---|---|---|
| Single（单一） | 一个选定模型直接解决任务 | 单模型能胜任时保留速度与效率 |
| Cascade（级联） | 高效模型先起草，质量门判断接受还是升级到更强模型 | 让便宜模型先试，质量不达标时保留升级路径 |
| Critique（批判） | 一个模型起草，跨模型家族的只读批判者审查，起草模型再做一次修订 | 审查比「再来一次独立尝试」更有价值时，提供独立视角 |
拆开看几个关键设计：
- Cascade 的核心是质量门（quality gate）：它是一个程序化的判定点，先让低成本模型出草案，门判定达标就交付，不达标才升级到更强推理模型重做。这样能力边界是可伸缩的，而不是赌「便宜模型一定够用」或「贵模型一定需要」；
- Critique 有三个容易被忽略的细节：批判者来自与起草者不同的模型家族（同源模型会共享盲点）；审查在隔离的无工具上下文里运行，只能读不能改仓库；修订次数有界，只允许一次，防止无休止的来回拉扯。官方博客提到其审查模式与 Rubber Duck 的审查一致；
- Single 不是「默认最弱」，而是「最简单且达标」——编排系统只在确定收益时才引入额外调用。
四、运行时怎么选：能力信号 + 束搜索
HydraFusion 把工作流选择当成一个优化问题，而不是一堆手写 if-else：
- 决策输入是能力信号：推理、代码生成、调试、工具使用等任务画像，路由据此估计「哪种模式最可能达标」；
- 候选策略用束搜索（beam search）构造，每个候选都对照一个冻结的基线（frozen baseline）在质量、成本、失败模式三个维度上评估，再在 CheckpointBench、DeepSWE、TerminalBench 2.1 三个基准上迭代优化——刻意不在单一基准上过拟合；
- 开发日志里还记录了一个有意思的细节：8 月 11 日到 25 日之间评测框架自身出过两次操作故障（产生无效运行），团队把它剔除修正后才继续。也就是说，做编排的系统连「评估自己的评估」都要纳入工程管理；
- 路由策略不是一次性定死的：Copilot 每次新增模型，HydraFusion 都会重新评估并决定是否让新模型接管一部分任务。
五、五大运行原则：把编排做成能安全落地的工程
| 原则 | 内容 | 防的是什么 |
|---|---|---|
| 完整核算 | 聚合每个环节（起草、批判、修订、升级、重试、回退）的成本与用量 | 成本黑洞：某个隐蔽环节悄悄吃掉预算 |
| 有界执行 | 每个环节有明确的超时与取消行为 | 失控循环：一次失败引发无限重试 |
| 隔离审查 | 审查在无工具上下文运行，求解用共享工作区加权限感知循环 | 批判者误改仓库：把 review 变成 write |
| 故障安全 | 工作流取消或验证失败时，不应用任何补丁 | 半成品落地：把不完整更改合进代码库 |
| 验证路由 | 执行前验证工作流定义、模型绑定、回退行为与模型可用性 | 配置错误空跑：路由到了不存在的模型或断掉的绑定 |
这五条里最值得 Agent 开发者抄走的是故障安全：验证不过就不落盘。多模型链路环节越多，越需要一个「任何一环失败则整体不生效」的兜底，否则编排带来的不是质量而是事故面。
六、效果数字与口径
官方给出的最佳调优配置（所有模型都在相同的 medium 推理强度下评估）对照 Claude Opus 5：
| 基准 | 成本变化 | 质量变化 |
|---|---|---|
| TerminalBench 2.1 | -67% | +4.9 个百分点 |
| DeepSWE | -36% | -1.5 个百分点 |
| CheckpointBench | -65% | -0.1 个百分点 |
- TerminalBench 2.1 测终端环境里的复杂多步编码任务；DeepSWE 测仓库级软件工程（导航大代码库、跨文件依赖、端到端修复）；CheckpointBench 是 GitHub 内部基准，从真实 Copilot 编码会话中抽取、锚定到公开仓库与不可变提交，可重放；
- 口径提醒三连：这是 GitHub 官方自测、选的是最佳调优配置、且只对中等推理强度成立；研究预览阶段尚未被独立复现，数字以官方博客为准。内部工程师反馈称推理与任务求解能力「不低于 Opus」，同样属内部口径：
“So far, the reasoning and task solving capability is at or better than Opus.”
（微软首席软件工程师，GitHub Blog 引用，非公开基准数据。）
七、最小示意：一个 Cascade 质量门的骨架
Cascade 的「便宜先试 + 门禁升级」逻辑可以缩到很小（示意代码，非 GitHub 官方 API，仅演示机制）：
defcascade(task,drafter,escalator,judge):draft=drafter.run(task)# 起草模型先跑一轮，成本低verdict=judge.check(task,draft)# 质量门独立判定：达标与否 + 原因ifverdict.passed:returndraft# 达标直接交付，不再花升级的钱returnescalator.run(task,draft,verdict.reason)# 不达标才升级重做说明：drafter是低成本起草模型，escalator是更强模型，judge是质量门（在真实系统里它是另一套判定逻辑，不是让起草模型自己给自己打分）；verdict带passed与reason两个字段，reason会作为上下文传给升级模型，让它知道上一版差在哪。三个角色分开注入，才能做到「起草便宜、判定独立、升级有据」。以上为概念示意，真实实现与 CLI 接入方式以 GitHub 官方文档为准，未验证最新版本。
八、给 Agent 开发学习者的启示
- 把任务难度当变量而不是常量：给应用加一条「便宜先试 + 质量门升级」的链路，比盲目全上最强模型更接近成本最优；
- 审查者要和执行者解耦：跨家族、只读、隔离上下文、修订有界——同源模型会共享盲点，批判者越独立越值钱；
- 失败安全默认开启：任何一环验证不过就不落盘，这条对越长的 Agent 链路越重要；
- 成本要算全账：起草、批判、修订、重试、回退每一环的 Token 都记账，否则编排优化无从谈起；
- 路由策略放在基准闭环里迭代，别用手写阈值：模型一更新，静态规则就过期；
- 目前的官方建议是从首轮、单提示、范围明确的任务开始用，多轮迭代长会话的强表现是后续工作重点——上手时别一上来就压长任务。
九、总结
HydraFusion 的价值不在「多调几个模型」，而在把「选模型」这件事工程化了：三种模式定义了可组合的执行单元，质量门和跨家族只读审查解决了「谁来判断质量」的问题，五大原则保证了多环节链路不会变成事故面。对学习者来说，这套东西最直接的迁移价值是设计自己的 Agent 时多问一句：我的任务是 Single、Cascade 还是 Critique？以及——我的质量门和失败兜底在哪里？
