返回所有文章
發佈於 · 作者 Renaud Deraison

Bromure Agentic Coding 現已內建 Fusion 模式

OpenRouter 公佈了一個引人注目的結果:一組模型構成的評審團,經過裁判與綜合,勝過任何單一前沿模型。我們在 Bromure Agentic Coding 內部從零把這套技術重新實作了一遍——沒有任何東西會經過 OpenRouter。由於產品本就坐在你的編碼代理與模型 API 之間的線路上,3.0 版把我們自己的 Fusion 直接放到那裡。在標題列翻動那個 ⚡,每一段提示詞就由最多三個模型同時作答。一位裁判把它們調和,一位綜合者寫出結果,Claude Code 收回一個答案,彷彿出自單一模型之手。用你自己的金鑰或訂閱,而且軌跡記錄了每一段歷程。

OpenRouter 上個月讓我們看到一件我們立刻就想要的東西:一組模型構成 的評審團——其中一個負責裁判這組評審團,另一個負責寫出裁決——勝過 榜上最強的那一個單一模型。它同時詢問好幾個模型,再把它們的答案綜合 成一個。他們的招牌 fusion 在一項深度研究基準上拿到 69.0%,而 Fable 5 單獨上場時只拿到 65.3%。我們並不是去串接他們的服務——而是自己把 這套技術重新實作了一遍,往下挪一層,挪進你的編碼代理本來就在對話的 那個代理伺服器裡。Bromure Agentic Coding 3.0 用一道閃電把它送了出來。

這個機制很乾淨。你把提示詞平行送給好幾個模型。一位裁判讀過每一份 答案,標出哪裡彼此一致、哪裡互相矛盾、各個模型獨自掌握到什麼、又集體 漏掉了什麼。接著一位綜合者從那份分析寫出最終答案,而不是憑肉眼掃過 那些草稿。 OpenRouter 的 Fusion 文章 把我們重新實作的這套機制講得很清楚,而那個增益的幅度讓我們吃了一驚:在某個案例裡,把 一個模型和它自己配對,分數還是上升了。多數增益都來自那個綜合步驟。

我們知道想把它放在哪裡。Bromure Agentic Coding 把 你的代理跑在一個用過即丟的 Linux VM 裡,同時主機上有一個中間人代理 伺服器盯著它送往 api.anthropic.com 的每一個位元組。我們本來就握有 那條線路,所以這組評審團就在那裡開會,那裡你的程式碼、提示詞與憑證 永遠不會繞道經過任何別人的路由器。Fusion 是那個代理伺服器的一種行為。 它把一個對外的 Claude 請求變成一場簡短的委員會會議,再以代理所預期 的線路形狀回傳單一答案。Claude Code 永遠不會知道 GPT-5.5 和 Grok 也 在現場。

一道閃電。

Fusion 只有一個控制項,就位於代理會話視窗的標題列裡。

代理會話標題列,Fusion 閃電呈深灰色、未啟用
未啟用 · 灰色閃電
代理會話標題列,Fusion 閃電亮起黃色、已啟用
已啟用 · 黃色閃電
Fusion 的全部 UI:會話標題列裡的那個 ⚡。左邊它未啟用,一道填實的閃電,呈深灰色,本次會話可用但關閉中。右邊它亮起黃色,已啟用。設定的模型少於兩個時,閃電會變空心並停用,因為只有一個成員的評審團就只是一個模型。位址列裡的 192.168.64.2 是代理跑在裡面的、每個設定檔專屬的 VM,那就是 Fusion 所坐的那條線路。

Fusion 跑在 Claude Code 會話上,因為它攔截的是 Claude 的 /v1/messages API——那是它懂得如何展開又重新組裝的請求。你在設定檔的 Agents 分頁裡設定兩到三個帶憑證的代理,挑選哪些供應商加入評審團、由 哪個模型擔任裁判,從此以後你唯一要碰的就只有那道閃電。灰色代表關閉, 單純的 Claude。黃色代表開啟,委員會召開。閃電是一個執行期旗標,所以 你可以在會話進行中切換它,不必重新啟動。

線路上發生了什麼。

閃電亮黃時,代理伺服器做的不只是把代理的請求轉發給 Anthropic。它會跑 底下這段順序。

在線路上 · 在每個設定檔專屬 VM 的 MITM 代理伺服器內CLAUDE CODE(在 VM 內)POST /v1/messages model: claude-opus-4-8 stream: true tools: [bash, edit, …] 以為:只有一個模型歷程 A · Claude · 最先詢問,工具完整api.anthropic.com · 非串流 · 真正的請求若是文字回合 → 融合 · 若是工具回合 → 直通評審團 · 同一個問題,平行進行歷程 A · Claude草稿(已在手)歷程 B · GPT-5.5api.openai.com歷程 C · Grokapi.x.ai裁判 · Opus 4.8分析草稿,不投票共識 · 衝突獨到 · 盲點產出 JSON 分析,非散文綜合者 · Opus 4.8寫出唯一答案,立基於上方的分析重新包裝 · Claude 自己的 id/model/usage 封套,內容換成融合後的文字以 Anthropic SSE 或單一 JSON 主體串流回去,正好是代理所要求的形狀會話軌跡 · 每一段歷程都是一個有名稱的 SubCall:anthropic · openai · x.ai · judge · synth(代理只發出了一次呼叫)一個答案回到代理
Fusion 在一段「對你說話」的回合裡所走的路徑。代理伺服器最先詢問 Claude,帶著代理真正的請求與工具。遇到純文字答案時,它會把同一個問題拿去問評審團的其餘成員,把每一份草稿交給一位裁判,由它回傳一份結構化分析,再由一位綜合者從那份分析寫出唯一的最終答案。代理伺服器接著把結果重新包進 Claude 自己的訊息封套,並以代理所要求的任何形狀串流回去。三個模型作了答,代理只讀到一個。

有一個細節讓這件事不只是個展示品:代理伺服器最先詢問 Claude,而且是 完整地詢問。歷程 A 帶著代理真正的請求,工具與完整逐字紀錄一應俱全, 帶著真正的憑證送往 Anthropic。代理伺服器強制它非串流,好讓自己能在 決定要怎麼做之前讀完整份答案。路由的決定,就繫於那第一份答案。

編碼代理改變了問題。

Fusion 跑在編碼代理裡,和跑在聊天框裡是兩個不同的問題,而這正是我最 自豪的部分。

在一個聊天產品裡,多數回合都是寫給人讀的散文,那正是裁判加綜合所打造 來處理的東西。但在一個代理式迴圈裡,多數回合都是動作:用 npm test 呼叫 bash、編輯這個檔案。每一個都是一個帶有結構化輸入的 tool_use 區塊,SDK 正等著去執行它。要是你在那裡把三個模型的意見融合成一段文字, 你就刪掉了那個工具呼叫,迴圈停擺。Fusion 會先看清楚再下手。它最先 詢問 Claude,好讓自己能檢視這個回合,然後依照答案的形狀來決定路由:

Claude 最先作答非串流 · 工具完整檢視這個回合什麼形狀?工具回合 → 直通stop_reason: tool_use (或任何 tool_use 區塊)原封不動重播 Claude 的真實回應不呼叫 GPT · 不裁判 · 不綜合 · 迴圈完整文字回合 → 融合stop_reason: end_turn,純文字答案跑評審團 · 裁判 · 綜合真正在對你說話的那個回合
回合路由器讀取 Claude 的第一份答案。工具回合,亦即任何帶有 tool_use 區塊或 tool_use 停止原因的回合,都是動作,所以 Fusion 會原封不動地重播 Claude 的真實回應並跳過評審團:不呼叫 GPT、不裁判、不綜合,也沒有剝掉命令的風險。純文字回合,那種對你說話的回合,才會經過完整的委員會。這個路由器讓代理式迴圈保持完整。

一場會話的大部分時間裡,Fusion 都是沉默的。那一長段跑測試、讀失敗、 打補丁的過程全都是工具回合,全速直通而過。委員會只在 Claude 開始解釋 而非動作時才召開:架構問題、它所發現之事的最終摘要。第二與第三個意見 正是在那些回合上掙到了價值。

裁判做的是分析,不是投票。

「用三個模型」的天真版本,就是多數決投票,或是去問一個模型「哪個最好?」 再把贏家轉發出去。兩種做法都丟掉了大部分訊號。一組評審團之所以勝過一個 模型,正是因為這些模型在不同的地方出錯,而投票只是把它們數一數而已。

裁判不產出答案。把問題和每一份標好出處的草稿交給它,它只會回傳一份 結構化分析,別無其他:

{
  "consensus":   [ "各份答案彼此一致的論點" ],
  "conflicts":   [ { "topic": "...", "positions": "誰主張什麼" } ],
  "unique":      [ { "source": "供應商名稱", "insight": "..." } ],
  "blind_spots": [ "各份答案漏掉或答錯的地方" ],
  "verdict":     "用一句話說明哪份答案最強以及原因"
}

那份 JSON 才是這組評審團真正的產出。綜合者拿起問題和那份 JSON,寫出 最終答案:把衝突朝正確的方向化解、把獨到的洞見納進來、把盲點補上,而且 絕口不提這組評審團。它向你下筆的方式,彷彿它一開始就知道答案。

Fusion 預設把裁判和綜合者都釘在 Opus 上。分析和定稿是攸關品質的步驟, 所以 Fusion 在這兩步用的是強模型,而不是代理當下所要求的那個。你可以在 Fusion 面板裡更換裁判。我們刻意把它預設成那個強的模型。

沒有 Fable 的 Fable 水準。

對一個編碼代理來說,誠實的展示就是一次建置。我們把同一段提示詞分別交給 一個單一強模型和那組評審團,先閃電灰、再閃電黃,然後各自產出什麼,我們 就直接出貨什麼:

用 node 寫一個網站,把使用者的 user agent 回顯出來,做成一個受 Tron 啟發、設計得很漂亮的 WebGL 頁面,要快、要動態,而且要讓訪客驚艷

⚡ 灰 · 單一模型(Opus 4.8)
⚡ 黃 · Fusion 評審團
同一段提示詞、同一個代理、只翻一個開關。左邊,閃電灰:一個單一模型,Opus 4.8。右邊,閃電黃:一個由 Claude + GPT-5.5 + Grok 組成、再由 Opus 裁判並綜合的評審團。Fusion 不去動檔案編輯,因為那些是直接直通的工具回合,它只處理代理出聲推理的那些回合。讓訪客驚艷的那個頁面,是評審團的版本。

一段提示詞本身證明不了什麼。OpenRouter 做了真正的量測:一百項深度研究 任務、數十項加權準則,一組評審團領先最佳單一模型好幾分,而 Fable 5 也 在其中。這個機制一模一樣,只是指向你自己的模型。一個由 Claude + GPT-5.5

  • Grok 組成、再由 Opus 裁判並綜合的評審團,在一場編碼會話的散文回合上 勝過它們任一個單獨作答,Fable 也算在內。你得到的是 Fable 等級的產出, 現場卻沒有 Fable。

模型出了名地常在簡單的謎題上失手。評審團會在那些顯而易見的錯誤抵達你 面前之前就把它們攔下。

一場啟用了 Fusion 的 Claude Code 會話:它正確數出「strawberry」裡有三個 r,並對「該走路還是開車去 50 公尺外的洗車場」給出一個審慎的答案
Fusion 面對那兩道催生了上千篇「LLM 其實不會推理」討論串的問題。數字母的陷阱題答對了,三個 r 位置在第 3、8、9,而那道「該走路還是開車」的問題,得到的是一個審慎的答案,而不是一個自信滿滿的錯答。三個模型互相交叉檢查,所以那些笨答案活不下來。

一切都在軌跡裡。

這部分是只有 Bromure 才能宣稱的,而它正是從 Fusion 所住的位置自然來的。 代理坐在一個 VM 裡,每一個對外呼叫都會經過主機的代理伺服器,所以 Fusion 的側邊呼叫即使在代理看不到時也保持可見。主機把每一段歷程——Claude 草稿、 GPT 草稿、Grok 草稿、裁判那一遍、綜合那一遍——都記錄進和代理其他所作所為 相同的會話軌跡裡。

一個融合回合 · 如實記錄歷程主機角色線路A · Claudeapi.anthropic.com草稿200 · 2.1 KBB · GPT-5.5api.openai.com草稿200 · 1.8 KBC · Grokapi.x.ai草稿200 · 1.6 KB裁判api.anthropic.comJSON 分析200 · 0.9 KB綜合api.anthropic.com最終答案200 · 2.4 KB代理的視角:對 Anthropic 1 個請求 · 軌跡的視角:5 次上游呼叫,全數歸屬
管理員在一個融合回合裡看到的東西。代理相信自己對 Anthropic 發了一次呼叫。軌跡記錄的是五次:一份 Claude 草稿、一份在 api.openai.com 的 GPT 草稿、一份在 api.x.ai 的 Grok 草稿,接著是一遍裁判和一遍綜合。Fusion 對代理保持透明,對任何審視這場會話的人則完全可讀,正是我們企業文章一再回到的那套家風。

一個把側邊呼叫藏起來的融合模型路由器,等於是把一份未經稽核的提示詞與 程式碼副本交給企業,展開送給另外兩家供應商卻不留任何紀錄。Fusion 做了 展開,而且把每一次呼叫都寫了下來。你的資安團隊可以問為什麼 api.openai.com 收到了一段提示詞,並從軌跡裡的一列讀到答案:閃電當時 是黃的。

Fusion 的代價。

Fusion 向你索取的是時間。一個融合的文字回合會跑評審團,然後對 Opus 多發兩次呼叫,一次給裁判的分析、一次給綜合。它們是接續執行的,發生在 Claude 自己的答案之後,因為代理伺服器必須先讀到那份答案才能決定要不要 融合。一個融合回合會比一個普通回合慢。這筆交易很窄:在那些向你解釋 事情的回合上,你多等一會兒,換來一個更好的答案。這就是為什麼 Fusion 是 一道你去翻動的閃電,而不是預設值,也是為什麼它只碰散文回合,留著工具 迴圈不動。

翻動那道閃電。

Bromure Agentic Coding 3.0 把 Fusion 放進每一場代理 會話的標題列裡。設定兩到三個代理、挑一位裁判,那個 ⚡ 就會從空心走到 灰色,再走到黃色——當你想開委員會時。你的編碼代理會繼續表現得像是在跟 一個模型對話,因為就它所能察覺的而言,它確實是。軌跡會顯示出每個答案 背後的那五次呼叫。