模型选择器正在变成编排选择器
9 月 30 日，GitHub 将 HydraFusion 从命令行移入编辑器。该研究预览版现可在 VS Code 1.140 及更高版本，以及 GitHub Copilot 应用中运行，这向普通开发者提出了一个相当不同寻常的理念：不要再选模型，而是选工作流。
HydraFusion 不是一个模型。它是一层机制，决定每一轮任务需要多少个模型角色。
同一请求的三种形态
Single 是熟悉的情形。一个模型处理请求，就像 Copilot Auto 已有的工作方式。
Cascade 从低成本开始。一个高效模型先写出初稿，质量门禁要么接受它，要么将工作升级给更强的模型。其目的是让日常编辑留在廉价模型上，把昂贵模型留给真正需要它们的问题。
Critique 花更多成本换取更高安全性。一个模型起草，另一个来自不同模型家族的模型充当只读评审，起草模型根据反馈修订一次。评审者从不碰代码，这避免了循环变成两个模型互相争论。
与 Auto 的区别是架构性的。Auto 决定应由哪一个单一模型接收你的提示词。HydraFusion 决定这一轮需要多少个角色，以及它们如何交互。这是智能控制所在位置的一次有意义转变。过去你选择模型，是因为它更擅长你这类工作。在这里，你选择一种优化策略，让平台在底层组合模型。
成本账是真实的，但也是自行报告的
问题在于计费。GitHub 按 token 计费，费率采用每个所选模型的标准价格。一次 Critique 运行至少调用两个模型，因此单次请求的成本可能高于一次单一调用。Cascade 的设计是通过把简单工作下推来降低成本。这种节省并不是任何模型上的折扣。它是一种押注：大多数轮次并不需要最好的模型。
GitHub 自己的对照评估报告称，在三个编码智能体基准测试中，相对于其 Claude Opus 5 基线，工作流成本降低了 36% 至 67%，质量在 TerminalBench 2.1 上提高了 4.9 个百分点，在 DeepSWE 上降低了 1.5 个百分点，在 CheckpointBench 上降低了 0.1 个百分点。这些是厂商在 GitHub 自有测试设置上生成的数据。它们是关于你的代码库的一种假设，而非保证，而且参与 HydraFusion 的模型池尚未完全公布。任何基于该预览版构建的东西，都应把路由行为视为可能随时变化。
还有明显的延迟成本。草稿加评审比一次回答耗时更长。Business 和 Enterprise 套餐的团队必须密切关注使用仪表盘，因为系统决定何时升级，而这个决定并非没有成本。
无法审视的优化难以信任
路由的尴尬之处在于，做决定的是平台，而不是开发者。事后你能看到哪个模型给出了回答，但不容易看到系统为什么选择某个工作流、质量门禁衡量了什么，或者一次 Cascade 运行距离升级有多近。GitHub 的基准声明描述的是其自有测试集上的平均值，而平均值会掩盖真正重要的案例。
这个缺口使编排变成了治理问题，而非纯粹的技术问题。一个工程团队如果要解释为什么某个拉取请求由两个模型家族评审并相应计费，就需要路由遥测数据，而预览版尚未提供。补救方法不是避开该功能。而是像测试任何内部隐藏的依赖项那样测试它：在一组固定、枯燥的仓库任务上，用单个前沿模型对照衡量完成任务成本，并观察重试和评审投入，而不是单次选择的标价。
与 Auto 的比较值得记住。Auto 回答的是哪个模型最适合某个提示词。HydraFusion 回答的是一轮任务值得投入多少流程，而流程一直是软件工作中昂贵的部分。
奇怪的副作用是，它让模型选择变得不那么情绪化。开发者会对特定模型产生依恋，而这些依恋通常建立在少数几次令人难忘的成功上。一个按任务类型路由并在失败时升级的系统，悄然承认了没有任何单一模型能在每个类别中胜出——这一点早已成立，却很少被付诸行动。
编辑器的下一块阵地正为此而建
Insiders 版本已经展示了它下一步的方向。一个名为 Compare Agents、标记为 Run Multiple Agents 的功能，将同一个提示词并行发送给多个智能体，每个智能体都在自己的 git worktree 中，然后由裁判智能体选出胜者，或将入围名单交给人类。
有趣的细节是裁判看什么。它比较更改的文件和 diff 统计、测试结果、构建状态、诊断信息、耗时以及架构差异。它会运行测试套件。它不会让另一个语言模型阅读代码并猜测。这是一个影响深远的小决定，因为它意味着比较基于项目的实际状态，而不是模型对项目的看法。
同一版本的其他部分是更安静的基础设施，只有智能体并行运行后才会显得重要。多文件夹会话让一个会话中的每个对话使用自己的文件夹或 worktree，因此更改不再冲突。远程委派将任务交给已连接的远程智能体主机。共享 worktree 文件夹复用被忽略的目录，以避免在每个分支上重新安装依赖项。Dev Containers 现在会在空闲五分钟后停止，并按需重启。
治理总是和功能出现在同一批提交里
面向 IT 的那一半发布内容并非事后补充。当 AI 功能不可用时，编辑器现在会说明最低所需版本，而不是给出通用的更新提示。管理员可以为 Auto 模型设置默认层级。一个新的 OpenTelemetry 设置可将 Copilot 使用情况映射回各个开发者。
把这三项放在一起看，轮廓就很清晰。一个跨多轮协调多个模型的平台，会产生单一模型自动补全从未有过的成本、遥测和权限问题。成本归属不再是财务上的好奇心，而成为让该功能接近生产环境的先决条件。
多模型评审在严谨的工程团队中已是惯例。你让一个模型写作，另一个模型找错，或者先尝试快速模型，在输出不理想时升级。HydraFusion 把这种习惯自动化，这很方便，同时也移除了某些团队喜欢手动做出的决定。
预览功能应该保持预览多久，是一个合理的问题。工具落地的速度超过了围绕它的政策，而价格可预测性成为第一个牺牲品。一次 Critique 运行若在一个大型仓库上悄悄调用两个前沿模型，可能在任何人注意到之前就花掉真金白银。HydraFusion 能否晋升为默认功能，与其说取决于路由是否有效，不如说取决于 GitHub 能否让账单足够清晰，让人愿意签字。