HydraFusion：Agent 不再只选模型，而是选择执行路径

OpenAI 的 GPT-6 Astra 上线后，今天这期把视线转向另一条更贴近代码生产线的动态：GitHub 在 2026 年 9 月 4 日公开了 HydraFusion 研究预览。它不是一个新模型，而是把多个模型组织成运行时工作流：同一个请求，系统可以让一个模型直接完成，也可以先起草、再升级，或者交给独立模型批评后再修改。1

HydraFusion 当前有三种执行模式：Single 让一个模型直接解决；Cascade 先让更高效的模型起草，再由质量闸门决定是否升级到更强模型；Critique 让一个模型起草，由不同模型家族的独立、只读评审者检查，然后让起草模型修改一次。1

这个变化的重点不在于“模型越多越好”。重点在于：模型调用本身变成了可以被编排、计费和验证的循环。简单任务不必经过完整的多模型流水线；只有当质量、风险或难度值得额外调用时，系统才增加一次审查或升级。

GitHub 把 HydraFusion 描述成一个优化问题：系统根据推理、代码生成、调试和工具使用等能力信号，为请求选择预期最省事、同时能达到质量门槛的执行模式。这个判断发生在运行时，开发者只选择 HydraFusion，具体调用路径由系统决定。1

但只让路由器“会选”还不够。官方文章列出的五条运行原则，才是工程上更值得拿走的部分：每一段调用都要算清成本；每一段都要有超时和取消；评审模型放在隔离、无工具的环境里；取消或验证失败时不应用补丁；执行前先验证工作流定义、模型绑定、回退逻辑和模型可用性。1

这几条原则把“多 Agent 协作”从角色扮演拉回了控制面。一个评审 Agent 如果能改仓库，它就不再是独立评审。一个失败的升级如果留下半个补丁，系统就无法判断下一轮是在修复原任务，还是在收拾上一次残留。一个只统计首轮模型的成本报表，也会把批评、重试、回退和升级的账漏掉。

HydraFusion 的离线评估覆盖 TerminalBench 2.1、DeepSWE 和 CheckpointBench。GitHub 把所有模型放在相同的中等推理等级，并把起草、批评、修改、升级、重试和回退都算进完整工作流成本。1

这组数字首先说明，运行时编排有机会把质量和成本同时放进一个目标函数。它没有说明每个仓库、每种语言、每段长任务都会得到同样的结果。GitHub 也明确说，这些结果只适用于文章列出的基准版本、工作流配置、模型池、价格假设和评分条件。

第一，把路由策略当成产品逻辑测试。不要只测最终答案对不对，还要记录系统为什么走了直连、升级还是批评路径。否则一次质量提升可能只是多花了几轮调用，团队却不知道。

第二，把评审隔离和补丁闸门分开。评审可以读取结果、指出风险、给出修改建议，但写入仓库的动作仍由受权限控制的执行器完成。验证失败时，默认结果应该是“不应用变更”，而不是尽量留下一个看起来接近完成的版本。

第三，成本要按完整任务结算。一次 Agent 任务的真实成本，至少包括所有模型调用、评审、修改、重试、回退和等待。只看最后一次响应长度，会把最贵的失败路径隐藏起来。

HydraFusion 目前是研究预览。GitHub 建议先从范围清楚、可以在一次提示中交给 Copilot 的代码任务开始；更长的多轮会话和迭代任务，仍是后续要验证的方向。模型、工作流、可用性和产品行为都可能变化。1

所以，今天这条动态真正值得记住的，不是“HydraFusion 比某个模型便宜多少”。更重要的是，Agent 系统正在从“挑一个最强模型”，转向“为每个任务构造一条可审计的执行路径”。这条路径要能解释为什么升级，能证明评审真的独立，能在失败时不留下半成品，还要把整条循环的成本和质量一起带回来。