GitHub HydraFusion 在 Copilot 執行期編排多模型，以級聯與交叉審查控制成本

GitHub 於 9 月 4 日推出 Project HydraFusion，把模型選擇從提示送出前的一次決定，改成執行期間的複合工作流。使用者在 Copilot CLI 將它當成一個模型選取，系統則依推理、程式生成、除錯及工具使用能力訊號，從三種路徑擇一：`Single` 直接交給單一模型；`Cascade` 先由較省資源的模型產生解法，未通過品質閘門才升級；`Critique` 則由另一模型家族在唯讀、無工具的環境審查草稿，再讓原模型修訂一次。

這套隔離方式值得注意。解題模型共享工作區並沿用 Copilot 權限控制，審查模型不能修改儲存庫；流程若取消或驗證失敗，系統不套用任何 patch。執行器會記錄每一段的角色、結果、延遲、診斷與成本，計費也涵蓋草擬、審查、重試、升級及備援所消耗的全部 token。因此，多呼叫模型不必然更便宜，節省取決於路由器能否讓足夠多的任務停在低成本路徑。

GitHub 以固定策略測試 TerminalBench 2.1、DeepSWE 與內部 CheckpointBench。相較 Claude Opus 5，最佳調校組態在 TerminalBench 2.1 的驗證品質高 4.9 個百分點、估算成本低 67%；DeepSWE 則便宜 36%，但品質低 1.5 個百分點；CheckpointBench 成本低 65%、品質低 0.1 個百分點。這些都是 GitHub 控制的離線結果，且採用最佳組態；官方沒有公開路由模型、品質閘門、逐任務分布或端到端延遲，內部基準也無法獨立重現。

預覽版已向所有 Copilot 方案開放，但官方建議先用於範圍明確的首輪單提示任務，多輪長工作階段仍在開發。工程團隊接下來應觀察實際儲存庫中的尾端延遲、失敗回退、成本可預測性，以及是否能匯出足夠的路由紀錄進行稽核；若這些控制不可見，模型編排層也可能成為新的供應商依賴與除錯盲點。