编程 Agent 的竞争，正在从「谁的模型更强」转向「谁能把不同模型用在最对的地方」。9 月 4 日 GitHub 在 Copilot CLI 里上线的 HydraFusion 研究预览，给出的思路是：不要总让最贵的模型从头干到尾，而是按任务动态调度多个模型。结果据称在几个主流编程基准上追平甚至超过 Claude Opus 5，而 Token 成本估计低了 36% 到 67%。
一、三种编排模式：单干、升级、互审
HydraFusion 的核心是三套执行模式。Single（单干）即一个模型独立完成整件事；Cascade（升级）让便宜的模型先试，只有质量不达标时才升级到更强的模型接管；Critique（互审）则是一模型写代码、另一模型做评审，再由第一模型根据反馈修订。简单说，它把「用什么模型」从一个固定选择，变成了随任务难度浮动的决策。所有 Copilot 订阅档位的用户都能通过 CLI 里的 /experimental 命令调用，且不单独收费，计费走底层模型的常规费率。
二、成本与质量的再平衡
官方给出的基准覆盖 TerminalBench 2.1、DeepSWE 与 CheckpointBench，结论是在这些项目上 HydraFusion 与 Claude Opus 5 相当或更好，而 Token 成本却低 36% 到 67%。需要客观看待的是，这类自测数据通常服务于产品叙事，真实工程场景的波动会更大；但它至少点破了一件事：在不少编程任务里，盲目调用旗舰模型是一种浪费，把简单活交给小模型、把关键判断留给大模型，往往能在体验不掉队的前提下显著省钱。
三、对编程 Agent 产品化的意义
HydraFusion 的信号意义在于，它把「多模型路由」从研究玩具推向了日常工具。过去一年，编程 Agent 的卖点多是「更聪明、更自主」；现在拐点开始出现——能否在不牺牲质量的前提下把账单压下来，正在成为企业采购的关键考量。对开发者而言，这意味着未来选 Agent 不只是选模型，更是选它背后的调度策略：谁能更聪明地分配算力，谁就更接近可持续的生产力。
四、局限与适用边界
当然，编排再巧也有边界。Cascade 的「质量不达标再升级」依赖可靠的评判信号，而在缺乏明确测试的工程任务里，升级触发可能失灵；Critique 模式多了一次评审往返，延迟与成本也会相应上升。更现实的是，当前预览仍跑在 CLI 场景，能否平滑扩展到 IDE、PR 审查、CI 流水线，还要看后续迭代。但方向已经清楚：编程 Agent 的下一程，拼的是「编排智慧」而非单纯的「模型肌肉」。