AIREITERGitHub HydraFusion 是 Copilot CLI 中的研究預覽版協調系統；它在離線基準測試的成績，並不保證面對大型、雜亂的真實儲存庫時也有同樣表現。
先說結論：現在適合用嗎？
如果你已有 GitHub Copilot 方案，手上又有一項範圍明確、份量足夠、能以單一提示描述完成的開發任務，GitHub HydraFusion 值得一試。不過，我暫時不會把它設為關鍵正式環境變更或長時間來回協作的預設選項：GitHub 目前仍將它標示為研究預覽，並指出更強的多輪支援仍屬未來工作。
HydraFusion 並不是新的基礎模型，而是內建於 GitHub Copilot CLI 的執行期協調系統。它會判斷一項任務適合交給單一模型、是否需要升級至更強模型，或在交付結果前加入獨立審查。
在 Copilot CLI 啟用 HydraFusion
這項預覽功能不是從一般 VS Code 模型選擇器開啟，而是直接在 Copilot CLI 中設定。GitHub 的官方公告表示，所有 Copilot 方案都能透過一組實驗性命令使用它；至於安裝和驗證，則可參考 Copilot CLI quickstart。
- 執行
/update更新 Copilot CLI。 - 以
/experimental on啟用實驗功能。 - 輸入
/model開啟模型選擇器。 - 選取 HydraFusion (Research Preview)。
- 先從一個具份量且邊界清楚的單一開發任務開始，不要一開始就拿它處理長篇對話式專案。
若清單中沒有 HydraFusion，先更新 CLI，並確認你的 Copilot 帳號、組織政策與 CLI 版本都支援這項預覽。現行命令流程應以 GitHub 的官方公告為準；預覽名稱和可用性都可能變動。
搜尋時也可能會看到 AICPS/hydrafusion，這是一個自動駕駛感測器融合研究儲存庫，與 GitHub 為 Copilot 推出的 Project HydraFusion 無關。
不同任務，適合不同協調流程
HydraFusion 會依任務預期的品質、成本與延遲需求，在三種執行模式間選擇。以目前預覽版來說，使用者並不能手動切換「模式」；GitHub 將 HydraFusion 呈現為一個模型式選項，由它在執行期間決定底層工作流程。
| 工作流程 | 運作方式 | 適合先拿來處理的任務 | 主要取捨 |
|---|---|---|---|
| Single | 由一個模型直接完成任務。 | 直接的修改、說明或小型修正。 | 表面上的流程額外成本最低，但沒有升級機制或獨立審查。 |
| Cascade | 先由高效率模型產出草稿；品質閘門可決定是否升級交給更強模型。 | 多數情況可能簡單，但偶爾需要更高能力的任務。 | 首次結果過關時可節省成本，但會多一道檢查，且可能發出第二次呼叫。 |
| Critique | 一個模型先起草，另一個模型家族中隔離執行的評論者負責審查，原起草模型再修訂一次。 | 第二個觀點有機會找出錯誤的變更。 | 需要更多呼叫與等待時間，且評論者無法直接使用工具。 |
Single：直接完成任務
Single 是最單純的路徑。GitHub 表示，單一解題模型會接收任務，並在一般具備權限感知的 Copilot agent 迴圈中執行。因此，實作方向明確、測試路徑短的請求，很適合走這條路。
它的優勢是降低流程額外負擔，但 Single 不會提供內建的第二意見。
Cascade：先求效率，必要時再升級
Cascade 會先交給高效率模型，再由品質閘門判斷結果是否足夠好，或是否應升級處理。它的成本邏輯在於選擇性升級：日常請求不該預設就耗用能力最強的模型。
當第一輪通過品質閘門時，Cascade 確實可能省錢；但 GitHub 沒有公布通用的升級比例，因此應以實際任務結果評估，而非假設每個請求都會走便宜路線。
Critique：先寫草稿，再獨立審查、修訂一次
Critique 會加入來自不同模型家族的獨立審查者。GitHub 表示，評論者會在隔離、無工具的環境中審查草稿，將意見交回原始解題模型進行一次修訂；它不能直接修改儲存庫。
這讓 Critique 類似自動化同儕審查，但代價是多一次模型呼叫和更高延遲。
基準數據該看成取捨，而不是保證
GitHub 的離線測試顯示的是特定基準下的品質與成本取捨，並非保證每一項 Copilot 任務都能降低 67% 成本。
| 基準測試 | HydraFusion 品質相較於 Claude Opus 5 | 預估成本相較於 Claude Opus 5 | 應如何解讀 |
|---|---|---|---|
| TerminalBench 2.1 | +4.9 個百分點 | 低 67% | 公布結果中最亮眼的一項：經驗證的任務品質更好，預估成本也更低。 |
| DeepSWE | −1.5 點 | 低 36% | 在困難的儲存庫任務中，以可量化的品質讓步換取明顯節省。 |
| CheckpointBench | −0.1 點 | 低 65% | 在 GitHub 內部重播式基準測試中，品質近乎持平，但預估成本低得多。 |
根據其官方 HydraFusion 公告，GitHub 使用一致的評估設定，並將所有工作流程呼叫都納入計算，包括重試、評論、升級與備援。
CheckpointBench 的測試方式，是以不可變動的公開儲存庫提交版本重播經過挑選的 Copilot 工作階段。這使它比單純的文字生成測試更貼近程式設計 agent 的實際工作，但本質上仍是受控基準。DeepSWE 中 HydraFusion 品質較低的結果尤其重要，因為它提醒我們不能把整張表解讀成全面勝出。
目前來自真實世界的獨立證據仍不多。獨立開發者 @DoDataThings on X 點出了最關鍵的驗證疑慮：
「負責規劃的模型，不一定要是負責寫程式的模型。GitHub 的說法是，HydraFusion 在受控離線評估中追平或超越 Opus 5 基準；但從離線評估走到雜亂的真實儲存庫，往往正是協調系統失去優勢的地方。很好奇那段成本差距究竟能保留多少。」
這篇貼文提出的是問題，而不是測量結果；不過它指出了正確的測試方向：在雜亂儲存庫中檢驗成本和品質。
真正放進儲存庫時，該注意的操作細節
HydraFusion 的價值，不只是選到較便宜的模型。由於多模型流程會比單一直接請求產生更多操作狀態，GitHub 文件特別說明了用量計算、取消、路由驗證、審查隔離與修補套用等控制機制。
| 控制機制 | 對使用者的意義 |
|---|---|
| 成本與時間控制 | HydraFusion 會追蹤各流程分支的呼叫，並支援限制執行範圍；不過評論、升級、重試和備援仍可能拉高延遲或總用量。 |
| 路由與修補控制 | GitHub 表示會驗證路由，且在流程無效或被取消後不會套用修補；但這兩項控制都無法證明所選路徑或最終程式碼是正確的。 |
| 審查隔離 | 解題模型使用共用工作區時，評論者僅能讀取且沒有工具，能減少審查者直接造成的變更；但仍必須檢閱 diff 並執行測試。 |
GitHub 公告也提到一項可見性取捨：中間草稿會保留到最終結果才顯示。這讓輸出看起來更乾淨，但等待期間你看不到草稿、重試、升級和捨棄結果的過程。
第一次測試 HydraFusion，建議這樣做
最適合作為首測的，不是要求它「改善」整個程式碼庫這類開放式需求，而是有客觀驗收方式、範圍受限的儲存庫任務。把這項預覽功能當成實驗：先固定起始提交版本，再定義明確的成功條件。
- 建立乾淨的 branch 或 worktree，並記下起始提交版本。
- 選一項檔案邊界狹窄、可重現測試命令的任務。
- 在第一個提示中說明預期行為、限制條件與測試要求。
- 讓 HydraFusion 完成工作後，先檢查 diff；不要只因 agent 宣稱成功就直接接受。
- 自行執行相關測試，並檢查是否改動了無關檔案。
- 若 CLI 有提供這些資訊，記錄延遲、可見的用量或成本資料、重試、升級行為與最終測試結果。
- 累積幾個任務的結果後，再將 HydraFusion 與固定模型比較，或考慮調整團隊預設值。
不要用一次成功的修補來驗證基準測試主張。較有意義的測試單位，是一小組任務，涵蓋例行修正、跨檔案變更，以及刻意設計的模糊案例，看看升級或評論機制是否真的有幫助。
HydraFusion 怎麼計費，又沒有承諾什麼？
GitHub 並未在公告中公布 HydraFusion 的獨立美元定價。它表示，使用量會按照底層模型的標準 token 費率計費，因此最後成本取決於執行期實際使用了哪些模型，以及走過哪些工作流程分支。
| 計費問題 | 目前答案 |
|---|---|
| HydraFusion 是否有獨立訂閱費？ | GitHub 公告中未提及任何獨立的 HydraFusion 費用。 |
| 使用量如何計費？ | 依組成模型消耗的 token，按其標準費率計算。 |
| 一個任務可能有多次需計費的呼叫嗎？ | 可以。Cascade 和 Critique 都可能涉及多個流程分支，用量計算也包含重試與備援。 |
| 基準中節省 67%，是否等於客戶也會省下 67%？ | 不是。那是針對特定基準、政策、模型池與定價設定的預估比較。 |
| HydraFusion 是穩定的正式功能嗎？ | 不是。GitHub 將它標示為研究預覽，並表示模型、工作流程、可用性、行為與名稱都可能變動。 |
一開始請將 HydraFusion 用在可檢查、可由單一提示完成的任務；對於長時間多輪協作或高後果工作，在儲存庫層級的測試支持更廣泛使用前，仍應保留固定模型作為替代方案。
HydraFusion 常見問題
HydraFusion 是模型，還是路由器？
HydraFusion 是 GitHub Copilot CLI 中的執行期多模型協調系統，不是獨立的基礎模型；它會為程式開發任務選擇模型與執行模式。
如何在 Copilot CLI 啟用 HydraFusion？
依序執行 /update、/experimental on 和 /model，然後選取 HydraFusion (Research Preview)。
所有 Copilot 方案都能使用 HydraFusion 嗎？
GitHub 表示，這項預覽可透過 Copilot CLI 在各種 Copilot 方案中使用；不過帳號、組織設定、CLI 版本或可用性調整都可能影響是否看得到它。
HydraFusion 使用哪些底層模型？
GitHub 說明它會在多家供應商的模型之間進行選擇，但未公布每次請求固定使用哪些模型，因此不應假定每個任務都由某個指定模型處理。
HydraFusion 是否總能勝過 Claude Opus 5？
不是。GitHub 在 TerminalBench 2.1 報告了領先表現，在 CheckpointBench 接近持平，而在 DeepSWE 則落後 1.5 點。
HydraFusion 要額外付費嗎？
使用量依底層模型的標準 token 費率計費，而且一條路由可能呼叫多個模型；GitHub 表示公告中沒有另外列出 HydraFusion 的美元價格。
HydraFusion 能在 VS Code 使用嗎？
推出資料記載這項預覽功能是透過 Copilot CLI 提供，因此其他環境的可用性應以 GitHub 現行文件為準。
可以放心讓 HydraFusion 修改儲存庫嗎？
GitHub 說明了解題模型的權限感知機制、隔離的評論者、路由驗證、受限執行，以及無效或取消流程不套用修補等措施；但在合併前，仍應檢查 diff 並執行測試。