发布事实：一个被简化传播的公告
HydraFusion 的传播过程本身就值得记录。9 月 1 日，GitHub 在社区论坛的 Copilot 公告板块开了一个只有一行「Coming soon」的占位帖；9 月 4 日，工程博客与基准数据发布，占位帖随即替换为完整公告与 FAQ。此后大量二创报道把它概括成「达到或超越 Claude Opus 5，成本降 36–67%」——这句话对了一半：成本确实在三套基准上全部下降，但「质量超越」只在其中一套成立。
几个容易被忽略的发布细节，恰恰是评估这个产品的关键：
- 入口与计费：功能通过 Copilot CLI 的
/experimental开启（需先/update升级 CLI，再在/model中选择 HydraFusion 研究预览），对所有 Copilot 订阅档位开放；GitHub FAQ 明确说明没有单独的 HydraFusion 费用——你为它跑的每个模型环节按标准 token 单价付费，一次对话的成本是各环节之和。 - 覆盖面：截至 9 月中旬，公告面只有 Copilot CLI。VS Code 与 Copilot 应用被描述为「目标 9 月快速跟进」，但 9 月 9 日发布的 VS Code 1.137 并未包含该功能；9 月 11 日 VS Code 主干合并了一个默认关闭的实验设置
chat.copilot.hydraFusion.enabled，尚无随版本发布的明确时间点。 - 任务形态：官方明确当前最适合单提示词编码任务，更长的多轮工作流仍在开发中，预览期行为可能变化。
Single / Cascade / Critique：三种执行模式拆解
HydraFusion 的核心抽象是把「一次任务」拆成可编排的执行计划。系统依据任务在推理、代码生成、调试、工具调用四个维度上的能力信号，选择预计能过质量门槛的最简工作流——不必要的模型调用一概不花。三种模式按成本从低到高排列：
| 模式 | 执行流程 | 成本逻辑 | 适用场景 |
|---|---|---|---|
| Single | 单一模型直接完成任务，无额外评审环节 | 一次模型调用，最便宜 | 样板代码、简单补全 |
| Cascade | 低成本模型先起草，质量门评估：通过即交付，不通过则升级到更强模型重试 | 多数任务停在廉价档，只有未过门的任务付出升级成本 | 量大、难度分布不均的日常任务 |
| Critique | 一个模型起草，另一个跨家族模型在隔离的只读上下文中评审（无仓库写权限），起草模型按反馈修订一次 | 三个模型环节（起草、评审、修订），成本较高 | 高风险变更、需要独立复核的任务 |
两个设计细节体现了工程取舍。其一，Critique 模式中评审模型被结构性剥夺修改代码的能力——它只能读、只能评，改不改、怎么改仍由起草模型决定。这避免了「评审者越权改坏代码」的失控路径。其二，编排器跨供应商路由（Anthropic、OpenAI 等多家模型都在可选池内），意味着 GitHub 把自己定位在编排层而非单一模型分销商——模型在这里是可替换的输入。
用户不配置用哪种模式——系统替你选。这是 HydraFusion 与「模型选择器」类功能（Cursor、Windsurf 的模型下拉框）的本质区别：前者把质量与成本做成运行时决策，后者把这个决策留给了用户的直觉。
五条工程护栏：从演示到生产的距离
多模型编排不难做演示，难做生产。GitHub 公布的五条运行原则，恰好对应生产环境中最容易翻车的五类事故：
- 完整核算：起草、评审、修订、升级、重试、回退的每个环节都计入同一个成本总账，不存在散落在用量日志里的隐性调用。这直接回应了「一个任务被收三次钱」的计费透明问题。
- 有界执行：每个环节有明确的超时与取消行为，系统不会无感知地超预算运行——这针对的是 Agent 系统典型的循环失控。
- 隔离评审：评审环节运行在剥除工具的精简上下文中，评审模型无法改仓库、无法调用外部工具。
- 失效保护：工作流被取消或校验失败时，不应用任何部分补丁，仓库保持干净——防止「改了一半的代码」留在工作区。
- 路由前置校验：执行前验证模型绑定、回退行为与模型可用性，避免跑到一半才发现某个模型不可用。
这五条护栏合起来回答了一个此前行业悬而未决的问题：多模型编排要达到可用，工程开销到底在哪里——不在「会调用多个模型」，而在失败路径的每一条都有明确行为。
基准成绩单的正确读法
官方基准对照 Claude Opus 5（部分环节另设 GPT-5.6 Sol 基线），覆盖三套 Agentic 编码测试集，结果如下：
| 基准 | 考察内容 | 质量变化 | 估算成本变化 |
|---|---|---|---|
| TerminalBench 2.1 | 多步骤终端任务 | +4.9 个百分点 | −67% |
| DeepSWE | 仓库级软件工程任务 | −1.5 个百分点 | −36% |
| CheckpointBench（内部基准） | 来自真实 Copilot 会话的任务 | −0.1 个百分点 | −65% |
三点读法提示：
- 这是一份成本成绩单，不是能力成绩单。三套基准上成本全降，质量一升两微降。均值的构成方式解释了这种形态：Cascade 模式下多数请求由廉价模型承接，只有未过质量门的少数任务触发强模型，平均成本自然下移，而质量被门控锚定在「接近但不必然超过」基线的位置。
- 注意基准版本时效。HydraFusion 取胜的 TerminalBench 2.1，在其维护者自己后续发布的 3.0 与 4.0 版本之前已经是上一代——用它论证「前沿质量」存在版本滞后风险。
- 绝对分数未进摘要表。公告摘要只报差值，绝对分数藏在正文交互图表中；对比其他系统的公开数据时，需要回到原始图表核对绝对值与运行配置。
计费结构也值得二次阅读：一个 Cascade 任务实际计费一腿，一个 Critique 任务计费三腿。「成本降 67%」的对照系是「同任务单模型跑 Opus 5」；如果团队原本就在用廉价模型，实际节省会小于表中数字。
与 Auto 模式的分层关系：选模型 vs 选工作流
GitHub 在 2026 年早些时候已有模型路由功能 Auto：按请求为任务挑选单个最合适模型。其规模已经不小——6 月单月路由超过 90 亿次请求，过半付费订阅用户让平台自动选模型。产品负责人对两者关系的表述是「分层互补」：Auto 决定哪个模型处理任务，HydraFusion 决定整个工作流——是否需要起草、是否需要评审、是否需要升级路径。
这个分层叙事有其产业背景。微软 CEO 纳德拉把 HydraFusion 概括为「从模型选择到模型编排的转变」。Cursor 与 Windsurf 提供的模型下拉框，本质是把编排问题转译成了用户体验功能；HydraFusion 则主张「选模型」本身是错误的抽象——真正的问题是「哪些模型与工作流模式的组合，能在这类任务上以团队可承受的成本产出合格结果」。
对工程团队的实际意义在于预算模型的改变：按席位采购 Copilot 之后，token 消耗仍随任务难度分布浮动。编排层把「质量」变成了一个可在运行时调节的旋钮——愿意接受 1–2 个百分点的质量回撤，可以换回三到六成的 token 成本。
行业对照：编排层的竞争格局
HydraFusion 并非孤例，编排层正在成为平台型玩家的公共赛道：
- OpenAI Agents API（9 月 10 日公开 Beta）：把 Codex 的托管 harness、会话持久化与子智能体协调打包成 API，走「服务端托管编排」路线——编排逻辑在供应商云上。
- 开源框架路线：LangGraph 等框架把多模型路由留给开发者自建，灵活但工程开销自负。
- 模型聚合网关：OpenRouter 类产品做请求级路由，但按独立评测的口径，其「会评审会升级」的完整工作流编排能力仍是空白——多家评测都指出路由器市场普遍缺少 HydraFusion 这种「带质量门的编排」。
三条路线的分野在于编排逻辑放在哪一层：平台托管（OpenAI）、产品内置（GitHub）、用户自建（开源）。选择标准不是谁更先进，而是团队愿意把多少编排复杂度外包出去——外包越多，对成本结构与数据边界的控制力越依赖供应商的账单和审计能力。
局限与风险
- 基准时效与配置封闭：核心成绩来自 TerminalBench 2.1（已有更新的 3.0/4.0 版本）与未公开的内部基准 CheckpointBench，第三方难以独立复现；官方数据为离线评测，真实代码库上的结果会有差异。
- 预览期不确定性：研究预览行为可能变化，VS Code 与 Copilot 应用的落地时间点尚未官宣；多轮长任务支持仍在开发中，当前能力边界限于单提示词任务。
- 成本的对照系问题：「降 36–67%」全部对照 Opus 5 级别基线；团队若已默认使用中低档模型，实际节省幅度需按自身任务分布重新估算。
- 供应商依赖的转移而非消除：编排层由 GitHub 掌控，意味着路由策略、质量门标准与模型池构成不可审计——团队从「选哪个模型」的自由，换来了「接受系统编排」的信任成本。