一个 0.6B 小模型，凭什么指挥 Opus 和 GPT

不是更大的模型在赢，而是会用模型的系统在赢。

一个反常识的开源项目

Sakana AI 发布 Fugu 时，外界把它当成一个”新模型”来报道。

但它本质上不是模型，是一套编排策略：用一个极小的语言模型当调度器，根据用户问题，从 Opus、GPT、Gemini 等大模型池里选出最合适的 worker，再把答案拼回给用户。外表看起来像一个模型，内部却是一整个 multi-agent 系统。

现在，这套系统有了完整的开源复刻版：OpenFugu。

项目地址：trotsky1997/OpenFugu，协议 Apache-2.0，代码 100% 可运行。

0.6B 模型指挥大模型的秘密

OpenFugu 的核心架构叫 TRINITY，用三个词就能说清：

1. 不生成答案 一个约 0.6B 参数的 Qwen3-0.6B 作为 backbone，永远不直接回答用户。它只在最后一层隐藏状态输出一个向量。

2. 线性打分 这个向量进入一个无偏置线性头，给每个候选 worker 模型打分。训练后，这个 head 只有约 19.5K 可训练参数。

3. 分发执行 得分最高的 worker 被 dispatch，执行任务，返回最终答案。整个决策过程对用户完全透明。

这个机制最巧妙的地方在于：调度器本身不生成内容，它只做决策。这极大降低了推理成本和延迟，同时保留了”多模型协作”的能力上限。

验证结果：95% / 100% / +107%

OpenFugu 不是纸面复刻，它把可验证的数字做出来了：

self-test 95% agent / 100% role：用真实权重跑 37 题 fixture，agent 判别 95%，role 判别 100%，说明复刻的决策逻辑和原版高度一致。
+107% over best single worker：在 orchestration 评测中，训练好的路由器比”只选最优单模型”的成绩高 107%。
reward 1.21 → 1.64：GRPO 训练 100 步，Conductor（7B 版编排器）的 reward 稳定上升，说明”让模型学会规划工作流”这件事确实可学。

这些数字重要，因为它们回答了最关键的问题：**开源复刻不只是”看起来像”，而是”跑起来也成立”**。

四阶段完整 Pipeline

OpenFugu 把自己拆成四个可独立运行的部分，这也是它作为开源项目最实用的设计：

Read（读懂） docs/HOW_FUGU_IS_IMPLEMENTED.md 把原论文和作者代码里的数学机制完整还原，每一处推导都有 EXEC / CODE / DATA 三级证据标注。不是”我觉得是这样”，而是”源码/论文/实验结果对应到了哪一段”。

Run（跑通） openfugu/mini.py 提供离线 mock pool 演示；openfugu/ultra.py 提供 Fugu-Ultra 的 workflow-DAG 版本。加上 scripts/fetch_artifacts.py 拉取 Qwen3-0.6B 和公开权重，pip install 之后就能跑。

Train（可训练） 两个训练脚本都很干净：

train_trinity.py：用 sep-CMA-ES 从零训练路由头，不需要任何 Sakana 权重，mock 环境下几秒就能看到从随机到最优的收敛过程。
train_conductor.py：用 GRPO 在 ToolScale 数据集上训练 7B Conductor，让模型学会生成可执行的 workflow DAG。

Serve（可上线） openfugu/serve.py 对外暴露一个 OpenAI 兼容的 /v1/chat/completions 接口，内部自动走 TRINITY 路由到一个 litellm worker pool。对上层应用来说，它就是一个普通模型；对内部来说，它已经悄悄调度了多个模型。

这套设计意味着开发者可以直接把 OpenFugu 接入现有系统，而不需要改写业务代码。

Fugu-Ultra：不止选模型，还能生成工作流

TRINITY 解决的是”选哪个 worker”的问题，属于单步路由。

Fugu-Ultra 解决的是更复杂的问题：用户任务可能天然需要多步，比如”先检索 → 再计算 → 再总结”。这时候”选模型”不够，需要一个编排器来规划工作流。

OpenFugu 的 Ultra 版本用一个 7B Conductor 来生成完整的 workflow DAG，然后自动执行。它甚至可以递归修订自己的输出：第一轮答案作为第二轮输入的上下文，形成 test-time scaling 的效果。

实验结果是诚实的：mock 场景 +9%，真实递归场景目前是 TIE（平局）。这个 honesty 本身值得尊重，说明作者没有为了宣传效果过度包装。

自适应 k-of-n：换模型池也能跑

很多 multi-model 方案的问题是绑定死某个 worker pool，换一批模型就要重新训练。

OpenFugu 解决这个问题的思路是自适应 k-of-n 路由：每次只从 n 个候选里随机 mask 掉一部分，让模型学会在不知道完整池的情况下仍然做出合理决策。

实测结果：mock 下 +44% over blind，94% of oracle；真实 per-step 场景下，base 0.625 → 1.000（n=8），通过验证。

这给了开发者一个实用的承诺：你可以换掉 worker 池里的模型，只要保持接口格式不变，路由器不用重新训。

开源生态位：填补了什么空白？

OpenFugu 的价值不只是”又一个多模型项目”。

在此之前，多模型协作大多是两种路线：

手工编排：LangChain/LlamaIndex 的 chain 和 DAG，需要开发者自己写路由逻辑。
黑箱产品：Sakana Fugu 本身效果强，但权重和训练细节都不公开，无法复现、无法定制。

OpenFugu 刚好填补了中间的空白：可复现、可训练、可接入现有系统、可替换 worker 池。

Apache-2.0 协议意味着你可以把它塞进商业产品；独立的反向工程意味着它不是 Sakana 的附属物，而是社区可维护的独立资产。

一个值得关注的信号

OpenFugu 的项目结构非常”研究向工程化”：read 阶段有带证据等级的架构文档，run 阶段有可执行的最小例子，train 阶段有从零训练脚本，serve 阶段有标准 API。

这不是一个为了 star 而生的 demo，而是一个希望被实际使用和继续迭代的项目。

266 个 star，48 个 fork，1 个 issue——项目还很早期，但骨架已经清晰。如果你关心 multi-agent 系统、模型路由、或 LLM 编排层的开源方案，这个 repo 值得放进 watch list。