GitHub 在 2026 年 9 月 4 日推出 HydraFusion 研究預覽，讓 Copilot 依任務選擇模型分工。值得評估的情境，是需求已明確、修改有一定複雜度，而且能驗證成果的工作。如果連要保留哪些行為都還沒決定，增加模型數量不會自動補上產品需求。
這篇整理 Copilot CLI 的啟用方法、與 Auto 和 Rubber Duck 的差別，並提供可改用的任務範本。資料截至 2026 年 9 月 7 日；採用建議與成本例子屬分析，未進行實機評測。
GitHub HydraFusion 是什麼
GitHub Copilot 是協助撰寫與修改程式的開發助手；其中的 Agent 能讀取專案、使用工具並處理多步驟工作。HydraFusion 是 Copilot 裡的多模型編排功能，會在執行任務時決定如何分工，目標是減少開發者手動換模型與安排複查的負擔。 GitHub 官方公告 將它定位為研究預覽，並非可另行下載的一組模型權重。
它處理的是「這項工作如何交給模型完成」。例如修正匯入流程，除了產生程式，還可能需要檢查錯誤分類與相容性；開發者仍要提供需求，並決定什麼結果可以接受。多模型的實用價值，應看它有沒有減少後續補修，而不是畫面上出現幾個模型名稱。
HydraFusion 與 Auto、Rubber Duck 的差別
已使用 Copilot 的開發者，可以從目前缺少哪個步驟來選擇。Auto 著重模型選擇，Rubber Duck 補上第二份意見；HydraFusion 則會選擇整段執行方式。
| 功能 | 主要處理的問題 | 適合的使用需求 |
|---|---|---|
| Auto | 依任務與可用性選模型 | 不想每次手動挑模型 |
| Rubber Duck | 另一個模型檢查計畫或修改 | 已有工作成果，需要找遺漏 |
| HydraFusion | 選擇直接解題、逐級升級或交叉複查 | 願意讓系統安排解題流程 |
Auto 文件 說明它同時考慮任務複雜度與服務狀態，也受方案與管理政策限制。因此，Auto 並非隨機挑一個模型；如果日常任務已能順利完成，沒有必要只因為多了研究預覽就全部切換。
三種分工方式
HydraFusion 目前有 Single、Cascade、Critique 三種模式：Single 由單一模型完成；Cascade 先嘗試，再由品質關卡決定是否升級；Critique 由不同模型家族的唯讀審查者提出意見，原模型再修改一次。這些是系統可選的流程，不代表每個請求都會啟動所有步驟。
已有成果時的第二份意見
如果只是想檢查現有計畫，可以沿用 Rubber Duck 。它不自行修改檔案，主 Agent 再決定如何採納建議；官方目前列出主 Agent 使用 Claude 或 GPT 模型的條件。下列是可輸入 Copilot CLI 的中文請求範例，重點是指定要找的問題：
/rubber-duck 檢查目前修改是否漏掉空值、重複資料與錯誤回復。
只提出具體問題與理由，不擴大功能範圍。第二份意見仍需要測試支持。例如兩個模型都認為應該忽略空白欄位，但產品需求要求回報錯誤，兩者一致也不能讓實作變正確。關於 VS Code 的相關入口，可參考 VS Code 1.135 與 Rubber Duck 介紹 。
Copilot CLI 如何開啟 HydraFusion
以下適用已具備 Copilot 使用資格的 CLI 使用者。HydraFusion 公告列出所有 Copilot 方案可參與；組織提供的帳號，還要符合管理員的 CLI 政策。這是目前已確認的 CLI 入口，不能由此推定所有 IDE 都有相同選項。另依 個人方案文件 ，Free／Student 一般模型存取仍限 Auto；文件尚未解釋此研究預覽是否為例外，實際能否選取應以帳號清單為準。
尚未安裝 CLI 時，可依 官方安裝文件 選擇套件管理器。以下以 npm 示範，需要 Node.js 22 以上；已安裝者可跳過安裝，直接在專案目錄啟動。
# 尚未安裝時執行，需要 Node.js 22 以上
npm install -g @github/copilot
# 在準備處理的專案目錄啟動
copilot首次啟動時確認專案目錄可信，未登入則輸入 /login 完成 GitHub 登入。接著在 Copilot 的互動輸入框依序執行以下指令；它們不是一般終端機的 shell 指令。
/update
/experimental on
/model在模型清單選擇 HydraFusion (Research Preview)。若沒有出現，先核對版本、登入帳號與組織政策；仍不可用就保留現有模型，不必為了顯示新功能而自行放寬組織設定。想回到原本流程時，可以用 /model 選回原先可用的模型。
Copilot CLI 使用文件 說明工具執行可能要求核准。啟用 HydraFusion 不等於必須開放所有權限；只授予當次工作所需的存取，能降低「需求還沒確定，修改卻已經擴散」的機會。
哪些任務值得交給多模型分工
建議從有明確完成條件的專案修改開始，例如修正跨檔案錯誤處理、補足已知缺陷的測試。下表是採用判斷，並非 GitHub 公布的路由規則，也不保證系統會選到特定模式。預覽目前顯示流程階段，會等完整結果產生後再交付，暫不即時展示中間草稿；需要每一步都介入的工作，可先分段討論。
| 任務情境 | 建議 | 判斷理由 |
|---|---|---|
| 修正匯入流程，保留既有 API，補錯誤案例測試 | 適合評估 | 有跨檔影響，也有可核對的結果 |
| 補一段說明、改變數名稱、詢問語法 | 先維持原流程 | 任務簡短，額外協調可能增加等待 |
| 重新設計產品，但功能與相容性尚未決定 | 先釐清需求 | 無法驗收的需求，也難判斷哪份答案較好 |
| 需要每一步都立即觀察並調整的探索工作 | 先分段討論 | 預覽暫不展示中間草稿，不利於逐步調整 |
可直接改用的任務提示詞
以下為自行撰寫的範本，貼到 Copilot CLI 的任務輸入框即可依專案調整。它把功能、修改範圍與驗收放在同一份需求裡；不要求模型憑空增加工作。使用前先將路徑與測試命令換成專案實際名稱。
目標：修正 CSV 匯入功能的錯誤回報。
修改範圍：
- 匯入模組 src/importer/ 與對應測試。
- 保留既有公開 API、資料格式及正常匯入行為。
- 不新增套件，不修改其他功能。
驗收條件：
- 空白必要欄位、重複識別碼、無效日期各有明確錯誤。
- 正常資料仍可匯入。
- 使用專案既有測試命令驗證以上情境。
完成時列出：
- 修改檔案與理由。
- 實際執行的測試及結果。
- 尚未驗證的條件。
若需要超出範圍、需求互相衝突或缺少關鍵資訊，
先停止並說明；完成驗收後不要追加其他工作。這份範本不需要規定誰先寫、誰複查，避免把系統能選擇的流程全部鎖死；但「哪些檔案能改」和「什麼情況要停」仍由提出需求的人決定。若需要變更資料格式，應另行討論遷移與相容性，不能讓 Agent 自行把它當成順便整理。
省下 67% 成本，能套到實際帳單嗎
不能直接套用。GitHub 公布的是受控離線評測，表中為其最佳調校配置相對 Opus 5 的結果，並非訂閱折扣；三項評測也沒有全部提高解題品質。
| 評測 | 估算流程成本 | 驗證正確的任務比例差異 |
|---|---|---|
| TerminalBench 2.1 | 降低 67% | 增加 4.9 個百分點 |
| DeepSWE | 降低 36% | 減少 1.5 個百分點 |
| CheckpointBench | 降低 65% | 減少 0.1 個百分點 |
來源為 GitHub 評測說明 。測試統一使用 medium 推理設定與相同工具、限制；結果只適用當時的模型池及設定。其中 CheckpointBench 是 GitHub 內部評測。研究預覽目前優先建議範圍明確、單次提示就能交付的任務，長篇反覆互動仍是後續改善方向。
對實際專案，比較方式應該是完成同一項驗收要求的總用量、等待時間與人工補修。假設原流程一次完成花 100 個成本點，另一流程第一次只花 80 點，之後補修又花 30 點，合計是 110 點。這是無幣別的示意算式，沒有對應任何模型實測；它說明只看第一次回覆會漏算後續補修。
用量與額外預算
HydraFusion 的用量依它實際呼叫的模型與 token 計算。 Copilot 模型價格文件 區分輸入、輸出與快取項目，再換算成 GitHub AI Credits；不同方案包含的額度也不同。因此，即使沒有另外的 HydraFusion 月費項目，也不代表啟用後不消耗原方案額度。
在 CLI 執行 /usage 可以查看這個工作階段使用的 AI Credits、時間與各模型 token 明細。建議在新任務開始與結束各記一次，並在同一欄加上「驗收通過、需要補修、未完成」；不要用產生幾行程式碼代替完成度。
個人方案額度用完後，可依 官方個人計費說明 依資格選擇升級、設定額外用量預算，或等下個週期。目前或曾經透過 iOS／Android 的 GitHub Mobile 訂閱 Copilot 的帳號，不能購買額外 AI Credits，此例外列於前述模型價格文件。開始評估前先確認目前帳號的追加預算設定，避免把研究預覽的可用資格誤解為免費試用。此處不建議為了測新功能就先提高預算。
交付結果的驗收方式
無論使用 Single、Cascade 或 Critique，最後仍以專案需求驗收。可以先閱讀 git diff，確認修改範圍，再核對既有測試與新增案例；若只收到「已完成」的敘述，卻沒有可追查的修改與測試結果，就不能只憑模型一致同意而接受。
處理範本中的 CSV 任務時，驗收至少要看正常資料是否仍可匯入，以及三種異常資料是否各有測試。若模型藉由放寬檢查讓測試通過，卻改變原本要拒絕的資料，那是需求偏移，應退回修正。這種核對比重跑多次、直到得到滿意的自然語言結論更有用。
採用 HydraFusion 的理由，可以是減少手動協調、降低補修次數，或讓既有品質要求以較低費用完成。當這些改善沒有出現在實際工作裡，保留 Auto 或原本單模型流程也合理；研究預覽適合先放進範圍清楚的任務，再依成果決定是否擴大使用。
常見問答
入口、計費與品質驗收是三個不同問題，使用時需要分別確認。
所有 Copilot 方案都能用，代表完全免費嗎？
不代表。功能可用資格與方案額度分開，實際模型用量仍依 Copilot 計費規則處理。先確認帳號剩餘額度與追加預算，再決定是否使用。
選了 HydraFusion，就一定會有第二個模型複查嗎？
不一定，系統也可能選擇 Single。若需求只是檢查既有修改，可在可用條件下直接請 Rubber Duck 提供第二份意見；即使已複查，測試與人工 review 仍要保留。
沒有可重現測試的專案適合使用嗎？
可以先把人工驗收步驟與預期輸出寫下來，例如固定輸入會得到什麼結果。若連這些條件都無法確定，先處理需求與驗收，會比直接增加模型分工更容易判斷修改是否正確。
參考來源
- GitHub: Project HydraFusion: Frontier quality via multi-model orchestration (HydraFusion 研究預覽)
- GitHub Docs: About Copilot auto model selection (Auto 模型選擇)
- GitHub Docs: About the rubber duck agent (第二模型複查)
- GitHub Docs: Installing GitHub Copilot CLI (CLI 安裝方式)
- GitHub Docs: Using GitHub Copilot CLI (CLI 操作與用量查詢)
- GitHub Docs: Models and pricing for GitHub Copilot (模型與計費)
- GitHub Docs: Usage-based billing for individuals (個人方案用量計費)