多模型编排 — Fugu 与 Fusion 的编排秘密¶

利用低成本开源模型进行优化组合，在深度研究、代码审查等复杂任务上表现已能接近甚至超越昂贵的单体巨兽。两个代表方案：Sakana AI 的 Fugu（黑盒学习派）和 OpenRouter 的 Fusion（白盒规则派），展示了「架构优化」有时更胜于单纯堆叠参数。

目录¶

#背景与行业痛点
#Fugu (Sakana AI) 技术拆解
#Fusion (OpenRouter) 技术拆解
#第一性原理对比
#多模型编排设计框架

背景与行业痛点¶

出口管制与依赖风险¶

美国政府对 Fable 5 等地表最强模型的出口管制，让科技圈意识到将所有业务逻辑「绑死」在单一闭源模型上的巨大风险。多模型编排成为企业确保「AI 主权」与风险对冲的战略备胎。

臭皮匠战术的逆袭¶

Fugu 与 Fusion 证明：低成本开源模型 + 好的编排策略 = 接近甚至超越顶级单体模型的性能。关键不在模型变聪明，而在架构设计。

单模型依赖风险：
┌─────────────────────┐
│   业务逻辑          │
│        ↓            │
│   单一闭源 API      │  ← 地缘政治风险 / 供应商锁定 / 成本不可控
│   (e.g. GPT-5)     │
└─────────────────────┘

多模型编排架构：
┌─────────────────────┐
│   业务逻辑          │
│        ↓            │
│   编排层            │  ← 可插拔、可替换、成本可控
│  ┌──┼──┐           │
│  ↓  ↓  ↓           │
│ M1 M2 M3 ...       │  ← 开源 + 闭源混合
└─────────────────────┘

Fugu (Sakana AI) 技术拆解¶

核心概念：轻量级协调器¶

基于两篇 ICLR 2026 论文（Trinity 与 Conductor），Fugu 的核心是一个仅 0.6B 参数的轻量协调器，它不需要自己懂所有知识，只需精准分工。

三位一体角色分配¶

         ┌──────────────┐
         │   协调器       │  0.6B 参数
         │ (Conductor)   │  基于 CMA-ES 训练
         └──┬────┬────┬─┘
            │    │    │
     ┌──────┘    │    └──────┐
     ↓           ↓           ↓
┌─────────┐ ┌────────┐ ┌──────────┐
│ Thinker │ │ Worker │ │ Verifier │
│ (思考者) │ │(工作者) │ │ (验证者)  │
└─────────┘ └────────┘ └──────────┘

角色	职责	模型选择
Thinker（思考者）	分析任务、规划步骤	推理能力强的模型
Worker（工作者）	执行具体子任务	领域专精模型
Verifier（验证者）	检查结果、发现错误	擅长找 Bug 的模型

数学底层：Sep-CMA-ES¶

不同于传统强化学习（RL）易陷入局部最优，Fugu 采用「可分离的协方差矩阵自适应进化策略（Separable Covariance Matrix Adaptation Evolution Strategy）」。

利用快 \(\epsilon\)-可分性数学特性
在高维度、预算受限的搜索空间中，高效找出最优调度策略
不需要梯度信息，适合黑盒优化场景

实战表现¶

在代码审查等工程任务中，早期用户反馈 Fugu 抓出的 Bug 比顶级单体模型多出数倍。

Fusion (OpenRouter) 技术拆解¶

核心概念：结构化合成管道¶

Fusion 不依赖学习，而是通过工程化的三步走管道实现多模型合成。

三步走架构¶

步骤 1：并行分发               步骤 2：判官分析              步骤 3：大老合成
┌──────────────────────┐    ┌──────────────────────┐    ┌──────────────────────┐
│ 问题 → 同时派发给       │    │ 判官模型结构化分析：     │    │ 顶级模型根据判官报告    │
│ 1~8 个不同模型         │    │ • 共识（高信赖度）      │    │ 提炼最终答案           │
│ + 联网搜索工具          │───→│ • 矛盾（争议点）       │───→│                      │
│                       │    │ • 盲点               │    │ (e.g. OP 4.8)        │
└──────────────────────┘    └──────────────────────┘    └──────────────────────┘

判官分析的关键机制¶

分析维度	说明	价值
共识	多模型一致认同的结论	高信赖度，可直接采纳
矛盾	模型间存在分歧的点	需深入分析，往往是难点
盲点	所有模型都忽略的内容	揭示系统性缺陷

架构红利¶

即使是顶级模型自己与自己组合，经过这套流程分数也能拔高 6~7 个百分点。证明成功关键在于「架构优化」而非模型变聪明。

第一性原理对比¶

特性	Fugu (Sakana AI)	Fusion (OpenRouter)
底层流派	基于学习的黑盒协调（进化算法）	基于规则的白盒协调（服务端管道）
核心隐喻	眼光毒辣的 HR 调配顶尖专家	人类团队开会，汇总意见由 Leader 拍板
学习需求	需要训练协调器	无需训练，即插即用
最佳场景	长期多步骤复杂任务（论文复现）	深度研究报告、资料对比分析
部署复杂度	中（需训练 + 推理）	低（API 调用即可）
可解释性	低（黑盒调度策略）	高（结构化判官报告）

选型决策树¶

你需要多模型编排？
├─ 任务是否需要长期多步骤执行？
│  ├─ 是 → 长期任务，需动态调整策略
│  │       → 偏好 Fugu（学习型协调器，越用越好）
│  └─ 否 → 单次请求型任务
│
├─ 是否需要快速部署、低启动成本？
│  ├─ 是 → 无需训练，API 即用
│  │       → 偏好 Fusion（白盒规则，即插即用）
│  └─ 否 → 可投入训练资源
│
├─ 是否需要高可解释性？
│  ├─ 是 → 需要结构化分析报告
│  │       → 偏好 Fusion（判官报告清晰可见）
│  └─ 否 → 效果优先，不关心黑盒
│
└─ 最佳实践：两者混合
    Fugu 处理长期复杂流程
    Fusion 处理单次深度分析

多模型编排设计框架¶

设计原则¶

原则 1：模型多样性

拒绝同质化模型堆叠。团队需纳入不同知识结构与推理风格的模型：

❌ 错误做法：GPT-4 + GPT-4o + GPT-4-turbo
   → 同质化严重，共识多、矛盾少，无互补价值

✅ 正确做法：DeepSeek（代码）+ Claude（逻辑）+ Llama（常识）
   → 异质化组合，共识/矛盾/盲点分析才有意义

原则 2：智能协调机制

放弃手写大量 If-Else 规则，应导入结构化提取共识/矛盾的机制，或用小模型动态调度大模型。

原则 3：高质量合成灵魂

多模型系统的成败取决于最后的「判官审视」与「融合提炼」，绝非简单的文本拼接。

工程师落地清单¶

✅ 设计可插拔的代理池（Agent Pool）架构
✅ 纳入不同知识结构和推理风格的模型
✅ 导入结构化的共识/矛盾/盲点分析机制
✅ 用小模型做协调器，大模型做执行者
✅ 将「绑死单一闭源 API」转为随时可替换的模型组合
❌ 不要简单拼接多个模型的输出文本
❌ 不要堆叠同质化模型（同一家族的变体）
❌ 不要手写复杂 If-Else 调度规则

全文总结¶

单体超级模型的时代并未结束，但在深度研究与代码验证等特定任务上，「模型编排」已成为一条全新且极具成本优势的性能扩展路线（Scaling Law 的新解）。

架构设计的分工协作力量，有时更胜于单纯堆叠模型参数规模。以几十分之一的预算成本，搭建出超越当前顶级闭源模型性能的专属 AI 团队，正在从设想变为现实。

参考资料¶

便宜模型组合打败 Fable 5？Fugu 和 Fusion 的编排秘密
Sakana AI — Trinity & Conductor (ICLR 2026)
OpenRouter Fusion