以前谈模型路由，通常是在几个模型之间选一个：简单问题交给便宜模型，复杂问题交给更强模型。9 月 4 日，GitHub 介绍了 Project HydraFusion，把选择范围又向前推进了一层：编程智能体不只选择“用哪个模型”，还会在运行时选择“用什么流程解决”。
HydraFusion 是 GitHub Copilot 中的研究预览。它会先理解任务，再在单模型、级联和批评修订等执行模式之间做选择，必要时调用多个模型完成一次任务。GitHub 公布的受控离线评测显示，经过调优的 HydraFusion 配置在不同基准上相对 Claude Opus 5 的预估成本降低了 36% 至 67%，但质量并非每个基准都更高。这个结果值得关注，恰恰是因为它把重点从“某个模型分数最高”转向了“怎样组织一次完整执行”。
背景：模型选择已经不够描述一次编码任务
一个真实的编码任务往往不是一问一答。智能体需要阅读仓库、理解约束、修改文件、运行测试，再根据失败信息继续修正。不同任务的难点也不一样：有些只需要一次直接生成，有些适合先让快速模型给出草稿，有些则值得让另一个模型独立检查后再修改。
如果所有请求都交给最强模型，质量可能比较稳定，但成本和延迟会一起上升。如果所有请求都交给便宜模型，又容易在跨文件修改、调试和边界条件上失手。简单的“按问题分类选模型”只能处理第一层选择，无法回答下面这些问题：
- 这次任务是否值得再做一次独立检查？
- 草稿质量不够时，应当升级到更强模型，还是让原模型修订？
- 多调用一次模型带来的收益，是否值得额外成本和等待？
HydraFusion 把这些问题视为执行计划问题。它的目标不是永远调用更多模型，而是在预计能达到质量要求的前提下，选择复杂度最低的工作流。
HydraFusion 的三种执行模式
GitHub 目前公开了三种基本模式。它们不是三个需要开发者手动编排的 API，而是 HydraFusion 在运行时可选择的执行结构。
1. Single：一个模型直接完成
Single 模式只选择一个模型处理任务，适合目标明确、上下文较小、一次完成概率较高的请求。它的成本和延迟最容易预测，也是其他模式的基线。
2. Cascade：先快后强，按质量门槛升级
Cascade 模式先让更高效的模型生成方案，再由质量门判断是否接受。如果草稿没有达到要求，流程才升级到更强的模型。
1 | 任务 |
它的关键不在“先用便宜模型”这句话，而在质量门。没有可靠的质量判断，级联就只是把一次调用变成两次调用，成本增加了，错误却未必减少。对于代码任务，测试结果、补丁是否完整、是否触碰了无关文件，都可以成为质量信号的一部分。
3. Critique：独立检查后再修订
Critique 模式先由一个模型生成结果，再让另一个独立的、只读的批评步骤检查同一结果，最后让起草模型修订一次。这个结构类似代码评审，但评审者不是直接修改仓库，而是提供反馈。
把批评步骤设为只读很重要。一个检查模型如果能同时修改文件，就很难判断最终变化来自原始解法还是评审过程，也可能在检查阶段引入新的副作用。独立评审的意义正在于隔离观察和修改。
三种模式可以简单表示为：
| 模式 | 额外步骤 | 适合解决的问题 | 主要代价 |
|---|---|---|---|
| Single | 无 | 目标清楚、一次完成的任务 | 对复杂错误缺少复核 |
| Cascade | 质量门和可能的升级 | 大部分简单任务，少量复杂任务 | 质量门判断错误会影响收益 |
| Critique | 独立检查和一次修订 | 需要减少遗漏的代码修改 | 多一次或多几次模型调用 |
研究预览如何使用
GitHub 表示，HydraFusion 目前可以在 GitHub Copilot 计划中通过 Copilot CLI 的 /experimental 入口试用。基本步骤是：
1 | /experimental on |
官方建议从一个范围明确、但确实需要多步处理的编码任务开始体验。HydraFusion 使用的模型按各自的标准模型费率计费，实际费用取决于它在一次任务中调用了哪些模型以及调用了多少次。研究预览中的模型池、工作流、名称和产品行为都可能发生变化，因此不应把当前结果直接当成长期 SLA 或固定成本承诺。
真正难的是编排控制，不是画出流程图
多模型工作流看起来像把几个模型串起来，但要让它在代码仓库里可靠运行，必须同时处理成本、权限、状态和失败。GitHub 在介绍 HydraFusion 时列出了五项运行原则，这些原则也适用于自行构建的复合智能体。
完整记录每一段成本
一次任务的成本不能只记录最后返回结果的模型。草稿、批评、修订、升级、重试和回退都属于同一次执行。若只按请求记录总价，团队会知道“这次很贵”，却不知道贵在质量门触发、重复重试，还是某个模型频繁升级。
更可用的账单维度应该至少包括：任务 ID、执行模式、每一段使用的模型、输入输出 token、耗时、重试次数和最终结果。只有这样，路由策略才有可能被真正优化。
给每一段设置时间和取消边界
级联和批评流程天然比单次调用更慢。每个工作流步骤都需要明确的超时、取消和最大调用次数，否则一个失败的质量门可能不断触发升级，最后把成本和延迟一起推高。
这也影响用户体验。用户取消任务后，后续的批评、修订或回退不应继续运行。取消信号必须能穿过整个执行图，而不能只停止最外层的界面等待。
把检查步骤放进隔离上下文
批评模型应当在只读、无工具或受限工具的上下文里工作，求解模型再使用共享工作区和正常的权限控制。这样做的目的不是让模型“更聪明”，而是让评审结论不会和评审者自己的修改混在一起。
对于涉及密钥、生产配置和内部文档的仓库，隔离还可以减少不必要的数据暴露。哪些上下文能被草稿模型看到，哪些只能提供给只读检查器，都应该成为执行计划的一部分。
验证失败时不要应用半成品补丁
如果工作流被取消、校验失败或中途异常，系统不应把已经生成的一部分补丁直接写入仓库。HydraFusion 把“失败时不应用补丁”作为安全原则，避免一个未完成的复合流程把半成品带进开发分支。
对普通 Agent 来说，这意味着修改文件之前应保留可回滚边界，应用补丁之后再统一做语法检查、测试和差异审查。模型说“完成”不是提交条件，验证通过才是。
执行前验证路由定义和模型可用性
运行时编排依赖多个外部条件：工作流定义是否合法，模型绑定是否存在，回退路径是否可用，当前计划是否仍然有权限执行。把这些问题推迟到任务中途，用户看到的往往只是一次模糊的“Agent 失败”。
执行前做一次计划校验，可以把配置错误和模型故障分开，也能在模型临时不可用时选择明确的降级策略。
评测结果应该怎样读
GitHub 在 TerminalBench 2.1、DeepSWE、CheckpointBench 以及基于真实 Copilot 会话的内部基准上，对 HydraFusion 和其他模型进行了受控离线评测。对比使用 Claude Opus 5 和 GPT-5.6 Sol 等模型作为基线，所有策略使用相同的任务输入、工具、执行限制、价格假设和评分条件；成本还包括草稿、批评、修订、升级、重试和回退。
官方给出的结果如下。质量分数是相对 Opus 5 的变化，成本是完整工作流的预估成本变化：
| 基准 | 成本变化 | 质量变化 |
|---|---|---|
| TerminalBench 2.1 | 降低 67% | 提高 4.9 个百分点 |
| DeepSWE | 降低 36% | 降低 1.5 个百分点 |
| CheckpointBench | 降低 65% | 降低 0.1 个百分点 |
这张表最容易被误读成“HydraFusion 便宜且质量更高”。事实更接近于：在 GitHub 选择的模型池、工作流配置、价格假设和离线任务上，最佳调优配置展示了很好的质量成本折中。DeepSWE 的质量下降说明，成本优势并不自动等于任务能力更强；研究预览还需要通过真实开发者工作负载继续验证。
另一个值得注意的细节是，GitHub 不只报告单一模型的调用价格，而是把每个工作流环节都计入成本。这种计算方式更接近企业真正关心的账单，也提醒我们：复合智能体的优化目标应该是“完成一个可验证任务的总成本”，不能只比较某个模型每百万 token 的单价。
它和普通模型路由有什么区别
普通模型路由解决的是选择问题：根据任务特征把请求发给模型 A、B 或 C。HydraFusion 多解决了一层执行问题：一次任务是否需要草稿、升级、独立批评和修订，以及这些步骤应当如何连接。
两者的区别可以用一个简单的例子说明。普通路由可能把“修改一个跨文件 bug”发给最强模型；HydraFusion 可能先让高效模型处理，再根据测试和质量信号决定是否升级，或者安排一个只读模型检查补丁。最终选择的不是一个孤立模型，而是一段有状态的执行图。
这也是它更难工程化的原因。路由策略需要了解工具权限、仓库状态、测试结果、价格和取消信号。模型越多，流程越复杂；流程越复杂，越需要明确的状态机和可观测性。
对开发团队的实践启示
先记录总成本，再谈“智能路由”
如果团队准备自己实现类似的多模型编排，第一步应该是记录每个任务的完整执行轨迹：调用了谁、调用几次、在哪一步升级、最终是否通过测试。没有这条数据，所谓“便宜模型先行”只能停留在直觉层面。
把质量门设成可验证信号
代码任务中的质量门可以包括测试是否通过、静态检查是否新增问题、补丁是否只触碰目标文件、是否完成用户要求的验收项。模型自评可以作为信号，但不应是唯一信号。一个能被测试和差异审查验证的门槛，才有机会支撑级联流程。
评审者应当与修改权限隔离
独立检查模型不必拥有写文件和执行任意命令的能力。让它只读取必要上下文并返回结构化意见，再由主执行器决定是否修订，可以减少评审阶段的副作用，也便于审计“谁提出了什么意见、谁应用了什么变化”。
先把失败路径设计好
复合 Agent 的成功路径很容易展示，真正决定可用性的却是取消、超时、模型不可用、测试失败和回退。每条路径都应该有明确结果：保留原状、回滚临时改动、转交人工，或返回可重试状态，而不是把一个半完成目录留给用户。
用自己的任务集复核公开基准
TerminalBench、DeepSWE 和 CheckpointBench 可以帮助比较方向，但不能替代团队自己的任务集。真实项目的语言、仓库结构、测试耗时、内部依赖和权限边界都可能不同。上线前至少应使用脱敏后的历史任务做离线回放，再进行小范围、可观测的在线试用。
结语
HydraFusion 的新意不只在于一次 Copilot 模型更新，而在于它把“模型能力”与“执行结构”拆开了。一个任务是否值得批评、升级和修订，和应该由哪个模型完成，是两个不同层次的决策。
这条路的收益很诱人：简单任务少走几步，复杂任务在关键位置增加检查，整体成本还有机会下降。但它的前提也很具体：每一段调用可计量，每一次升级有边界，检查过程与修改权限隔离，失败时不留下半成品。对开发团队来说，这些工程约束比“模型会自动选择”更值得先实现。
HydraFusion 仍然是研究预览，公开评测也有明确的任务集和假设条件。把它当作一个值得观察的架构信号，比把一张成本对比表当作普遍结论更稳妥：下一阶段的编程智能体，竞争点可能不只是模型本身，还包括谁能把多个模型组织成一条可验证、可取消、算得清的工作流。