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 跑在 Claude Code 會話上,因為它攔截的是 Claude 的
/v1/messages API——那是它懂得如何展開又重新組裝的請求。你在設定檔的
Agents 分頁裡設定兩到三個帶憑證的代理,挑選哪些供應商加入評審團、由
哪個模型擔任裁判,從此以後你唯一要碰的就只有那道閃電。灰色代表關閉,
單純的 Claude。黃色代表開啟,委員會召開。閃電是一個執行期旗標,所以
你可以在會話進行中切換它,不必重新啟動。
線路上發生了什麼。
閃電亮黃時,代理伺服器做的不只是把代理的請求轉發給 Anthropic。它會跑 底下這段順序。
有一個細節讓這件事不只是個展示品:代理伺服器最先詢問 Claude,而且是 完整地詢問。歷程 A 帶著代理真正的請求,工具與完整逐字紀錄一應俱全, 帶著真正的憑證送往 Anthropic。代理伺服器強制它非串流,好讓自己能在 決定要怎麼做之前讀完整份答案。路由的決定,就繫於那第一份答案。
編碼代理改變了問題。
Fusion 跑在編碼代理裡,和跑在聊天框裡是兩個不同的問題,而這正是我最 自豪的部分。
在一個聊天產品裡,多數回合都是寫給人讀的散文,那正是裁判加綜合所打造
來處理的東西。但在一個代理式迴圈裡,多數回合都是動作:用 npm test
呼叫 bash、編輯這個檔案。每一個都是一個帶有結構化輸入的 tool_use
區塊,SDK 正等著去執行它。要是你在那裡把三個模型的意見融合成一段文字,
你就刪掉了那個工具呼叫,迴圈停擺。Fusion 會先看清楚再下手。它最先
詢問 Claude,好讓自己能檢視這個回合,然後依照答案的形狀來決定路由:
一場會話的大部分時間裡,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 頁面,要快、要動態,而且要讓訪客驚艷。
一段提示詞本身證明不了什麼。OpenRouter 做了真正的量測:一百項深度研究 任務、數十項加權準則,一組評審團領先最佳單一模型好幾分,而 Fable 5 也 在其中。這個機制一模一樣,只是指向你自己的模型。一個由 Claude + GPT-5.5
- Grok 組成、再由 Opus 裁判並綜合的評審團,在一場編碼會話的散文回合上 勝過它們任一個單獨作答,Fable 也算在內。你得到的是 Fable 等級的產出, 現場卻沒有 Fable。
模型出了名地常在簡單的謎題上失手。評審團會在那些顯而易見的錯誤抵達你 面前之前就把它們攔下。

一切都在軌跡裡。
這部分是只有 Bromure 才能宣稱的,而它正是從 Fusion 所住的位置自然來的。 代理坐在一個 VM 裡,每一個對外呼叫都會經過主機的代理伺服器,所以 Fusion 的側邊呼叫即使在代理看不到時也保持可見。主機把每一段歷程——Claude 草稿、 GPT 草稿、Grok 草稿、裁判那一遍、綜合那一遍——都記錄進和代理其他所作所為 相同的會話軌跡裡。
一個把側邊呼叫藏起來的融合模型路由器,等於是把一份未經稽核的提示詞與
程式碼副本交給企業,展開送給另外兩家供應商卻不留任何紀錄。Fusion 做了
展開,而且把每一次呼叫都寫了下來。你的資安團隊可以問為什麼
api.openai.com 收到了一段提示詞,並從軌跡裡的一列讀到答案:閃電當時
是黃的。
Fusion 的代價。
Fusion 向你索取的是時間。一個融合的文字回合會跑評審團,然後對 Opus 多發兩次呼叫,一次給裁判的分析、一次給綜合。它們是接續執行的,發生在 Claude 自己的答案之後,因為代理伺服器必須先讀到那份答案才能決定要不要 融合。一個融合回合會比一個普通回合慢。這筆交易很窄:在那些向你解釋 事情的回合上,你多等一會兒,換來一個更好的答案。這就是為什麼 Fusion 是 一道你去翻動的閃電,而不是預設值,也是為什麼它只碰散文回合,留著工具 迴圈不動。
翻動那道閃電。
Bromure Agentic Coding 3.0 把 Fusion 放進每一場代理 會話的標題列裡。設定兩到三個代理、挑一位裁判,那個 ⚡ 就會從空心走到 灰色,再走到黃色——當你想開委員會時。你的編碼代理會繼續表現得像是在跟 一個模型對話,因為就它所能察覺的而言,它確實是。軌跡會顯示出每個答案 背後的那五次呼叫。