GitHub HydraFusion Copilot CLI 指南：執行期路由

看似簡單的程式工作，一旦牽涉跨檔案相依性，複雜度往往立刻上升。Project HydraFusion 會選擇它預期能達到品質門檻的工作流程，但目前的研究預覽版仍不會公開完整路由，也不保證每個 Repository 都能獲得相同幅度的成本節省。

一張表看懂 HydraFusion 的路由選擇

Project HydraFusion 是 GitHub Copilot CLI 裡的執行期協調層，不是另一個全新的基礎模型。你只需要選擇 HydraFusion (Research Preview)，接著由執行期決定要用哪些模型，以及採用什麼執行方式。

若要試用預覽版，先執行 /update，接著輸入 /experimental on，再執行 /model，選擇 HydraFusion (Research Preview)。GitHub 在官方 HydraFusion 公告中說明了這套流程。預覽版適用於各種 Copilot 方案，但如果是由組織管理的帳戶，能否使用仍可能取決於管理員啟用的Copilot CLI 政策。

這三種是執行模式，不是讓使用者手動強制指定請求走哪條路的公開開關。官方發布資料目前只說明如何選擇 HydraFusion，之後由執行期自行在效能、成本與延遲之間取得平衡。

執行期到底在預測什麼？

GitHub 表示，HydraFusion 會參考推理、程式碼生成、除錯與工具使用等能力訊號，選擇它預期能達到請求品質門檻、同時效率最高的執行方式。不過，GitHub 並未公開具體門檻，也沒有提供「修改三個檔案就一定走 Cascade」這類確定規則。

因此，任務型態只能當作理解路由的方向，不能視為保證：範圍明確、測試路徑清楚的小幅修改，概念上適合 Single；可能需要較高能力的請求，適合 Cascade 的選擇性升級；而需要獨立檢查的變更，則更符合 Critique。但官方公告沒有提供每個請求固定使用的模型清單，也沒有可直接閱讀的路由追蹤紀錄。

可以強制指定 Single、Cascade 或 Critique 嗎？

GitHub 的文件只描述如何選擇 HydraFusion，並讓執行期自行決定工作流程；目前沒有公開指令可以強制使用其中一種模式。如果你需要可預測的路由，就應該改用固定的 Copilot 模型。

什麼情況值得多付一次模型呼叫？

Single：路徑明確時，直接完成任務

Single 會讓任務經過 Copilot 一般具備權限感知的代理人迴圈，由一個解題模型完成。它適合小型且規格清楚的修改、簡短說明，或實作方式與測試路徑都很明確的修正。

它的優勢在於成本與延遲都比較容易預估。這個工作流程不會刻意加入品質閘門或第二個意見，因此如果解題模型誤解需求，主要審查責任仍落在開發者身上。

Cascade：第一輪不夠好，才升級處理

Cascade 會先交給高效率模型處理，再由品質閘門評估結果。如果候選答案未達標，便可能把任務升級給更強的模型。

它的成本邏輯是有條件的：

1. 先由第一個模型處理它能充分完成的工作。
2. 由品質閘門篩掉品質不足或結果不確定的候選答案。
3. 只有真正需要更高能力的任務，才會進入更強模型的路徑。

相較於把每個任務都交給前沿模型，這種做法有機會降低平均工作流程成本。不過，一旦發生升級、重試或備援處理，成本較高、等待時間較長的尾端情況仍可能出現；GitHub 也尚未公布適用於所有 Repository 規劃工作的通用升級比例。

Critique：用額外成本換第二種觀點

Critique 是一個「草稿—審查—修訂」迴圈。第一個解題模型先產生結果，再由不同模型家族的評論模型，在隔離、無工具且唯讀的環境中進行審查，最後由原本的解題模型修改一次。

評論模型不能執行專案測試、透過指令檢查生成的檔案，也不能自行套用修正。Critique 提供的是審查觀點的多樣性，而不是另一套獨立完成端到端實作的流程。

看懂基準測試帳本：成本降低，不代表品質承諾只有一種

GitHub 以三項代理人程式設計基準測試，比較固定 HydraFusion 政策與 Claude Opus 5 的表現。以下數據來自GitHub 官方公告。

品質結果之所以不一致，正是重點所在：HydraFusion 的設計目標不是每次請求都使用更多模型，而是在預期品質提升足以抵銷成本與延遲時，才增加推理工作。

GitHub 表示，這項評估維持輸入、工具、執行限制、定價與評分方式一致，並將草稿、評論、修訂、升級、重試與備援處理等階段一併計算。不過，這些仍是受控的離線估算，適用範圍取決於測試過的政策、模型池、基準測試版本與定價假設。

這些數據不能證明一般 Copilot 任務一定能省下 67% 成本，也不能保證 HydraFusion 在某個特定程式碼庫中一定勝過 Claude Opus 5。GitHub 建議，在測試預覽版的實際工作負載時，先從規模較大、範圍明確，而且能在一次提示中完成的第一輪程式設計任務開始。

成本要拆成三個部分來看

評估 HydraFusion 時，請分開看預期 Token 成本、尾端成本與等待時間。

預估工作流程成本較低，不代表回應一定更快：Cascade 在升級的案例中可能變慢，Critique 會加入串聯的審查流程，而 Single 雖然回應迅速，卻會把更多驗證工作留給開發者。

GitHub 的Copilot CLI 使用文件指出，/usage 會顯示工作階段持續時間、消耗的 AI Credits、修改的程式碼行數，以及依模型細分的 Token 用量。這些資訊有助於比較真實任務，但無法解釋每次路由決策，也不會顯示被捨棄的中間草稿。

提示與 Patch 之間的黑盒子

GitHub 描述了完整計算各工作流程階段用量、具備逾時與取消行為的受限執行、隔離式審查、經過驗證的路由，以及在工作流程無效或遭取消後安全套用 Patch。這些控制措施能降低營運風險，但不能證明路由本身或最後產生的程式碼一定正確。

GitHub 也表示，預覽版會保留中間草稿，直到能回傳一個一致的完整結果。這讓使用者更難判斷任務究竟一直留在 Single、經過 Cascade 升級，還是走過 Critique 與修訂流程。

有使用者直接指出了這個可觀測性缺口：

「我下一個最想要的產品功能，是一份可讀的追蹤紀錄，清楚說明哪個模型做了什麼，以及路由器為什麼切換。」— X 上的 @_Mazzana

沒有路由收據，開發者就無法完整把任務的成本、延遲與最終 Patch，對應回產生它的工作流程。

如何測試預覽版，避免過度解讀結果

在把 HydraFusion 設為團隊預設之前，先把它當成一項實驗：

1. 建立乾淨的分支或 Worktree，並記錄開始時的 Commit。
2. 分別測試一個例行修正、一個跨檔案變更，以及一個具歧義的任務，並為每項任務準備可重現的驗收檢查。
3. 在第一個提示中寫清楚預期行為、限制條件與測試指令。
4. 檢查最後的 Diff，確認沒有修改無關檔案，並自行執行相關測試。
5. 記錄工作階段持續時間、可見的 AI Credit 或 Token 用量、測試結果，以及任何可見的重試或升級訊號。
6. 累積多個任務後，再拿 HydraFusion 與固定模型比較。

不要只憑回應長度猜測背後使用了哪種模式。回應很長，可能只是因為 Repository 較複雜，不代表一定用了 Critique。對於冗長、多輪、對延遲敏感或後果嚴重的工作，請保留固定模型作為備援：GitHub 目前建議預覽版先處理第一輪任務，並在發布指南中將更強的多輪表現列為未來重點。

HydraFusion 常見問題

可以手動選擇 Single、Cascade 或 Critique 嗎？

目前沒有文件記載可用的 HydraFusion 模式指令。現階段能做的是選擇 HydraFusion，再讓執行期自行決定；如果你需要確定的路由，就使用固定模型。

HydraFusion 如何計費？

GitHub 表示，使用量是根據 HydraFusion 實際使用的模型所消耗的 Token 計算，並按照各模型的標準費率收費，詳情請參考官方公告。基準測試中的成本降幅不是所有客戶都能享有的通用折扣，而多階段工作流程的用量也可能高於直接處理一個請求。

當任務重要到值得透過選擇性升級或審查來提升成果，同時又具備足夠清楚的結構、方便驗證時，HydraFusion 最能展現價值。對快速工作來說，Single 的簡潔可能更重要；至於冗長或高風險任務，在有足夠的 Repository 實證支持額外協調機制之前，行為可預測的固定模型仍可能是更好的營運選擇。