没有指挥的一千个agent

一千个编码 agent 同时开工，没有一个指挥，微软研究院这篇论文把这事做成了。它测的是自组织的多 agent 架构 Agensh，跟眼下大多数带层级的系统不同，这里没有中心编排器，全靠共享状态彼此协调。 每个 agent 的动作链很朴素：收集上下文，认领一个子任务，把活干完，共享发现，验证结果，再合并进工作区。共享工作区加一条消息通道，整套流程全异步跑。 数字最能说明问题。ProgramBench 最难的五道题上，用 GPT-5.6-sol，agent 从 1 个加到 128 个，平均最终测试通过率从 19.31% 涨到 28.78%，而且团队越大，达到同一通过率用的时间越短。换到 pandoc 这个题上更猛，1,024 个 agent 把通过率从 33.89% 拉到 55.06%。 更值得记的是论文提到的一种现象：agent 之间会自发长出合作套路，团队一变大，这些套路就固化成了标准做法。没人写规则教它们。是规模把协作逼出来了。组织行为学的老结论在 agent 身上重演了一遍。 把这组数字放到架构选择里看，取舍很清楚。中心编排器省心，可它自己会成为瓶颈，任务一多就得排队。共享状态这条路反着来，前期要设计好工作区和消息通道，后期横向加 agent 几乎不加成本。19.31% 到 28.78% 的爬升不陡，但它是加机器换来的，不是调参调来的。 我自己搭 agent 集群时，最费劲的就是协调那层，要写调度、要防冲突。这篇给的思路是把协调成本转嫁给共享状态，让每个 agent 自己找活干。对长任务来说，异步加共享工作区可能比精巧的调度器更抗造。 论文在 arxiv.org/abs/2609.26781 ，配套的逐段解读在 academy.dair.ai/papers/agensh-… 。两处我都存了，先看论文里那张通过率曲线，再看解读里对异步合并的拆法。