用 GitHub Copilot CLI 的 HydraFusion 做多模型编排：单模型、级联、互评三种模式怎么选

HydraFusion 只走 Copilot CLI 的实验入口，网页版和编辑器插件里没有。先在 CLI 里更新到最新版：

# 在 GitHub Copilot CLI 会话里执行
/update          # 安装最新版本
/experimental    # 查看实验特性开关状态
/experimental on # 打开实验特性
/model           # 在模型列表里选 HydraFusion (Research Preview)

GitHub 给的建议很具体：先用体量足够、边界清晰、能用一段话描述完整的编码任务来试。任务太小，三种模式都会退化成 Single，你测不出差别；任务太模糊，你又分不清是路由不好还是需求没说清。

一个可用的五任务组合（每个都有客观验收标准）：

1. 让一个原本失败的测试通过（有明确 pass/fail）
2. 实现一个小功能（有验收描述）
3. 升级一个依赖并修掉随之而来的编译错误
4. 按文档要求做一次小范围重构（不改变对外行为）
5. 修一个有可复现步骤的 Bug

HydraFusion 不是一口价，它按实际调用到的模型、按各自标准单价计费。级联和互评都可能有多条计费腿（起草、评审、修订、升级、重试、回退）。所以账单不能只看最终那个模型：

路由本身是看不见的，但你可以从结果反推：

结果特征                                大概率走了哪种模式
------------------------------------------------------------
一次成型、无额外调用、延迟低            Single
先有一段「看起来能跑」的草稿，           Cascade
  之后质量突然提升、总成本仍偏低
输出里能看到明显的「先评后改」痕迹、     Critique
  修订只有一轮、耗时明显更长

HydraFusion 背后有五条运行原则值得抄：完整记账、有界执行（每条腿有超时与取消）、隔离评审、失败不打补丁（校验失败就一个补丁都不落）、执行前校验路由（模型绑定与可用性先确认）。把这套抽象出来，骨架是这样：

def solve(task, budget):
    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

GitHub 公布的离线受控评测（对比 Claude Opus 5 单模型、中等推理强度、调优后的配置）大致是这样：