Learning to Orchestrate Agents in Natural Language with the Conductor · 干货攻略

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

这是什么

Sakana AI 在 ICLR 2026 发表了一篇非常有意思的论文：让一个小模型学会当「指挥家」，而不是自己下场干活。

传统多智能体系统的做法是：人类预先写好流水线（planner → coder → verifier），然后让模型按这个固定流程走。问题在于：不同任务复杂度差异巨大——简单事实问答根本不需要 5 步 pipeline，而复杂编程题可能需要 planner + executor + verifier + 纠错器。硬编码的流程在真实生产环境（用户需求高度异构）下会成为瓶颈。

Sakana AI 的答案是：训练一个 RL「指挥家」，让它自己学会为每个问题动态编排工作流。 这个指挥家（Conductor）是一个 7B 参数的模型（基于 Qwen2.5-7B 微调），它不做具体任务，而是输出自然语言工作流描述：指定调用哪个 worker、给什么具体指令、worker 之间能互相看到哪些上下文。

原文主张（Sakana AI 官方博客）："We trained a 7B Conductor model using Reinforcement Learning to orchestrate a pool of frontier models (including GPT-5, Gemini, Claude, and open-source models)"

为什么值得关注

来自 @omarsar0 的分享，他评价这篇论文是值得 bookmark 的硬核工作。核心亮点：

  1. 全新的 LLM 编排范式：不是 router（只选一个模型），而是 meta-prompt engineer（为每个 worker 写专门的指令）+ 拓扑设计（谁看谁的输出）。
  2. RL 驱动的涌现策略：通过端到端 reward 最大化，指挥家自动学会 prompt engineering、迭代 refinement、meta-prompt 优化——无需人工设计。
  3. 递归测试时扩展（Recursive Test-Time Scaling）：允许 Conductor 把自己也选为 worker，它能看到团队的先前输出，发现失败后立即启动纠错流程。这解锁了一种全新的推理时计算扩展轴。
  4. SOTA 基准：7B Conductor 在发布时刷新 LiveCodeBench（83.9%）和 GPQA-Diamond（87.5%）记录，超越池内所有单个 worker 模型。

⚠️ 注意：上述 LiveCodeBench 83.9% 和 GPQA-Diamond 87.5% 是论文发布时（2026 年 4 月）的数据，并非当前 leaderboard 最新分数。Sakana Fugu 产品在 2026 年 7 月已达 GPQA 95.5%，该分数属于产品而非原始 7B Conductor 论文结果，原帖混用了两个数字，下文坑与边界节会说明。

核验过程

官方来源

来源 内容
Sakana AI 官方博客 https://sakana.ai/learning-to-orchestrate/ 完整介绍了 Conductor 思路、benchmark 数字（83.9% LCB、87.5% GPQA-Diamond）、商业产品 Fugu
arXiv 2512.04388 https://arxiv.org/abs/2512.04388 论文全文（v5），包含方法细节、worker 池组成（GPT-5、Gemini 2.5 Pro、Claude-Sonnet-4 等）、AIME25 93.3%
Sakana AI X @SakanaAILabs 原文声明，83.9% LCB、87.5% GPQA-Diamond
VentureBeat 报道 确认 worker 池包含 7 个模型（3 闭源 + 4 开源）；Conductor 基于 Qwen2.5-7B 微调，训练用 GRPO 算法

交叉验证

  • @omarsar0 原帖数字与官方博客完全一致（83.9% LCB、87.5% GPQA-Diamond），可确认。
  • AIME25 93.3% 在 arXiv 论文和 VentureBeat 报道中均有出现，可确认。
  • BenchLM.ai（2026-07-07） 显示 GPQA 最新 leaderboard Sakana Fugu-Ultra 95.5%，这高于论文中的 87.5%，说明产品层（Fugu）已进一步迭代，原始 7B Conductor 论文结果是 87.5%（发布时 SOTA）。
  • @omarsar0 分享中「GPQA-Diamond 达 87.5%」是论文数字，与 Fugu 产品 95.5% 不是同一指标，需区分。

冲突处理

原帖提到「Sakana AI 7B Conductor 达 GPQA-Diamond/LiveCodeBench SOTA」——这里的 SOTA 是指论文发布时（2026-04）的状态，而 2026-07 BenchLM leaderboard 已更新。本攻略以官方论文数字（87.5%）为准，并注明产品层后来更高。

上手步骤

方法论核心：RL Conductor 是怎么工作的

训练阶段： 1. 给你一个 7B 模型（Qwen2.5-7B 基座）+ 一个随机 worker 池（每次训练随机选择） 2. 每次给一个任务，Conductor 输出自然语言工作流（action: <agent>, instruction: <...>, access_list: [...]） 3. 执行工作流，根据答案是否正确给 reward（GRPO 算法，端到端 reward maximization） 4. 重复，最终指挥家学会：简单问题单步搞定，复杂问题自动搭 planner-executor-verifier 链

推理阶段： - 任意给定 worker 池，指挥家都能动态适应（因为训练时见过随机组合） - 可让指挥家把自己也选为 worker → 递归拓扑 → 自我纠错

关键代码结构（伪代码）

# Conductor 的输出格式（自然语言工作流）
workflow = conductor.generate(
    task=question,
    worker_pool=[gpt5, gemini25, claude_sonnet4, deepseek_r1, ...],
    max_steps=5
)
# workflow 示例（简化）
# Step 1: { agent: planner, instruction: "分析这道题需要什么能力...", access_list: [] }
# Step 2: { agent: coder, instruction: "写代码实现上述方案...", access_list: [1] }
# Step 3: { agent: verifier, instruction: "验证代码正确性...", access_list: [1, 2] }

for step in workflow:
    result = step.agent.execute(step.instruction, context[step.access_list])
    context.append(result)

访问方式

  • 论文：https://arxiv.org/abs/2512.04388
  • Sakana AI 博客：https://sakana.ai/learning-to-orchestrate/
  • 商业产品 Sakana Fugu（beta）：https://sakana.ai/fugu-beta/
  • GitHub：https://github.com/sakanaai（AI-Scientist 等项目在此，Conductor 专项代码本攻略发稿时未见独立仓库，Fugu 相关代码在 SakanaAI/fugu 仓库中）

坑与适用边界

⚠️ 重要数字区分

指标 数字 来源
7B Conductor 论文 GPQA-Diamond 87.5% arXiv 2512.04388（2026-04 发布时 SOTA）
Sakana Fugu 产品 GPQA-Diamond 95.5% BenchLM.ai（2026-07-07），属产品迭代
7B Conductor 论文 LiveCodeBench 83.9% arXiv 2512.04388
7B Conductor 论文 AIME25 93.3% arXiv 2512.04388 + VentureBeat

原帖分享时将「Conductor」与「Sakana AI 7B」混用，可能让读者误以为 87.5% 是最新分数，需注意这是论文原始结果。

适用边界

  • worker 池限制：论文中 Conductor 在池内每个 worker 上都能超越该 worker 单独使用的表现，但池外模型没有保证。
  • 任务类型：论文聚焦推理/数学/编程类 verifiable 任务，对开放式创意写作类任务效果未经充分验证。
  • 成本考量：虽然单次 API 调用成本低于 MoA 等多 agent 基线，但调用多个 frontier 模型的总成本仍然显著高于单个模型。
  • 黑盒依赖：训练时用哪些 worker，推理时就需要能访问这些 API，企业私有部署有挑战。
  • 可复现性：论文发稿时尚未见独立代码仓库，方法复现依赖后续开源。

一句话区分本方法 vs Mixture-of-Agents

MoA 是固定 topology 的人为设计多 agent 组合；Conductor 是让 RL 自己发现每个问题该用什么 topology，更动态、更端到端。

一句话结论

用 RL 训练一个 7B 小模型学会「当指挥」，动态编排多模型工作流——比任何单一 frontier 模型强，比硬编码多 agent 流水线更灵活，刷新了 GPQA-Diamond（87.5%）和 LiveCodeBench（83.9%）的论文发布时 SOTA 记录，代表了从「人设计 agent 流程」到「AI 自己学编排」的关键范式转变。