GitHub Copilot 近期推出了一項名為 Project HydraFusion 的研究預覽功能，旨在透過運行時模型編排（Runtime Model Orchestration）來提供頂尖等級的編碼智能。這項技術的核心在於將開發者的工作流程視為一個優化問題，不再依賴單一的靜態模型，而是在執行過程中動態地建構執行計畫，並調度來自不同供應商的多個模型來處理核心的開發任務。
背景與核心挑戰
在目前的 AI 編碼助手實作中，開發者通常面臨一個兩難：使用參數規模較大的頂尖模型（Frontier Models）雖然能處理複雜邏輯，但推論速度慢且成本高昂；而輕量化模型雖然快速且便宜，但在處理多步驟推理或複雜除錯時容易出錯。為了打破這個僵局，Project HydraFusion 引入了模型路由（Model Routing）機制，這是一種根據輸入請求的複雜度與需求，自動將任務分配給最適合模型的技術。系統會針對進入的提示詞（Prompts）進行能力信號評估，判斷該任務是否涉及多步驟推理、自動化程式碼生成、結構化除錯或進階工具調用，進而決定最合適的執行路徑。
三種動態執行模式
HydraFusion 根據任務的複雜度與上下文，將請求路由至三種不同的運行時執行模式，以平衡效能、品質與成本。
第一種是單一模式（Single）。當系統評估單一模型已具備足夠能力獨立解決任務時，會直接由該模型執行。這種模式的主要目標是極大化速度並降低延遲，適用於簡單的程式碼片段生成或基礎查詢。
第二種是級聯模式（Cascade）。這是一種循序漸進的過濾機制，首先由一個高效能的輕量模型生成初步解決方案草案，接著由一個品質閘門（Quality Gate）進行評估。如果輸出結果符合要求，則直接採納；若不合格，任務將被升級（Escalate）交由能力更強的頂尖模型處理。
第三種是評論模式（Critique）。此模式模擬了軟體工程中的橡皮鴨除錯（Rubber Duck Review）模式。首先由一個草擬模型產生初步成果，隨後由一個獨立且僅限讀取的評論模型（Critic Model）進行審核。值得注意的是，這個評論模型來自不同的模型家族，且不具備工具執行權限，以確保審核的獨立性。最後，原先的草擬模型會根據評論結果進行一次結構化的修正。
生產等級的運作原則
為了確保在實際生產環境中的穩定性，HydraFusion 建立了五項基本運作原則。首先是完整計費（Complete Accounting），精確追蹤工作流中每個環節（如草擬、評論、修正、升級、重試與回退）的 Token 成本與用量。其次是受限執行（Bounded Execution），對所有操作強制執行超時限制與取消處理，避免模型陷入無限循環。
此外，系統實作了隔離審核（Isolated Review），確保評論步驟在無工具環境中進行，防止審核者直接修改程式碼。在應用階段，則採用失效安全程序（Fail-safe Application），若驗證失敗或執行被取消，系統會直接拒絕套用補丁。最後是驗證路由（Validated Routing），在運行啟動前先預檢模型的可用性與綁定狀態，確保請求不會被路由至失效的端點。
實務影響與效能表現
根據在三個代理編碼基準測試（Agentic Coding Benchmarks）中的離線評估，HydraFusion 在維持或提升品質的同時，大幅降低了成本。在 TerminalBench 2.1 測試中，其驗證後的任務品質比 Claude Opus 5 提升了 4.9 個百分點，而預估成本卻降低了 67%。
在 GitHub 內部的 CheckpointBench 測試中（該測試基於真實的 Copilot 代理編碼會話，並錨定於公開儲存庫的不可變提交），HydraFusion 的平均會話得分與 Claude Opus 5 的基準線幾乎持平（僅差 0.1 個百分點），但工作流成本降低了 65%。這證明了透過多模型路由，可以在不犧牲頂尖模型性能的前提下，顯著優化資源利用率。
目前的限制與獲取方式
Project HydraFusion 目前仍處於研究預覽階段。使用者可以透過 GitHub Copilot CLI 的 /experimental 設定來啟用此功能。開發者需更新 CLI 環境，執行 /experimental on 並在 /model 介面中選擇 HydraFusion。其費用將根據執行過程中實際調用的底層模型 Token 費率進行計算。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。