Scaling Agent Swarm

Junxiao Yang

这个方向的源头可以说从OpenAI解决NS方程讲起，具体解法没有披露，但是我们可以看blog中对于解决方案的简要说明：

Agents were subdivided into groups with the ability to communicate within the group. The groups varied in size, and the group that produced the Navier–Stokes resolution involved on the order of 10,000 concurrent agents. … For each problem, we prompted different groups of agents with different variants of the problem statement, covering all variants of the problem. For the Navier–Stokes problem, we suggested versions “A” and “B” (particular forms of the Navier–Stokes problem which would result in a proof) and versions “C” and “D” (which would result in a disproof) to separate groups of agents. … We encouraged different groups of agents to explore a diversity of approaches. After some time, we cross-pollinated the agent groups by using Codex to consolidate the most useful insights from each agent group. These follow-up prompts drew on the agents’ own intermediate results. The group that found the solution to Navier–Stokes was guided in such a way.

这个描述虽然很上层，但是我们可以看到两个信号：1. 多样性指导的抽卡：一个大的open question可以分成几个研究问题，甚至形成adversarial的proposal提供更多元的claim；2. 去中心但是有组织：scale agent一定要去中心，抛弃过去main agent spawn subagent的严格主从形式，解放信息和调度瓶颈。但是同时又要有合适的组织和广播机制，我觉得cross-pollinate这个说法很有意思（异花授粉），让不通group有组织地相互共享并吸收有用的思路。总而言之，我们可以归结一个discovery loop的示意图如下：分组、归结、广播、循环。

紧接着最近有两篇很有意思的agent swarm的工作，很巧都来自Microsoft Research：

• Scaling Discovery through Test-Time Communication (https://arxiv.org/pdf/2609.21032)
• Agensh: Scaling Organizational Intelligence to 1,024 Agents (https://arxiv.org/pdf/2609.26781)

我们可以先从第一篇说起，这篇工作对比了一个Best@n和Team@n，从ARC-ACI-3， Polyomino Packing和MNIST Compression三个场景证明了agent交流可以带来更多增益。这里论文的图是非常符合直觉的，对于之前的任务比如低复杂度数学题（Math, AIME）等等，best@k本身就挺好了，因为这个过程不够长，无交流的抽卡就能达到上限。但是对于长程的复杂任务，我们不确定哪个方向更好，甚至方向之间存在重叠和因果，那适当的交流（cross-pollinate）直觉上一定是有利的。

具体做法上有一些很初步的设计，暂时还没开源代码，我的理解如下：

1. 模型抢占slot开始研究，这个后抢到slot的agen是可以看到之前agent选择的研究方向的，进而会选择其他研究方向；
2. 模型会把自己方向的研究写到一个共享findings文档里面，能广播自己的发现，也可以看到别人的发现。这一切都是agent主动完成的，没有hard harness design。
3. 模型连着几次都做不出来更好的结果，会切换方向，如果其他的方向足够好，也会认可结果并且站在已有的基础上继续发展。 我们画一个示意图就是下面的流程，我觉得是一个非常理想的小规模agent swarm的合作方式了。

我们接着看第二篇论文，这个就是scale到一个非常高的agent数目了，思想上是一致的，去中心化的组织：

这篇工作的几个图和说明，也是比较符合直觉，看起来比较舒服，初步结果和demo也很有意思。但是有几个问题要等待开源后再学习，一个是agent scaling的收益来自于哪里，program bench其实不是一个特别适合scale agent swarm的场景，我觉得算不上开放度较高的探索场景，还是比较重开发（这里和作者讨论了一下是否应该对比pass@n，我还是觉得是一个open question，并且倾向于要证明agent交流的意义）；另一个是1024 agents的去中心化，我总觉得简单的基建不能支持。这里第二篇和第一篇的做法其实是基本类似的，我觉得这个信息负载处理能力理论不会超过32个agent，再往上很难想象这个设计可以支持信息交流。不过这个还得去做实验和看源码进一步探索和学习。

总而言之，我觉得scale agent swarm是一个很有趣的话题，也是一个新的scaling维度。可以总结现在两个关键入手点就是：1. 多样性支持、去中心化的多方向探索分工；2. 基于共享文件机制的自由、主动信息同步逻辑。另一个我个人觉得的关键设定，就是题目的约束尽可能少，探索空间尽可能大，否则研究sclae agent swarm没有多大的意义。当然这里面有着非常多open question，期待更多论文和报告！