一段代码到底该交给谁写，正在变成一个很别扭的问题。

简单的活，用最强模型，贵。复杂的活，用便宜模型，返工更贵。再找一个模型审一遍，看起来稳了，可它也会消耗时间和 Token，而且两个模型一起自信地犯错时，场面并不会更好看。

GitHub 9 月 4 日放出的 Project HydraFusion，没有再端出一个新模型。它把重心放在了另一个位置，运行时决定这一次任务要走单模型、先便宜后升级，还是跨模型复核再修改。GitHub 在 TerminalBench 2.1 的离线评测里给出的数字很醒目，相比 Claude Opus 5，验证任务质量高 4.9 个百分点，估算成本低 67%。

我读到这里的第一反应不是「又一个路由器」。

真正有价值的地方在于，它把多模型协作从一套 Prompt 手艺，往一个可计费、可取消、可审计、不会把半截补丁写进仓库的运行时系统推了一步。对做 AI 平台的人，这比排行榜上的一个分数更值得看。

别再把模型选择当成下拉框

很多团队已经在手工做 HydraFusion 的事了。

写一个 Spring 服务的接口，顺手找速度快的模型。排一个偶发的线上故障，换成推理强一点的。准备合并前，把 diff 丢给另一个模型做 Review。模型不行就重试，或者人再接手。这个流程不奇怪，甚至相当合理。问题是它全靠人记住，也全靠人承担漏掉边界条件的后果。

模型选择下拉框解决的是入口问题，没解决执行问题。它默认相信一次选择能覆盖一个完整任务。可一个真实的 Agent 任务根本不是一次回答，它会读仓库、找文件、改代码、跑测试、根据报错再改。任务进行到一半时，难点、上下文和失败成本都会变。

你如果做过 LangGraph 或自己搭过 Agent loop，应该很熟悉这种变化。开始时只需要检索几个类，后面碰到跨模块事务、异步重试、测试夹具，难度一下子就上来了。让一个模型从头扛到尾，当然最容易实现。但它把「何时需要更强能力」这个判断，粗暴地压成了调用前的一次选择。

HydraFusion 的判断是，模型不是唯一可切换的变量，工作流也是。

这两者看似只差一句话，工程含义差得很远。前者是路由问题，后者是编排问题。路由关心把请求发给哪个模型。编排还要关心这次调用是否需要第二个视角、第二次执行能否复用工作区、失败后能不能升级、每一段的钱由谁记账、取消时留下什么状态。

没有这些，所谓多模型协作很容易退化成一次昂贵的群聊。

三条路径，其实是三种风险处理方式

GitHub 目前给 HydraFusion 配了三种执行模式，Single、Cascade 和 Critique。名字很朴素，背后对应的却是三种完全不同的风险判断。

Single 最直接，选定一个模型完成任务。它适合难度明确、验证便宜、失败影响有限的工作。比如补齐一个单元测试，修一处格式化逻辑，或者把明确的 DTO 映射补完。这里如果强行加审查和升级，收益通常抵不过等待和成本。

很多人会把 Single 叫成简单模式。其实吧，它更像一种克制。运行时先承认，不是每个任务都值得叫来一支专家组。Agent 系统最常见的浪费，往往不是模型不够强，而是把复杂流程用在了根本不需要它的地方。

Cascade 更接近人类工程师的直觉。先让成本更低的模型给出候选结果，再通过质量门决定是否接收，或者升级给更强的模型。这里最关键的名词不是「便宜模型」，而是质量门。

没有质量门，Cascade 只是失败以后再问一次更贵的模型。真正的门应该是可执行的。例如测试是否全部通过，静态检查有没有新增告警，改动范围是否越过允许目录，接口契约是否被破坏，或者 Patch 能否干净地应用在当前工作区。它们不必完美，但必须比「看起来不错」更可验证。

我自己的感受是，做业务 Agent 时最容易偷懒的地方就在这儿。团队会花很多时间比较两个模型的 benchmark，却很少认真设计接受条件。结果是小模型写得对不对靠感觉，大模型接管得合不合理也靠感觉，成本报表最后只剩一条总数。那条总数没有解释力。

Critique 则是另一种思路。一个模型产出，来自不同模型家族的只读 Reviewer 审查，原作者再修一次。GitHub 特意把 Reviewer 放进无工具、隔离的上下文中，让它不能直接改仓库。这个设计看着保守，我反而觉得很对。

Review 的职责是指出问题，不是抢走写入权限。

如果 Reviewer 也能随手改文件，两个角色的边界会迅速融化。你很难回答一个基础问题，到底是谁引入了那个改动。更麻烦的是，Reviewer 为了验证自己的猜测又去调用工具，它也会产生新的副作用和新的上下文噪声。最后系统看起来有了双重保险，实际上多了一条难以审计的写入链。

跨模型审查也不是天然更可靠。两个模型可能共享训练盲区，也可能被同一个模糊需求带偏。它适合用在「第二种观察角度有实际价值」的任务上，比如并发边界、错误处理、权限绕过和修改影响面。拿它去审一个改变量名的 PR，只是在认真地浪费预算。

67% 这个数字，先别急着截图转发

GitHub 的结果来自三个 agentic coding benchmark 的离线评测。TerminalBench 2.1 那一项，HydraFusion 的验证任务质量比 Claude Opus 5 高 4.9 个百分点，估算工作流成本低 67%。这个结果当然值得关注，但它不等于你的仓库也会省 67%。

这里有三个边界，不能省略。

第一，数字是 offline evaluation，任务、环境、工具链和判分方式都是受控的。生产仓库里有私有依赖、脏工作区、慢测试、隐含约定，还有人类随时插进来的修改。运行时的收益会被这些不确定性重新分配。

第二，GitHub 写的是 estimated cost。它已经在统计草稿、批评、修订、升级、重试和 fallback 的调用，但这仍是模型 Token 维度的估算。你的真实成本还包括 CI 排队、沙箱、上下文构建、失败重跑、人类 Review 和一次错误发布之后的修复。Token 少，不必然代表总成本少。

第三，基线是被评测的 Claude Opus 5，不是所有模型，也不是所有任务。评价一个编排器，最怕把单一基准的胜利说成普遍规律。这里能确定的是 GitHub 在它选定的离线场景里观察到了不错的质量和成本组合。至于它能否迁移到企业 Java 单体、微服务仓库或内部工具，得看同样严格的验证数据。

这话听着有点扫兴，但它恰好指向了 HydraFusion 最值得学习的部分。

不是那 67%。是它把优化目标明摆着放在质量、成本、延迟三者之间，而不是假装三者能同时达到最优。

编排器最难的不是挑模型，是收住执行

一个多模型系统一旦开始工作，最容易失控的不是回答质量，而是执行链条。

GitHub 在文章里列出了五个运行原则，完整记账、受限执行、隔离审查、失败安全应用和路由预验证。它们不像炫目的架构图，更像生产事故之后才会写进规范的东西。

完整记账很好理解。一次任务不应该只记录最后那个模型用了多少 Token。草稿、审查、修订、升级、重试和 fallback 都是成本。把它们拆开，你才知道所谓节省来自哪里。是大部分任务停在了 Single，还是 Cascade 的质量门挡住了不必要的升级，抑或 Critique 减少了返工。

这个颗粒度也决定你能不能持续优化。假如一个 Agent 总是在 Review 后失败，问题可能不是 Reviewer 太弱，而是初稿模型拿到的上下文不够，或者质量门只检查了编译没有检查行为。只看总花费，你无法定位。

受限执行更重要。每一段都要有 timeout 和取消语义。因为 Agent 的任务不是纯推理，它们常常握着 shell、文件和网络权限。一个已经被用户取消的 Cascade，如果后台还在继续升级和改文件，那不是效率问题，是权限问题。

我们做平台时，经常把取消设计成 UI 上一个好看的按钮。可运行时真正需要的是状态机。哪个 leg 在跑，哪个 leg 已经写入临时工作区，取消后是否回收子进程，是否禁止后续 patch apply，最终向用户呈现成功、部分完成还是已回滚。这个事儿不做细，模型越能干，坑越大。

失败安全应用听起来也很普通。任务取消或验证失败时，不应用补丁。可很多 Agent demo 恰恰把这一步跳过去了，先让模型直接写，再用一句「建议检查」把责任丢回给用户。

这不是 Agent，最多算一个会动的编辑器宏。

更稳妥的做法是把执行和提交分开。Solver 可以在受控工作区里改，测试和 Review 都围绕这个候选变更跑。只有所有硬条件都满足，系统才生成一个权限感知的变更集，让用户或策略引擎决定是否落库、发 PR、触发部署。对 Spring 项目而言，这和数据库事务的想法并不陌生，先在边界内积累变更，满足约束再提交。把它迁到 Agent 世界，提交点就是最后的 Patch apply 或 Git commit。

一个能落地的最小版本

HydraFusion 是 GitHub Copilot CLI 里的 research preview，入口在 /experimental，它还不是一个可以原样搬回公司内网的开源框架。但文章给了一个很实际的起点。

如果你在搭自己的代码 Agent，我建议别从「接入十个模型」开始。先做一个只有三条路径的最小编排器。

第一条路径，低风险任务走 Single。要求是任务有明确验收，比如单测通过、格式化无改动、目标文件在白名单内。这里追求的是快，不是表演复杂度。

第二条路径，验证失败或风险评分升高时走 Cascade。注意升级条件不要只依赖模型自己说「我不确定」。可以把仓库规模、改动文件数、是否触及鉴权、是否改数据库迁移、测试时长和历史失败率都放进策略。规则开始时完全可以是手写的，别急着训练一个神秘 Router。

第三条路径，只对高价值改动走 Critique。Reviewer 使用只读上下文，输出结构化问题列表，例如正确性、回归风险、权限影响、未覆盖的测试。它不能写文件，不能执行有副作用的工具。Solver 根据问题列表只允许修一轮，然后重新走验证。

这三条路径之外，还要补四个不怎么性感却不能缺的部件。

一是事件日志。一次任务至少要有 task id、工作流、每个 leg 的模型、开始结束时间、Token、工具调用、验证结果、取消原因和最终变更摘要。没有它，出了问题只能翻聊天记录，基本等于没日志。

二是预算。预算不只是一笔 Token 上限，也该包括最大升级次数、最大并发 Agent 数、单任务 wall-clock 上限和允许访问的工具集合。预算是编排器的刹车，不是财务系统月底的一张账单。

三是验证器分层。编译通过只是最低层。再往上可以有单测、集成测试、契约测试、安全扫描和人工审批。不同任务用不同门，别把一个慢得离谱的全量 CI 塞给每一次改 README 的请求。

四是可回滚的交付物。不要只把自然语言回复留给用户。输出应当包括 diff、验证摘要、已知风险和一个明确的应用动作。这样人接手时能看到系统做了什么，也能拒绝它做的事。

你会发现，做完这些之后，多模型选择反而不再是最难的一层。模型供应商可以替换，策略可以迭代，但运行边界一开始就应该是硬的。

多模型不是多叫几个人干活

有人会说，单模型能力继续涨上去，多模型编排迟早会变成过渡方案。这种看法有合理的一面。模型足够强时，Single 的覆盖面确实会变大，系统也会更简单。

但不是说编排会消失，而是它的重心会移动。

今天我们编排的是能力差异。谁适合写，谁适合审，谁适合在失败后接管。明天更可能编排的是执行责任。谁能读生产配置，谁能调用浏览器，谁只能看 diff，谁的改动必须经过人批准。模型再强，也不能替你决定一个 Agent 是否有资格修改支付回调或删除一张表。

这才是我看 HydraFusion 时最在意的地方。它没有把多模型讲成魔法，而是把复杂性藏在一个可观察的运行时里。对用户而言，是选一次模型。对平台而言，是在背后明确地做选择、计算代价、设置边界、验证结果，并在失败时收手。

能收手，才配得上自动化。

该从哪里开始试

如果你已经在用 GitHub Copilot CLI，可以在 /experimental 查看 HydraFusion。它按所调用模型的标准 Token 费率计费，适合拿一个有测试覆盖的小仓库做体验。别一上来就交给它迁移核心服务，更别把 research preview 当成生产 SLA。

如果你在自建 Agent 平台，先挑十到二十个重复出现的代码任务，给每个任务定义验收方式，再记录 Single、Cascade、Critique 的完成率、成本、耗时和人工接管率。两周后再判断有没有必要增加模型和路径。

一开始不需要一头九头蛇。

你只需要一条会在该停的时候停下来的执行链。

参考资料