GitHub 已将 HydraFusion 研究预览从 Copilot CLI 扩展到 VS Code 与 Copilot 应用

GitHub 在 9 月 30 日的中宣布，HydraFusion 的研究预览现已从 Copilot CLI 扩展到 Visual Studio Code（VS Code）和 GitHub Copilot 应用。HydraFusion 会出现在模型选择器里；它是一套运行时编排系统，为每个请求选择工作流，并协调多个模型完成一次任务。

9 月 4 日，GitHub 用一篇发布了 HydraFusion。CLI 阶段的里，FAQ 写道：「GitHub Copilot 应用和 VS Code 都计划在 9 月内快速跟进」。HydraFusion 目前仍为研究预览，面向 Copilot Pro、Pro+、Business 和 Enterprise 用户；GitHub 表示该功能可能发生变化。

在 VS Code 和 Copilot 应用里怎么开启

VS Code 需要 1.140 或更高版本（或 VS Code Insiders）：在 Copilot Chat 的模型选择器中选中 HydraFusion；如果它没有出现，需要打开 chat.copilot.hydraFusion.enabled 设置。Copilot 应用则要更新到最新版本，在设置（Settings）里打开 Experimental（实验性功能），开启 HydraFusion，再从模型选择器中选中它。GitHub 的补充说，在 VS Code 中它排在 Auto 之下。

如果你通过组织或企业使用 Copilot，还有一道管理员门槛：GitHub 表示，Business 和 Enterprise 的管理员可能需要在组织或企业设置中允许预览功能。文档另有一条规则：HydraFusion 只调用你的套餐可用、且符合组织或企业模型策略的模型；如果这些模型对你全都不可用，它就不会出现在选择器里。

GitHub 在更新说明中称，把 HydraFusion 带到更多界面是早期反馈中呼声最高的请求。这类请求在讨论帖里反复出现：用户 @hallatore 写道「我希望它能尽快来到 VS Code Insiders」，@matthewteeter 则问它是否会来到非 CLI 的「富客户端」。

三种工作流：Single、Cascade 与 Critique

GitHub 强调 HydraFusion 不是单一模型：它是一套运行时编排器，会选定一条工作流，连同运行它的模型，最后只返回一个响应。工作流的选择被当作一个优化问题：用推理、代码生成、调试与工具使用四类能力信号，挑出最有效率、且能满足质量门槛的那一条。三种工作流是：

Single：由一个模型直接完成任务。
Cascade：先用高效模型起草方案，再由质量门决定是接受，还是升级到更强的模型。
Critique：一个模型起草，另一个来自不同模型家族的独立只读评审模型给出意见，起草模型据此修改一次。这种审查模式与 Copilot CLI 里的 Rubber Duck 代理相同。

GitHub 还说明了它与 Auto 的不同：Auto 为每个请求选一个模型；HydraFusion 选择的是工作流，并可能在一轮里协调多个模型。文档给出的使用建议是：日常任务用 Auto；范围明确、工作量较大的编码任务，比如修复复杂 bug 或跨多个文件改动，再用 HydraFusion，因为额外的模型轮次可能值得多花的时间和 AI credits（AI 额度）。文档还说，它调用的模型池并不固定，会随新模型上线与评估结果变化，用户不能自行选择或排除；同一会话里，不同提示可以走不同工作流，而选择工作流本身是一个轻量步骤。

那篇研究博客里有一张架构图，把这条链路画成四段：任务路由、编排模式、执行、发布结果。求解阶段在共享的真实工作区里运行、遵循常规工具与权限；评审阶段使用隔离的上下文、不接触工具；最终只发布一份选定的结果。

更透明的步骤与更频繁的进度更新

更新说明列出三项改进：工作流每一步在做什么显示得更清楚；工作期间的进度更新更频繁；任务耗时较长时，也更容易看出 HydraFusion 仍在工作。文档里还有一个查看方式：把鼠标悬停在已完成的回复上，可以看到这次任务用了哪些模型；CLI 里则会显示所选工作流、每一段调用的状态和已运行的时间。

在 CLI 阶段，反馈里反复出现的一类问题是看不到中间过程：用户 @shawn-cummins-dsg 说，当任务需要先做研究、给出分析和建议、再请示下一步时，他能看到的只有「你想怎么做」这一句问题；也有参与者反映，审批提示出现时看不到被审批的计划内容。GitHub 当时在 FAQ 里解释过：中间结果只是工作草稿，可能被修改或丢弃，所以只展示最终经过审查的结果。

GitHub 给出的基准数字与限定范围

那篇研究博客报告了三项智能体编码基准的离线评测结果，对照基线是 Claude Opus 5 与 GPT-5.6 Sol，所有模型在相同的 medium（中等）推理级别下运行，表格数字来自调优后的最优配置。TerminalBench 2.1 测终端环境中的复杂多步任务，DeepSWE 测需要理解大型代码库与跨文件依赖、给出端到端修复的仓库级任务，CheckpointBench 则是 GitHub 内部基于真实 Copilot 会话整理的多轮基准。

TerminalBench 2.1：验证任务质量（被确认正确完成的任务占比）比 Opus 5 高 4.9 个百分点，估计成本低 67%；
DeepSWE：质量低 1.5 个百分点，估计成本低 36%；
CheckpointBench：质量低 0.1 个百分点，估计成本低 65%。

成本的口径是「估计的工作流成本」，把起草、评审、修订、升级、重试、回退等每一段调用都计算在内。GitHub 提醒，这些受控的离线结果只在被评测的基准版本、工作流配置、模型池与价格假设下成立；三个基准里有两个，HydraFusion 的质量略低于 Opus 5，换来的则是成本大幅下降。

按模型计费，预览期没有服务等级协议

计费规则是：使用 HydraFusion 时，你为它调用的每个模型按标准价格付费，没有单独的 HydraFusion 费用，Auto 模型选择享受的折扣也不适用；一次任务可能消耗比单模型更多的 AI credits。文档建议，快速或例行任务改用 Auto；Cascade 与 Critique 要跑多轮模型调用，因此更慢，也更耗额度。

预览期的限制同样写在文档里：没有服务等级协议（SLA），HydraFusion 也不面向生产工作负载；它不会启动子代理（subagents），两者分开工作；如果它丢弃某份草稿，草稿已经写进工作区的文件编辑不会被自动撤销，提交前需要自行审查；它使用的工作流和模型都可能随预览变化；显示的上下文窗口按所用模型里最小的限制取一个保守值，会话过长时需要先压缩再切换。

GitHub 说，接下来要验证这些离线结果如何落到真实开发者工作负载，并把多轮、长会话的强表现列为下一个重点；目前推荐的起点是单轮、范围明确、一次说清的编码任务。反馈帖中，另有参与者提出企业环境下的问题：HydraFusion 的内部路由是否在包括评审、裁判、回退与升级在内的每个阶段都遵守企业禁用的模型策略，模型使用是否受既有数据处理协议覆盖。