Fusion — 多模型面板
不同的前沿模型有着各自不同的失败方式。一个模型漏掉了另一个模型能捕捉到的边缘情况；一个模型会臆造出另外三个模型拒绝虚构的 API。Fusion 把这种多样性变成了一项功能：启用后，你的 Claude Code 会话提出的每个问题都会由多个模型同时回答，一个评判器模型梳理各份草稿在何处一致、冲突以及各自的亮点，然后将一份基于该分析的综合答案交付回 Claude Code，仿佛出自单个模型之手。代理永远不会知道曾召集过一个面板。
Fusion 完全运行在宿主机侧的代理服务器中（参见核心概念），因此虚拟机内部毫无变化：没有代理标志，没有包装脚本，也没有代理可以据以反应的可见延迟来源。它在Fusion设置窗格中按工作区配置，并通过会话标题栏中的闪电按钮 (⚡) 按会话启用。
注意： Fusion 在 UI 中标注为 BETA。它是一个可用的原型：机制是稳定的，但评判器提示、供应商后端和失败处理仍在演进中。在依赖它之前，请参阅 Beta 限制。
Fusion 的工作原理
Fusion 拦截 Claude Code 会话发往 Anthropic /v1/messages 端点的流量。每个请求分阶段处理：
- A 支 — Claude 首先回答。 客户机的原始请求原封不动地发送给 Anthropic（强制为非流式，以便可以检查完整回复）。你的 Claude Code 会话始终是 fuse 的一支。
- 工具轮次直接通过。 如果 Claude 的回复是一次工具调用——这是代理式编程中的常见情况，其中大多数轮次是"读取此文件""运行此命令"——它会原样转发给代理，并跳过该轮次的 fusion。代理循环永远不会被一次综合出的工具调用打断。
- 文本轮次分发。 只有当 Claude 返回纯文本答案时，Fusion 才会启用。每个其他已选供应商——Codex (OpenAI)、Grok (xAI)，以及可选的一个本地设备端模型——都会就同一份扁平化后的对话记录被问及同一个问题。
- 评判器梳理全局。 评判器模型比较所有草稿，并发出一份结构化的 JSON 分析——共识、冲突、独到见解、盲点以及一个裁定——而不是散文式的评论。
- 评判器进行综合。 随后，同一个评判器模型基于它刚刚产生的分析，写出确定性的答案。
- 交付。 综合后的答案以它所请求的确切传输形态（Anthropic SSE 或 JSON）流式返回给虚拟机内的代理。从 Claude Code 的视角看，是单个模型作了回答。
任何阶段的失败都会优雅降级，而不是中断会话：某支的凭据无法解析，或者报错、超时，就会被静默地从 fuse 中剔除。如果存活的答案少于两个，则原封不动地返回 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)——都需要在工作区的代理标签页中配置其凭据。在此之前，它在 Fusion 窗格中的行会呈灰色，并附有提示*— no cloud credential (configure it in Agents)*。
- 本地模型支需要在本地模型窗格中至少下载一个模型。在此之前，它的行显示*— 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 窗格。
- 在要融合的模型下，勾选你希望其答案出现在面板中的供应商。Claude Code (Anthropic) — 你的会话始终是一支；添加 Codex (OpenAI)、Grok (xAI) 和/或本地模型。本地模型行包含一个已安装本地模型的选择器。
- 在评判器下，选择将权衡各份草稿并写出最终答案的供应商和模型。供应商列表提供每一个拥有可用凭据的云端供应商，以及在至少安装了一个本地模型时的 Local。云端模型列表从供应商的
/v1/models端点实时获取，并包含一个 (default) 条目；如果获取失败，则改为提供一个小型内置列表。本地评判器从已安装的目录模型中选择。 - 点击存储。
| 设置 | 默认值 | 说明 |
|---|---|---|
| 要融合的模型 | 未选中任何项 | Claude Code 始终是一支；其他的需要凭据（云端）或已安装的模型（本地）。 |
| 评判器 → 供应商 | 首个可用供应商 | 一旦安装了本地模型，即出现 Local。 |
| 评判器 → 模型 | (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 是一个显式的、按会话的选择，绝不是静默的默认。
从命令行
在应用运行时，你可以在不触碰窗口的情况下切换正在运行的虚拟机上的 Fusion：
bromure-cli vm fusion enable <vm>
bromure-cli vm fusion disable <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 交换一样被追踪管道捕获，受工作区追踪级别的约束（参见追踪）。
实际影响：
- 追踪检查器（窗口菜单 → Trace Inspector…）在会话正常流量旁列出这些额外交换，并将捕获到的请求和响应渲染为解析后的对话——你可以准确读到每一支回答了什么以及评判器得出了什么结论。
bromure-cli trace hostnames显示，诸如api.openai.com之类的主机是从一个你可能以为只涉及 Anthropic 的会话中被联系的。如果你的组织审计出站流量，请预期融合会话会显示每个已选供应商的端点。- Fusion 还会以
[fusion]前缀详细地记录到应用的 stderr——这在诊断某一支为何被剔除时很有用。
注意： 如果你的工作区的数据处理规则限制哪些供应商可以看到你的代码，请记住每个选中的支都会接收对话的完整扁平化记录。据此选择各支。
环境覆盖
在启动应用时，可以用环境变量覆盖少数几个默认值——用于实验，并非意在作为日常配置：
| 变量 | 默认值 | 效果 |
|---|---|---|
BROMURE_FUSION_TIMEOUT | 600 | 每支的上游超时，单位为秒。 |
BROMURE_FUSION_OPENAI_MAX_TOKENS | 128000（GPT-5/o 系列），16384（gpt-4o 及更早） | OpenAI 支的补全令牌上限。 |
Beta 限制
Fusion 是一项 beta 功能，有一些值得了解的锋利边缘：
- 仅限 Claude Code 会话。 Fusion 拦截 Anthropic
/v1/messagesPOST 请求。以 Codex 或 Grok 作为主代理运行的会话不会被融合——那些代理的流量会正常通过。 - 非 Claude 支不带工具回答。 对于 Codex、Grok 和本地支，工具定义会被丢弃；它们就着扁平化的对话记录以散文形式回答。它们的草稿为综合提供信息，但其本身无法采取动作。
- 尽力而为的订阅后端。 Codex 订阅支通过 WebSocket 搭载 ChatGPT 后端，Grok 订阅支使用
cli-chat-proxy.grok.com——两者都是未公开的接口。发生任何错误时，该支会被剔除，而不是让 fuse 失败。 - 静默降级。 被剔除的支和评判器失败会回退到 Claude 自己的答案（或一份原始草稿），而不会提醒代理。追踪和
[fusion]stderr 日志是你唯一能看到这一情况发生的地方。 - 延迟。 一个融合的文本轮次要等待存活支中最慢的一支，然后再进行两次评判器调用。请预期答案轮次会明显慢于普通会话；工具轮次不受影响。