超越更大的模型：为什么模型编排是 AI 基础设施的下一层

一句话判断

AI 的下一层竞争，不只是“谁训练出更大的模型”，而是“谁能把多个模型、多个 Agent、多个供应商，稳定地编排成一个可用、可控、可替换的智能系统”。

Sakana AI 发布的 Fugu，就是这个方向的一个重要信号。

但需要先把判断放准：Fugu 不是从 0 到 1 的技术突破，也不是突然发明了多模型协作。它更像是 MoA、多模型路由、AI Gateway 和 Agent 编排的一次高阶产品化。

它真正值得关注的地方，不是“它有多神”，而是它把一个趋势推到了台前：

AI 基础设施正在从 Model API，走向 Model Operating Layer。

过去我们关心的是：哪个模型最强。

接下来我们更需要关心的是：如何把多个模型变成一个稳定、可控、可进化的系统。

大模型是能力源。

编排层才是操作系统。

1. Fugu 到底是什么？

Fugu 的产品形态很关键。

它不是一个传统意义上的单体 LLM，也不是简单的模型网关，而是一个 Multi-Agent System as a Model。也就是说，它把一个多模型、多 Agent 协作系统，包装成了一个看起来像普通模型的 API。

用户不需要手动选择模型，也不需要自己写复杂的工作流。只要调用一个 OpenAI-compatible API，Fugu 在背后决定：这个任务该由哪个模型处理？要不要拆成多个步骤？谁负责规划？谁负责执行？谁负责验证？是否需要切换模型？是否需要更深的推理池？

Sakana 官方页面把 Fugu 定义为 “One Model to Command Them All”，强调它通过一个统一 API 动态编排多个模型和专家 Agent，处理复杂、多步骤任务。

这就是 Fugu 最值得讨论的地方：

它不是普通的“模型选择器”，而是试图成为“模型指挥层”。

传统 LLM Router 解决的是：

给一个 prompt，选哪个模型。

Fugu 想解决的是：

给一个任务，组织一组模型完成它。

这两者不是一个层级。

前者是 routing。

后者是 orchestration。

2. 但必须客观看：Fugu 并不是凭空冒出来的新范式

如果只看技术原创性，Fugu 不应该被高估。

多模型协作早就存在。Mixture-of-Agents 已经提出通过多层 LLM agent 协作，让后一层读取前一层多个模型的输出，再综合出更好的结果。

MoA 论文链接： https://arxiv.org/abs/2406.04692

模型路由也早就存在。RouteLLM、Not Diamond、OpenRouter Auto Router、FrugalGPT 都在解决类似问题：不同任务应该调用不同模型，而不是每次都用最贵、最强的模型。

RouteLLM 官方介绍： https://lmsys.org/blog/2024-07-01-routellm/

RouteLLM 论文： https://arxiv.org/abs/2406.18665

OpenRouter Auto Router 文档： https://openrouter.ai/docs/guides/routing/routers/auto-router

OpenRouter Auto Router 模型页： https://openrouter.ai/openrouter/auto

Not Diamond 官网： https://www.notdiamond.ai/

Not Diamond 模型路由文档： https://docs.notdiamond.ai/docs/what-is-model-routing

FrugalGPT 论文： https://arxiv.org/abs/2305.05176

AI Gateway 也已经存在。LiteLLM、Portkey、OpenRouter 这类系统，已经在做统一 API、多 provider 接入、fallback、限流、负载均衡、成本控制和调用治理。

LiteLLM 官网： https://www.litellm.ai/

LiteLLM GitHub： https://github.com/BerriAI/litellm

LiteLLM Router 文档： https://docs.litellm.ai/docs/routing

Portkey AI Gateway GitHub： https://github.com/portkey-ai/gateway

所以如果把 Fugu 拆开看，它确实很像：

MoA + OpenRouter / NotDiamond + LiteLLM / Gateway + 一层 Agent 编排包装。

这不是贬低，而是更准确地定位。

Fugu 的价值，不在于它发明了多模型协作；而在于它把多模型协作、模型路由、任务拆解、角色分配、验证综合、供应商抽象，封装成了一个像基础模型一样调用的产品形态。

这才是它的核心信号：

模型编排正在产品化。

3. Fugu 背后的研究：TRINITY 和 Conductor

Fugu 也不是纯营销包装。它背后确实有明确的研究支撑。

Sakana 官方说明，Fugu 基于两篇 ICLR 2026 论文：TRINITY 和 Conductor。二者都指向一个方向：learned model orchestration，也就是让系统学习如何组装、路由和协调专家 Agent，而不是完全依赖人类手写工作流。

TRINITY 官方介绍： https://sakana.ai/trinity/

Conductor 官方介绍： https://sakana.ai/learning-to-orchestrate/

3.1 TRINITY：轻量协调器

TRINITY 的核心思想是 test-time model composition。

它不修改底层模型权重，而是在推理时用一个轻量 coordinator，把多个模型的能力组合起来。这个 coordinator 会在多轮过程中从模型池中选择 LLM，并分配不同角色。

这些角色包括：

Thinker：负责思考、规划、拆解。
Worker：负责执行、求解、生成。
Verifier：负责验证、判断、终止。

这很重要。

过去我们做 Agent，经常是人类手写流程：先 Planning，再 Execution，再 Reflection。

TRINITY 的方向是：让一个协调器学习何时规划、何时执行、何时验证，以及调用谁来做。

这就是从 prompt workflow 走向 learned orchestration。

3.2 Conductor：让模型学会管理模型

Conductor 更进一步。

Sakana 对 Conductor 的解释是：过去几年，人类一直在做 prompt engineering，试图激发不同 LLM 的最佳表现；而 Conductor 研究的是，如果训练一个 AI 来做这件事，会发生什么。

结果是，通过强化学习训练后，Conductor 会自然学会为一整个模型池写出有效的定制指令，本质上是在用自然语言管理其他模型。

这句话很关键：

未来的 Agent 编排，不一定是人类写 DAG，而可能是模型动态生成 DAG。

以前的工作流系统是人定义节点：

第一步调用 A，第二步调用 B，第三步验证。

Conductor 的方向是模型自己判断：

这个问题需要三个角色。先让强推理模型做方案，再让代码模型实现，再让验证模型检查边界条件，最后由综合模型汇总。

这不是“多接几个模型”那么简单，而是把编排策略本身变成可学习对象。

不过也要注意：目前 Fugu 的底层模型池、路由策略、每个模型的贡献路径、失败案例、成本结构并不完全透明。所以它是否形成了真正难以复制的技术壁垒，还需要更多独立验证。

4. 为什么这不只是技术优化，而是基础设施问题？

过去模型路由主要解决三个问题：

第一，降成本。简单问题不用最贵模型。

第二，降延迟。低难度任务走快模型。

第三，提质量。复杂问题交给强模型。

但现在，模型编排正在被推到更高层：

供应商依赖、出口管制、组织韧性、AI 主权。

Sakana 在 Fugu 页面中强调，它提供的是 “frontier-level performance without single-vendor dependency”，也就是在不依赖单一供应商的情况下获得前沿能力。它还提到，用户可以从 Fugu 的模型池中排除特定模型或 provider，以满足数据、隐私、合规或组织要求。

Sakana Fugu 官方页： https://sakana.ai/fugu/

这背后的现实背景是：前沿模型已经不再只是普通 SaaS 服务，而正在变成战略资产。

2026 年 6 月，Reuters 报道了 Anthropic 的 Mythos 和 Fable 模型出口管制事件。报道称，美国商务部长在致 Anthropic CEO 的信中要求暂停这些模型的出口和对外国国民的转让，Anthropic 随后表示会在全球范围内关闭这些模型访问。

Reuters 报道链接： https://www.reuters.com/technology/anthropic-us-officials-meeting-monday-resolve-dispute-over-export-curbs-2026-06-15/

这件事的信号意义很强：

模型访问权可能因为监管、地缘政治或供应商政策突然变化。

对于个人开发者来说，这可能只是“今天 API 不能用了”。

但对企业、金融、关键基础设施、政府系统来说，这就是运营风险。

如果核心业务只绑定一个模型供应商，一旦出现涨价、限流、模型下架、区域限制、合规调整、出口管制，整个业务链路都会被动。

所以模型编排不再只是“省钱工具”。

它正在变成：

供应商风险管理
合规隔离层
成本控制层
可观测治理层
任务执行编排层
AI 主权基础设施

这就是 Fugu 这条信号真正值得关注的原因。

5. 模型编排不等于“模型越多越强”

这里必须降温。

多模型、多 Agent，并不天然更强。

很多人看到多个模型协作，就会直觉认为：模型越多，结果越好。

但真实情况不是这样。

多模型协作有成本，也有噪声。低质量模型可能拖累整体结果。不同模型之间的输出可能相互污染。复杂编排可能带来更高延迟、更高 token 成本、更难排查的问题。

所以真正高级的模型编排，不是盲目堆模型，而是知道什么时候不该编排。

一个成熟的 Orchestrator 至少要回答五个问题：

什么时候只用一个最强模型就够了？
什么时候应该先用便宜模型试探？
什么时候应该拆成多个子任务？
什么时候需要独立验证模型？
什么时候继续调用模型已经不值得？

这才是模型编排的核心难点。

不是“把模型放进池子里”，而是“知道何时调用、调用谁、调用几次、如何停止”。

从这个角度看，真正的壁垒不是模型数量，而是调度策略。

6. Fugu 的边界：它不是 AI 主权的全部

Fugu 的方向重要，但不能把它夸成“AI 主权的完整答案”。

首先，Fugu 本身也是一个商业服务，也会受到自身公司、地区、法规和服务条款影响。官方页面也说明，Fugu 暂未向 EU/EEA 提供服务，其他地区也可能因为网络条件或当地法规而无法访问。

其次，Fugu 并不公开具体调用了哪些底层模型。官方 FAQ 写到，Fugu 选择了哪些模型、如何协调它们属于专有技术，因此不会向用户暴露。

Fugu 官方页： https://sakana.ai/fugu/

这意味着它解决了一部分问题，也引入了新的黑箱。

对于普通开发者，这可能不是问题。

但对于金融、医疗、政务、国防、企业核心数据系统，仅仅知道“系统会自动编排模型”是不够的。

真正的 AI 主权至少还需要：

本地可部署模型
可控算力资源
数据边界控制
模型调用审计
供应商白名单/黑名单
权限与身份系统
Eval 和回归测试
成本与 SLA 治理
故障降级策略
合规留痕

所以更准确的说法是：

Fugu 不是 AI 主权本身，而是 AI 主权架构中的一个关键方向：可替换、可编排、可降级的模型能力层。

7. 从 Router 到 Gateway，再到 Orchestrator

Fugu 不是孤立事件。它背后是一整条正在形成的技术路线。

可以分成三层看。

第一层：LLM Router —— 选择哪个模型

这一层解决的是：同一个请求，应该发给哪个模型？

代表项目包括 RouteLLM、Not Diamond、OpenRouter Auto Router、FrugalGPT。

RouteLLM 是 LMSYS 提出的开源模型路由框架。它基于偏好数据训练 router，在推理时动态选择强模型或弱模型，目标是在成本和质量之间取得更好平衡。

RouteLLM 官方介绍： https://lmsys.org/blog/2024-07-01-routellm/

RouteLLM 论文： https://arxiv.org/abs/2406.18665

OpenRouter 的 Auto Router 是更产品化的版本。官方文档写到，openrouter/auto 会自动分析 prompt，并从 curated model set 中选择最佳模型，考虑因素包括 prompt complexity、task type 和 model capabilities；它的能力由 NotDiamond 提供。

OpenRouter Auto Router 文档： https://openrouter.ai/docs/guides/routing/routers/auto-router

OpenRouter Auto Router 模型页： https://openrouter.ai/openrouter/auto

Not Diamond 的定位也很直接：它提供 model routing，让开发者在质量、成本、延迟之间自动选择更合适的模型。

Not Diamond 官网： https://www.notdiamond.ai/

Not Diamond 文档： https://docs.notdiamond.ai/docs/what-is-model-routing

FrugalGPT 则更早提出了 LLM cascade 思路：通过 prompt adaptation、LLM approximation、LLM cascade 等方法降低调用成本。

FrugalGPT 论文： https://arxiv.org/abs/2305.05176

这一层的核心价值是：

不要每次都用最贵模型，而是按任务难度动态选择模型。

第二层：LLM Gateway —— 多供应商治理

这一层解决的是：如何把多个模型、多个 provider、多个 key 变成一个稳定服务？

代表项目包括 LiteLLM、Portkey、OpenRouter。

LiteLLM 的 Router 支持 load balancing、fallbacks、budget routing、tag-based routing、timeouts、health check driven routing 等能力。它的核心价值，是把多个模型 provider 抽象成统一的 AI Gateway。

LiteLLM 官网： https://www.litellm.ai/

LiteLLM GitHub： https://github.com/BerriAI/litellm

LiteLLM Router 文档： https://docs.litellm.ai/docs/routing

Portkey 的 AI Gateway 也强调 automatic retries、fallbacks、load balancing、conditional routing、guardrails 和多模型接入。

Portkey AI Gateway GitHub： https://github.com/portkey-ai/gateway

这一层已经很接近企业基础设施。

它不一定让模型更聪明，但能让模型服务更稳定、更可控、更便宜。

如果说 Router 解决的是“选哪个模型”，Gateway 解决的就是：

模型调用如何进入生产系统。

这里的关键词不是 intelligence，而是：

稳定性
熔断
重试
降级
限流
计费
审计
成本治理
多供应商管理

第三层：Orchestration Model —— 让模型管理模型

这一层才是 Fugu 最接近的方向。

代表包括 Fugu、TRINITY、Conductor、Router-R1、Mixture-of-Agents。

Mixture-of-Agents 是 Together AI 提出的多模型集成方法。它通过分层 MoA 架构，让每一层的多个 LLM agent 参考上一层所有输出，再生成更好的答案。

Mixture-of-Agents 论文： https://arxiv.org/abs/2406.04692

Router-R1 则把多 LLM 路由和聚合建模为一个 sequential decision process。它让 router 本身作为一个 LLM，在多轮中交替进行 think 和 route 动作，并把各模型响应整合进上下文。

Router-R1 论文： https://arxiv.org/abs/2506.09033

Router-R1 GitHub： https://github.com/ulab-uiuc/Router-R1

Fugu 的特殊性在于：它不是论文 demo，而是把这个能力包装成了一个可商用 API。

这意味着下一阶段的模型基础设施，可能不是一个静态网关，而是一个“会思考的调度层”。

它要判断的不只是：

用 GPT 还是 Claude？

而是：

这个任务应该怎么拆？哪个模型适合规划？哪个模型适合代码？哪个模型适合验证？是否需要多轮？是否需要并行？是否值得增加成本？什么时候应该停止？

这就是从 routing 到 orchestration 的跃迁。

8. 对产品和组织的启发

Fugu 这条信号，对 AI 产品和企业系统有三个直接启发。

第一，模型中转不是终点

很多团队现在在做 LLM Proxy、AI Gateway、模型聚合器。这是必要的，但不是终局。

如果只是把多个模型接进来，然后提供一个统一 API，本质上还是“模型中转”。

真正的下一层能力是：

模型治理 + 编排策略 + Eval 反馈闭环。

也就是说，系统不仅要能调用模型，还要知道：

哪些任务适合哪个模型？
哪些模型在当前场景下表现下降？
哪些 provider 最近失败率上升？
哪些任务值得升级到强模型？
哪些输出需要二次验证？
哪些失败要触发 fallback？
哪些调用成本异常？
哪些模型应该下架、灰度或隔离？

这才是 AI 基础设施的壁垒。

第二，Agent 的核心不是工具数量，而是调度能力

过去做 Agent，很容易陷入“接更多工具”的思路。

但 Fugu、Conductor、TRINITY 共同说明：真正重要的不是工具越多越好，而是系统是否知道什么时候调用谁、以什么角色调用、如何验证结果。

Agent 的能力不是简单叠加：

工具 + 模型 + prompt

而是一个调度系统：

任务理解 → 模型选择 → 角色分配 → 上下文路由 → 执行验证 → 结果综合 → 反馈学习

没有调度能力，工具越多，系统越乱。

有调度能力，多个普通模型也可能组合出强结果。

第三，AI 主权不是只靠国产模型，也不是只靠开源模型

AI 主权经常被简单理解为“自己有模型”。

但从 Fugu 这条线看，更完整的 AI 主权应该包括三层：

第一层是 模型主权：有没有可控模型。

第二层是 数据主权：数据是否能留在受控环境。

第三层是 编排主权：系统是否能在模型、供应商、任务和合规约束之间自主调度。

没有编排主权，即使有多个模型，也只是“多个供应商账号”。

有了编排主权，模型池才真正变成能力池。

所以未来企业建设 AI 基础设施，不能只问：

我们接了哪些模型？

更应该问：

我们是否能在模型失效、涨价、限流、下架、合规变化时，自动切换、降级、审计和恢复？

这才是组织级 AI 能力。

9. ReelOS.ai 的判断

Fugu 代表的不是一个单点产品，而是一个行业阶段变化：

AI 正在从 Model API 时代，进入 Model Operating Layer 时代。

Model API 时代的核心问题是：

哪个模型最强？

Model Operating Layer 时代的核心问题是：

如何把多个模型变成一个稳定、可控、可进化的系统？

这会带来一批新的基础设施机会：

AI Gateway
LLM Router
Model Eval
Agent Orchestrator
Context Router
Cost Controller
Provider Governance
Compliance Layer
Model Observability
Workflow-to-Agent Runtime

但对 Fugu 本身，也要保持克制判断。

它没有证明“编排一定超过所有大模型”。

它没有证明“多模型天然优于单模型”。

它也没有完整解决 AI 主权问题。

它真正证明的是：

当模型越来越多、能力越来越接近、价格越来越复杂、监管越来越不确定时，谁掌握模型编排层，谁就掌握 AI 系统的主动权。

未来最强的 AI 系统，可能不是一个巨大的黑箱模型，而是一个由多个模型、多个 Agent、多个工具、多个上下文层组成的协作生态。

单模型决定能力上限。

编排层决定任务完成率。

治理层决定能不能进入生产。

Eval 闭环决定系统能不能持续进化。

这就是 Fugu 这条信号的核心：

下一代 AI 基础设施，不是更大的模型，而是更强的模型操作系统。

可执行原则

不要只接一个模型。 关键业务至少要有主模型、备选模型和降级模型。
不要只做模型中转。 中转层必须加入健康检查、成本统计、失败率、fallback 和审计。
不要盲目多 Agent。 多模型协作有成本、有延迟、有噪声，先判断是否真的需要编排。
不要手写死工作流。 复杂任务要逐步引入动态路由、角色分配和验证机制。
不要迷信单次 benchmark。 真正的模型选择要基于自己的业务 Eval。
不要把 AI 主权等同于本地模型。 真正的主权是模型、数据、上下文、权限、编排和治理的组合。
不要把 Agent 当聊天框。 Agent 的下一层核心能力是调度、验证和可复用执行。
不要等供应商出问题后再治理。 模型层的韧性要在架构设计阶段完成。

结语

Fugu 不一定是终局，也不一定有不可复制的技术壁垒。

但它把一个趋势讲清楚了：

模型中转正在升级为模型治理，模型治理正在继续走向模型编排。

过去，AI 产品的基础设施是“能不能接上模型”。

现在，AI 产品的基础设施是“能不能稳定治理模型”。

未来，AI 产品的基础设施会变成“能不能动态组织模型完成任务”。

这才是模型编排成为 AI 基础设施下一层的原因。

更大的模型依然重要。

但更大的模型之后，一定会出现更强的编排层。

因为未来的 AI，不只是生成答案，而是组织能力。

扩展阅读 / 具体链接

Fugu / Sakana AI