GitHub 于 2026 年 9 月 30 日宣布，HydraFusion 研究预览版现在可以在 Visual Studio Code 及 GitHub Copilot App 使用，覆盖面由原本的 Copilot CLI 扩大。HydraFusion 出现在模型选择器中，但 GitHub 特别强调它不是一个单一模型，而是一套协调多个模型的工作流系统。
它把工作流选择视为一个优化问题，根据推理、代码生成、调试和工具使用等能力信号，选择较有效率、同时能达到质量门槛的执行方式。第一种是 Single，由一个选定模型直接处理任务；第二种是 Cascade，先由较有效率的模型起草，再由质量闸门决定接受结果或升级到更强模型；第三种是 Critique，由一个模型起草，再交给不同模型家族的独立只读评论者检查，最后让原模型修订一次。
这个设计与传统的「Auto 选一个模型」不一样。GitHub 表示 Auto 是按每个请求选模型，而 HydraFusion 会在同一回合内同时考虑选择工作流及协调多个模型。对编程代理来说，这将决策单位由模型名称提升到任务路径：简单任务可以直送，风险较高或不确定的任务则可能加入质量闸门或独立批判。
GitHub 这次也改善了可见度。用户可以更清楚看到 HydraFusion 每一步在做什么，系统会发送更频密的实时进度，在长任务中显示更明确的状态。这类产品细节看似不是模型能力，但对 agent 工作流很重要：如果用户不知道系统正在等待、切换、重试还是已经失败，就很难判断何时需要介入。
目前 HydraFusion 可以供 Copilot Pro、Pro+、Business 和 Enterprise 使用；Business 及 Enterprise 需要管理员开启预览功能。它仍然是 research preview，功能及表现可能改变。这一点也限制了新闻的解读：GitHub 的公告说明产品形态及可用范围，但没有在这篇更新中提供一套足以证明所有任务都会改善的独立基准。
对 AI 编程工具市场来说，HydraFusion 的信号是模型路由正逐步变成工作流路由。当模型数量增加，最难的问题未必是「哪个模型最强」，而是怎样按任务成本、速度、可靠性和风险选择路径。Cascade 的质量闸门及 Critique 的独立检查，也把测试、审查和人类介入点放到代理流程之中，而不是只靠最后一次对话判断结果。
不过，多模型编排也带来新的治理要求。团队需要知道每一步用了哪个模型、谁作了接受或升级决定、评论者看到了什么内容，以及任务失败时能否重播和回滚。HydraFusion 仍是预览功能，最稳妥的做法是把它视为可观察的实验工作流，配合版本控制、测试及权限限制，而不是把它当成自动保证代码质量的黑盒。
