从单模型到多模型编排：GitHub HydraFusion 如何让编程 Agent 降本 36%-67%

2026 年 9 月 4 日，GitHub 在 Copilot CLI 中悄然上线了 Project HydraFusion 的研究预览。它的思路很简单却极具冲击力：与其让编程 Agent 永远调用同一个"最强模型"，不如让系统根据任务难度动态编排多个模型------便宜的模型先上，搞不定再升级，必要时让两个模型互相"挑刺"。官方数据显示，这套机制在三项编码基准上取得了与 Claude Opus 5 相当甚至更好的成绩，而 token 成本下降了 36% 到 67%。

对于每天被 API 账单刺痛、又被单一模型能力上限卡住的开发者来说，这几乎是"既要又要"的答案。本文拆解 HydraFusion 的设计、用法与实践启示。

为什么需要"多模型路由"？

过去两年，编程智能体的主流用法是"一个模型打天下"：选最强旗舰，把所有任务都交给它。代价很直观：

问题	表现
成本失控	简单补全与复杂重构等价计费，旗舰模型 token 单价高
时延偏高	小任务也被迫走大模型，响应慢、占上下文
质量瓶颈	单一模型存在系统性盲区，无人复核

多模型编排要解决的核心矛盾是：任务难度分布极不均匀，而模型能力与价格并不线性。简单任务用便宜模型足够，只有少数高难度任务值得动用旗舰；再进一步，代码质量可以通过"写手+评审"的对抗机制逼近甚至超过单一旗舰模型。

HydraFusion 的三种执行模式

HydraFusion 的动态编排围绕三种模式展开，系统会结合任务特征自动选择：

Single（单模型）：一个模型直接执行，适合简单任务。
1. Cascade（级联）：便宜模型先试，只有质量不足时才升级到更强模型，形成"成本阶梯"。
1. Critique（评审） ：一个模型写代码，第二个模型审查，写手根据反馈修订------用对抗提升质量。
  架构上可以抽象为一个 Router + Executor 的闭环：Router 对任务打难度标签并选择模式；Executor 按模式调度模型；质量门控（Quality Gate）负责判断 Cascade 是否需要升级、Critique 是否需要进入下一轮修订。
用户请求
│
▼
┌─────────┐ 难度评估 ┌──────────────┐
│ Router │────────────▶│ 模式选择 │
└─────────┘ │ Single/Cascade │
│ /Critique │
└──────┬───────┘
▼
┌──────────────────┐
│ Model Executor │
│ cheap ── upgrade │
│ writer ── critic │
└──────────────────┘
│
▼
┌──────────────────┐
│ Quality Gate │
│ pass? 是→交付 │
└──────────────────┘
```
## 怎么用起来
HydraFusion 以研究预览形式集成在 Copilot CLI 中，所有订阅层级的用户都可通过实验命令启用：
bash 复制代码
```
# 启用 HydraFusion 实验特性
gh copilot config set experimental hydrafusion on

# 在对话中显式选择编排模式
/experimental hydrafusion --mode cascade
/experimental hydrafusion --mode critique
```

计费不需要额外订阅，直接按底层各模型的原有单价走。也就是说，成本节省来自"模型选择"而不是"折扣"------这正是路由策略的价值所在。

如果要在自己的 Agent 框架中复刻这套思想，核心逻辑并不复杂，可以抽象为：

python 复制代码

def solve(task: str, budget: Budget) -> Result:
    difficulty = router.estimate(task)
        if difficulty.low:
                return cheap_model.run(task)                      # Single
    draft = cheap_model.run(task)                         # Cascade 起点
        if not quality_gate.pass_check(draft, task):
                draft = flagship_model.run(task)                  # 升级
    if difficulty.high:                                   # Critique 兜底
            review = critic_model.review(draft, task)
                    draft = writer_model.revise(draft, review)
                        return draft
                        ```
关键在于 **Quality Gate 的定义**：级联模式要把"便宜模型答错"的代价控制在升级成本之下，评审模式则要避免无限循环------通常设定最大修订轮数。
## 数据说话

GitHub 公布的评估覆盖三项编程基准：

- **TerminalBench 2.1**：终端命令与 shell 任务
- - **DeepSWE**：长程软件工程任务
- - **CheckpointBench**：多步编码检查点
HydraFusion 在三项上均与 Claude Opus 5 成绩相当或更优，而估算 token 成本下降 36%-67%。这个结果的启示是：**"最强的单一模型"未必是"性价比最优的解"，路由和对抗评审可以在不牺牲质量的前提下显著压低账单**。

## 实践心得

1. **按任务难度分级，而非按模型强弱选型**：把成本预算当成一等公民参与调度，简单任务一律不碰旗舰模型。
2. **Critique 不是简单"再让 AI 检查一遍"**：它要求评审模型有独立判断，且写手要能针对反馈修订，否则只是增加 token 消耗。
3. **质量门控是编排的灵魂**：级联升级的触发条件、评审的终止条件都要显式设计，否则编排会退化成"随机抽卡"。
4. **可观测性要跟上**：多模型链路里"哪一步用了哪个模型、花了多少钱、质量是否达标"必须全程可追踪，否则无法持续调优路由策略。
从 LangGraph 1.2 强调的 durable execution，到 HydraFusion 把多模型路由做进官方 CLI，行业正在完成一次共识收敛：**Agent 的竞争不再只是模型的竞争，更是调度、编排与成本治理的竞争**。对开发者而言，尽早把"模型路由"纳入自己的工具链，可能是下一阶段最值得的投资。