GitHub 推出 HydraFusion：多模型协同新范式
Project HydraFusion: Frontier quality via multi-model orchestration
GitHub 发布了 Project HydraFusion 研究预览，通过运行时编排技术实现前沿级智能。它不再依赖单一模型，而是根据任务动态选择 Single、Cascade 或 Critique 三种执行模式，在本地、云端及复合模型间自动路由。在 TerminalBench 2.1 等基准测试中，HydraFusion 相比 Claude Opus 5 将成本降低了 67%，同时任务质量提升了 4.9 个百分点。开发者只需选择 HydraFusion，系统后台便会自动平衡性能、成本与延迟，将复杂的模型调度转化为无缝的编码体验。
我们相信，编码智能体的下一次真正飞跃，将来自将前沿智能与运行时编排相结合。
HN 评论区
32- hdz
如果你是 copilot cli 的用户（我们确实存在），你就知道自动模式还有很多不尽如人意的地方。它只在会话开始时或压缩后才切换模型。现在大多数开发任务都重度依赖子代理，但子代理之间并没有模型路由机制。
我注意到对比中完全没有提及算力消耗水平。5.6 Luna Max 表现真的很好，而且非常便宜。一个 5.6 Sol 高级编排器搭配 5.6 Luna Max，成本低廉，拥有前沿水平的性能，而且比单独使用 Sol 更快。这可以通过简单的代理指令来实现。期待运行我自己的 HydraFusion 基准测试，看看它的表现如何。看来，除非任务不需要调用工具，否则单模型包揽一切的时代已经过去了。
- gopalv
> 一个模型起草结果，另一个来自不同模型家族的独立只读批评者对其进行审查
这里的关键是多模型供应商。级联模式不需要这样，但批评模式需要。
去年 11 月，我的团队写了一篇论文（《Team of Rivals》），探讨了使用 OpenAI 模型来批评 Anthropic 模型的输出，与在同一供应商处运行自我审查代理循环之间的区别。
消融实验 [1] 证明，单独使用任何一家公司的模型都不如同时使用两家公司的效果好。
这篇论文是对“你们公司有什么是 Anthropic 做不到的？”这一问题的普遍回应，但更多的是展示如何利用评估得分只有 60% 左右的模型，构建出 90% 以上优秀程度的系统（Gas Town 的帖子也解开了我们关于“这是商业机密”的论文争议）。
- Roark66
我对他们的结果存疑。如果在模型和测试框架之间加一层额外的软件，要超越前沿模型在单项基准测试中的表现并不难。
这也是为什么对比那些权重公开的“裸模型”和那些供应商可以在后台为所欲为的前沿模型是不公平的。
具体来说，要让 Qwen3.8-27B 在 SWEbench Pro 和 Terminal Bench 2.0 上多拿 10% 的分数，只需要一个具备以下基本功能的代理：
- 微调几个解码设置，比如稍微提高温度
- 检测到模型卡住时，告诉它“继续”
- 检测到响应被截断、只包含推理过程的空响应、格式未通过验证等情况时，告诉模型“再试一次”
仅此而已。就能多拿 10%。我承认这是在部分任务子集上，但结果就是结果，哪怕只是子集。
- zatkin
这绝对是我今年见过的最烂的项目名字。
- guybedo
我在工作流的规划、方案设计和实施步骤中，一直使用对抗性批评和审查机制。
它非常有效，能帮我发现大量设计缺陷、实现疏漏等等……以至于我在想，人们如果不采用这类流程，是怎么用代理构建复杂或大型项目的。好吧，其实是我自己因为得不到好的结果，才不得不想办法造了这个东西。
我打算开源整个项目，不过还需要一些清理工作。这里有一个基础落地页 https://kodfactory.com，如果有人想在它发布到 GitHub 时收到通知，可以去看看。是的，我知道，这世界真的不需要另一个软件工厂了 :-)