GitHub 公開「HydraFusion」：執行期編排多個 AI 模型，成本較 Opus 5 最多降低 67%

GitHub 公開了名為 Project HydraFusion 的研究預覽版，它會在執行期把來自多家供應商的 AI 模型組合起來，最後給出一份答案。它可以把草稿交給另一個系列的模型評閱，也可以在判斷難度太高時交棒給更強的模型，而這些判斷都在開發者看不見的地方自動完成。內部評測顯示，它在維持與 Claude Opus 5 相當品質的同時，把估算成本最多壓低了 67%。

挑的不是模型，而是解題的方式

GitHub Copilot 先前已經有 Auto model selection，會依照請求內容指派最合適的模型。HydraFusion 又往前推進一步，被挑選的對象不再是單一模型，而是整套工作流程本身。系統會為每一次請求建立執行計畫，並從跨供應商的模型池中指派起草者、評閱者，必要時再加上接手的更強模型。

使用者這邊不需要多做什麼。只要在模型清單中選取 HydraFusion，後續流程就會在內部依照品質、成本與延遲的平衡自動決定。GitHub 把它定位為更大規劃的一環，目標是在本機模型、雲端模型與複合模型之間做到自動的語意路由。

三種執行模式

HydraFusion 把流程選擇當成最佳化問題處理，依據推理、程式碼生成、除錯與工具操作等能力指標，挑出能達到品質門檻的最輕方案。目前提供三種模式。

Single 由一個模型直接解決任務。面對單純的請求，不多插入環節反而更快也更省。

Cascade 先讓效率較好的模型起草，再由品質關卡決定要接受結果，還是交棒給更強的模型。簡單的請求便宜處理，困難的情況仍保留退路。

Critique 會讓另一個系列的模型以唯讀方式擔任評閱者，之後由起草的模型修改一次。評閱模型在沒有工具的隔離環境中運作，因此評閱過程不會更動程式碼儲存庫。

流程中途產生的草稿在結果確定前不會顯示給使用者。理由是那些可能被捨棄的內容不該看起來像完成品，不過 GitHub 也承認，缺少進度資訊的等待確實是一種取捨，並把改善進度顯示列為後續課題。

基準測試：逼近 Opus 5，成本大幅壓縮

固定的路由方針在三項代理式程式設計基準上接受評測。對照基準是 Claude Opus 5 與 GPT-5.6 Sol，所有模型都在相同的推理強度下評估，成本統計涵蓋起草、評閱、修改、交棒、重試與備援等每一個環節。

在檢驗終端環境多步驟作業的 TerminalBench 2.1 上，HydraFusion 品質勝過基準，費用卻只有三分之一。DeepSWE 需要在大型程式碼庫中橫向查找並完成端對端修正，這裡差了 1.5 個百分點，但若這點差距能換來 36% 的成本下降，可以選它的場合並不少。CheckpointBench 則是以真實 Copilot 工作階段建立的內部評測集，每段對話都綁定公開儲存庫與固定的 commit，可以重播重現。

路由方針本身並非人工調參而來。GitHub 以集束搜尋探索候選方針。開發紀錄也提到，8 月 11 日至 25 日之間評測平台出現兩次故障而產生無效執行，剔除這部分之後改善仍持續累積。

可試用的範圍與使用方式

HydraFusion 對所有 GitHub Copilot 方案開放，以 GitHub Copilot CLI 的實驗功能形式提供。計費依各模型實際消耗的 token 量，套用各自的標準單價。

/update
/experimental on
/model

最後在清單中選擇 HydraFusion (Research Preview) 就完成了。現階段最適合的是範圍明確、一次提示就能交代完的程式設計工作。多輪長時間工作階段的支援留待下一階段，GitHub 也表示名稱、行為與開放範圍都可能隨研究進展而改變。

總結

HydraFusion 談的不是哪個模型最強，而是把多個模型組合得宜能否用更低的成本得到同樣的結果。在 TerminalBench 2.1 上一邊提升品質、一邊把費用壓到三分之一，說明這個方向還有空間。研究預覽階段的數字未必能原封不動套用到日常開發，但可以看出程式設計輔助工具的競爭重心，正從單一模型的效能擴展到運作方式的設計。