Sakana AI : 怎么把多个大模型"组队"，让组合体打败任何单个模型？

过去两年，我们已经习惯了一种叙事：参数更多、数据更大、算力更猛，分数就更高。可越来越多人开始感到一种 "边际疲劳" ——继续把单个模型做大的回报，正变得既昂贵又不确定。

论文-1 ：TRINITY: An Evolved LLM Coordinator 链接：https://arxiv.org/pdf/2512.04695v3

论文-2：Learning to Orchestrate Agents in Natural Language with the Conductor 链接：https://arxiv.org/pdf/2512.04388v5

而桌面上其实早已摆满了好东西：GPT-5、Gemini 2.5 Pro、Claude 4 Sonnet，还有 DeepSeek-R1、Qwen3、Gemma3 这些开源选手。它们各有所长，却没有谁是全能冠军——有的擅长数学推理，有的更会写代码，有的胜在知识广博。

于是一个很自然的问题浮上来：能不能不再纠结"哪个模型最强"，而是把它们当成一支乐队，让它们合奏？

难点在于，这支乐队没法被简单地"焊"成一个。权重合并（model merging）要求架构彼此匹配，而闭源模型连权重都不会给你，你手里只有一个 API。Sakana AI 的回答是绕开合并，走另一条路：在推理时协同（test-time coordination）。不去改动任何一个大模型的参数，只训练一个轻量的"指挥者"，让它在每道题面前临场决定——让谁上场、做什么、又能看到什么。

更有意思的是：同一支团队在 ICLR 2026 上，一口气交出了两张答卷。它们攻的是同一个问题，给出的却是两种几乎相反的指挥哲学。

先说清楚：为什么"组队"值得做

把多个模型摆在一起，并不是越多越热闹越好。

第一，没有"万能选手"。在 Sakana 的实验里，Gemini 2.5 Pro 在数学和常识推理上突出，GPT-5 在代码上更强，Claude 4 Sonnet 则相对均衡——没有任何一个能在所有任务上通吃。这意味着，如果你总是只用同一个模型，就一定在某些题上吃亏。

第二，"理论上限"高得诱人。TRINITY 这篇论文做了一个很有说服力的对照：如果对每道题，都能从七个模型里挑出那个恰好答对的，得到的"逐题最优"（Per-Question-Best）分数，会显著高于任何单一模型。换句话说，这群模型的集体能力，远没有被现有用法榨干——只是缺一个会挑、会调度的指挥。

第三，已有的多智能体方法，要么贵、要么笨。让多个模型互相"辩论"、反复自我反思，或者用一个固定的路由器把问题分给某个模型，这些做法要么调用成本高得惊人，要么策略写死、不会随题目变化。有些方法在某些任务上的表现，甚至还不如随机选一个模型。

所以真正的挑战不是"把模型堆起来"，而是：用一个足够轻、又足够聪明的协调机制，把这群异构模型的长处精准地组织起来。Sakana 的两篇论文，正是这个问题的两个极端解。

第一种活法：TRINITY，一个"沉默的"进化指挥家

TRINITY 的赌注是：指挥者本身不需要很聪明，甚至不需要"开口说话"。

它的协调器小得惊人——一个约 0.6B 参数的小语言模型（用的是 Qwen3-0.6B），后面接一个极轻量的"头"，可训练参数加起来不到 20000 个（其中那个头大约只有 10000 个参数）。对照动辄几十上百亿参数的大模型，这几乎可以忽略不计。

它最反直觉的一点是：协调器自己生成的文字会被直接丢掉。它真正用来做决策的，是模型内部的隐藏状态（hidden state）——具体说，是倒数第二个 token 那一刻的隐向量。论文的核心假设是：一个小模型的内部表示里，已经编码了对当前问题足够丰富的上下文信号，足以让一个微型的"头"据此做出调度决策。于是它不必等模型把整段话写完，读一眼内部状态就能快速决定。

决策本身被收敛成两个离散选择：从模型池里选哪一个 LLM，以及给它指派三种角色中的哪一个——

• Thinker（思考者）：负责出高层策略、拆解问题、点评半成品方案；
• Worker（执行者）：负责动手，产出推导、代码或具体答案；
• Verifier（验证者）：负责检查当前解对不对、完不完整，给出"接受 / 返工"的判断，必要时还附带诊断。

整个过程是多轮循环：每一轮，指挥者读一遍完整对话，挑一个模型、派一个角色；当验证者点头"接受"，或者用满了回合预算（最多 5 轮），就停下来交出答案。一道复杂的折旧计算题，可能就是 Thinker 先拆步骤、Worker 再算数、Verifier 最后挑出"该用直线法还是双倍余额递减法"的边界情形——三个角色像接力一样把题做完。

那它怎么训练？这是另一个反直觉之处：不用强化学习，而用进化策略（sep-CMA-ES）。论文给出的理由很硬核：这个优化问题维度很高、参数之间几乎互不相关、每走一步都要真的去调用一串大模型（很贵），而且回报只有"对 / 错"这种二值信号。在这种"块可分"（block-ε-separable）的地形里，REINFORCE 这类基于梯度的方法信噪比极低、信用分配很糟；而免梯度的进化策略反而更稳、更强。论文用理论和实验都论证了：在这种极度受限的预算下，进化策略明显优于强化学习、模仿学习与随机搜索。

成绩也很硬：TRINITY 在 LiveCodeBench 上刷出 86.2% 的 pass@1，创下新纪录；在四个训练外的新任务（AIME、BigCodeBench、MT-Bench、GPQA-D）上零样本迁移，平均分 54.21，超过它所调度的每一个单模型。一个不到 20000 参数、还"不说话"的指挥，调度出了超越所有独奏者的合奏。

第二种活法：Conductor，一个"健谈的"语言指挥家

如果说 TRINITY 是把指挥压到极简，那 Conductor 走的是完全相反的方向：让指挥者成为一个真正会"写谱"的大模型。

Conductor 本身就是一个 7B 的语言模型（从 Qwen2.5 出发），它的输出不是某个隐向量，而是一整套用自然语言写成的"协作工作流"。具体来说，它会吐出三段一一对应的列表：

• subtasks：一串自然语言子任务，等于是给每个工人现场写好的指令；
• model_id：每个子任务交给七个工人模型里的哪一个；
• access_list：每个工人能看到此前哪些步骤的结果——这等于在设计"谁跟谁通信"的拓扑。

这三样东西合起来，让 Conductor 可以自由地搭建各种协作结构：可以是链式的（一个接一个），可以是树形并行的，也可以先各自独立尝试、再开一轮"辩论"互相比对。它不仅在做任务分配，更在为每个工人做提示工程（prompt engineering）——把同一道题，翻译成最能激发某个模型长处的问法。

它用强化学习训练（GRPO），奖励信号朴素得近乎简陋：工作流格式能不能被正确解析，以及最终答案对不对。就这么端到端地训了 200 步、960 道题，一些相当老练的协作策略就自己"涌现"出来了：把难题拆成越来越细的子任务、让工人之间共享推理、引入验证与返工。论文用一张训练曲线，展示了这种从笨拙到老练的演化过程。

Conductor 还有两个有意思的延伸。一是递归：它可以把"自己"也当成一个工人来调用，于是形成递归式的拓扑——相当于多给一些推理算力就能再涨一截，开辟了一条新的测试时扩展（test-time scaling）轴。在 BigCodeBench 上，递归版本把分数从 37.8 提到了 40.0。二是自适应工人池：通过在随机子集上微调，它能适配任意的开源 / 闭源模型组合——你想省钱只用开源模型，或者只用闭源模型，它都能重新编排策略。

一个很美的细节是它的"看人下菜碟"：在 MMLU 这种偏知识问答的简单任务上，它学会了只用 2 个智能体协作就够；而在 LiveCodeBench 这种硬核代码任务上，它会自动调度 3 到 4 个智能体、安排更多规划和验证步骤。难者多算、易者少算，而且平均每道题只用约 3 步——比那些动辄堆叠四五个模型的多智能体方法便宜得多。

成绩同样亮眼：7B 的 Conductor 在 GPQA Diamond 和 LiveCodeBench 上都拿到 SOTA，综合平均分 77.27，压过它池子里最强的 GPT-5（74.78）。论文还顺手做了个对照：把指挥模型从 7B 缩到 3B，两者最终都收敛到"重用三个最强模型"的相似分工，但 7B 那版的提示工程明显更老练——说明指挥者越强，越会"写谱"，整支乐队的上限也越高。

两条路，同一个判断

把两篇论文摆在一起看，分野其实非常清晰。

一边是 TRINITY：协调器极小（不到 20000 参数）、靠隐藏状态而非文字做决策、动作空间是"选模型加派三种固定角色"、用进化策略训练。它像一个沉默寡言、却反应极快的调度员。

另一边是 Conductor：协调器是个 7B 大模型、用自然语言写出完整工作流、动作空间是开放的（任意子任务、任意通信拓扑）、用强化学习训练。它像一个会写总谱、会现场说戏的乐队指挥。

一个把"指挥"做成了极简的潜空间路由，一个把"指挥"做成了富表达力的语言元智能体。表面相反，骨子里却共享同一个判断：在一个已经有很多强模型、却没有全能冠军的世界里，下一步的关键能力，可能不在于再造一个更大的独奏者，而在于学会指挥。

而且两条路殊途同归——都在 LiveCodeBench 这类硬基准上拿到 SOTA，都超过了自己池子里的每一个单模型，也都比那些昂贵的多智能体基线更省。

这件事为什么重要

往大里说，这是一种重心的转移：从"把一个模型做到极致"，转向"把一群模型组织到极致"。

对研究者，它提示了一条新的扩展轴。我们已经熟悉了"把模型做大"和"在推理时多想几步"这两条算力轴，而协同——尤其是 Conductor 那种可递归的协同——给出了第三条：把算力花在"怎么调度一群模型"上。

对使用者，它的含义更直接：你不必拥有、也不必重训那些最强的模型，只要训练一个轻巧的协调器，就能把市面上现成的开源与闭源模型，组合出超过其中任何一个的表现。这某种程度上，把"集体智能"变成了一种可以工程化的能力。

也要泼一点冷水

热闹之外，有几处需要清醒。

其一，它仍然站在巨头的肩膀上。两套方法的强大，很大程度来自池子里那几个昂贵的闭源前沿模型。Conductor 论文自己的伦理声明就坦承：这种对昂贵大模型的依赖，可能进一步加剧 AI 带来的鸿沟与门槛。指挥得再好，也得先请得起乐手。

其二，"零参数协同"是个误解——指挥者本身依然要训练，无论是进化出来的微型头，还是强化学习调出来的 7B 模型，都需要数据和算力，只是相比重训一个大模型便宜得多。

其三，目前的亮眼成绩，主要集中在数学、代码、推理这类有明确对错、便于打分的任务上。换到更开放、更主观、更长程的真实场景，这套"指挥—合奏"还能不能同样奏效，仍有待检验。

写在最后

很长一段时间里，我们默认"更强"等于"更大"。Sakana AI 的这两篇工作提供了另一种想象：当强模型已经多到用不过来，真正稀缺的，也许是那个知道何时该让谁上、该说什么、该看什么的指挥。

一个沉默的微型路由，一个健谈的语言元智能体——它们从两端逼近同一个未来：模型的竞争，正在从"独奏的音量"，悄悄转向"合奏的编排"。

---

、算法原理、部署服务、微调训练、Agentic RAG，到系统工程优化和多模态 OCR 项目实战，构建一套完整的大模型学习路径。适合希望深入学习大模型技术、提升工程实战能力、理解前沿论文与开源实现的同学。

---

🌟 关注“唐国梁TGLTommy”，一起持续追踪 AI 技术演进背后的长期趋势。

#大模型 #强化学习 #AIAgent #智能体 #GRPO #Agentic