GitHub 剛剛提出了一個令人信服的觀點：最優秀的 AI 編程助手並非單一模型，而是一名交通指揮員，懂得在何時調用哪個模型。
該公司於 2026 年 9 月 4 日在 GitHub Copilot 內宣布了 Project HydraFusion，該系統是一個多模型協調層，可動態選擇不同的 AI 執行模式，以優化品質、成本和速度。
HydraFusion 如何實際運作
在核心上，HydraFusion 運行於三種執行模式：Single、Cascade 和 Critique。Single 模式將任務路由至單一模型；Cascade 模式將多個模型串聯起來，按需提升複雜度；Critique 模式則增加一個獨立的審核步驟，由另一個模型在發送前評估其輸出。
這是在 GitHub 之前的自動模型選擇功能基礎上進行的升級，該功能讓 Copilot 為用戶選擇模型。不同之處在於，自動選擇是靜態的，而 HydraFusion 是動態的，會在任務進行中根據情況調整其方法。
GitHub 列出了四項規範系統的設計原則：完整成本核算（追蹤每個路由決策的真實開支）、執行限制（防止計算失控）、隔離的審查步驟（將評論與生成分開）、以及安全的變更應用（確保程式碼修改不會引入回歸）。
基準數字
GitHub 在三個基準測試中對 HydraFusion 與 Claude Opus 5 進行了測試：TerminalBench 2.1、DeepSWE 和 CheckpointBench。
在 TerminalBench 2.1 上，HydraFusion 的品質分數比 Opus 5 高出 4.9 分，但成本估計低了 67%。在 DeepSWE 上，HydraFusion 的分數比 Opus 5 低 1.5 分，但成本降低了 36%。在 CheckpointBench 上，HydraFusion 僅比 Opus 5 低 0.1 分，成本卻削減了 65%。
值得注意的是：這些是 GitHub 在其自身系統上的基準測試結果。第三方的獨立驗證將大大增強這些說法的可信度。但這些基準測試本身——TerminalBench 2.1、DeepSWE 和 CheckpointBench——都是編程 AI 領域公認的評估框架。
一個不斷增長的產業共識
GitHub 並非在真空中運作。OpenRouter 已開發出 Auto 和 Pareto 路由器，同樣旨在跨多個模型提供者平衡品質與成本。Nvidia 已在其企業 AI 工具包中發布了 LLM 路由器藍圖。
GitHub 的官方通訊並未聲稱與 Nvidia 或 OpenRouter 就 HydraFusion 有任何直接合作或推薦。
這對開發者和 AI 編碼市場意味著什麼
HydraFusion 目前為研究預覽版，僅限特定用戶群提供回饋，待後續全面推出。GitHub 正明確徵求開發者意見，以優化系統處理實際程式開發工作流程的方式。
在競爭格局中，TerminalBench 2.1 上以極低的成本取得的 4.9 分優勢，正是讓採購團隊重新考慮供應商選擇的結果。單一模型的競爭對手面臨壓力，必須要么達到同等效率，要么證明其品質優勢足以證明期權費的合理性。