Fusion — 多模型面板

不同的前沿模型會以不同的方式失誤。一個模型漏掉的邊界情況，另一個卻能捕捉到；一個模型憑空捏造出某個 API，另外三個則堅拒虛構。Fusion 把這種多樣性轉化為一項功能：一旦啟用，你的 Claude Code 工作階段所提出的每個問題都會由多個模型同時回答，一個評審模型會標示出這些草稿在何處一致、何處衝突，以及各自的獨到之處，然後將一則以該分析為依據的綜合答案交付回 Claude Code，彷彿是由單一模型所寫。代理程式永遠不會知道曾召集過一個面板。

Fusion 完全在主機端的代理伺服器中執行（參見 概念），因此 VM 內部毫無改變：沒有代理程式旗標、沒有包裝指令碼、也沒有代理程式能察覺並據以反應的可見延遲來源。它是在 Fusion 設定窗格中依工作區逐一設定，並透過工作階段標題列中的閃電按鈕（⚡）依工作階段逐一啟用。

附註： Fusion 在 UI 中標示為 BETA。它是一個可運作的原型：機制已經穩定，但評審提示、供應商後端與失敗處理仍在演進中。在依賴它之前，請先參閱 Beta 版限制。

Fusion 的運作方式

Fusion 會攔截 Claude Code 工作階段送往 Anthropic /v1/messages 端點的流量。每個請求都會分階段處理：

  1. Leg A — Claude 先回答。 客體的原始請求會原封不動地送往 Anthropic（強制以非串流方式送出，以便檢視完整回覆）。你的 Claude Code 工作階段永遠是這道熔絲的其中一道支線。
  2. 工具回合直接通過。 如果 Claude 的回覆是一次工具呼叫——這是代理式編碼中的常見情況，其中多數回合都是「讀取這個檔案」、「執行這個指令」——它就會原樣轉發給代理程式，而該回合會略過 fusion。代理迴圈絕不會被綜合過的工具呼叫打斷。
  3. 文字回合展開扇出。 只有當 Claude 回傳純文字答案時，Fusion 才會介入。每一個其他選定的供應商——Codex（OpenAI）、Grok（xAI），以及選用的本機裝置端模型——都會針對同一份攤平的對話記錄被詢問相同的問題。
  4. 評審勘測全局。 評審模型會比對所有草稿，並產出一份結構化的 JSON 分析——共識、衝突、獨到見解、盲點，以及一項裁決——而非散文式的評述。
  5. 評審進行綜合。 同一個評審模型接著寫出最終定稿的答案，並以其剛才產出的分析為依據。
  6. 交付。 融合後的答案會以代理程式所要求的確切傳輸格式（Anthropic SSE 或 JSON）串流回 VM 內的代理程式。從 Claude Code 的角度看，是一個模型回答了問題。

任何階段的失敗都會優雅降級，而非中斷工作階段：某道支線若無法解析其憑證、或發生錯誤或逾時，就會被默默地從熔絲中剔除。若存活下來的答案少於兩則，就會原封不動地回傳 Claude 自己的答案。

工具回合對比文字回合

工具回合／文字回合的區別，正是讓 Fusion 能安全用於代理式工作的關鍵。動作（工具呼叫）會完全依照 Claude 發出的樣子執行；只有答案——說明、設計、審查、計畫——才會被融合。在典型的編碼工作階段中，多數回合都是動作，因此 Fusion 的影響力會集中在模型多樣性最重要之處：推理與結論，而非機械式的檔案編輯。

每道支線的身分從何而來

Fusion 本身沒有專屬的憑證 UI。每道支線都會解析工作區 Agents 分頁已為該供應商保存的憑證：

  • 訂閱模式——該支線使用來自主機訂閱儲存區的即時 OAuth 權杖；主機會視需要重新整理它。Claude 訂閱權杖會自動取得 Anthropic 所要求的 Claude Code 身分系統區塊與 OAuth beta 標頭。
  • API 權杖模式——該支線使用來自主機端權杖替換對應表中的真實 API 金鑰（客體只曾看過一個誘餌；參見 憑證）。
  • 本機模型——該支線以其內部金鑰指向主機上的推論引擎（參見 本機與混合推論）。
  • Bedrock（AWS）——處於 Bedrock 模式的 Claude 代理程式僅透過客體自身的請求做出貢獻；並沒有另外獨立的 Bedrock fusion 支線。

某道支線若其憑證無法解析，就會伴隨一行日誌被剔除，而絕不會將錯誤呈現給代理程式。

系統需求

Fusion 需要至少兩個可用的模型：

  • 只要 Claude Code 代理程式擁有可用的憑證，你的 Claude Code 工作階段永遠算作一道支線。
  • 每個額外的雲端支線——Codex（OpenAI）、Grok（xAI）——都需要在工作區的 Agents 分頁中設定好其憑證。在此之前，它在 Fusion 窗格中的那一列會呈灰色，並附上提示 — no cloud credential (configure it in Agents)。
  • 本機模型支線需要在 Local Models 窗格中至少下載一個模型。在此之前，它那一列會顯示 — download one in Local Models。
  • 若選取的可用模型少於兩個，窗格會顯示輔助文字 "Pick at least two models to fuse — your Claude Code session counts as one, so add one more (a cloud agent or a local model)."，且工作階段的閃電按鈕會維持停用。

為工作區設定 Fusion

Fusion 是在 編輯工作區 視窗的 Fusion 窗格中設定（側邊欄中的黃色閃電圖示，標示為 BETA）。逐欄位的參考說明位於 Fusion 設定；本節帶你走過工作流程。

編輯工作區視窗的 Fusion 窗格，顯示 BETA 徽章、因缺少憑證而所有列都呈灰色的「要融合的模型」清單、要求至少兩個模型的橘色輔助文字，以及下方的評審區段

在上方的螢幕截圖中，尚未設定任何代理程式憑證，因此 Models to fuse 底下的每一列都呈灰色，而橘色的輔助文字說明了缺少了什麼。一旦 Agents 分頁持有憑證，這些列就會變為可選取。

  1. 在工作區瀏覽器中開啟工作區並按一下 編輯工作區，然後選取 Fusion 窗格。
  2. 在 Models to fuse 底下，勾選你希望其答案出現在面板中的供應商。Claude Code (Anthropic) — your session 永遠是一道支線；再加上 Codex (OpenAI)、Grok (xAI) 和／或 Local model。Local model 那一列包含一個已安裝本機模型的選擇器。
  3. 在 Judge 底下，挑選將權衡各草稿並寫出最終答案的 Provider 與 Model。Provider 清單會提供每個具有可用憑證的雲端供應商，並在至少安裝了一個本機模型時加上 Local。雲端模型清單會即時從供應商的 /v1/models 端點擷取，並包含一個 (default) 項目；若擷取失敗，則改為提供一份小型的內建清單。本機評審則從已安裝的目錄模型中挑選。
  4. 按一下 儲存。
設定預設值附註
Models to fuse未選取任何項目Claude Code 永遠是一道支線；其他項目需要憑證（雲端）或已安裝的模型（本機）。
Judge → Provider第一個可用的供應商一旦安裝了本機模型，就會出現 Local。
Judge → Model(default) → claude-opus-4-8雲端清單會即時從 /v1/models 擷取。

當某道支線的模型未明確固定時，預設值為：Claude → claude-opus-4-8；Codex → 訂閱時為 gpt-5.5，使用 API 金鑰時為 gpt-5.5-2026-04-23；Grok → grok-build。

提示： 本機模型可作為一道能力不俗、零邊際成本的額外支線——而評審本身也可以在本機執行，讓整個分析與綜合階段都留在你的 Mac 上。參見 本機與混合推論。

在工作階段中啟用 Fusion

設定窗格只是讓 Fusion 可供使用。每個工作階段都會透過工作階段視窗標題列中的閃電按鈕（⚡）自行決定是否使用它：

閃電外觀狀態工具提示
空心、停用不可用——可用模型少於兩個"To enable Fusion you need to have at least two models enabled."
實心、深灰可用、未啟用"Fusion available — disengaged. Click to engage multi-model synthesis."
實心、黃色已啟用"Fusion engaged — answers are synthesized across your selected models. Click to disengage."

按一下閃電即可切換。新的工作階段一律以未啟用的狀態開始——Fusion 是一項明確、依工作階段做出的選擇，絕非默默套用的預設值。

從命令列

在應用程式執行的情況下，你可以不必碰觸視窗，就在執行中的 VM 上切換 Fusion：

bromure-cli vm fusion enable <vm>
bromure-cli vm fusion disable <vm>

<vm> 是一個 VM id 或一個工作區名稱，而 on／off／engage／disengage 皆可作為別名接受。bromure-cli vm 的狀態輸出中包含一列 fusion 資訊，內容為 engaged 或 available (off)。這些指令會與應用程式的控制 API 通訊，因此需要應用程式（或其代理程式）正在執行；參見 自動化與 CLI。

Fusion 的成本

Fusion 會使模型用量倍增，你應在了解其算術後再啟用它。對於每個 Claude 回傳純文字答案的回合：

  • 每個額外選定的支線都會進行一次完整的模型呼叫，並接收與其他支線相同的攤平對話記錄作為上下文——因此長對話會在每道支線、每個融合回合上按比例產生成本。
  • 評審會多進行兩次呼叫：一次產出 JSON 分析，一次寫出綜合結果。兩者的輸出上限皆為 4,096 個權杖。

因此，在四道支線全數選取的情況下，一則融合答案的成本，最多會比你本來就在進行的 Claude 呼叫多出五次模型呼叫。工具呼叫回合則展開為零次額外呼叫，這在實務上讓代理式工作階段遠比最壞情況便宜得多——編碼迴圈中的多數回合都是工具呼叫。

每道支線如何計費取決於其憑證：API 金鑰支線按權杖計費、訂閱支線動用訂閱的配額，而本機支線僅耗用裝置端運算資源（在筆記型電腦上還有電力）。每道支線預設有 600 秒的上游逾時。

追蹤記錄中的 Fusion

Fusion 刻意對代理程式隱形，但對你完全可見。每一次上游的旁路呼叫——每道支線、評審分析與綜合——都會像任何其他 AI 交換一樣被追蹤管線擷取，並受工作區追蹤層級的約束（參見 追蹤）。

實務上的影響：

  • 追蹤檢視器（Window 選單 → Trace Inspector…）會將這些額外的交換與工作階段的正常流量並列列出，並將擷取到的請求與回應轉譯為已解析的對話——你可以確切讀到每道支線回答了什麼，以及評審得出了什麼結論。
  • bromure-cli trace hostnames 會顯示諸如 api.openai.com 這類主機曾被一個你或許以為只連線 Anthropic 的工作階段聯絡過。如果你的組織會稽核輸出流量，那麼融合過的工作階段應當會顯示每個選定供應商的端點。
  • Fusion 也會以 [fusion] 前綴詳盡地記錄到應用程式的 stderr——在診斷某道支線為何被剔除時很有用。

附註： 如果你工作區的資料處理規則限制了哪些供應商可以看到你的程式碼，請記住每個選定的支線都會接收對話的完整攤平記錄。請據此選取支線。

環境覆寫

啟動應用程式時，可以用環境變數覆寫少數幾項預設值——這對實驗有用，並不打算作為日常設定：

變數預設值效果
BROMURE_FUSION_TIMEOUT600每道支線的上游逾時，以秒為單位。
BROMURE_FUSION_OPENAI_MAX_TOKENS128000（GPT-5／o 系列）、16384（gpt-4o 及更早）OpenAI 支線的完成權杖上限。

Beta 版限制

Fusion 是一項 beta 功能，有一些值得了解的鋒利邊角：

  • 僅限 Claude Code 工作階段。 Fusion 攔截的是 Anthropic /v1/messages POST 請求。以 Codex 或 Grok 作為主要代理程式執行的工作階段不會被融合——那些代理程式的流量會正常通過。
  • 非 Claude 支線在無工具的情況下作答。 對於 Codex、Grok 與本機支線，工具定義會被捨棄；它們是以散文形式針對攤平的對話記錄作答。它們的草稿會為綜合提供資訊，但本身無法採取行動。
  • 盡力而為的訂閱後端。 Codex 訂閱支線透過 WebSocket 搭乘 ChatGPT 後端，而 Grok 訂閱支線使用 cli-chat-proxy.grok.com——兩者都是未公開的介面。發生任何錯誤時，該支線都會被剔除，而不會讓整道熔絲失敗。
  • 靜默降級。 被剔除的支線與評審失敗會退回 Claude 自己的答案（或一份原始草稿），而不會提醒代理程式。追蹤記錄與 [fusion] stderr 日誌是你唯一能看到此事發生過的地方。
  • 延遲。 一個融合的文字回合會等待存活下來最慢的那道支線，接著是兩次評審呼叫。預期答案回合會明顯比純工作階段慢；工具回合則不受影響。