從選模型到組工作流：GitHub HydraFusion 深度解析

過去兩年，AI 輔助編程的心智模型很簡單：選一個你負擔得起的最強模型，然後接受它的成本與品質取捨。GitHub 於 9 月 4 日在 GitHub Copilot CLI 推出的研究預覽版 Project HydraFusion，明確押注這個時代即將結束。HydraFusion 不再選擇「一個」模型，而是動態建構「一套工作流」——跨供應商調度多個模型來起草、審查、修改或升級——並宣稱以極低的成本提供前沿級品質。

核心數字很難忽視。在評測編程 agent 於終端環境中執行複雜多步任務的 TerminalBench 2.1 上，HydraFusion 相較 Claude Opus 5 基線將驗證任務品質提升了 4.9 個百分點，同時將估計工作流成本降低 67%。在專注於倉庫級軟體工程任務（導航大型程式碼庫、理解跨檔案依賴、產出端到端修復）的 DeepSWE 上，它以 36% 的成本降幅達到與 Opus 5 差距 1.5 分內的水準。而在 GitHub 內部、由真實 Copilot 編程會話策劃的 CheckpointBench 上，差距僅 0.1 分，成本降低 65%。

三種執行模式，一個優化器

HydraFusion 的核心是把工作流選擇當作最佳化問題。對每個請求，它依據推理、程式碼生成、除錯、工具使用等能力訊號，選出預期能達到品質門檻的「最簡單」執行模式。目前有三種：

Single（單模型）：一個選定的模型直接解題。任務單純時，編排開銷就是純浪費，所以 HydraFusion 根本不加。

Cascade（級聯）：高效率模型先嘗試，品質閘門決定接受草稿或升級到更強的模型。這是省下大部分成本的關鍵——便宜模型處理簡單的八成任務，昂貴的前沿模型只留給困難的兩成。

Critique（審查）：一個模型起草，再由來自「不同模型家族」的獨立唯讀審查者檢視（沿用 GitHub 稱為 “Rubber Duck” 的審查模式），起草模型修改一次。跨家族審查很重要：模型審查自家輸出時會繼承同樣的盲點。

從開發者座位上看，這一切全不可見。你在 /model 裡像選其他模型一樣選 HydraFusion，它在幕後管理模型與工作流，最後回傳一個連貫的答覆和一份經權限控管的變更集。計費按工作流實際呼叫的各模型 token 用量、以各模型標準費率計算——沒有編排溢價。

讓編排真正可用的工程原則

多多模型編排在架構圖上看起來優雅，在真實倉庫裡卻是噩夢。GitHub 的工程文章罕見地坦率，列出五項讓 HydraFusion 可靠運作的原則：

• 完整計費——起草、審查、修改、升級、重試、後備等每一條工作流支線的成本與用量都被彙總，帳單與現實一致。
• 有界執行——每條支線都有明確的超時與取消行為，讓執行時間與成本都受限。
• 隔離審查——審查步驟在隔離、無工具的環境中執行，審查者能評估工作卻無法修改倉庫；解題步驟則使用共享工作區與正常的權限感知 agent 迴圈。
• 失效安全——工作流被取消或驗證失敗時不套用任何修補檔，不完整的變更永遠不會進到倉庫。
• 路由驗證——工作流定義、模型綁定、後備行為與模型可用性都在執行前驗證。

還有一個值得注意的產品決策：HydraFusion 顯示工作流階段，但會扣住中間草稿直到最終結果就緒。GitHub 的理由是，草稿可能隨時被修改或丟棄，即時顯示會讓未完成的工作看起來像定案。團隊承認這是取捨（「在沒有足夠可見性的情況下等待，對開發者是真實的取捨」），並表示更好的進度顯示正在路上。

路由策略是怎麼煉出來的

技術上最有趣的細節，是 GitHub 如何調校 HydraFusion 的路由。團隊沒有手動設定閾值，而是用束搜索（beam search）建構最佳決策策略，每個候選都在凍結基線上量測品質、成本與失敗模式。CheckpointBench——由錨定到特定公開倉庫與不可變 commit 的真實 Copilot 會話軌跡構成、每個會話皆可重播——為最佳化提供了真實訓練訊號，而非合成任務。

開發紀錄顯示這不是一條乾淨的曲線。8 月 11 日到 25 日之間，評測 harness 的兩次運作故障產生了無效運行，必須排除並修正。到 8 月 25 日，HydraFusion 達到紀錄系列中的最強操作點。這種對失敗運行的透明度在基準行銷中很少見，反而讓結果更有可信度。

對編程 agent 市場的意義

HydraFusion 不只是一個 Copilot 功能，更是一個戰略標記。如果編排能以三分之一的成本達到單一前沿模型的品質，那麼任何單一前沿模型的價值都會被侵蝕，價值將轉移到掌握路由層的人手上。GitHub 將此表述為「從選擇最好的模型，轉向動態建構解決每個任務的最佳方式」。

但限制也很實在，而且 GitHub 說得很白：結果來自受控的離線評測，僅適用於當時評測的基準版本、工作流配置、模型池與計價假設，所有模型都在相同的中等推理等級下評測。只有 TerminalBench 2.1 出現品質「勝出」；DeepSWE 和 CheckpointBench 接近平手。預覽版目前最適合首輪、單提示詞的編程任務，強健的多輪表現被明確推遲到後續。而隨著新模型加入 Copilot，HydraFusion 的模型池也會跟著擴張——這究竟是優勢還是移動目標式的基準問題，取決於你的視角。

對開發者來說，試用成本很低：在 Copilot CLI 執行 /update，再 /experimental on，然後 /model 選擇 HydraFusion（Research Preview）。今天最適合的工作負載，是你會以自動駕駛模式、用單一提示詞交給 Copilot 的實際且有明確範圍的任務。

更大的訊號是給整個產業的。GitHub——身在微軟體系內、同時能用 OpenAI、Anthropic 與開放權重生態的模型——處於獨特位置把模型商品化、把編排利潤留下來。如果 HydraFusion 的結果在真實工作負載上站得住腳，每家編程 agent 供應商要回答的問題將不再是「你跑哪個前沿模型？」，而是「你為什麼只跑一個？」