GitHub这周给Copilot CLI加了个新选项，名字挺唬人：Project HydraFusion。研究预览版，能在多个模型提供商之间自动排兵布阵——该省钱时用便宜模型，遇到难题就升级，需要复核就换一个模型家族来审。官方甩出的数字很抓眼：在TerminalBench 2.1上，它比Claude Opus 5质量高4.9个百分点，成本却低67%。听起来像一次全面碾压。但官方页面里另外两组数字，被放在了不起眼的位置——换个基准，这套编排系统的成绩单没那么好看。
三种执行模式，一句话讲清楚
HydraFusion不是一个新模型，是一套调度规则。面对一个编程任务，它只从三条路径里选一条：
- Single.一个模型直接把活干完，图快。
- Cascade.便宜模型先写一版，质量门检测不过关就升级到更强模型。
- Critique.一个模型起草，另一个模型家族只读不改地审一遍，原模型再改一次。
这套逻辑开发者早就在手动做——自己选模型、找另一个模型挑错、遇到难题换更贵的模型。HydraFusion干的事，是把这套“人工调度”搬进运行时，替你决定该走哪条路。GitHub把这个思路放进了它更大的盘子：此前的Auto model selection是“选对一个模型”，HydraFusion想做的是“选对一整套解决问题的流程”。
亮眼数字之外，还有两组不那么亮眼的
官方公告标题和图注反复出现的，是TerminalBench 2.1那组数字。但GitHub自己公布的完整评测其实是三个基准，放在一起看是这样：
| 基准 | 成本变化(对比Opus 5) | 质量变化(对比Opus 5) | 判断 |
|---|---|---|---|
| TerminalBench 2.1 | -67% | +4.9pp | 唯一全面领先 |
| DeepSWE | -36% | -1.5pp | 省钱,但质量打了折 |
| CheckpointBench | -65% | -0.1pp | 基本打平 |
CheckpointBench是GitHub用真实Copilot会话攒出来的内部基准，比另外两个更贴近日常使用场景——它的成绩是省65%成本，质量几乎没差，是打平，不是超越。DeepSWE那组更直接：成本降了，质量确实跌了。
三个基准放在一起，故事从“全面领先”变成了“看任务”。这正常，任何路由系统都是概率上的取舍——但公告只把最好看的那组数字放进摘要和图表，另外两组藏在正文往下滑才能看到。这不是造假，是选择性陈述，读者得自己把三张表拼起来才看得到全貌。
对开发者和企业采购来说，真正的问题不是这三个数字，是它们背后没交代的两件事。
第一是不透明。你选了HydraFusion，系统替你决定走Single、Cascade还是Critique，调用了几次模型、升级发生在哪一步、评审到底改没改结果——这些信息目前不会展示给用户，只留在内部日志里。GitHub说自己“完整核算”了每一段调用的成本和延迟，但这份账目现在只对内，不对外。
- 风险.用户只看到一个最终答案和一个总账单，看不到编排过程，出问题时很难判断是模型的锅还是路由策略的锅。
第二是延迟。Critique模式意味着至少两次串行模型调用——起草、评审、再改一次，中间结果在流程走完前不会露出来。省下的是token成本，不一定是等待时间。官方评测测的是离线固定策略下的估算成本，不是真实生产环境里用户实际等待的时间和账单，这中间还有一段没验证的距离。
省钱是真的,全面领先是加了滤镜的说法。
放在行业坐标里看，这个选择更清楚。Anthropic的Claude Code有子代理机制，但官方文档自己都提醒过度委派会浪费token和时间；OpenAI Codex走的是显式并行代理和任务级监督，用户能看见每个子任务在干什么；Cursor的Auto模式模型路由是可见的，虽然官方也承认它更容易消耗额度。GitHub这次选的是反方向：决策权全交给系统，用户只挑一个选项，剩下的看不见。集成度确实是这几家里最完整的一个——它长在Copilot现成的代理框架和评测体系里，不是从零搭起来的新东西——但透明度也是这几家里最低的一个。
这本身不算大问题，编排把决策权收进黑箱早晚会发生。真正决定这套系统能不能被企业放心用的，是GitHub接下来是否愿意把黑箱打开一角——给用户一张“执行收据”，写清楚这次任务到底调用了什么、升级了几次、多花了多少时间。现在的研究预览版，更像是一次公开测试：先把最漂亮的一组数字亮出来吸引尝鲜者，真正的成本和延迟分布，还得等更多人把它接进日常工作流之后才见分晓。