AI Newsway

GitHub的HydraFusion不再挑模型,而是搭一條工作流

Copilot研究預覽在三套智慧體程式設計基準上追平Claude Opus 5,預估成本最多低67%

|6分鐘閱讀0
Source code on a developer screen: HydraFusion decides how many models should touch a task like this, and in what order.
Source code on a developer screen: HydraFusion decides how many models should touch a task like this, and in what order.

GitHub最新一輪Copilot實驗裡最值得玩味的數字不是質量分,而是賬單:在一項高難度的終端基準上成本低了67%,得分卻比Claude Opus 5高出4.9個百分點。這是GitHub就Project HydraFusion公佈的頭號結果。這項研究預覽不再追問某個程式設計任務該交給哪個模型,而是開始追問該動用幾個模型、按什麼順序動用。

核心要點

  • HydraFusion在TerminalBench 2.1上以低67%的預估成本領先Claude Opus 5基線4.9個百分點,在另外兩套基準上也分別以低36%和低65%的成本打成平手。
  • 它不是把請求路由給某一個模型,而是為每個請求組裝執行計劃,可以起草、升級到更強模型,或引入來自競爭廠商模型家族的只讀評審。
  • 所有Copilot套餐都能在Copilot CLI中開啟,除了實際呼叫模型的常規token費率之外不另收費。

為什麼成本那一行比質量那一行更要緊

智慧體程式設計存在一個基準表格往往掩蓋的經濟性問題:把冗長、頻繁呼叫工具的任務整個交給前沿模型的團隊,會為迴圈中的每一段都付出前沿價格,包括那些更便宜的模型本就能正確收尾的環節。HydraFusion正是GitHub為每一段單獨定價的嘗試。

GitHub公佈的證據來自三套智慧體基準的離線執行,以Opus 5和GPT-5.6 Sol作參照,並將所有模型的推理檔位固定在中等。三項結果中有兩項本質上是"同等表現、更低價格":側重跨檔案倉庫作業的DeepSWE與Opus 5相差1.5分以內,成本低36%;CheckpointBench的差距僅0.1分,成本低65%。唯一齣現明確質量增益的是TerminalBench 2.1,而GitHub也指出這套基準相對飽和——這也是它同時跑另外兩套的原因之一。

CheckpointBench值得多看一眼,因為它出自GitHub自家之手。公司從真實的Copilot會話軌跡中彙編而成,把每段對話錨定到公開倉庫的某個不可變提交上以便重放,再按語言、任務型別和難度做了平衡。它比公開排行榜更接近生產流量,但GitHub之外的任何人都無從審計。

開發記錄裡還附了一條異常坦率的腳註:8月11日至25日期間,評測環境中發生兩次執行故障併產生了無效結果,這些資料在繪製趨勢線之前已被剔除。

一條提示詞如何變成多模型計劃

HydraFusion會讀取推理深度、程式碼生成、除錯和工具使用等能力訊號,然後在它判斷能夠達標的三種形態中挑最便宜的一種。可能只由一個模型直接作答;也可能由快速模型起草,再由質量閘門決定是直接交付還是升級給更強的模型;還有一種被GitHub類比為"小黃鴨評審"的模式——起草模型產出成果,來自另一個模型家族的評審模型在不掛載任何工具的情況下閱讀它,起草模型則獲得且僅獲得一次結構化的修訂機會。

這些閾值不是人工設定的。GitHub針對凍結的基線,對分能力得分跑了束搜尋,並且是三套基準一起調優,而不是死盯其中任何一套——當拿得出手的那套基準恰恰是飽和的那套時,這樣的取捨尤為重要。

到目前為止,[HydraFusion的]推理與解題能力已達到甚至優於Opus。

這一評價來自在內部測試該系統的一位微軟首席軟體工程師。

動手之前必須先鎖死的事

把多個模型對準同一棵工作樹,會帶來單模型迴圈不會有的失敗形態:評審者改動了它本該評判的程式碼;被取消的執行留下只打了一半的補丁;賬單分散在六個環節上,沒人說得清歸屬。GitHub的答案是一組硬性約束——評審模型不帶工具執行、無寫入許可權;一旦校驗未過或被取消,補丁整個丟棄而非部分應用;每一段都配有超時與取消控制代碼;執行之前先校驗模型繫結;token開銷則把起草、評審、修訂、升級、重試和回退全部彙總,讓整條工作流只掛一個數字。

如何開啟,以及它仍做不到什麼

入口在Copilot CLI:更新客戶端、啟用實驗性開關,HydraFusion就會出現在模型選擇列表裡。需要注意的是,觸發兩次升級或走了評審環節的任務,會比一次成型的同類任務更貴,因為計費跟隨實際呼叫的模型。

GitHub正引導早期使用者把規模大、邊界清晰的單次提示任務交給它,並表示更長的迭代式會話是下一個工程目標。它也主動承認了一處粗糙:預覽版在拿出一個連貫答案之前不會展示中間草稿,理由是被丟棄的工作不該看起來像成品;但實際體驗就是盯著進度指示器,幾乎不知道里面在發生什麼。反饋正在Copilot社群討論帖中收集。

後市觀察

把這些數字當作假設而非結論。它們是離線得出的,綁定於特定的模型池和一套定價假設,而這次預覽的存在意義,恰恰是驗證真實開發者把雜亂活兒丟進來之後它們是否依然成立。如果成立,競爭的焦點就會從"誰的模型最強"轉向"誰排程得最好"——這樣的轉向,對能接入眾多供應商的平臺廠商遠比對任何單一實驗室更有利。它出現的時點也不尋常:GitHub正在自家基礎設施上消化由智慧體帶來的流量激增,這一點我們在關於該平臺提交量增長的報道中做過梳理。

常見問題

Project HydraFusion能在GitHub Copilot CLI之外使用嗎?

暫時不能。它只在Copilot CLI內、開啟實驗性配置後提供。GitHub尚未給出推廣到IDE擴充套件或Copilot應用的時間表。

它會在Copilot訂閱費之外額外收費嗎?

沒有單獨收費。你按常規token費率為工作流呼叫的每個模型付費,也就是說一項任務的價格取決於它經過了多少個環節才收尾。

HydraFusion用的是哪些模型?

GitHub沒有公佈模型池,只說橫跨多家供應商,並表示評審模型是有意選自與起草模型不同的家族。Opus 5和GPT-5.6 Sol是評測基線,未必是模型池的成員。

對這篇文章有什麼感想?

SJ
載入中...

相關文章

LLM修復程式碼時弄壞可用程式碼的次數,是真正修好次數的十倍
Developer Tools

LLM修復程式碼時弄壞可用程式碼的次數,是真正修好次數的十倍

一項arXiv研究測得LLM修復迴圈破壞正確程式的比率為0.261,修復缺陷程式的比率僅0.023,並找到了驅動這一行為的內部方向。

Seung Jung4 天前
AI智慧體向RubyGems傾瀉2000多個包,新使用者註冊被關閉四天
Developer Tools

AI智慧體向RubyGems傾瀉2000多個包,新使用者註冊被關閉四天

一份取證報告還原了5月的GemStuffer行動:AI智慧體推送兩千多個gem,迫使RubyGems凍結新使用者註冊四天。

Seung Jung5 天前
OpenAI向開發者開放全雙工語音模型,每分鐘5美分
Developer Tools

OpenAI向開發者開放全雙工語音模型,每分鐘5美分

OpenAI的全雙工語音模型GPT-Live-1已通過API開放,每分鐘0.05美元,在Tau3基準上取得86.2%,遠高於前代的45.7%。

Seung Jung6 天前
Cognition SWE-2逼近前沿僅差一分,成本低64%
Developer Tools

Cognition SWE-2逼近前沿僅差一分,成本低64%

Cognition稱SWE-2在FrontierCode 1.1 Main上得分50.0%,僅落後Fable 5.1一分,成本卻低64%,基座是一款中國開源模型。

Seung Jung6 天前
Microsoft單月修補966個漏洞創紀錄,瓶頸轉移到防禦端
Developer Tools

Microsoft單月修補966個漏洞創紀錄,瓶頸轉移到防禦端

Microsoft九月修復966個漏洞,2026年累計逼近2,750個。資安團隊直言,現在難的不是發現,而是分流排序。

Seung Jung20 小時前
Meta 透過 MCP 把 WhatsApp Business 設定交給 Claude 與 Codex
Developer Tools

Meta 透過 MCP 把 WhatsApp Business 設定交給 Claude 與 Codex

Meta 將 WhatsApp Business 帳號設定開放給 AI 程式撰寫代理,新推出的 WhatsApp Business Tools MCP 伺服器讓 Claude Code 與 Codex 從註冊電話號碼一路處理到範本與 Webhook 設定。

Seung Jung20 小時前