Sakana AI Conductor：让一个 7B 模型学会"当主管" · 干货攻略

  • 链接:https://x.com/omarsar0/status/2051306659021242635
  • 分类:x-tips
  • 来源:X @omarsar0
  • 作者:Jay
  • 更新:2026-08-13

⚠️ 重要说明：原帖候选将本工作仓库写作 SakanaAI/Conductor，经核验该 GitHub 仓库返回 404（不存在或未公开）。本文以 arXiv:2512.04388 论文页面和 Sakana AI 官方博客 为权威来源；代码/模型权重是否公开 Release 需以上述官方渠道为准，本文不替代官方公告。

这是什么

Sakana AI Conductor 是一项 ICLR 2026 的研究工作（arXiv:2512.04388），提出了一个全新的Conductor 模型——不是让 AI 直接解题，而是让一个 7B 的"主管"模型学会： 1. 设计 worker 之间的通信拓扑（谁对谁说、说什么） 2. 为每个 worker 写专门的提示词（充当自动 prompt engineer）

Conductor 输出的不是答案，而是一套用自然语言描述的协作工作流（调用哪个 agent、给什么子任务、谁能看到谁的上下文）。它通过纯端到端强化学习（RL）从奖励信号中自然涌现出这些能力，无需人工设计协作策略。

为什么值得关注

解决的核心问题

当前多 Agent 系统要么靠人工设计的固定流程（rigid scaffolds），要么只是简单的"单模型路由器"（router 只选一个最佳模型）。两个方向都无法充分释放不同模型的专长——没有任何单一模型在所有任务上都最优（论文 Section 1 明确指出）。

Conductor 的核心洞察：把"协作拓扑设计"本身也当作一个 RL 优化的问题，让模型自主发现最优的分工策略。

谁分享的

@omarsar0（Sakana AI 研究员）在 X 推文中推荐，称之为"ICLR 2026 重要论文"。

解决什么问题

  • 不同模型在不同领域有各自专长，单一模型无法覆盖所有任务
  • 人工设计多 Agent 协作流程成本高、泛化差
  • MoA（Mixture-of-Agents）等方案调用成本高但效率不一定最优

关键效果（来自官方来源）

指标 数据 说明
LiveCodeBench 83.9% 论文 Figure 1 / 官方博客
GPQA-Diamond 87.5% 论文 Figure 1 / 官方博客
超越所有 worker 模型 ✅ 7B Conductor 超越其调用的任何单一模型
vs Mixture-of-Agents 显著优于，成本更低 官方博客明确说明

核验过程

官方来源（已读）

  1. arXiv Abstract 页（2512.04388）
    确认：ICLR 2026 接收，7B 模型，RL 训练，设计协作拓扑 + prompt engineer 给 worker，达到 LiveCodeBench / GPQA SOTA。Authors 包括 Stefan Nielsen、Edoardo Cetin（两人为共同核心贡献者）、Peter Schwendeman、Qi Sun、Jinglue Xu、Yujin Tang。

  2. arXiv HTML 全文（2512.04388v5）
    确认：Conductor 输出自然语言工作流（Section 1），通过端到端 reward maximization 涌现协作策略，支持递归拓扑（自己作为 worker 加入团队），finetune 后可适配任意 agent 组合。

  3. Sakana AI 官方博客（sakana.ai/learning-to-orchestrate）
    确认数字：LiveCodeBench 83.9%、GPQA-Diamond 87.5%；确认 RL 自发现协作策略（无人工设计）；确认递归测试时Scaling（Conductor 选择自己作为 worker 进行自我纠正）；确认比 Mixture-of-Agents 成本低得多。

交叉验证

  • LinkedIn @omarsar0 帖子与官方博客数字完全一致（83.9% / 87.5%），相互印证。
  • Tavily 搜索结果中多条独立信源（LinkedIn、技术社区讨论）引用相同数字，未发现矛盾。

⚠️ 未核验项（原帖主张，未全部官方文档交叉确认）

  • 原帖称"GPQA-Diamond / LiveCodeBench SOTA"——官方博客确认，SOTA 成立。
  • 原帖称"复现路径清晰"——代码仓库 SakanaAI/Conductor 返回 404，目前无法确认公开 Release 时间表；复现路径以论文方法描述为准，非开箱即用。
  • 具体使用的 worker 模型池（GPT-5、Gemini、Claude 等）——官方博客有描述，论文正文因篇幅限制尚未逐字确认，属较高可信度但非逐字可查证。

上手步骤

理解 Conductor 的输出格式

Conductor 不输出答案，而是输出一个自然语言工作流描述，格式大致如下：

Step 1: 调用 worker=code-expert
  指令："写一个函数来解决..."
  可见上下文：[系统提示 + 用户问题]
Step 2: 调用 worker=verifier
  指令="检查上述代码是否..."
  可见上下文：[Step 1 输出]

每一步指定：调用的 agent、子任务指令、谁能看到哪些历史消息。

关键机制一：动态拓扑

简单问题（如事实查询）→ Conductor 只调用 1 个 worker，1-shot 完成。 复杂问题（如代码调试）→ Conductor 自动构建 planner-executor-verifier 链路，多轮协作。

关键机制二：递归测试时Scaling

Conductor 可以把自己也放进 worker 池。当它读完团队的输出后，发现失败，可以实时启动一个"纠正工作流"——这是论文提出的新的测试时计算Scaling方向。

关键机制三：适配任意 Agent 池

通过在训练时随机化 worker 池组合，Conductor 学会适配任何开放或封闭模型的组合，用户可以自行替换 worker 模型而不影响 Conductor 的协调能力。

延伸阅读

  • 论文：https://arxiv.org/abs/2512.04388
  • OpenReview：https://openreview.net/forum?id=U23A2BUKYt
  • Sakana AI 官方博客：https://sakana.ai/learning-to-orchestrate/

坑与适用边界

⚠️ 当前无公开代码/模型

最大坑：SakanaAI/Conductor GitHub 仓库不存在（404）。目前无法直接跑推理或训练。如需复现，需等待作者团队公开代码仓库，或基于论文描述自行实现（工程量较大）。

适用边界

  • 适合：理解 Conductor 范式、设计类似的多 Agent 协调系统、跟进 RL+Coordination 研究方向
  • 不适合：需要立刻在生产环境部署（暂无 Release）
  • 不确定：benchmark 数字（83.9% / 87.5%）对应的是哪种 worker 池配置下的结果，论文附录可能有细分但尚未逐页核验

与 Mixture-of-Agents 的区别

Conductor MoA（Mixture-of-Agents）
核心思路 Conductor 输出工作流 + 动态拓扑 串行/并行调用多个模型取最优
协作策略 RL 自发现 人工设计路由
调用成本 低（Conductor 7B，小且精准） 高（大量 agent 调用）
可解释性 高（工作流显式输出） 低（隐式聚合）

一句话结论

Conductor 证明了"让一个 7B 小模型学会当主管"是 RL+多 Agent 协作的新方向，LiveCodeBench 83.9% / GPQA-Diamond 87.5% 的 SOTA 效果值得关注，但代码尚未公开，有兴趣跟进需持续关注 Sakana AI 官方渠道。