昨天我们还在比较 GPT‑6 Astra、Gemini 3.8 和 Claude Fable 5.1：面对一项复杂开发任务，到底该选哪个模型？GitHub 今天给出了一个更有工程味的答案——不要强迫一个模型包办全部工作。
9 月 4 日，GitHub 发布 Project HydraFusion 研究预览。它不是一个新的基础模型，而是一套运行时编排机制：根据任务情况选择单模型直达、低成本模型先做再升级，或者让不同模型分别承担起草和审查。
这意味着 AI 编程的竞争单位正在改变。过去我们关注模型榜单，接下来更重要的问题是：如何让多个模型在成本、速度和质量之间协作，并且最终只交付一份可验证的修改。
HydraFusion 不是“模型大乱斗”
HydraFusion 已作为 GitHub Copilot CLI 的研究预览向各档 Copilot 方案开放，可通过实验功能选择。用户看起来仍然是在选择一个“模型”，但背后的运行时会决定本次任务该走哪条执行路径。
GitHub 公布了三种核心模式：
Single：一个模型直接完成
当任务边界清楚、难度可控时，系统把请求交给一个模型直接解决。这条路径延迟最低，也避免了为了“多模型”而增加没有必要的调用。
Cascade：先用高性价比模型，再按需升级
系统先让更高效的模型生成结果，再通过质量门判断是否接受。如果结果不达标，任务才升级到能力更强、成本更高的模型。
它类似工程系统里的分级处理：多数普通请求走快速通道，真正困难的请求才占用昂贵资源。关键不在于第一个模型是否永远正确，而在于质量门能否可靠识别“这次不能直接交付”。
Critique：一个模型起草，另一个模型审查
第三条路径最值得开发团队关注。一个模型先生成方案，来自不同模型家族的独立审查者只读检查结果，再由原起草模型进行一次修订。
这里的角色分离很重要：审查模型没有写入工具，不直接操作工作区；最终修改仍由起草模型统一完成。这样既能引入不同模型的判断，又不会让多个执行者同时修改文件，制造彼此覆盖和难以追踪的状态。
真正困难的是编排纪律
调用两个模型并不自动等于更高质量。HydraFusion 的价值更多体现在它明确提出了一组生产级约束。
- 完整计费：路由、起草、审查、修订和升级的每一次调用都必须纳入成本，而不是只统计最终回答；
- 有界执行：每条路径都要有超时、取消和停止条件，不能无限自我反思；
- 隔离审查：审查者读取结果、提出意见，但不拥有写入工具；
- 失败安全：取消或验证失败时，不应留下半成品补丁；
- 配置校验：路由、模型绑定、降级策略和模型可用性都要在执行前确认。
这套纪律比“让三个 Agent 开会”更接近真实软件工程。多模型系统首先是一个受约束的执行系统，然后才是一个提示词技巧。
官方数据说明了什么
GitHub 以 Claude Opus 5 为参照，公布了 HydraFusion 在三个离线测试集上的结果：
- TerminalBench 2.1：估算成本降低 67%，质量提高 4.9 个百分点；
- DeepSWE：估算成本降低 36%，质量下降 1.5 个百分点；
- CheckpointBench：估算成本降低 65%，质量下降 0.1 个百分点。
最有价值的结论并不是“多模型一定更强”，而是编排能够改变质量与成本的组合：有些任务同时变得更便宜、更好；有些任务则用很小的质量损失换取明显成本下降。
这些仍是 GitHub 在受控环境中得到的离线结果，采用相同的中等推理强度，模型池、配置和价格假设也有特定边界。它们适合证明路线可行，不能直接替代团队自己的真实任务评测。
团队可以先做一个“小型 HydraFusion”
即使暂时不用 Copilot CLI 的研究预览，团队也可以在内部 Agent 平台上实践同样的思路。
- 先定义三条路：简单任务单模型直达；结果不确定时级联升级；高风险修改进入起草—审查—修订；
- 用客观信号做质量门：优先使用测试、类型检查、静态分析、变更范围和策略规则，不要只让模型给自己打分；
- 限制预算：为每个任务设置最大调用次数、总 token、总费用和最长执行时间；
- 分开写入权：同一时刻只有一个执行者能修改工作区，审查者保持只读；
- 统一交付：无论内部经过多少模型，最终都应收敛为一份连贯补丁和一组验证证据；
- 记录每一段链路：保留路由原因、模型调用、质量门结果、升级原因和最终成本，方便复盘。
内部评测也应该从“哪个模型得分最高”升级为“哪个编排方案每成功完成一个任务的总成本最低”。成功率、人工接管次数、回滚率、完成时间和成本必须放在一起看。
现在还不适合把它神化
GitHub 明确把 HydraFusion 定义为研究预览。当前最适合的是第一轮、单提示词、任务较重但边界清楚的自动执行场景；长对话中的持续路由和多轮协作仍是后续重点。
这也提醒我们，多模型编排不是把每个请求都拆成复杂流水线。路由本身有延迟和成本，审查也可能引入噪声。成熟系统必须知道什么时候调用更多模型，也必须知道什么时候一个模型已经足够。
我的判断：模型忠诚度会越来越不重要
前沿模型仍会继续竞争，但企业和开发者不会永远只押注一个模型。更现实的架构是：便宜模型处理大多数确定性工作，强模型解决困难节点，不同模型相互校验，系统负责权限、预算、状态和最终交付。
昨天的问题是“GPT‑6、Gemini、Claude 该选谁”；今天 HydraFusion 把问题推进了一步：我们能否把它们安排到最合适的位置，让整体系统比任何单个模型更可靠？
AI 编程下一阶段的优势，不只是拥有最强模型，而是拥有最会分工、最懂停止、也最能验证结果的编排系统。
资料来源：
- GitHub：Project HydraFusion — frontier quality via multi-model orchestration
- GitHub Changelog：GitHub Copilot weekly releases — August 31
本文依据 GitHub 截至 2026 年 9 月 5 日公开的信息整理。文中测试数据来自 GitHub 官方离线评测，实际效果会随任务、模型配置、推理强度和价格变化。