模型選擇器正變成協調流程選擇器
GitHub 在 9 月 30 日將 HydraFusion 從命令列移到編輯器中。這項研究預覽版現在可在 VS Code 1.140 及更新版本，以及 GitHub Copilot 應用程式中執行，這將一個相當不尋常的概念擺在一般開發者面前：別再挑選模型，改為挑選工作流程。
HydraFusion 不是模型。它是一個層，會針對每一回合決定任務需要多少個模型角色。
單一要求的三種形態
Single 是熟悉的情況。由一個模型處理請求，就像 Copilot Auto 目前的運作方式。
Cascade 一開始的成本較低。由效率導向的模型撰寫初稿，品質關卡會決定接受，或將工作升級給更強大的模型。重點是讓例行編輯交給便宜模型，把昂貴模型留給真正需要它們的問題。
Critique 花更多成本換取更安全的結果。一個模型負責草擬，另一個來自不同模型家族的模型擔任唯讀評論者，草擬模型會根據回饋修訂一次。評論者從不碰程式碼，避免整個循環變成兩個模型在爭論。
與 Auto 的差異在於架構。Auto 決定你的提示應由哪一個模型接收。HydraFusion 決定這一回合需要多少角色，以及它們如何互動。這是智慧控制所在位置的有意義轉變。以往你挑選模型，是因為它更擅長你這種工作。在這裡，你挑選的是最佳化策略，讓平台在底層組合模型。
經濟效益真實存在，卻也是自行回報的數據
問題在於計費。GitHub 會依照每個所選模型的標準費率，按權杖計費。一次 Critique 執行至少會呼叫兩個模型，因此每次請求的成本可能高於單次呼叫。Cascade 的設計是將簡單工作往下推，以降低成本。節省並不是任何模型提供折扣，而是一個賭注：大多數回合都不需要最好的模型。
GitHub 自家控制的評估指出，在三項程式碼代理基準測試中，相較於其 Claude Opus 5 基準，工作流程成本降低 36% 至 67%，品質在 TerminalBench 2.1 上高出 4.9 個百分點，在 DeepSWE 上低 1.5 個百分點，在 CheckpointBench 上低 0.1 個百分點。這些是供應商在 GitHub 自家測試設定中產出的數字。它們是關於你儲存庫的假設，不是保證，而且參與 HydraFusion 的模型池尚未完整公布。任何以預覽版為基礎打造的東西，都應將路由行為視為可能隨時變更而不另行通知。
另外還有明顯的延遲成本。一份草稿加上一次審查，會比單一回答花費更久。Business 與 Enterprise 方案的團隊必須密切留意使用量儀表板，因為系統會決定何時升級，而這個決定並非沒有代價。
無法檢查的最佳化難以信任
路由的棘手之處在於，做出決定的是平台，而不是開發者。你可以在事後看到是哪個模型回答，但不容易看出系統為何選擇某個工作流程、品質關卡測量了什麼，或一次 Cascade 執行有多接近升級。GitHub 的基準測試說法描述的是自家測試集上的平均，而平均會掩蓋真正重要的案例。
這個落差使協調流程變成治理問題，而不只是純技術問題。工程團隊若必須解釋為何某個提取要求會由兩個模型家族審查並據此收費，就需要路由遙測資料，而預覽版尚未提供。補救之道不是避開這項功能，而是像測試任何內部機制不透明的相依項目那樣測試它：在一組固定、無聊的儲存庫任務上，衡量完成任務的成本與單一前沿模型相比如何，並觀察重試與審查工作量，而不是只看某一次選擇的表面價格。
與 Auto 的比較值得記住。Auto 回答的是哪個模型最適合某個提示。HydraFusion 回答的是一個回合值得投入多少流程，而流程向來是軟體工作中昂貴的部分。
有趣的副作用是，它讓模型選擇變得不那麼情緒化。開發者會對特定模型產生依附，而這些依附通常建立在少數幾次令人難忘的成功上。一個依任務類型路由、並在失敗時升級的系統，悄悄承認了沒有單一模型能贏得每個類別，這件事早已成立，卻很少被付諸行動。
編輯器的下一個角落正為此打造
Insiders 版本已經顯示接下來會往哪裡走。一項名為 Compare Agents、標示為 Run Multiple Agents 的功能，會將同一個提示平行傳送給多個代理，每個代理各自在自己的 git worktree 中運作，然後由裁判代理選出優勝者，或將候選名單交給真人。
有趣的細節是裁判會看什麼。它會比較變更的檔案與差異統計、測試結果、建置狀態、診斷、時間，以及架構差異。它會執行測試套件。它不會要求另一個語言模型閱讀程式碼並猜測。這是個小決定，卻有重大後果，因為這表示比較是根據專案的實際狀態，而不是模型對專案的意見。
同一個版本的其他部分是較低調的基礎架構，只有在代理平行執行時才會顯得重要。多重資料夾工作階段可讓一個工作階段中的每個對話使用自己的資料夾或工作樹，因此變更不再互相衝突。遠端委派會將任務交給已連線的遠端代理主機。共用工作樹資料夾會重複使用被忽略的目錄，以免在每個分支上重新安裝相依項目。Dev Containers 現在會在閒置五分鐘後停止，並視需求重新啟動。
治理功能持續與功能一同出現在相同的提交中
這個版本中面向 IT 的那一半並非事後添加。當 AI 功能無法使用時，編輯器現在會說明最低所需版本，而不是給出通用的更新提示。系統管理員可以為 Auto 模型設定預設層級。新的 OpenTelemetry 設定可將 Copilot 使用量對應回個別開發者。
把這三項放在一起看，輪廓就很清楚。一個會在多個回合中協調多個模型的平台，會產生成本、遙測與權限問題，而這些是單一模型自動完成從未有過的。成本歸屬不再只是財務上的好奇，而是讓這項功能接近正式環境的先決條件。
多模型審查在嚴謹的工程團隊中早已是標準做法。你會請一個模型撰寫，另一個模型尋找錯誤，或先嘗試快速模型，並在輸出令人失望時升級。HydraFusion 把這個習慣自動化，這很方便，也移除了某些團隊喜歡手動做出的決定。
預覽功能應該維持預覽狀態多久，是個合理的問題。工具推出的速度比圍繞它的政策更快，而價格可預測性往往是第一個犧牲品。一次 Critique 執行若悄悄在大型儲存庫上呼叫兩個前沿模型，可能在任何人注意到之前就花掉真金白銀。HydraFusion 是否會升級為預設功能，與其說取決於路由是否有效，不如說取決於 GitHub 能否讓帳單清楚到有人願意簽核。