Sakana AI Fugu技术分析

1. Fugu 发布了什么？#

更准确地说，这次发布的不是一个可下载的单一模型权重，而是一套由 orchestrator model（编排器模型）驱动的服务化系统。官方技术报告把 Fugu 描述为一族用于调度并放大 LLM 代理团队能力的 orchestrator models。对外使用时，它表现为一个 OpenAI-compatible API；对内运行时，它会在一个 worker model pool（工作模型池）上做动态编排。

初始发布包含两个版本：

官方页面和技术报告都强调，Fugu 的目标不是要求用户自己设计多代理流程，而是把多代理系统封装在模型调用背后。用户不需要决定该先让哪个模型规划、再让哪个模型执行、最后让哪个模型检查；这些选择变成了 orchestrator 在 inference time 的决策。

这和普通 routing 系统也不完全一样。一个简单 router 可能只是把问题分到“数学模型”“代码模型”或“通用模型”。Fugu 要学习的是更细粒度的调度策略：在一个多步任务中，某个模型可能不是最终答案最强，但很适合作为 planner；另一个模型在 benchmark 上不一定最高，但在带有工具调用、文件编辑、执行反馈的 harness 里更稳定。Fugu 的训练目标正是捕捉这种“模型在系统中的能力”，而不是只看孤立问答分数。

2. 为什么需要 learned orchestration（学习式编排）？#

单体大模型继续 scaling 当然仍然有效，但代价越来越高，而且不同 frontier model 的专长正在分化。技术报告举的背景包括：一些模型更强于数学和物理推理，一些模型更强于软件工程和安全分析；即使在同一领域里，也可能出现“一个模型擅长规划，另一个模型擅长执行”的细粒度差异。

传统的 model merging 试图在权重层面融合能力，但它有几个天然限制：

• 需要访问模型权重，闭源 API 模型无法直接参与。
• 不同模型架构、tokenizer、训练方式不兼容时，很难合并。
• 合并后的模型通常是静态的，不能根据每个 query 动态选择组合方式。

Fugu 走的是另一条路：不在参数层面合并模型，而是在行为层面组合模型。它把每个 frontier model 当作黑盒 agent，学习如何选择、路由、分工、通信、验证和合成结果。可以把它理解成一种 macro-level model composition（宏观层面的模型组合），或者更直观地说，是“行为级 model merging”。

这也是 Fugu 这类系统的核心技术主张：模型能力不只由 weights 决定，也取决于模型被怎样放进 scaffold 中使用。这里的 scaffold 指模型外部的执行结构，包括提示模板、工具调用、反馈循环、记忆、验证器、多个模型之间的调用顺序和信息传递方式。同一个 LLM 放在普通 chat 界面里是一种能力，放进带工具、反馈、记忆、验证和多模型协作的 agentic scaffold 里，又是另一种能力。

3. 两篇论文分别提供了什么？#

Fugu 背后主要有两篇 ICLR 2026 论文：

• TRINITY: An Evolved LLM Coordinator
• Learning to Orchestrate Agents in Natural Language with the Conductor

它们不是重复关系，而是两种不同粒度的 learned orchestration。

从产品系统看，Fugu 可以理解为把 TRINITY 的轻量编排思路扩展到真实生产任务；Fugu Ultra 则更接近 Conductor，把自然语言 workflow 生成、工具调用、多模型协作和长程记忆结合起来。

4. TRINITY：用小模型隐状态做协调#

TRINITY 的起点可以表述为一个模型组合问题：在已有一组强大 LLM 的前提下，能否用一个很小的 coordinator，把它们组合得比任何单个模型更好？

它的设计非常轻。Coordinator 由一个约 0.6B 参数的小语言模型和一个约 10K 参数的轻量 head 组成。每一轮交互中，系统把当前 query 和已有对话 transcript 输入小模型，取 hidden state，再由 head 输出两类决策：

1. 选择哪个 LLM worker。
2. 分配什么角色：Thinker、Worker 或 Verifier。

三个角色分别承担不同职责：

• Thinker 负责策略、分解、批评和高层计划。
• Worker 负责具体求解、写代码、计算或生成答案。
• Verifier 负责检查当前答案是否正确、完整、对齐用户问题。

形式上，TRINITY 可以写成一个基于 hidden state 的策略：

其中 $s$ 是当前交互状态，$h(s)$ 是小语言模型给出的上下文表示，$a$ 是“选择某个模型 + 某个角色”的动作。这里的关键假设是：即使小模型本身没有 frontier model 的解题能力，它的 hidden state 仍然能编码足够多的任务语义，帮助轻量 head 做出有效调度。

TRINITY 没有主要使用常规 RL 来训练这个 head，而是使用 separable CMA-ES。论文给出的理由是，这个问题维度高、每次评估都要调用多个 LLM、reward 又稀疏，传统基于梯度的 REINFORCE 信号噪声很大。sep-CMA-ES 这种黑盒演化策略可以直接优化终局 reward，不需要构造复杂的中间监督信号。

这里的训练方式和普通语言模型训练差别很大。普通 SFT 通常是“给定输入和标准输出文本，优化 next-token loss”；TRINITY 评估一个候选 coordinator 参数时，则要完整跑若干多轮任务。每一轮由 coordinator 根据当前 transcript 选择模型和角色，再真实调用被选中的 LLM，直到 verifier 接受答案或达到轮数上限，最后用任务是否完成得到 terminal reward。也就是说，一条训练轨迹内部已经包含多次外部 LLM 调用。

论文还指出，如果改成模仿学习，需要先构造“每个状态下应该选择哪个模型和角色”的 oracle 标签。单轮场景已经要对每个问题运行多个 agent、多次采样；多轮场景还会叠加不同历史路径，标签生成成本很快变得不可承受。因此 TRINITY 选择 label-free 的黑盒优化：不要求预先知道正确调度动作，只根据完整任务结果更新 coordinator。

论文实验中，TRINITY 在 MATH500、MMLU、RLPR、LiveCodeBench 等任务上超过单模型和多种 multi-agent baseline，并报告了 LiveCodeBench 86.2% 的结果。该结果的技术含义在于：一个很小的 coordinator，只要能读懂任务语义和 worker 行为差异，就可以把多个大模型组合成更强的系统。

5. Conductor：让 LLM 生成多代理工作流#

TRINITY 的协调空间相对有限：每轮选一个模型和一个角色。Conductor 走得更远，它让一个语言模型直接输出完整的 agentic workflow。

Conductor 的输出由三组列表组成：

• subtasks：每一步要执行的自然语言子任务。
• model_ids：每一步交给哪个 worker model。
• access_list（访问列表）：每个 worker 可以看到哪些前序步骤的结果。

这里的任务分割单位是 workflow step，不是把用户原始 prompt 按文本长度切成几段。Conductor 会先读完整的用户问题，然后生成多个新的自然语言子任务；每个子任务本身就是给某个 worker 的指令。论文里的执行方式是：第一个 worker 会收到用户问题和第一个 subtask；后续 worker 会收到自己的 subtask，以及 access_list 指定的前序 subtask 和对应回答。换句话说，Conductor 学的是“应该向哪个模型提出什么子问题，以及让它参考哪些前序结果”，而不是简单做 prompt slicing。

例如，一个 coding 问题可以被拆成：

1. 让某个模型分析算法。
2. 让另一个模型根据算法写 Python 实现。
3. 让第三个模型检查边界条件和复杂度。
4. 必要时让最终模型整合答案。

access_list 使 Conductor 不只是做线性链式调用，还可以设计树状或并行拓扑。两个 worker 可以独立解决子问题，第三个 worker 只看到它们的结果并负责合成；也可以让某个 verifier 只看到候选答案和题目，不被前面推理过程过度污染。

Conductor 的训练更接近“生成 workflow、执行 workflow、根据结果打分”的闭环。一次 rollout 不是让 Conductor 直接回答问题，而是先让它生成 subtasks、model_ids、access_list 三组列表；系统解析成 workflow 后，再按步骤真实调用对应 worker，最后用 worker 的最终输出和标准答案比对。

它的 reward 有两个层次：

1. 输出格式是否能解析成合法 workflow。
2. 执行这个 workflow 后，最终答案是否正确。

训练中使用 GRPO。论文实验里，Conductor 从 Qwen2.5 7B 初始化，单个 workflow 最多包含 5 个 step；worker pool 包括 Gemini-2.5-Pro、Claude-Sonnet-4、GPT-5，以及 DeepSeek-R1-Distill-Qwen-32B、Gemma3-27B-instruct、Qwen3-32B 等开源模型。训练数据由 960 个推理问题组成，覆盖数学、代码、一般真实世界推理和知识问答，来源包括 MATH、MMLU、RLPR 和 LiveCodeBench V1。论文还用了独立测试集检查泛化，例如 LiveCodeBench V6 和未参与训练的 MMLU/MATH/RLPR 子集。

GRPO 的更新单位是一组 Conductor completions。对同一个问题采样多个 workflow，每个 workflow 都要经过“解析、调用 worker、收集结果、打分”的完整执行过程；再用同组样本的相对表现估计 advantage，更新 Conductor。和普通 reasoning RL 不同的是，Conductor 优化的不是直接答案，而是“生成一个能让 worker pool 解出答案的协作策略”。随着训练推进，论文观察到一些协作策略自然出现：先规划再执行、让不同模型独立尝试、最后验证、针对不同模型专长写不同 prompt、根据任务难度使用更多步骤。

Conductor 还包含两个扩展。

第一是随机 worker pool 训练。训练时每次只给 Conductor 一个随机模型子集，让它学会在不同可用模型集合下重新组织策略。这对应产品里的现实约束：用户可能因为成本、隐私、合规或供应商偏好排除某些模型。

第二是 recursion。Conductor 可以把自己作为一个 worker 调用，在看到某个 workflow 的执行结果后，再生成新的协调策略。这相当于给多代理系统增加一条 test-time scaling 轴：不是让单个模型想更久，而是让 orchestrator 根据中间结果重新组织协作。

6. Fugu Ultra：把 Conductor 推到生产系统#

Fugu Ultra 更接近 Conductor 路线。它追求的不是一次快速 routing，而是在复杂任务上构造多步、多模型、多工具的 agentic workflow。

技术报告中特别提到，Fugu Ultra 在 Conductor 基础上增加了 function calling 和 adaptive agent memory（自适应代理记忆）。这个问题比普通单 agent 工具调用难很多。

单 agent 系统里，工具调用历史只需要进入同一个 transcript。多 agent workflow 里，任何 agent 都可能调用工具，但系统还必须知道：

• 这个 tool call 是哪个 agent 发出的。
• 这个 agent 位于当前 workflow 的哪一步。
• 它能看到哪些前序 agent 的输出。
• 后续 tool result 应该回到哪个 agent 的上下文里。

如果不维护这些状态，多代理工作流很容易塌缩成“第一个 agent 做了什么，后面的 agent 都沿着同一条轨迹走”。技术报告把这称为 orchestration collapse（编排塌缩）。Fugu Ultra 的解决方式是做 intra-workflow agent isolation（工作流内代理隔离）：同一个 workflow 内，不同 agent 的工具轨迹相互隔离，只有 access list 指定的信息会显式传递。

但完全隔离也不行。长程任务中，agent 需要知道前面已经读过哪些文件、运行过哪些命令、拿到过哪些环境反馈，否则会重复探索。Fugu Ultra 因此又引入 persistent shared memory（持久共享记忆）：跨 workflow 保留必要的环境交互历史，让不同 agent 在长期会话中不至于失忆。

从论文里的 Conductor 到产品里的 Fugu Ultra，系统难点已经不只是“训练一个会写 workflow 的模型”，而是要把 workflow、工具调用、记忆隔离、共享状态和最终合成都纳入一个稳定的执行系统。

7. 实验结果解读#

Fugu 官方技术报告在 model card 中给出了一组评测结果。下表摘出其中几个代表性 benchmark：

这组结果表明，Fugu/Fugu Ultra 在 coding、agentic benchmark、科学推理和多模态图表推理上取得了较强表现，同时需要注意三点。

第一，技术报告明确说，除 Fugu 自身外，许多 baseline 分数来自模型供应商报告。它适合作为发布时的横向参考，但还不能替代完全独立、统一 harness 下的评测。

第二，Fugu 并不是每个任务都赢。比如 MRCRv2 里 GPT-5.5 更高，Long Context Reasoning 里 Fugu 比 Fugu Ultra 更高。这反而符合 orchestrator 系统的特点：更多 agent、更深 workflow 不总是更好；有些任务更需要低干扰的直接处理，有些任务才真正受益于多模型协作。

第三，Fugu 的强项主要出现在复杂系统任务上。SWE Bench Pro、Terminal Bench、论文复现、AutoResearch、代码调试、工具调用这类任务，本来就不是单次生成答案，而是需要规划、执行、观察环境反馈、修正和验证。多模型 orchestration 在这种场景里更容易发挥价值。

官方报告中还有一些 qualitative case study，例如 AutoResearch 优化小 GPT 训练 recipe、古典日语假名书信阅读顺序恢复、Rubik’s Cube solver、CAD 机械光圈、盲棋和时间序列交易。这些案例更接近产品能力展示，不能直接等同于标准 benchmark，但它们揭示了 Fugu 面向的任务类型：长程、多步骤、有环境反馈、需要组合不同技能的任务。

8. 这项工作的意义#

Fugu 的技术意义在于，它把“agent scaffold”从手工工程提升成了可训练对象。

以往常见的 agent workflow 通常由人工写出：先 plan，再 call tool，再 reflect，再 revise；或者让多个 agent debate，最后 majority vote。这类方法有效，但很依赖人类对任务的先验设计。Conductor 和 Fugu Ultra 的思路是：让模型学习 workflow 结构、角色分配、信息可见性和验证策略。

TRINITY 和 Fugu 低延迟路线则说明，不是所有 orchestration 都需要完整生成自然语言计划。很多时候，一个小模型的 hidden state 已经足够支持高质量路由。只要训练信号来自真实 worker 表现，系统就能学到“这个 query 交给谁更可能成功”。

这两个方向组合起来，形成了一条新的 scaling axis：

• 单体模型 scaling：训练更大的模型。
• Test-time reasoning scaling：让单个模型想更久。
• Tool-use scaling：给模型更多环境交互能力。
• Orchestration scaling：让模型学会组织多个模型和工具。

Fugu 属于最后一种。它的能力上限不只取决于 orchestrator 自身，也取决于 worker pool、工具环境、记忆机制、评测任务和执行 harness。换句话说，它把“模型能力”变成了一个系统属性。

9. 局限和问题#

Fugu 这种系统也带来新的不透明性。

首先，用户看到的是一个模型 API，但内部到底调用了哪些 worker、各自承担什么角色、如何通信，官方 FAQ 明确说不会暴露。这对普通使用未必是问题，但对可复现研究、审计、安全分析和成本解释都会造成困难。

其次，Fugu 的能力依赖 worker pool。如果底层 provider 更新模型、改变 API 行为、调整安全策略或出现不可用，orchestrator 的行为也可能变化。Sakana 在 FAQ 里说，当新 frontier model 公开发布后，他们预计花大约两周训练和评估新版 Fugu。这说明 Fugu 不是一次性发布后固定不变的单体模型，而是一个会随底层模型生态变化的组合系统。

第三，多代理协作天然增加延迟和成本。Fugu 通过单一费率和低延迟版本缓解这个问题，但 Fugu Ultra 为了质量会调用更深的 agent pool。复杂任务可以接受这种代价，日常短问答未必值得。

第四，评测解释会变复杂。单模型 benchmark 主要评估“模型本身是否具备该能力”；Fugu 这类系统还需要进一步分析：

• 是哪个 worker 贡献了主要能力？
• orchestrator 是否真的学到了组合策略，还是只是学会选最强模型？
• 多代理 workflow 是否提升了正确率，还是只增加了采样次数？
• 工具 harness、执行反馈和 memory 对结果贡献了多少？

这些问题不是否定 Fugu，而是说明 learned orchestration 需要新的评测方法。评价一个 orchestrated system，不能只沿用单模型 leaderboard 的思维。

最后还有数据和合规问题。官方页面提到 Fugu 可通过设置排除特定 provider 或模型，Fugu Ultra 则依赖完整 agent pool；使用数据是否参与训练也提供 opt-out。对企业或研究机构来说，这些细节和 benchmark 分数一样重要。

10. 总结#

Fugu 的技术价值不在于宣称“又一个模型超过了谁”，而在于它把多模型协作本身变成了可训练、可产品化的模型能力。

TRINITY 证明了轻量 coordinator 可以利用小模型 hidden state 和演化优化，在多个强模型之间做有效调度。Conductor 证明了语言模型可以通过 RL 学会生成自然语言 workflow，自动设计子任务、模型分工和通信拓扑。Fugu 则把这两条路线推向实际系统：Fugu 偏低延迟的 learned routing，Fugu Ultra 偏复杂任务的 learned workflow orchestration。

如果说 model merging 是在权重层面融合多个模型，Fugu 更像是在行为层面融合多个模型。它不要求 worker 有相同架构，也不要求访问参数；只要这些模型能作为 agent 被调用，orchestrator 就有机会学习如何组合它们。

这条路线是否会成为下一阶段 frontier AI 的主流，还要看独立评测、成本、延迟、透明度和安全治理能否跟上。但它提出的方向很清楚：未来的强模型可能不只是一个更大的神经网络，也可能是一个学会组织其他模型、工具和环境反馈的模型。

11. 问题和讨论#

问题：这样的调度方法，在最坏的情况下，所有的 N 个 model 都需要处理所有的上下文；在 KV cache 未命中的情况下，每个 model 都需要 prefill，价格会比 cache 命中的情况高很多。最差情况下，最终花费会是单一 model 的 N 倍吗？

从计算量上看，最坏情况确实可能接近这个量级。如果一个 workflow 里有 N 个 worker，每个 worker 都接收完整上下文，且这些 worker 之间不能共享 KV cache，那么每个 worker 都要各自完成一次 prefill。假设上下文长度为 C，单个模型处理这段上下文的 prefill 成本近似为 O(C)，N 个模型各自处理同一段上下文，整体输入侧计算就接近 O(NC)。如果按底层模型调用成本估算，它可以接近“单模型完整处理一次上下文”的 N 倍。

但这是上界，不一定是实际常态。Conductor/Fugu Ultra 里的 access_list 本身就是为了控制信息可见性：后续 worker 不一定看到完整历史，而是只看到被允许访问的前序 subtask 和回答。多代理系统如果设计得好，应该尽量让不同 worker 只读自己需要的上下文，通过子任务、摘要、局部结果和最终合成来降低重复 prefill。否则，多模型协作会退化成“每个模型都读完整上下文再各自回答”，成本和延迟都会迅速放大。

KV cache 也会让成本结构更复杂。对同一个 provider、同一个模型、同一段稳定前缀，cache 命中可以显著降低重复 prefill 的边际成本；但跨 provider、跨模型、上下文被改写或 agent 隔离导致 prompt 不同，通常不能假设 cache 可以共享。Fugu 这种系统如果内部调用多个闭源 frontier model，就很难把一个 worker 的 KV cache 直接复用于另一个 worker。因此，最保守的成本分析应按“不同 worker 独立 prefill”来估计。

从用户侧价格看，还要区分底层推理成本和产品定价。Sakana 对外可以采用统一 API 价格，把内部多模型调用成本打包；但从系统经济性看，最坏情况并没有消失，只是由服务提供方在内部吸收、优化或通过定价覆盖。也正因为如此，learned orchestration 的目标不只是提高正确率，还必须学习何时不调用更多模型、何时缩短上下文、何时让 worker 只看局部信息。否则，多代理系统的质量提升可能会被 prefill 成本抵消。

我的看法：成本上涨就是成本上涨，统一定价并不能掩盖这个问题，一定会反映在用户方面。一样的定价，只能获取比其他家更少的tokens，或者解决相同的问题所需的tokens数量增加为所有模型的tokens之和。

问题：现有 LLM 评测通常用同一份提示词跑所有模型。这份提示词未必经过优化，但因为对所有模型一视同仁，影响是全局的，相对名次大体不变。而 Fugu 这类聚合系统相当于在内部先把提示词优化、拆解之后再交给底层模型，自然更容易拿到好成绩。那么这种比较有意义吗？如果给单体 LLM 和 Fugu 同样一份优化好的提示词，Fugu 还一定赢吗？

先看问题里的一个前提：同一份提示词对所有模型的影响是全局的、相对名次不变。这个假设其实并不牢固。不同模型对提示词格式、措辞、few-shot 示例和指令风格的敏感度差别很大，已有研究表明换一种 prompt 排版就可能让 leaderboard 上的相对名次发生翻转。所以「用统一 prompt 所以公平」更接近一种工程上的约定，而不是「影响被完全抵消」的事实。不过这只是细节，问题真正指向的是更重要的一点：评测到底在测什么。

关键在于，Fugu 的增益不能简单等同于「把提示词优化一下」。内部把用户问题拆成子任务、给每个 worker 改写指令，确实是一种自动化的 prompt engineering，这部分增益原则上可以被「给单体模型一份更好的 prompt」复现。但 Fugu 还做了几件单体模型靠改 prompt 做不到的事：根据任务挑选最合适的 worker（它本身就是在多个模型里选，而单体模型只有自己）、把数学强的模型和代码强的模型组合起来、用另一个模型做验证、以及对同一问题多次尝试再择优（test-time scaling）。这些是「系统结构」带来的能力，不是某一份提示词能塞进单个模型的。

所以这种比较是否有意义，取决于你想测的是什么。如果想测「裸模型智力」，那么确实应该把脚手架拉平——给单体模型同样的分解、检索、验证流程，再比较，这时 Fugu 的优势会明显收窄。但如果想测「在统一 API 背后，哪一种服务能给出更好的结果」，那么 Fugu（系统）对单体模型 API（系统）就是一个公平的产品级比较，文中表格里的分数正是后一种性质。它回答的是「用哪个 API 效果更好」，而不是「哪个模型更聪明」。这也正是第 9 节说评测方法需要更新的原因：learned orchestration 把「模型能力」变成了系统属性，沿用单模型 leaderboard 的思维去解读会失真。

回到最后一问：如果两边都拿到优化好的提示词，Fugu 还一定赢吗？分任务看。对单轮知识问答这种增益主要来自措辞和分解的任务，一份足够好的 prompt 喂给单体模型，很可能把差距追回来一大半——这和表格里 Fugu 在 MRCRv2、Long Context 这类任务上并不占优、甚至落后是一致的。但对 SWE Bench、Terminal Bench 这类需要规划、调用工具、观察反馈、多模型分工和验证的长程任务，优势来自单体模型靠 prompt 拿不到的东西（选专家、组合互补能力、跨模型验证、多次尝试），这时 Fugu 大概率仍然领先。换句话说，Fugu 的胜负本就不该是均匀的，它赢得最多的地方，恰恰是「提示词等价」也抹不平的地方。

我的看法：实际应用有意义，因为中间的调度模型确实优化了提示词。但是这个榜单数据意义不大，因为用于对比的其他模型的分数和提示词质量相关。

参考#

• Sakana Fugu 官方页面
• Sakana Fugu Technical Report
• TRINITY: An Evolved LLM Coordinator
• Learning to Orchestrate Agents in Natural Language with the Conductor