GitHub 於 2026 年 9 月 30 日宣布，HydraFusion 研究預覽版現在可以在 Visual Studio Code 及 GitHub Copilot App 使用，覆蓋面由原本的 Copilot CLI 擴大。HydraFusion 出現在模型選擇器中，但 GitHub 特別強調它不是一個單一模型，而是一套協調多個模型的工作流系統。
它把工作流選擇視為一個優化問題，根據推理、程式碼生成、除錯和工具使用等能力訊號，選擇較有效率、同時能達到品質門檻的執行方式。第一種是 Single，由一個選定模型直接處理任務；第二種是 Cascade，先由較有效率的模型起草，再由品質閘門決定接受結果或升級到較強模型；第三種是 Critique，由一個模型起草，再交給不同模型家族的獨立只讀評論者檢查，最後讓原模型修訂一次。
這個設計與傳統的「Auto 選一個模型」不一樣。GitHub 表示 Auto 是按每個請求選模型，而 HydraFusion 會在同一回合內同時考慮選擇工作流及協調多個模型。對編程代理來說，這將決策單位由模型名稱提升到任務路徑：簡單任務可以直送，風險較高或不確定的任務則可能加入品質閘門或獨立批判。
GitHub 今次也改善了可見度。使用者可以更清楚看到 HydraFusion 每一步在做甚麼，系統會發送較頻密的即時進度，在長任務中顯示較明確的狀態。這類產品細節看似不是模型能力，但對 agent 工作流很重要：如果使用者不知道系統正在等待、切換、重試還是已經失敗，就很難判斷何時需要介入。
目前 HydraFusion 可以供 Copilot Pro、Pro+、Business 和 Enterprise 使用；Business 及 Enterprise 需要管理員開啟預覽功能。它仍然是 research preview，功能及表現可能改變。這一點也限制了新聞的解讀：GitHub 的公告說明產品形態及可用範圍，但並沒有在這篇更新中提供一套足以證明所有任務都會改善的獨立基準。
對 AI 編程工具市場來說，HydraFusion 的訊號是模型路由正逐步變成工作流路由。當模型數量增加，最難的問題未必是「哪個模型最強」，而是怎樣按任務成本、速度、可靠性和風險選擇路徑。Cascade 的品質閘門及 Critique 的獨立檢查，亦把測試、審查和人類介入點放到代理流程之中，而不是只靠最後一次對話判斷結果。
不過，多模型編排也帶來新的治理要求。團隊需要知道每一步用了哪個模型、誰作了接受或升級決定、評論者看到了甚麼內容，以及任務失敗時能否重播和回滾。HydraFusion 仍是預覽功能，最穩妥的做法是把它視為可觀察的實驗工作流，配合版本控制、測試及權限限制，而不是把它當成自動保證代碼品質的黑盒。
