很多人第一個會先想到，多模型協作能不能讓程式寫得更好？但更前面的問題是，HydraFusion 如何安排任務流程，開發者又如何掌握品質、成本與責任？GitHub 已將這項研究預覽擴展至 VS Code 與 Copilot 應用程式；使用前仍須了解流程並驗收結果。

HydraFusion 進入 VS Code，更新重點是工作流程選擇

GitHub 將 HydraFusion 研究預覽從 Copilot CLI 擴展至 VS Code 和 GitHub Copilot 應用程式，讓使用者能在模型選擇器中指定它，由系統安排一輪任務使用的模型與流程。

過去的產品說明已提到 Copilot CLI 的 HydraFusion 預覽；2026 年 10 月 1 日的更新增加 VS Code 與 Copilot 應用程式入口。GitHub Changelog 也把它列為 VS Code 九月版更新中的研究預覽功能。目前功能仍屬研究預覽，尚未轉為正式穩定版。

GitHub 日文產品更新列出新介面、設定方式與自動選模（Auto）的差異；VS Code 更新紀錄也標示 HydraFusion 仍處於研究預覽。

在 VS Code 1.140 以上版本或 VS Code Insiders 中，符合資格的使用者可在 Copilot Chat 的模型選擇器查看 HydraFusion；若選單沒有出現，GitHub 說明可檢查 chat.copilot.hydraFusion.enabled 設定。透過 Organization 或 Enterprise 使用 Copilot 的團隊，可能還需要管理者允許預覽功能。

Copilot 應用程式則需更新至最新版，在設定中啟用 HydraFusion，再從模型選擇器選取。功能是否顯示取決於方案、模型政策、組織設定及客戶端版本，產品公告本身無法確認每個帳號都能立即使用。

「研究預覽」期間沒有服務等級協議（SLA），GitHub 也不建議用於正式生產工作負載；產品行為與可用條件可能改變。若團隊試用，仍要保留測試、程式碼審查與回復機制。

HydraFusion 官方文件列有使用步驟、用量查詢與限制。

一次任務如何交由多個模型處理

HydraFusion 是執行時的模型協調系統。GitHub 說明它會依推理、程式生成、除錯與工具使用等能力訊號進行內部路由判斷，挑選預期符合系統品質條件的流程；這些條件不是使用者自行設定的驗收標準。

「模型路由」是依請求選擇模型或步驟。HydraFusion 每次任務可選單模型（Single）、逐級升級（Cascade）或交叉檢視（Critique）；只有預期能改善結果時才增加步驟，因此同一對話的不同請求也可能採不同流程。

GitHub 官方 HydraFusion 說明把這三種模式界定如下：

模式執行方式適合觀察的重點
Single（單模型）由 HydraFusion 選定一個模型直接完成回應快、流程短；仍需驗證程式是否符合需求
Cascade（逐級升級）較有效率的模型先提方案，系統內部檢查條件判斷採納或升級確認最終改動及額外等待是否合理
Critique（交叉檢視）一個模型起草，另一模型唯讀檢視，再由起草模型修訂一次檢視意見是否具體、修訂是否解決問題

自動選模（Auto）是 Copilot 的另一項功能，不屬於 HydraFusion 流程。它為每個請求選一個模型；HydraFusion 則安排一輪任務的模型與步驟。

Single 適合局部格式調整或簡單修補，流程短但結果仍須驗收。Cascade 先由一個模型嘗試，再由系統內部條件決定採納或升級；這不代表使用者的測試與驗收條件已通過。

Critique 會把初稿交給另一模型家族唯讀檢視，再由起草模型修訂。這能增加檢查角度，卻不會補上缺漏測試，也無法保證找出根因；兩個模型仍可能共享盲點或誤解需求。

「HydraFusion 會選擇符合品質門檻的最有效率執行模式。」— GitHub 官方文件（本文中譯）

這是流程選擇說明，不是品質背書。操作仍受模型可用性、授權與工作區權限影響；錯誤或取消後，應檢查差異與版本控制狀態。GitHub 說明取消或驗證失敗時會避免套用修補，試用時仍須確認工作區狀態。

三條流程分別呈現單一模型直接回應、初稿經檢查後採納或升級，以及初稿經另一模型唯讀檢視後修訂。
三種模式的差別在任務如何流轉，增加檢查步驟仍不代表成果已通過驗收。

HydraFusion 和 Auto 的差別在任務流程

Auto 為每個請求挑選一個模型；HydraFusion 安排一輪任務的模型與流程，可能使用一個或多個模型。

日常短任務可先用 Auto；範圍明確、涉及多個檔案或需要另一模型檢視時，可評估 HydraFusion。GitHub 建議從單次提示可交付的明確任務開始試用。

開發者可追蹤步驟進度，但官方文件表示只展示最後回應，中間版本可能被修訂或丟棄。團隊可留存最終差異、測試紀錄與工具操作結果。自動流程也可能改變模型池或工作方式，單次成功不代表表現固定。

HydraFusion 沒有獨立的「協調器費用」，單一任務可能呼叫多個模型。GitHub 研究文章以標準費率估算模型呼叫量；帳戶實際記錄的計費用量則受費率與折扣影響，應查閱用量頁。因此，離線估算不等於個人帳單，多模型流程也未必比 Auto 划算。

用量與計費說明列有用量計算方式。

哪些程式工作適合先試

先從範圍清楚、可用測試或程式差異驗收的任務開始，例如一項有明確重現步驟的錯誤修補，或跨少數檔案且完成條件可描述的修改。

「可驗收」比任務大小更重要。試用前寫明預期行為、修改範圍與通過條件，例如輸入輸出、必須通過的測試及是否允許新增相依套件。條件明確，才容易判斷問題出在需求理解、程式修改、工具操作或驗證階段。

GitHub 建議首輪先試單一提示可交付的明確任務，長期、多輪迭代能力仍待觀察。大型重構、需求未定或依賴隱性產品知識的工作可留待後續；初稿看似完整，也要確認模型理解脈絡。

導入前應確認模型權限、資料處理政策、擴充功能設定與審查流程。若方案或組織不允許，HydraFusion 可能不會顯示；使用者也不能指定各步驟採用的模型。管理者還應確認預覽功能符合團隊的可追溯性、穩定性與變更審批要求。

「先從可透過單一提示交付、範圍明確的程式任務開始。」— GitHub 官方研究文章（本文中譯）

如何檢查成果與評估使用成本

把它當成可衡量的流程試驗：比對程式差異、執行既有測試，再記錄人工修正量、等待時間與實際用量。

檢查差異是否超出預期範圍，並確認邊界條件、錯誤處理、相依套件與安全變更。執行相符的測試或建置，由熟悉程式庫的人審閱；測試不足就補可重現案例。若任務會操作命令或檔案，也要確認授權、暫存檔、覆寫與非預期變更。

GitHub 研究文章報告了 TerminalBench 2.1、DeepSWE 與內部 CheckpointBench 的離線比較，以固定 HydraFusion 政策和 Opus 5 等基準衡量品質差距及估計流程成本。結果受任務集、流程設定、模型池、執行限制、計價假設與評分方式影響。

三組數據呈現的品質差距不同：TerminalBench 2.1 的品質高 4.9 個百分點、估計成本低 67%；DeepSWE 的品質低 1.5 個百分點、成本低 36%；CheckpointBench 的品質低 0.1 個百分點、成本低 65%。這些是受控離線評估，不能直接推論某個團隊的程式品質、延遲或帳單也會出現相同變化。

GitHub 公布的基準結果與條件亦指出，預覽階段還要觀察這些數據如何反映在真實開發工作中。

試用評估版面並列品質、測試、人工修正、耗時、模型用量與估計成本欄位，並將離線基準與團隊觀察分開。
離線基準只能提供特定條件下的參考，團隊是否受益要看自己的品質、修正時間與實際用量。

小範圍試用可挑可重複任務，保留驗收條件，記錄 Auto 與 HydraFusion 的品質、測試、人工修正、等待時間及實際用量。小樣本只能初步觀察；語言、程式庫、任務難度與使用習慣都會影響結果。若省下模型費卻增加人工修正或等待時間，單看 API 成本便不完整。

  1. 選一個範圍清楚、可重複驗收的程式任務，先寫下完成條件。
  2. 試用後逐項檢查差異、工具操作與測試結果，記錄人工修正量和等待時間。
  3. 查詢帳號的實際模型用量，與 Auto 的任務結果及原有流程比較。
  4. 累積足夠的代表性案例後，再由團隊決定是否擴大使用，並先確認預覽權限與程式碼審查責任。

  • HydraFusion 是模型與工作流程協調系統，依任務選 Single、Cascade 或 Critique；Auto 則逐請求選一個模型。

  • 目前仍是研究預覽，適合先試範圍清楚、能驗收的任務；長時間、多輪協作的表現仍待觀察。

  • GitHub 的離線基準結果依特定任務集與計價假設而定，不能當成個人品質、延遲或成本保證。

  • 採用前檢查程式差異、測試、工具操作、管理者權限和實際模型用量，人工審查責任仍由開發團隊承擔。

常見問題

Q1：HydraFusion 是一個新的單一模型嗎？

HydraFusion 是 GitHub Copilot 的執行時協調系統，會依任務挑選模型與工作流程；有些任務由一個模型處理，有些會經過升級或另一模型檢視。

Q2：使用 HydraFusion 一定比 Auto 省成本嗎？

是否比 Auto 省成本，需依實際用量判斷。HydraFusion 的單一任務可能呼叫多個模型；GitHub 研究文章以各模型標準費率估算用量，折扣與實際費率則應查看帳戶用量頁及當前 Copilot 計費說明。

Q3：團隊如何管理研究預覽功能？

先確認方案、Organization 或 Enterprise 的預覽權限及允許模型，再以可驗收任務小範圍試用。合併程式碼前仍照既有方式檢查差異、執行測試並完成程式碼審查；研究預覽沒有 SLA，也不建議直接用於正式生產工作負載。

Q4：HydraFusion 能檢視每個中間步驟嗎？

官方文件表示可追蹤各步驟進度，但只顯示最後回應。若需審查過程，團隊可另存程式差異、測試紀錄與工具操作結果。