如何训练一个群体（阅读约19分钟）

# 如何训练一个 Swarm 来源: https://www.gr.inc/blog/how-to-train-a-swarm Agent swarms 在近几个月来大放异彩。9 月，OpenAI 使用一个 swarm 在 88 小时内给出 Navier–Stokes 千禧年大奖问题的解法。¹(https://www.gr.inc/blog/how-to-train-a-swarm#note-1),²(https://www.gr.inc/blog/how-to-train-a-swarm#note-2) Swarm 也曾引发引人注目的安全事件，例如 Hugging Face 事件，其中多个 agent 通过一个未经授权的消息板协调发起网络攻击。³(https://www.gr.inc/blog/how-to-train-a-swarm#note-3),⁴(https://www.gr.inc/blog/how-to-train-a-swarm#note-4) 尽管已声名鹊起，但关于如何用强化学习训练 swarm 的公开工作仍然很少。 Swarm 是一种"agent collective"（agent 集体），即多个 agent 协同工作以实现共同目标的 AI 系统。最近，我们发布了一个训练 agent collective 的公开配方，称为集体奖励强化学习（RLCR (https://www.gr.inc/releases/avalon-m1)）。⁵(https://www.gr.inc/blog/how-to-train-a-swarm#note-5) 它使用一种简单的策略梯度算法，包含一个共享策略和施加于所有 agent 的扁平集体优势，并通过时间限制引入延迟压力以激励协调。 我们研究项目的核心目标是实现**集体推理时扩展（collective inference-time scaling）**，即 agent 能够并行扩展有用工作量以及实现这一目标所需的通信量。一个设计良好的强化学习设置应当奖励更快完成工作，这反过来应激励使用并行推理计算。而且，如果底层工作只能被不完全地并行化，那么 agent 应该通过相互通信来协调工作，从中获益。 集体推理时扩展可以被视为带有延迟约束或惩罚的推理范式的延伸。但与 reasoning models (https://openai.com/index/learning-to-reason-with-llms/) 不同，强化集体行为的路径是间接的。任务奖励中没有任何内容明确激励并行工作，因此设置必须通过让更快的工作获得回报来激励并行工作。 我们将在本文中解释如何为并行工作设计激励机制，包括我们在 RLCR 配方中使用的方法。但首先，我们将以现有的推理范式为例，介绍强化学习激励机制设计的一般话题。 ## 为 RL 设计激励机制 推理范式表明，强化学习（RL）可以激励策略在回答之前使用更多的推理计算。模型学会检查自己的工作、回溯和考虑替代方案是提高预期回报的有效策略。⁶(https://www.gr.inc/blog/how-to-train-a-swarm#note-6),⁷(https://www.gr.inc/blog/how-to-train-a-swarm#note-7) 这种方法特别优雅之处在于，激励策略"思考更久"所需的手工设计量很小——*前提*是你有正确的 RL 设置。在 RL 期间，策略可以探索不同的回答问题的方式，而使用检查工作和考虑替代方案等策略的 rollout 平均表现会更好。 这导致了一张著名的图表，展示了训练时计算与测试时计算之间的对应关系，随 OpenAI 的 o1 模型发布： **o1 随训练时和测试时计算量的增加而提升** **训练时** 0%20%40%60%80%100%1×10×100×训练时计算（对数刻度）AIME pass@1 准确率 **测试时** 0%20%40%60%80%100%1×10×100×测试时计算（对数刻度）AIME pass@1 准确率 后来 DeepSeek-R1 的图表也印证了这一点，展示了响应长度随训练过程中的准确率增长而增长：⁷(https://www.gr.inc/blog/how-to-train-a-swarm#note-7) **DeepSeek-R1-Zero 随准确率提升而推理更久** Pass@116 个多数投票（cons@16） **训练期间的 AIME 准确率** 20%40%60%80%02k4k6k8k10k训练步数 **平均响应长度** 05k10k15k20k02k4k6k8k10k训练步数 这就是推理模型的**推理时扩展（inference-time scaling）**模式，模型学会在回答之前思考更多。 较少被认识到的是，朴素的强化学习设置并不能保证获得这种扩展模式。因此，在 RL 设置中如何设计激励机制以学习正确的行为非常重要。 例如，超参数的选择错误可能会过度惩罚推理长度，阻止推理时扩展。如果几年前你使用标准 PPO 配方并设置了 γ<1 和/或 λ<1，你很可能看不到这种扩展模式。这在 DeepSeek-R1 之后不久就被 Open-Reasoner-Zero⁸(https://www.gr.inc/blog/how-to-train-a-swarm#note-8) 等工作所证实： **有偏的优势可能导致推理崩溃** 在 Open-Reasoner-Zero 的消融实验中，使用 GAE λ = 1 的 PPO 持续增加响应长度，而使用 λ = 0.95 时，响应长度在约 50 步内就崩溃了。 GAE λ = 1GAE λ = 0.95 **平均响应长度** 03006009001.2k050100150200训练步数 **训练奖励** 0.00.20.40.60.8050100150200训练步数 另一个决定成败的因素是底层先验的强度，具体来说是要有一个足够强的基模型来启动学习。较弱的基模型接触高质量数学数据较少，探索和强化有用的推理时策略的能力也较差。OpenAI 首先弄清了核心配方并在这一研究方向上保持信念，这值得相当大的赞誉，而且他们拥有 GPT-4 级别的基模型，比其他任何人都处于更有利的位置。 因此，强化学习设置对于激励正确的行为至关重要。 这就把我们带到了当下，模型现在被用于执行长时程（long-horizon）工作。推理模型在解决语言模型的许多可靠性问题方面非常成功，但它们的顺序性质意味着高延迟。这使得它们在长时程任务中存在问题。 并行推理方法的承诺在于它们可以分工合作，更快地完成长时程任务。agent 集体中的单个 agent 仍可能使用顺序推理，但作为一个整体，集体可以并行化工作，避免顺序瓶颈。 那么，我们如何激励策略并行化工作呢？ ## 让并行工作获得回报 下图展示了三种花费推理计算的方式：顺序方式、无通信的朴素并行方式，以及 agent 可以通信的 agent 集体方式： **三种花费大致相同推理计算量的方式** **扩展推理** **100**分钟流逝 Agent回答 **独立尝试，然后选择** **28**分钟流逝 尝试 1尝试 2尝试 3尝试 4选择回答 **一个可通信的组织** **46**分钟流逝 CEO调查员构建者测试者回答0255075100 分钟流逝 假设所有方法都能得出可接受的答案，我们倾向于以最小延迟获得结果的方法。当独立尝试已经足够时，通信可能只是增加了不必要的开销。当任务不能完全并行化时——即 agent 需要共享中间结果或组合互补的工作——协调就变得有价值。 共享奖励可以强化改善答案的协调。但当回报相同时，一个不依赖于时间的目标函数对更快的方法没有偏好。因此，我们需要让更快的工作获得回报。 ### 延迟惩罚 一种激励是显式的延迟惩罚。这种方法是训练 DeepSeek-V4.1-Flash agent 团队所用的技术之一，尽管其函数形式未被公开。⁹(https://www.gr.inc/blog/how-to-train-a-swarm#note-9) 一种可能的函数形式类似于推理长度惩罚：¹⁰(https://www.gr.inc/blog/how-to-train-a-swarm#note-10) R\(τ\) = R\_text{task}\(τ\) - β \bar{p}\(q\) \frac{T\(τ\)}{T\_max} 其中 T\(τ\) 是 rollout τ 的墙钟时间，T_max 是时间限制，\bar{p}\(q\) 是任务 q 在其所有 rollout 中的平均通过率，β 设置惩罚强度。 这是一种合理的纳入延迟的方式，但它有一些缺点： - 它可能与其他量（如推理力度）产生负面交互。 - 我们并不清楚是否应该在所有 rollout 长度上都施加延迟压力。 - \frac{T\(τ\)}{T_max} 在不同任务间可能差异很大，且高度依赖于 T_max。 ### 时间限制 另一种方法是使用时间限制 T_max 作为唯一的延迟压力来源，这就是我们在Avalon-M1 (https://www.gr.inc/releases/avalon-m1)中采用的方法。时间限制 T_max 是一个最大墙钟超参数。当 rollout 达到上限时，我们将其截至该时刻的总回报作为该 rollout 的回报。这激励策略在达到时间限制之前尽可能多地推进工作。 时间限制允许我们在预期集体有用的时间范围内施加延迟压力，在那里协调应该能带来收益。 下图展示了在Avalon-M1 (https://www.gr.inc/releases/avalon-m1)中如何通过随训练逐渐增加的最大墙钟调度来施加延迟压力。我们随时间增加时间限制，使策略在训练过程中学会在更长的时间跨度上进行协调。这给集体更多时间来回收协调的初始成本。单 agent 方法最初通常比集体取得更多进展，因为它们的协调开销更少。 **作为延迟压力的最大墙钟调度** **最大墙钟上限** 0h2h4h6h050100150200训练步数起始时 2 小时到第 200 步时超过 5 小时 **一组 rollout 示例** 0%50%100%02 h4 h6 h通过的测试流逝时间组平均值58%上限4.3h 训练步数 环境设计对这种设置至关重要。对于Avalon-M1 (https://www.gr.inc/releases/avalon-m1)，我们构建了具有"任意时刻回报（anytime-return）"特性的长时程环境，意味着我们可以在任何时间停止 rollout 并获得中间进度的度量。例如，测量长时程软件工程任务中通过的测试数量，或金融交易环境中的收益。我们可以在时间限制时停止一组 rollout，并奖励回报相对较高的 rollout。 这避免了在任务奖励中添加显式延迟惩罚的需要，尽管截止时间和其调度仍然是重要的设计选择。与显式延迟惩罚不同，截止时间并不奖励每一次完成时间的缩短。两个在截止时间前获得相同任务回报的 rollout 将获得相同的分数，即使其中一个更早完成。 延迟惩罚和时间限制是施加延迟压力的两种方式。但仅靠延迟压力不足以训练集体。agent 还需要通信原语来划分工作、避免重复和交接工作。接下来我们将介绍这些原语。 ## 通信原语 **Kimi K2.5 Agent Swarm** orchestratorsub-agents 训练只训练了 orchestrator；sub-agent 是冻结的 通信orchestrator 到 sub-agent，以及结果回传 规模在 K2.6 中扩展到 300 个 sub-agent **GR Avalon-M1** CEO消息板 训练所有 agent，基于一个集体奖励 通信任何人，通过频道、直接消息和存档 规模一个 CEO 和最多 8 个专家 **OpenAI（如所述）** board~10,000 agents组获得问题的不同版本 训练未描述（实际部署的 agent 数远少于此） 通信组内，不跨组；board 是我们的推测 规模~10,000 agents 在获得 Navier–Stokes 解法的那个组中 集体最重要的设计选择之一是它如何通信和协调。agent 之间的直接消息是一个核心原语，公共频道（或"消息板"）允许 agent 广播对单个对话之外也有用的信息。可选但流行的界面包括 issue board 和知识存档，它们有助于划分工作并建立在共享的集体知识之上。 研究者的一个首要目标应该是保持这些原语简单。我们希望 agent 自行发现如何协作，而不受 harness 的过度偏见。预先施加结构可能在初期有助于表现，但也可能阻碍策略发现 agent 协作的更好方式。 在实践中，当前的 agent 集体确实施加了一定程度的结构。Kimi 的 Agent Swarm 使用一个训练过的 orchestrator 将任务分配给冻结的 sub-agent。¹¹(https://www.gr.inc/blog/how-to-train-a-swarm#note-11) Avalon-M1 (https://www.gr.inc/releases/avalon-m1) 使用一个可以雇佣和解雇的 CEO agent，尽管每个 agent 都可以与其他任何人对话。⁵(https://www.gr.inc/blog/how-to-train-a-swarm#note-5) OpenAI 的 Navier–Stokes 系统采用了一种岛屿方法，将其 agent 分成不同的组，并为每个组提供问题的不同版本。¹(https://www.gr.inc/blog/how-to-train-a-swarm#note-1) 这些都是关于如何划分工作的先验，未来的系统应该能自己找出正确的结构。 一旦你有了一个施加延迟压力的强化学习设置，并为 agent 提供了通信和协作的原语，下一步就是在训练过程中度量学习进展。 ## 生命迹象 仅靠奖励曲线无法告诉我们集体是否学会了有效使用并行推理计算。因此，我们度量集体在环境中执行的工作、集体如何通信，以及集体是否改善了性能–延迟的权衡。 **更大的集体应该做更多有用的工作。** 如果 agent 学会了划分工作——并避免了通信开销——那么更大的团队应该在环境中执行更多"有用"的工作。我们将有用工作的代理度量定义为每个作用于环境的回合（如运行命令、编辑文件、运行测试）的输出和推理 token，并将每个 rollout 与该环境的平均有用工作进行比较。在Avalon-M1 (https://www.gr.inc/releases/avalon-m1)中，一个有 5-8 个雇员的集体在有用工作方面起初低于平均 rollout，但在第 200 步时达到了平均值的近两倍。 **随着训练进行，更大的集体在环境中做更多工作** 0.5×1.0×1.5×2.0×50100150相对于环境平均 rollout 的有用工作训练步数SoloBudget 2Budget 3Budget 4Budget 5-8 **如果能从协调中获益，agent 应该增加通信。** 在Avalon-M1 (https://www.gr.inc/releases/avalon-m1)中，agent 随着训练进行在通信上投入更多计算。这与更多的协调使用一致，但仅凭通信量并不能证明其有用性。我们按 rollout 持续时间进行归一化，以考虑更长运行中更大的通信量。可以看到，在不同环境上的归一化表现、总推理时计算量和通信强度是同步上升的。 **集体推理时扩展** 通信可以帮助 agent 划分工作、避免相互冲突，并检查或组合他们的贡献。它也会消耗本可用于工作的时间，因此其收益必须大于成本。 **集体应该更快达到可比的分数。** 一个获得与集体相同输出 token 数量的单个 agent 能恢复大部分性能提升，但需要更长时间才能做到。在Avalon-M1