上个月 OpenRouter 给我们看了一样我们立刻就想要的东西：一组模型——一个负责评审这组模型，另一个负责写出裁决—— 胜过榜单上单独最强的那个模型。它同时询问几个模型，并把它们的答案综合成一个。他们头条上的 fusion 在一项深度研究基准上拿到了 69.0%，而 Fable 5 单独作答只有 65.3%。我们没有去对接他们的服务——而是自己把这套技术重新实现了一遍，放在更下面一层，在你的编码 agent 本就在与之通话的那个代理里。Bromure Agentic Coding 3.0 用一道闪电把它交付。

机制很朴素。把 prompt 并行发给几个模型。一个评审者读完每一份答案，标出它们一致之处、相互矛盾之处、各自独到地抓住了什么、又集体漏掉了什么。然后一个综合者从那份分析里写出最终答案，而不是凭眼力比对草稿。 OpenRouter 的 Fusion 文章把我们重新实现的这套机制讲得很清楚，而增益之大令我们意外：在一个案例里，把一个模型与它自己配对，分数依然被抬高。增益大多来自那个综合步骤。

我们清楚自己想把它放在哪里。Bromure Agentic Coding 在一个一次性的 Linux VM 里运行你的 agent，宿主机上有一个中间人代理盯着它发往 api.anthropic.com 的每一个字节。我们本就在电线上，所以这一组模型就在那里运行，在你的代码、prompt 和凭据从不绕道经过任何别人的路由器的地方。Fusion 是那个代理的一种行为。它把一个出站的 Claude 请求变成一场快速的委员会会议，再以 agent 所期待的电线形态返回单一答案。Claude Code 永远不会知道 GPT-5.5 和 Grok 也在场。

一道闪电。

Fusion 只有一个控制项，它就在 agent 会话窗口的标题栏里。

agent 会话标题栏中处于未启用状态、呈深灰色的 Fusion 闪电图标 — Fusion 的全部 UI：会话标题栏里的那个 ⚡。左边它处于未启用——深灰色的实心闪电，本会话可用但已关闭。右边它点亮为黄色，已启用。当配置的模型少于两个时，闪电变为空心且禁用，因为只有一个的「一组」就只是一个模型。地址栏里的 192.168.64.2 是 agent 被装进去的、按配置文件划分的 VM，而那就是 Fusion 所坐落的电线。

agent 会话标题栏中处于已启用状态、点亮为黄色的 Fusion 闪电图标 — Fusion 的全部 UI：会话标题栏里的那个 ⚡。左边它处于未启用——深灰色的实心闪电，本会话可用但已关闭。右边它点亮为黄色，已启用。当配置的模型少于两个时，闪电变为空心且禁用，因为只有一个的「一组」就只是一个模型。地址栏里的 192.168.64.2 是 agent 被装进去的、按配置文件划分的 VM，而那就是 Fusion 所坐落的电线。

Fusion 运行在 Claude Code 会话上，因为它拦截 Claude 的 /v1/messages API——它知道怎么把这个请求扇出去再重新组装。你在配置文件的 Agents 选项卡里配置两到三个带凭据的 agent，挑选哪些供应商加入这组、由哪个模型来评审，从那以后你唯一要碰的就是那道闪电。灰色表示关闭，普通的 Claude。黄色表示开启，委员会召集。这道闪电是一个运行时开关，所以你可以会话中途切换它，无需重启。

电线上发生了什么。

闪电变黄之后，代理做的就不只是把 agent 的请求转发给 Anthropic。它运行下面这段流程。

Fusion 处理一个「与你对话」的 turn 的路径。代理先询问 Claude，携带 agent 的真实请求及其工具。在一个纯文本答案上，它把同一个问题抛给这组里其余成员，把每一份草稿交给一个评审者、由它返回一份结构化分析，再让一个综合者从那份分析里写出单一的最终答案。然后代理把结果重新包进 Claude 自己的消息信封，并以 agent 所要求的任何形态流式返回。三个模型作了答，agent 只读到一个。

有一个细节让这件事区别于演示：代理先询问 Claude，而且是完整地询问。Leg A 携带 agent 的真实请求，工具和完整对话记录一应俱全，用真实凭据发往 Anthropic。代理强制它非流式，好在决定怎么做之前读完整个答案。路由的决定取决于那第一个答案。

编码 agent 改变了问题。

编码 agent 里的 Fusion，所面对的问题不同于聊天框里的 Fusion，而这正是我最为自豪的那部分。

在一款聊天产品里，大多数 turn 都是给人读的散文，正是评审加综合所擅长的。但在一个 agentic 循环里，大多数 turn 是动作：用 npm test 调用 bash，编辑这个文件。每一个都是一个带结构化输入的 tool_use 块，SDK 正等着去执行它。在那里把三个模型的意见融合成一段话，你就删掉了那次工具调用，循环也就卡住了。所以 Fusion 在行动之前先做检查。它先询问 Claude，好检视这个 turn，再根据答案的形态来路由：

turn 路由器读取 Claude 的第一个答案。一个工具 turn——任何带有 tool_use 块或 tool_use 停止原因的——是一个动作，所以 Fusion 原样回放 Claude 的真实响应，跳过这一组：不调 GPT，不评审，不综合，也就没有剥掉命令的风险。一个纯文本 turn，那种真正与你对话的，才会获得完整的委员会。路由器让 agentic 循环保持完好。

在一次会话的大部分时间里，Fusion 都保持沉默。跑测试、读失败、打补丁这一长串都是工具 turn，全速原样直通。委员会只在 Claude 开始解释而非动作时才召集：架构问题、对所发现内容的最终总结。第二个、第三个意见在那些 turn 上才挣得回身价。

评审者负责分析，而不是投票。

「用三个模型」的幼稚版本，是来一场多数投票，或者问一个模型「哪个最好？」然后把胜者转发出去。两者都丢掉了大部分信号。一组模型胜过单个模型，恰恰是因为这些模型在不同的地方犯错，而一场投票只会对它们做计数。

评审者并不产出答案。把问题和每一份带标签的草稿交给它，它只返回一份结构化分析，别无其他：

{
  "consensus":   [ "各份答案一致的论点" ],
  "conflicts":   [ { "topic": "...", "positions": "谁说了什么" } ],
  "unique":      [ { "source": "供应商名称", "insight": "..." } ],
  "blind_spots": [ "各份答案漏掉或弄错的东西" ],
  "verdict":     "一句话说明哪份答案最强，以及为什么"
}

那份 JSON 才是这一组真正的产出。综合者拿着问题和那份 JSON，写出最终答案：把冲突向正确的方向解决、把独到的洞见纳入、覆盖盲点，并且对这一组只字不提。它对你落笔，仿佛它一直都知道答案。

Fusion 默认把评审者和综合者都钉死在 Opus 上。分析和撰写都是对质量至关重要的步骤，所以 Fusion 在强模型上运行它们，而不是在 agent 所请求的任何模型上。你可以在 Fusion 面板里更换评审者。我们故意把它默认为那个强模型。

Fable 在场，却没有 Fable。

对一个编码 agent 来说，老实的演示是一次构建。我们把同一个 prompt 交给一个单独的强模型，再交给这一组，先灰色闪电再黄色闪电，并原封不动地交付各自产出的东西：

用 node 写一个网站，把用户的 user agent 回显出来，放在一个受 Tron 启发、设计精美的 WebGL 页面上，页面应当快速而动态，并且应当让访客惊艳。

⚡ 灰色 · 单个模型（Opus 4.8）

⚡ 黄色 · Fusion 一组模型

同一个 prompt，同一个 agent，一次切换。左边，灰色闪电：一个单独的模型，Opus 4.8。右边，黄色闪电：一个 Claude + GPT-5.5 + Grok 组成的一组，由 Opus 评审与综合。Fusion 不去碰文件编辑，因为那些是工具 turn，原样直通，它只处理 agent 出声推理的那些 turn。让访客惊艳的那个页面，是出自这一组之手。

一个 prompt 本身证明不了什么。OpenRouter 做了真正的度量：一百个深度研究任务、几十条加权标准，一组模型比单独最好的那个模型高出好几分，连 Fable 5 都在其中。机制是同一个，只不过指向你自己的模型。一个 Claude + GPT-5.5 + Grok 组成的一组、由 Opus 评审与综合，在一次编码会话的散文 turn 上胜过它们中任何一个单独作答，Fable 也包含在内。你得到 Fable 级别的产出，房间里却没有 Fable。

模型出了名地会在简单的谜题上栽跟头。有这一组盯着，那些显而易见的错误会在抵达你之前就被逮住。

一个启用了 Fusion 的 Claude Code 会话：它正确数出 strawberry 里有三个 r，并对该走路还是开车去 50 米外的洗车房给出一个有分寸的回答 — Fusion 应对那两个催生了上千条「LLM 其实不会推理」帖子的问题。数字母的陷阱题答对了——三个 r，位于第 3、8、9 位——而「我该走路还是开车」的问题得到的是一个有分寸的回答，而不是一个自信的错答。三个模型彼此交叉核验，所以那些弱答案活不下来。

一切都在 trace 里。

这里是只有 Bromure 才能宣称的部分，而它出自 Fusion 所在之处。agent 坐在一个 VM 里，每一个出站调用都经过宿主机代理，所以 Fusion 的旁路调用即便 agent 看不见，也依然可见。宿主机记录下每一条 leg——Claude 草稿、GPT 草稿、Grok 草稿、评审一趟、综合一趟——落进与 agent 所做其他一切相同的那份会话 trace 里。

管理员在一个融合 turn 上看到的东西。agent 相信它向 Anthropic 发了一次调用。trace 记录了五次：一份 Claude 草稿、一份在 api.openai.com 的 GPT 草稿、一份在 api.x.ai 的 Grok 草稿，然后是评审一趟和综合一趟。Fusion 对 agent 保持透明，对审查会话的人则可读——这正是我们企业文章一以贯之的风格。

一个隐藏旁路调用的模型融合路由器，会交给一家企业一份未经审计的、其 prompt 和代码的副本，被扇出给另外两家供应商，且不留任何记录。 Fusion 做了扇出，并把每一次调用都写下来。你的安全团队可以追问 api.openai.com 为什么收到一个 prompt，并从 trace 里的一行读到答案：闪电当时是黄的。

Fusion 的代价。

Fusion 要花你的时间。一个融合的文本 turn 会运行这一组，然后额外向 Opus 发两次调用，一次给评审者的分析，一次给综合。它们按顺序运行，在 Claude 自己的答案之后，因为代理必须先读到那个答案才能决定是否融合。一个融合 turn 比一个普通 turn 慢。这个权衡很狭窄：在那些向你解释事情的 turn 上，你为一个更好的答案多等一会儿。这正是为什么 Fusion 是一道你去点亮的闪电，而不是一个默认值，也是为什么它触碰散文 turn，却不去碰工具循环。

点亮闪电。

Bromure Agentic Coding 3.0 把 Fusion 放进每个 agent 会话的标题栏。配置两到三个 agent，挑一个评审者，那个 ⚡ 就会从空心变灰色，再在你想要委员会时变到黄色。你的编码 agent 仍然表现得像在与一个模型对话，因为就它所能察觉的而言，确实如此。trace 展示每个答案背后的那五次调用。