AIREITERGitHub HydraFusion 是面向 Copilot CLI 的研究预览编排系统；它在离线基准测试中的表现，并不能保证在大型、复杂且杂乱的代码库里同样有效。
先说结论：适合试，但别急着当默认方案
如果你拥有 GitHub Copilot 计划，并且手头有一项范围明确、能用一条提示词讲清楚的中大型编码任务，GitHub HydraFusion 值得一试。不过，我暂时不会把它作为关键生产变更或长时间多轮协作的默认选择：GitHub 仍将其标为研究预览，并表示更强的多轮支持仍是后续工作。
HydraFusion 并不是一个新的基础模型，而是内置于 GitHub Copilot CLI 的运行时编排系统。它会判断任务适合交给单个模型处理、是否需要升级到更强模型，或是在返回结果前加入一次独立审查。
在 Copilot CLI 中启用 HydraFusion
这项预览功能需要在 Copilot CLI 中开启，并非普通 VS Code 模型选择器里的选项。GitHub 的官方公告称，它可通过一组实验性命令向各类 Copilot 计划开放；而 Copilot CLI quickstart 则单独介绍了安装与认证流程。
- 运行
/update更新 Copilot CLI。 - 通过
/experimental on启用实验性功能。 - 输入
/model打开模型选择器。 - 选择 HydraFusion (Research Preview)。
- 先从一项规模可观但边界清晰的编码任务开始，而不是直接开启一个长期对话式项目。
如果列表中没有 HydraFusion，先更新 CLI，再确认你的 Copilot 账户、组织策略和 CLI 构建版本是否支持该预览功能。GitHub 的官方公告是当前命令流程的权威来源；预览名称和可用性都可能变化。
搜索结果中还可能出现 AICPS/hydrafusion。这是一个自动驾驶传感器融合研究仓库，与 GitHub 面向 Copilot 的 Project HydraFusion 没有关系。
不同任务，交给不同工作流
HydraFusion 会根据任务对质量、成本和延迟的要求，在三种执行模式之间选择。对于当前预览版而言，用户并没有手动切换“模式”的入口；GitHub 将 HydraFusion 作为一个类似模型的选项提供，由它在运行时决定底层工作流。
| 工作流 | 执行方式 | 适合优先尝试的任务 | 主要取舍 |
|---|---|---|---|
| Single | 由一个模型直接完成任务。 | 直接的修改、解释或小型修复。 | 表面开销最低，但没有升级机制或独立复核。 |
| Cascade | 先由高效率模型生成方案，质量闸门可决定是否升级给更强模型。 | 大多数时候不复杂、但偶尔需要更强能力的任务。 | 首次结果通过时能节省成本，但会增加质量判断环节，也可能触发第二次调用。 |
| Critique | 一个模型先起草，来自另一模型家族的隔离审查者进行评估，原起草模型再修改一次。 | 第二个视角有机会发现错误的变更。 | 调用次数和延迟都会增加，且审查者没有直接工具访问权限。 |
Single：直接完成任务
Single 是最直接的路径。根据 GitHub 的说明，单个求解模型会接收任务，并在常规、具备权限感知能力的 Copilot agent 循环中工作。因此，对于实现路径清楚、测试链路较短的需求，它是很自然的选择。
它的优势是工作流额外开销更低，但 Single 不提供内置的第二意见。
Cascade：先用高效模型，不够再升级
Cascade 会先使用高效率模型，再由质量闸门判断结果是否足够好，或是否应升级到更强模型。它的成本逻辑在于按需升级：常规请求不该默认消耗最强的可用模型。
如果首轮结果顺利通过质量闸门，Cascade 确实可能省钱；但 GitHub 没有公布通用的升级比例。因此，应根据实际任务结果评估，而不是假定每个请求都会走低成本路径。
Critique：先产出，再独立审查，最后修订一次
Critique 会引入一名来自不同模型家族的独立审查者。GitHub 表示，审查模型运行在隔离且无工具的环境中：它负责审阅草稿、将反馈交给原始求解模型，再由后者进行一次修订；审查模型本身无法直接修改仓库。
这相当于自动化的同行评审，但代价是额外的模型调用和等待时间。
基准数据看的是取舍，不是性能承诺
GitHub 的离线测试展示的是特定基准下的质量与成本平衡，而不是承诺每一项 Copilot 任务都能节省 67% 成本。
| 基准测试 | HydraFusion 质量相对 Claude Opus 5 | 估算成本相对 Claude Opus 5 | 应如何解读 |
|---|---|---|---|
| TerminalBench 2.1 | +4.9 个百分点 | 低 67% | 报告中最强的一项结果：经验证的任务质量更高，估算成本也更低。 |
| DeepSWE | −1.5 点 | 低 36% | 在高难度仓库任务上，以可衡量的质量让步换取了显著节省。 |
| CheckpointBench | −0.1 点 | 低 65% | 在 GitHub 的内部回放式基准中，质量基本持平，但估算成本低得多。 |
根据其官方 HydraFusion 公告，GitHub 在测试中使用了一致的评估设置，并将工作流内的所有调用都计入，包括重试、审查、升级和回退。
CheckpointBench 被描述为：针对不可变的公开仓库提交记录，回放经过筛选的 Copilot 会话。它比简单的文本生成测试更贴近编码 agent 的实际工作，但本质上仍是受控基准。DeepSWE 中 HydraFusion 的较低质量得分同样很重要，它提醒我们不能把整张表理解为全面胜出。
来自真实世界的独立证据仍然有限。独立开发者 @DoDataThings on X 点出了最值得验证的问题：
“负责规划的模型不一定要负责写代码。GitHub 的说明称，HydraFusion 在受控离线评估中达到了或超过了 Opus 5 基线；但从离线评估走向杂乱的真实仓库，往往正是编排系统失去优势的地方。很好奇这种成本差距还能保留多少。”
这条帖子提出的是问题，而非测量结果；但它确实指出了正确的验证方向：在复杂仓库中衡量成本与质量。
在真实仓库中，更该关注这些运行细节
HydraFusion 的价值不只是选到了一个更便宜的模型。由于多模型调用会产生比单次直连请求更多的运行状态，GitHub 文档特别提到了计费统计、取消、路由验证、审查隔离和补丁应用等控制机制。
| 控制机制 | 对用户意味着什么 |
|---|---|
| 成本与时间控制 | HydraFusion 会跟踪工作流各阶段的调用，并支持有边界的执行；但审查、升级、重试和回退仍可能增加延迟或总用量。 |
| 路由与补丁控制 | GitHub 表示会验证路由，且在工作流无效或被取消后不会应用补丁；但这两项机制都不能证明所选路由或最终代码一定正确。 |
| 审查隔离 | 求解模型使用共享工作区，审查模型则是只读且无工具的，这减少了审查者直接修改的可能性，但代码差异审阅和测试依然不可省略。 |
GitHub 公告还提到一项可见性取舍：中间草稿会一直隐藏到最终结果才显示。这样能让最终回复更干净，但等待期间你看不到草稿、重试、升级或丢弃的具体过程。
第一次测试 HydraFusion，建议这样做
首轮测试最好选一个边界明确、验收标准客观的仓库任务，而不是笼统地要求它“改进”整个代码库。应将这项预览功能视为一场实验：起始提交明确，成功标准固定。
- 新建干净的分支或 worktree，并记录起始提交。
- 挑选一个文件范围较窄、拥有可复现测试命令的任务。
- 在第一条提示词中写清预期行为、约束条件和测试要求。
- 让 HydraFusion 完成任务后查看 diff，不要只因 agent 报告成功就直接接受。
- 亲自运行相关测试，并检查是否修改了无关文件。
- 如果 CLI 提供这些信息，记录延迟、可见的用量或成本数据、重试情况、升级行为和最终测试结果。
- 在少量任务上重复测试后，再与固定模型比较，或考虑调整团队默认方案。
不要用一次成功的补丁来验证基准测试结论。更有价值的做法是准备一小组任务，覆盖常规修复、跨文件改动，以及一个刻意设计得存在歧义、可能需要升级或审查的场景。
HydraFusion 怎么收费，又没有承诺什么
GitHub 没有在公告中公布 HydraFusion 的单独美元价格。它表示，用量将按照底层模型的标准 token 费率计费，因此最终成本取决于运行时实际使用了哪些模型，以及经过了工作流中的哪些阶段。
| 计费问题 | 当前答案 |
|---|---|
| HydraFusion 是否需要单独订阅付费？ | GitHub 的公告没有说明存在单独的 HydraFusion 费用。 |
| 用量如何计费？ | 按组成模型消耗的 token，依照各自标准费率收费。 |
| 一个任务会产生多次计费调用吗？ | 会。Cascade 和 Critique 都可能涉及多个工作流阶段，计费统计还包括重试和回退。 |
| 基准中节省 67%，是否等于客户实际也能节省 67%？ | 不等于。这是针对特定基准、策略、模型池和定价设置的估算比较。 |
| HydraFusion 是稳定的生产级功能吗？ | 不是。GitHub 将其标为研究预览，并说明模型、工作流、可用性、行为和名称都可能改变。 |
初期应将 HydraFusion 用于可检查、单提示词即可完成的任务；对于长时间多轮协作或后果严重的工作，在仓库级测试证明它适合广泛使用前，仍应保留固定模型作为后备方案。
HydraFusion 常见问题
HydraFusion 是模型，还是路由器？
HydraFusion 是 GitHub Copilot CLI 中的运行时多模型编排系统，并非独立的基础模型；它会为编码任务选择模型和执行模式。
如何在 Copilot CLI 中启用 HydraFusion？
依次运行 /update、/experimental on 和 /model，然后选择 HydraFusion (Research Preview)。
所有 Copilot 计划都能使用 HydraFusion 吗？
GitHub 表示，该预览功能可通过 Copilot CLI 面向各类 Copilot 计划提供；不过账户、组织策略、CLI 版本或可用性变化都可能影响你是否能看到它。
HydraFusion 会使用哪些底层模型？
GitHub 表示它会在多家供应商的模型之间进行选择，但没有公布每个请求固定使用的模型列表，因此不要假定每项任务都会由某个指定模型处理。
HydraFusion 是否总能胜过 Claude Opus 5？
不能：GitHub 报告其在 TerminalBench 2.1 上领先，在 CheckpointBench 上基本持平，而在 DeepSWE 上落后 1.5 点。
HydraFusion 要额外收费吗？
用量按底层模型的标准 token 费率计费，而且一条路由可能调用多个模型；GitHub 在公告中没有给出单独的 HydraFusion 美元价格。
HydraFusion 可以在 VS Code 中使用吗？
发布材料记录的是通过 Copilot CLI 使用该预览功能；任何更广泛的可用性，都应以当前 GitHub 文档为准。
让 HydraFusion 修改仓库安全吗？
GitHub 提到了具备权限感知能力的求解模型、隔离的审查模型、经过验证的路由、有边界的执行，以及无效或取消工作流不应用补丁等机制；但在合并前，仍应审阅 diff 并运行测试。