🤖 AI

SwarmResearch: Orchestrating Coding Agents for Open-Ended Discovery

SwarmResearch 引入了一种编排器-子代理框架，通过使用一个牧羊人代理（Shepherd Agent）来引导一群上下文隔离的搜索代理（Search Agents），从而缓解了单一长时运行编码代理的收敛局限性，进而通过自适应并行性和更高层级的探索实现了卓越的开放式发现。

原作者： Yuvraj Virk, Zack Edds, Chunqiu Steven Xia, Lingming Zhang

发布于 2026-07-07

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Yuvraj Virk, Zack Edds, Chunqiu Steven Xia, Lingming Zhang

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你正在发明一种全新的、超快速的烘焙蛋糕方法。你拥有一支才华横溢的烘焙师团队（AI 代码智能体），但你希望他们能找到“最好”的配方，而不仅仅是“稍微好一点”的配方。

这篇论文介绍了一种组织这些烘焙师的新方法，称为 SWARMRESEARCH。以下是它的工作原理，我们使用简单的类比来解释：

问题所在：“单向思维”陷阱

在过去，如果你要求单个 AI 烘焙师改进蛋糕配方，过程会是这样的：

它尝试一种新原料。
它品尝它。如果好吃，就保留；如果不好吃，就扔掉。
它就这样一遍又一遍地对同一个配方进行微小的调整，持续数小时。

问题在于： 烘焙师会陷入“局部最优解”中。他们不断完善一个“巧克力蛋糕”，因为这个蛋糕已经很不错了，但他们永远不会意识到切换到“柠檬塔”的方法可能会快上 10 倍。他们过于专注于当前路径上的微小细节，以至于看不见一个完全不同的、更好的路径。他们还倾向于忘记之前的想法，因为他们一直在改写同一个笔记本。

解决方案：集群方法

作者构建了一个名为 SWARMRESEARCH 的系统来解决这个问题。把它想象成一个研究农场，里面有两种类型的工人：

牧羊人（管理者）： 这是主 AI。它不亲自烤蛋糕。相反，它观察整个农场，观察哪些做法有效，并决定在哪里提供帮助。
搜索智能体（烘焙师）： 这些是实际进行烘ды烘焙的工人。

以下是它们组织方式的奥秘：

新鲜开始（“探索者”烘焙师）： 与其让一个烘焙师对着一个笔记本工作，不如由牧羊人派出带着空白笔记本的新烘焙师。这些“探索者”被告知要忽略旧配方，从头开始尝试疯狂的新想法。他们不会被困在“巧克力蛋糕”的思维定式中。
专业精炼师（“优化器”烘焙师）： 如果牧羊人看到一个非常有前景的新想法（比如“柠檬塔”），它会向那个特定的分支派出一类不同的烘焙师。这个“优化器”可以查看该特定想法的详细历史记录，以便将其打磨得尽善尽美。
独立的作业空间（Git 分支）： 这是最关键的部分。每位烘焙师都在自己的独立厨房（一个独立的 “git 分支”）中工作。
- 如果烘焙师 A 尝试了一个糟糕的想法，他们只需扔掉自己的厨房即可。这不会毁掉烘焙师 B 的厨房。
- 如果烘焙师 B 发现了一个绝妙的技术，牧师可以将那个厨房复制给烘焙师 C，而无需让烘焙师 C 删除自己目前的工作。
- 这防止了团队仅仅因为试图修复一个错误，就意外删除了好的想法。

它如何战胜竞争对手

论文将这个系统与其他方法进行了对比测试（例如，一个长时间工作的单个烘焙师，或者一群共享一个大笔记本的烘焙师）。

结果： 在 13 个具有挑战性的难题中（范围涵盖数学问题到计算机系统优化），Swarm 找到了比其他方法更好的解决方案。
原因： 因为 Swarm 不仅仅是在“微调”现有的解决方案。它足够勇敢，敢于尝试完全不同的方法。
- 例子： 在其中一项任务中，旧方法只是微调了烤箱的温度。而 Swarm 尝试建造一种全新的烤箱。

现实世界的案例：加速 AI

作者使用这个系统来尝试让 AI “思考”得更快（具体来说，是一种叫做“投机采样/speculative decoding”的技术）。

旧方法： AI 尝试对代码进行微小的编辑，比如在这里改动一个变量。它获得了一定的速度提升。
Swarm 方法： Swarm 智能体尝试了不同的策略。一个智能体意识到，与其逐一检查每个单词，不如成组地检查单词（就像批处理一样）。另一个智能体意识到，可以使用更少的“专家”来检查简单的单词。
结果： Swarm 找到了一种让 AI 比标准方法快 4.58 倍的方法，而其他方法仅实现了约 2 倍的加速。

核心结论

SWARMRESEARCH 是一种管理 AI 研究人员的新方式。它不再让一个 AI 陷入墨守成规，而是通过一个管理者，同时派遣许多不同的团队去探索不同的路径。它保持了各自作业空间的独立性，确保好的想法不会丢失，并且知道何时从“尝试新事物”切换到“完善最好的事物”。

这就像是一个人试图通过拧紧每一个螺栓来修理汽车，而另一边则是一个机械师团队，他们同时尝试建造一个新引擎、一个新变速器和一个新底盘，然后挑选出最佳的组合。

技术摘要：SWARMRESEARCH

问题陈述

长时运行的编程智能体（例如 autoresearch 框架）能够持续发现开放式问题的优化方案。然而，作者观察到一个关键的失效模式：这些智能体往往会迅速收敛到单一的高层方法上，随后在特定的邻域内进行大量的低级编辑和微调。这种行为导致智能体错失了该问题的更优且截然不同的处理路径。

作者假设这种收敛是由现有系统中两个特定的底层设计选择引起的：

上下文累积（Context Accumulation）： 智能体会积累充满单一方法增量改进的长对话历史，使得进行实质性的策略转变变得极其困难。
单一程序状态（Single Program State）： 智能体会将所有改进都提交给同一个可编辑的程序，从而有效地丢弃了其他替代方向，并将搜索过程转变为一种贪婪的局部搜索。

方法论：SWARMRESEARCH

为了解决这些瓶颈，作者引入了 SWARMRESEARCH，这是一个旨在促进开放式发现的编排者-子智能体（orchestrator-subagent）框架。该系统实现为一组与流行编程智能体工具（如 Claude Code）兼容的技能。

架构

该系统由两个主要角色组成：

牧羊人智能体（Shepherd Agent，编排者）： 一个全局控制器，负责管理一组搜索智能体（Search Agents）。它维护全局上下文（所有尝试的摘要、评分和方法），并进行战略性地引导搜索群体。
搜索智能体（Search Agents，子智能体）： 负责构思、实现、评估和迭代解决方案的独立智能体。它们在与其分配任务相关的局部上下文下运行。

核心设计机制

SWARMRESEARCH 采用了三种特定的机制来保持多样性并防止过早收敛：

基于 Git 的分支管理（程序版本控制）：
- 与编辑单一程序状态的系统不同，SWARMRESEARCH 为每个搜索智能体分配一个新的 Git 分支。
- 主分支仅包含基准版本（baseline）。搜索智能体可以从基准分支（用于从零开始的探索）或从已完成智能体的提交（commit）中分支出来（用于迭代）。
- 这允许多个竞争性的高层方法独立演进。虽然非最优但有前景的方案不会被丢弃，而是保留在各自的分支中，以便未来进行潜在的精炼或组合。
分层上下文管理：
- 局部上下文： 搜索智能体在新鲜或受控的上下文窗口中运行。
  - 探索型智能体（Explorer Agents）： 从新鲜的上下文窗口开始，仅读取其分配的工作树内容。这防止了它们被先前的研究工作所锚定，从而鼓励高层级的探索。
  - 优化型智能体（Optimizer Agents）： 除了工作树之外，还会继承其父级智能体的对话历史。这使得在特定方法展现出潜力时，能够进行深度的序列化精炼。
- 全局上下文： 牧羊人智能体维持所有搜索智能体活动的全局视图（摘要和评分），但不会将所有智能体的完整对话历史暴露给每个子智能体。这防止了在其他多智能体系统中观察到的“共享记忆”导致的收敛现象，即智能体集体放弃独立的探索方向去精炼单一的最佳方案。
由编排者引导的缩放（Orchestrator-Guided Scaling）：
- 牧羊人智能体通过改变并行智能体的数量和串行迭代次数，根据搜索深度动态管理搜索预算。
- 它可以在生成波次式的并发探索型智能体以扩大搜索空间，并在主导方案出现时切换到生成优化型智能体。
- 牧羊人使用提示词来分享极简且相关的上下文（例如“应避免的想法”、“有用的发现”），但不规定具体想法，从而保持想法的多样性。

评估与结果

作者在数学、系统和启发式算法三个领域的 15 个开放式优化任务上对 SWARMRESEARCH 进行了评估。他们将其与最先进的基准进行了对比：

EvoX： 一种由 LLM 引导的进化基准。
CORAL： 一种使用共享内存的最先进多智能体系统。
固定缩放（Fixed Scaling）： 一个执行 $n$ 个并发智能体和 $k$ 次串行迭代的朴素基准。

性能指标

任务成功率： SWARMRESEARCH 在 15 个任务中的 13 个上发现了更好或相当的解决方案。
- 它在 13 个任务上严格优于 EvoX，并在 1 个任务上与之持平。
- 它在 10 个任务上严格优于 CORAL，并在 2 个任务上与之持平。
探索粒度： 与基准相比，SWARMRESEARCH 通常实现了 1.7 倍至 3.2 倍更大的代码变更（以每次尝试中修改的代码行数衡量）。这表明它具有更高频率的高层方法探索，而非仅仅是低级调优。
缩放效率： 在与最优固定缩放（测试各种 $(n, k)$ 配置）的比较中，SW，SWARMRESEARCH 的编排者引导缩放在 5 个任务中的 4 个上优于最佳固定配置。该系统成功地在不同搜索深度下调整了并行度，在初期分配预算用于广泛探索，在后期转向深度串行迭代。

案例研究：投机采样（Speculative Decoding）

作者对优化 LLM 推理中的投机采样进行了详细的案例研究。

目标： 在保持推理密集型任务准确性的同时，最大化 Token 吞吐量。
结果： SWARMRESEARCH 在 60.6% 的准确率下（基准为 65.8%）实现了 4.58 倍于朴素解码的加速。
对比： 在相同的运行时间内（约 12 小时），autoresearch 仅实现了 1.80 倍加速，而 CORAL 实现了 2.26 倍加速。
发现： 该系统发现了系统级的优化（例如，批处理目标前向传递、用于构建分布的持久线程池）以及自适应专家计数（MoE），而这些在基准模型中并未出现。它还探索了松弛的接受条件，尽管一些新颖的尝试（如“共单调采样”）在严格审查后被发现是不正确的。

重要性与主张

论文声称，SWARMRESEARCH 证明了底层架构工程（harness engineering）——特别是上下文管理和程序版本控制——是长时运行编程智能体成功的关键因素。

发散性发现： 通过将智能体从长期的、趋于收敛的对话历史中解耦，并通过 Git 分支保留替代程序状态，该系统避免了单智能体或共享内存多智能体系统中常见的“贪婪局部搜索”陷阱。
自主缩放： 编排者-子智能体架构允许进行自适应的测试时缩放（test-time scaling），无需手动调整超参数即可动态调整并行探索（exploration）与串行精炼（exploitation）之间的平衡。
局限性： 作者谦虚地指出，该框架本身并不能增强底层 LLM 的创造力；所探索的方法仍然倾向于已知方法的变体。此外，牧羊人智能体的战略引导行为目前仍依赖于提示词，且测试的模型有时在没有明确指导的情况下难以合成复杂的战略计划。

这项工作将 SWARMRESEARCH 定位为未来用于开放式发现的底层架构和训练的最小且可互操作的基础，强调了结构性设计选择可以显著放大现有编程智能体的发现能力。