过去使用Coding Agent时，我们通常先选择一个模型，然后让它从任务分析一直执行到代码完成。 但这种方式存在一个明显问题： 修改一个变量和重构整个项目，使用的可能是同一个旗舰模型。

简单任务因此花费了不必要的Token；复杂任务又可能因为单个模型判断错误，需要从头返工。 2026年9月4日，GitHub发布Project HydraFusion研究预览，尝试改变这种工作方式。 它不再要求一个模型从头完成全部任务，而是在运行过程中选择不同模型和执行流程：

• 简单任务由一个合适的模型直接完成；
• 中等任务先交给低成本模型，不合格再升级；
• 复杂任务由一个模型生成，另一个模型独立审查。 GitHub公布的离线评测显示，在TerminalBench 2.1上，HydraFusion相较Claude Opus 5基线，验证任务质量提高4.9个百分点，估算成本降低67%。 这背后的真正变化不是“又发布了一个模型”，而是： Coding Agent的竞争正在从模型能力，转向模型路由和工作流编排。

一、HydraFusion并不是一个新模型

虽然HydraFusion可以像普通模型一样在GitHub Copilot CLI中选择，但它本质上是一个运行时编排系统。 它会分析当前任务，然后决定：

• 使用哪个模型；
• 是否需要多个模型；
• 谁负责生成；
• 谁负责审查；
• 是否需要升级到更强模型；
• 在什么阶段停止继续调用。

传统调用方式是：

Task
  ↓
Fixed model
  ↓
Final result

HydraFusion的调用方式更接近：

Task
  ↓
Task analysis and routing
  ├── Single model completes directly
  ├── Low-cost model generates → Quality check → Upgrade to stronger model
  └── Model A generates → Model B reviews → Model A revises

用户看到的是一个入口，背后执行的可能是一整套模型工作流。

二、HydraFusion的三种工作模式

GitHub目前公布了三种执行模式：Single、Cascade和Critique。

1. Single：单模型完成

Single模式会选择一个适合当前任务的模型，让它独立完成工作。 适合：

• 修改变量名；
• 补充注释；
• 调整代码格式；
• 生成简单测试；
• 修复明确的小错误；
• 修改单个配置项。

执行流程：

Task
  ↓
Select suitable model
  ↓
Generate result

它的核心并不是使用最便宜的模型，而是避免对简单任务启动不必要的多模型协作。

2. Cascade：低成本模型先做，不合格再升级

Cascade模式会先让成本较低的模型尝试完成任务。 如果结果通过质量检查，就直接返回；如果不通过，再升级给更强的模型。

执行流程：

Task
  ↓
Low-cost model generates
  ↓
Quality check
  ├── Pass → Return result
  └── Fail → Stronger model reprocesses

适合：

• 常规代码生成；
• API封装；
• 数据格式转换；
• 测试用例补充；
• 中等规模重构；
• 错误原因分析。

这种模式能够降低成本的前提是： 大部分任务可以被第一层模型正确完成。

假设低成本模型可以处理80%的请求，只有20%的任务需要升级，那么旗舰模型不再承担全部流量。

3. Critique：一个模型写，另一个模型审

Critique模式先让一个模型生成方案或代码，再由另一个模型进行只读审查。 审查模型发现问题后，原模型根据反馈修改一次。

执行流程：

Task
  ↓
Model A generates
  ↓
Model B reviews independently
  ↓
Model A revises based on feedback
  ↓
Final result

适合：

• 涉及多个文件的修改；
• 数据库迁移；
• 权限和鉴权代码；
• 并发逻辑；
• 计费代码；
• 核心业务重构；
• 对正确性要求较高的任务。

如果生成模型和审查模型来自不同模型家族，通常还能减少两个模型犯下完全相同错误的概率。 不过这不意味着模型越多越好。 每增加一个模型，就会增加一次或多次：

• 输入Token；
• 输出Token；
• 网络延迟；
• API失败概率；
• 上下文同步成本；
• 调试难度。 因此，Critique应该用于审查价值高于额外成本的任务。

三、为什么多调用模型反而可能更便宜？

直觉上，多个模型共同工作应该比单模型更贵。 但如果原来的方案是让最强模型处理所有请求，多模型编排反而可能降低总成本。

假设有1000个编程任务：

任务类型	数量	推荐处理方式
简单修改	600	低成本模型
常规开发	300	均衡模型
复杂重构	100	旗舰模型或多模型审查

如果全部交给旗舰模型，1000个任务都会按照最高档模型计费。 使用分层路由后，只有约10%的复杂任务需要直接使用旗舰模型，其余请求可以使用更低成本的模型。

成本下降主要来自三个地方：

1. 简单任务不再使用旗舰模型；
2. 低成本模型成功后不再升级；
3. 只有高价值任务才增加独立审查。

所以，多模型编排的核心并不是“同时调用更多模型”，而是： 把昂贵推理集中到真正需要的任务上。

四、GitHub公布的67%成本下降应该怎样理解？

根据GitHub官方文章，在TerminalBench 2.1离线评测中，HydraFusion相较Claude Opus 5基线：

• 验证任务质量提高4.9个百分点；
• 估算工作流成本降低67%。

这组结果很有吸引力，但不能直接理解为所有项目都能节省67%。 至少需要注意四点。

1. 这是GitHub自己的离线评测 目前公开结果来自GitHub，并不是独立第三方测试。

2. 结果针对特定基准 TerminalBench主要评估终端环境中的Agent任务，并不能代表所有代码生成和企业业务场景。

3. 成本取决于任务分布 如果项目中的任务普遍非常复杂，大部分请求最终都会升级到旗舰模型，节省比例就会下降。

4. 审查本身也会消耗Token Critique模式至少需要生成、审查和修改三个阶段。对于非常简单的任务，审查成本可能高于它带来的收益。

因此，更值得参考的不是“67%”这个单一数字，而是HydraFusion使用的分层方法。

五、用Python实现简化版Cascade

下面使用兼容OpenAI SDK的接口，实现一个简化版Cascade流程：

1. 低成本模型先生成；
2. 质量模型检查结果；
3. 不合格时升级处理。

模型名称可以通过环境变量设置，请替换为控制台显示的实际模型ID。

import json
import os

from openai import OpenAI

client = OpenAI(
    api_key=os.environ["AI_API_KEY"],
    base_url="https://genvis.xyz/v1",
    timeout=90,
)

DRAFT_MODEL = os.getenv(
    "DRAFT_MODEL",
    "gpt-5.6-luna",
)

REVIEW_MODEL = os.getenv(
    "REVIEW_MODEL",
    "gpt-5.6-sol",
)


def call_model(
    model: str,
    messages: list[dict],
) -> str:
    response = client.chat.completions.create(
        model=model,
        messages=messages,
    )

    return response.choices[0].message.content or ""


def review_result(
    task: str,
    candidate: str,
) -> dict:
    review_prompt = f"""
You are a code quality checker.

Determine whether the candidate result completes the task, and return only JSON:

{{
  "accepted": true or false,
  "reason": "reason for the judgment",
  "required_changes": ["changes that need to be made"]
}}

Task:
{task}

Candidate result:
{candidate}
"""

    raw_result = call_model(
        REVIEW_MODEL,
        [
            {
                "role": "user",
                "content": review_prompt,
            }
        ],
    )

    return json.loads(raw_result)


def run_cascade(task: str) -> dict:
    draft = call_model(
        DRAFT_MODEL,
        [
            {
                "role": "system",
                "content": (
                    "You are a software engineer. "
                    "Complete the task directly and explain the key changes."
                ),
            },
            {
                "role": "user",
                "content": task,
            },
        ],
    )

    review = review_result(task, draft)

    if review["accepted"]:
        return {
            "model": DRAFT_MODEL,
            "escalated": False,
            "result": draft,
            "review": review,
        }

    final_prompt = f"""
Please complete the task again.

Task:
{task}

Initial draft from the low-cost model:
{draft}

Review comments:
{json.dumps(review, ensure_ascii=False)}

Fix the issues pointed out in the review and return the final result.
"""

    final_result = call_model(
        REVIEW_MODEL,
        [
            {
                "role": "user",
                "content": final_prompt,
            }
        ],
    )

    return {
        "model": REVIEW_MODEL,
        "escalated": True,
        "result": final_result,
        "review": review,
    }


result = run_cascade(
    "Add parameter validation and exception handling for a Python order endpoint."
)

print(f"Final model: {result['model']}")
print(f"Escalated: {result['escalated']}")
print(result["result"])

这个示例展示了基本结构，但真实生产环境还需要解决一个问题： 由模型判断另一个模型是否合格，本身也可能判断错误。

六、质量门不能只依赖另一个模型

模型审查适合检查：

• 逻辑是否完整；
• 是否遗漏需求；
• 异常处理是否充分；
• 代码是否容易维护；
• 是否存在明显安全风险。

但可以程序化验证的问题，应优先交给确定性工具。 例如：

检查项目	推荐工具
代码能否编译	编译器
测试是否通过	单元测试
格式是否正确	Formatter
类型是否匹配	类型检查器
是否存在已知漏洞	安全扫描器
是否泄露密钥	Secret Scanner
SQL是否兼容	多数据库测试
API响应是否符合结构	Schema校验

更可靠的质量门应该是：

模型审查 + 编译 + 测试 + 静态分析 + 安全检查

而不是让多个模型互相评价后，默认最终结果一定正确。

七、实现一个更实用的质量门

下面以Python项目为例，使用测试结果决定是否升级。

import subprocess


def run_tests() -> tuple[bool, str]:
    process = subprocess.run(
        ["python", "-m", "pytest", "-q"],
        capture_output=True,
        text=True,
        timeout=120,
        check=False,
    )

    output = process.stdout + process.stderr
    return process.returncode == 0, output

完整流程可以变成：

Low-cost model generates changes
       ↓
Apply to isolated workspace
       ↓
Run tests and static checks
       ↓
   Passed?
   ├── Yes → Return result
   └── No → Hand errors to stronger model to fix

这种方式比单纯询问模型“你觉得代码对不对”更可靠。

八、Critique模式为什么强调“独立审查”？

如果审查模型可以直接修改文件，它可能在审查过程中改变问题现场。 因此，审查阶段最好使用只读权限：

允许：

• 读取文件
• 查看差异
• 读取测试输出
• 分析日志

禁止：

• 直接修改文件
• 执行高风险命令
• 连接生产环境
• 提交代码
• 删除数据

只读审查还有一个好处：可以清楚区分不同模型的责任。

• 生成模型：负责提出和实现修改
• 审查模型：负责发现问题
• 验证工具：负责提供确定性结果
• 最终执行者：负责修正并提交

如果所有模型都可以随意修改同一个工作区，很难判断某个错误是谁引入的。

九、如何判断一个任务应该使用哪种模式？

可以先使用简单规则。

Single模式 满足大部分条件时使用：

• 只修改一个文件；
• 修改内容少；
• 不涉及权限和资金；
• 不改变公共接口；
• 有完整自动化测试；
• 失败后容易回滚。

Cascade模式 满足以下情况时使用：

• 任务难度中等；
• 低成本模型可能完成；
• 有明确测试可以判断质量；
• 失败后可以安全升级；
• 对延迟没有极端要求。

Critique模式 满足以下情况时使用：

• 涉及核心业务；
• 修改多个模块；
• 影响数据库或计费；
• 涉及权限和安全；
• 测试覆盖不足；
• 错误修复成本高；
• 需要不同模型提供第二意见。

十、多模型编排最容易踩的坑

1. 所有任务都启动多个模型 这会让成本和延迟快速增加。 应该先判断任务是否真的需要协作。

2. 将完整上下文重复发送给每个模型 如果每个模型都读取完整仓库、历史日志和工具输出，Token成本可能比单模型更高。 可以分别提供：

• 生成模型所需的实现上下文；
• 审查模型所需的代码差异；
• 升级模型所需的失败信息。

3. 用同一个模型扮演所有角色 同一个模型生成、审查再修改，很容易保留相同的盲点。 复杂任务可以考虑跨模型家族审查。

4. 没有记录实际调用路径 至少应该记录：

• task_id
• route_type
• draft_model
• review_model
• final_model
• input_tokens
• output_tokens
• latency
• test_result
• escalated

否则无法判断多模型方案到底有没有节省成本。

5. 只统计每次调用价格 更合理的指标是：

成功完成任务的总成本 = 所有模型调用成本 + 失败重试成本 + 人工修正成本

某个模型单次价格更低，但如果失败率很高，最终成本可能反而更高。

十一、多模型路由需要哪些基础能力？

一个可用于生产环境的模型编排层，通常需要：

• 统一的模型调用接口；
• 模型能力标签；
• 价格和Token统计；
• 请求超时控制；
• 限流与并发控制；
• 故障自动切换；
• 上下文裁剪；
• Prompt缓存；
• 质量门；
• 调用日志；
• 预算上限；
• 权限隔离；
• 人工确认。

模型越多，接口、错误格式和计费方式就越复杂。 因此，多模型系统的重点不是简单维护一个模型名称列表，而是建立统一、可观测的调用层。

十二、上线前检查清单

准备实现类似HydraFusion的路由时，可以检查：

• 是否区分简单、常规和复杂任务；
• 是否为每类任务配置成本上限；
• 是否设置低成本模型的升级条件；
• 是否使用自动化测试作为质量门；
• 审查模型是否保持只读；
• 是否记录每个阶段的模型和Token；
• 是否限制最大模型调用次数；
• 是否避免向多个模型重复发送无关上下文；
• 是否配置请求超时和故障回退；
• 是否对不可逆操作进行人工确认；
• 是否比较每个成功任务的实际成本；
• 是否使用真实项目任务进行灰度评测。

常见问题

HydraFusion是一个新的大模型吗？ 不是。它是GitHub Copilot中的多模型运行时编排系统，会根据任务选择Single、Cascade或Critique等工作流。

成本一定能降低67%吗？ 不能保证。67%来自GitHub在TerminalBench 2.1上的离线估算结果，实际效果取决于任务难度、模型价格、升级比例和上下文长度。

模型越多，结果一定越好吗？ 不一定。简单任务使用多个模型可能只会增加成本和延迟。多模型最适合高价值、复杂或者需要独立审查的任务。

为什么不直接一直使用最强模型？ 因为大量开发任务并不需要旗舰能力。将简单请求路由给低成本模型，可以把高价推理资源留给真正困难的任务。

模型审查能替代测试吗？ 不能。模型可以发现需求、逻辑和设计问题，但编译、测试、类型检查和安全扫描仍应由确定性工具完成。

总结

HydraFusion值得关注的地方，不是它又给GitHub Copilot增加了一个名称。 真正重要的是，它把Coding Agent的工作方式从：

选择一个模型 → 从头做到尾

变成了：

识别任务难度 → 选择执行模式 → 低成本模型优先 → 必要时升级 → 独立模型审查 → 确定性工具验证

下一阶段的AI开发工具，竞争重点可能不再只是“接入了多少个模型”，而是： 能不能在正确的任务上，以正确的成本，调用正确的模型组合。

参考资料

• GitHub：Project HydraFusion官方介绍
• GitHub：第三方Coding Agent说明
• TerminalBench官方网站