十个一伙的，胜过一个百人大队

——为什么"打群架"是 AI 并行推理的最优阵型

开场：彩票的两种买法

你手里有一百块钱，想买彩票。有两种买法：

第一种，把一百块拆成一百张单式票。每张票各选各的号，彼此不认识，谁也不理谁。最后你可能中一两张小奖，但大奖跟你没关系——因为每张票的中奖概率实在太低了。

第二种，把一百个人拉进一个群，凑钱买一张复式票。这一张票确实比单式票强多了，中奖概率高了。但你只有这一张。万一号码差一点，全军覆没，连再来一次的机会都没有。

你想过没有？这两种买法都不是最优解。

最优解是什么？分成十组，每组十个人，每组凑一张复式票。 这样你既有十张票（比一张票多了九次机会），每张票又比单式票强得多（因为十个人的智慧凑在了一块）。你同时获得了"多抽几次"的运气和"每次更强"的实力。

这个彩票比喻，就是 Duke University、Modal Labs、Princeton 和 NYU 的研究者们在一篇题为《Test-Time Compute Scales Better with Parallel Agent Teams》的论文中提出的核心洞察。他们发现：当 AI agent 组队解决复杂任务时，多个小团队并行工作、取最好成绩，比"大量独立 agent 各自为战"和"所有 agent 挤在一个大团队里"都要好。

这篇论文登上了 papers.cool 的 cs.AI 板块，来自 Zhuang Liu 团队——就是做 LLaMA pruning 的那位 Zhuang Liu。他们的结论简单而有力：在同等 agent 预算下，10 个 10 人小团队在 12 个任务中的 10 个上击败了 100 个独立 agent；在全部 4 个被测任务上击败了 1 个 100 人大团队。

让我们一步步拆开这个发现。

🎰 推理时算力：AI 的"加钱时刻"

要理解这篇论文，先得搞清楚一个问题：当你给 AI 更多算力时，钱花在哪？

传统做法是训练时加钱——更大的模型、更多的参数。但近些年，另一条路越来越受关注：推理时加钱。意思是不改模型，而是在推理（inference）阶段花更多计算资源，让模型"想得更久"。DeepSeek-R1 证明了这条路走得通；OpenAI o3 系列把这条路推到了极限。

但推理时加钱也有不同的花法。当任务是开放式、没有标准答案的那种——比如"帮我优化这个 GPU kernel"或"证明这个数学定理"——主流方案叫 Best-of-N 采样：跑 N 个独立的 agent，每个各自为战，最后取成绩最好的那个。

这就像开头的第一种彩票买法。问题是，Best-of-N 的回报递减得非常快。论文发现，50 个 agent 就能拿到 100 个 agent 收益的 81% 到 100%。换句话说，从第 50 个 agent 往后，每个新 agent 几乎都在白跑。为什么？因为独立 agent 之间没有任何信息交流，第 51 个 agent 和第 1 个 agent 的起点完全一样，没有任何积累。

另一种思路是让所有 agent 协作。你有一个大团队，agent 之间共享发现、互相启发、踩在彼此的肩膀上前进。这确实能把团队的平均分拉高——但问题是，你只有一次机会。一个大团队跑出一份答案，无论好坏，就是它了。你不能从这个团队里拆出方差来——因为没有第二个团队可以比较。

这就像开头的第二种彩票买法：一张很强的复式票，但你只有这一张。

论文的贡献，就是把这两条路的缺陷用一个统计框架讲清楚了，然后指出了一条更优的中间路线。

📐 数学不会说谎：为什么"中间路线"是对的

作者们用了一个简洁的统计模型来说明问题。

假设你跑了 N 个 agent（或 N 个团队），每个的成绩是一个随机变量。你最终取最好的那个成绩。这个"最大值"的期望值可以写成：

其中：

• μ（均值） 是单个 agent（或团队）的平均成绩
• σ（标准差） 是成绩的波动幅度
• a_N 是"从 N 个样本中取最大值"带来的增益，近似等于 √(2 ln N)

关键在这个 a_N：它随 N 增长得非常慢——是对数级别的。N 从 10 增长到 100（10 倍），a_N 只从约 1.95 增长到约 2.80。这就是 Best-of-N 很快饱和的数学原因：抽得越多，每次新增"最好成绩"的边际贡献越小。

而 σ 的效果完全不同——它是线性放大的。如果你能把 σ 从 1 增加到 1.5，那最大值直接多了 0.5·a_N。

现在看三种策略在这个公式里的表现：

独立 Best-of-N（k=1，N=B）： N 很大，a_N 也很大，但 μ 很低——因为每个 agent 都在独立探索，没有协作带来的平均分提升。就好比一百张单式彩票，每张中奖概率极低。

单一大团队（k=B，N=1）： μ 可能很高——协作确实提升了平均分。但 N=1 意味着 a_N = 0，你从方差中得不到任何增益。一张复式票，但你只有一张。

并行小团队（k=B/s，N=s）： 比如把 100 个 agent 分成 10 个 10 人团队。每个团队的 μ 比独立 agent 高（因为团队内协作），同时你还有 N=10 个团队可以取最大值。均值和方差两头都吃。

论文进一步算了一笔账：如果团队规模增大导致成本增加了 c 倍（大团队需要更多算力），你需要 μ 增加多少才能抵消？答案是只需 σ · ln(c) / √(2 ln B)。在 200 个 agent 的预算下，即使成本增加 10 倍，均值增益只需 0.88σ 就能打平。而 10 人团队相对于独立 agent 的均值增益远超这个数——实测在 27% 以上。

数学不会说谎。中间路线确实两头占便宜。

这个公式还有一个有趣的推论。如果协作能把 σ 从 1 提升到 1.3（标准差增加 30%），那你只需要 8 个团队就能在 E[max] 上追平 100 个独立 agent。换句话说，协作带来的"稳定性提升"（σ 缩小），其价值远超多抽几个样本。 这和直觉相反——我们通常认为"多试几次"比"每次都更稳"更重要，但在这个公式里，两者是平等的。

🔬 实验：12 个硬任务，100 个 AI 编程马拉松

理论归理论。作者们在 12 个真实任务上检验了这个想法，这些任务来自 6 个不同的基准，每个都足够难、足够开放：

• KernelBench（GPU kernel 优化）：让 AI 写高性能 GPU 代码。你需要让 AI 写出一个矩阵乘法 kernel，性能要尽可能接近 cuBLAS——这要求对 GPU 架构、内存层次、并行策略有深刻理解。
• MiniF2F（形式化数学证明）：让 AI 用 Lean 语言证明数学定理。这不是"算个答案"——你需要构造严格的形式化证明，每一步都要经得起机器验证。
• NYU CTF Bench（网络安全夺旗）：让 AI 发现并利用二进制漏洞。这需要逆向工程、理解内存布局、构造输入——完全是黑客技能的考验。
• SWE-Bench Pro（软件工程）：真实世界的 bug 修复。给 AI 一个大型代码库和一个 bug 报告，让它找到问题并修复——测试的是对复杂代码的理解和修改能力。
• Taubench（旅行预订）：多轮 API 交互任务。模拟用户和旅行预订系统的对话，测试 agent 在长时间交互中的一致性和正确性。
• PINTO（地球物理反演）：用物理约束从地震数据推断地下结构。这是一个科学计算任务，要求 AI 理解物理模型并能进行数值计算。

这些不是"答个选择题"那种浅任务，而是需要 agent 持续探索、试错、迭代数小时甚至十几小时的深度任务。主实验使用 Qwen3.8-27B 作为 agent 模型，每个 agent 运行 12 小时。Agent 之间通过一个异步论坛交流——发帖、回帖、共享中间结果。每个任务跑 10 到 11 个团队，取最好成绩。

任务设计也很有意思：扁平团队，没有角色分工，没有经理，没有任务分配器。 Agent 们自组织。为什么不设经理？实验后面会告诉你答案——结果可能会让你大跌眼镜。

📊 结果一：10×10 完胜 100×1 和 1×100

这是最核心的对比。给定 100 个 agent 的固定预算：

对 100 人大团队的优势尤其显著——10 个 10 人团队在全部 4 个被测任务上都赢了，优势幅度在 8% 到 30% 之间。这直接验证了统计模型的预测：大团队的 μ 优势无法弥补 N=1 的方差损失。

那如果预算缩小呢？10 个 agent 的预算下，团队 vs. 独立 agent 的对比也很有意思：10 人团队胜过了 10 个独立 agent，平均分数高约 10%。也就是说，即使只有 10 个 agent，让它们协作也比让它们单打独斗强。 但随着预算增大到 100 个 agent，团队的优势扩大到 27%——团队协作的收益随规模增大而放大。

更细致地看收益递减的模式。对独立 agent，从 10 个增加到 20 个 agent，每个新增 agent 贡献的分数增量是 0.64%。对 10 人团队，同样的增加让每个新增 agent 贡献 1.27%——恰好是独立 agent 的两倍。团队不仅起点更高，而且饱和得更慢。

这意味着什么？如果你只有固定预算，把预算花在"更少的、更强的团队"上，比花在"更多的、更弱的独立 agent"上更高效。特别是当任务足够难、需要深度探索时，协作的复利效应会随规模放大。

💰 结果二：小模型的团队，打败了大模型的单干

这可能是对实践最有冲击力的发现。

作者们做了一个对比：同等美元成本下，27B 小模型组团队 vs. 前沿大模型 GPT-5.6-sol 单干（各自独立采样）。在 8 个可对比的任务中，小模型的团队在 一半（4 个）任务上击败了大模型。

让我再强调一遍：一个 27B 的模型，组上 10 个一队的小团队，在 GPU kernel 优化、形式化证明这类硬核任务上，打败了比它大得多的前沿模型——花的钱一样多。

这个结果的含义深远。它意味着在推理时计算的场景下，"模型大小"不是唯一的决定因素。一个中等模型加上好的协作结构，可以在特定任务上挑战比它大一个数量级的模型。对于那些预算有限、无法负担最大模型 API 费用的团队来说，这是一个极具操作性的洞见：你不需要追上最大的模型，你只需要把中等模型的协作结构优化好。

当然，需要诚实地说：大模型在另外 4 个任务上还是赢了。小模型团队不是万能的。但这个结果至少说明，协作结构是可以跟模型规模"换算"的资源——你在结构上花心思，能部分弥补规模上的差距。这对于 AI 民主化——让小团队也能在特定任务上跟大公司竞争——是一个好消息。

🧑‍🤝‍🧑 团队内部发生了什么：自发涌现的协作行为

论文中最有趣的部分之一，是对团队内部交流模式的观察。作者们没有设计复杂的协作协议，只是给了一个简单的异步论坛，让 agent 自由发帖。结果呢？自发的、结构化的协作行为涌现了。

几个让人印象深刻的发现：

标签系统。 Agent 们自发开始使用标签来标记帖子：[win] 标记成功的实验，[fail] 标记失败的尝试。在 88% 的情况下，当一个 agent 开始用标签发帖后，它的队友也会跟着用。没有人教它们这么做——这是从"共享信息能提高团队效率"这个简单逻辑中自然涌现的惯例。想想人类开源社区怎么运作的：PR 标题前缀 feat: / fix: / docs:，和这些 AI agent 的行为如出一辙。

快速传播。 在一个案例中，8 个 agent 中有 6 个在 10 分钟内就提交了一个同伴刚发现的新最优解。没有中央协调器告诉它们"快去用那个解"。它们只是看到了，觉得有用，就用上了。这和人类开源社区的工作方式惊人地相似——一个好的 commit 被迅速 review、merge、然后其他人基于它继续工作。

社交礼貌。 Agent 们对具名同伴的赞同是反对的 3 倍以上。当帖子提到具体队友的名字时，正面回应远超负面。也许这只是训练数据里的人类社交模式在起作用，但它确实营造了一种鼓励分享的社区氛围。一个互相支持的环境，比一个互相攻击的环境更有利于知识传播——这在 AI 社区里也一样成立。

共享工件。 在 KernelBench 的 GPU kernel 优化任务中，一个 agent 发现了一个有效的共享内存优化策略，发帖描述后，其他 agent 很快在自己的 kernel 中采用了类似方案。最终整个团队的最好成绩都比独立工作时高——因为最好的想法被整个团队复用了。

这些观察指向一个更深层的结论：协作行为不需要被显式编程。 只要你给 agent 一个交流渠道和一个共同目标，有用的协作模式就会自发涌现。这对多 agent 系统的设计有直接启示——不要过度设计协议，给一个足够简单的交流基础设施，让行为自然长出来。这比 handcrafted 的协作规则更鲁棒、更适应不同的任务类型。

🚫 结果三：经理是有害的

这是一个违反直觉的发现，也是论文中最具挑战性的结论。

作者们对比了扁平团队（所有 agent 平等交流，无角色）和编排团队（有显式的经理 agent 负责任务分配和协调）。结果是：

有经理的团队在所有预算下，成绩都低于扁平团队和独立 agent。

所有预算。没有例外。

为什么？论文没有给出一个完整的理论解释，但提供了一些线索。可能的解释包括：

经理成为单点瓶颈。 一个有 20 个 agent 的团队，经理需要理解和调度 20 条并行的工作流——这本身就是一个极难的任务。经理可能无法及时跟进所有 agent 的进展，导致信息滞后和错误决策。

任务分配引入了锁定效应。 一旦 agent 被分配了特定任务，它们可能会"困在"这个任务里，即使后来发现有更好的方向也不愿意或不能够转向。而在扁平团队中，任何 agent 看到更好的机会都可以自主转移注意力。

协调开销浪费了探索预算。 经理和 agent 之间的协调通信消耗了宝贵的上下文窗口和处理时间——这些资源本可以用来做实际的探索和实验。

这个发现和近年来软件工程中" flat hierarchy "的趋势暗合。很多最有效的工程团队并不是靠一个超级 PM 自上而下地指挥，而是靠一群能力相当的工程师自组织、互相 code review、共享上下文。论文用实验数据支持了这个直觉：在开放式探索任务中，中央协调的代价超过了它带来的秩序。

当然，这不意味着经理在所有场景下都是有害的。对于目标明确、步骤清晰的任务（比如"按这个流程处理 1000 条数据"），中央协调可能仍然有效。但对于需要大量探索、试错和创意的开放式任务，扁平结构更有优势。

🧩 一个补充发现：工具使用差异

论文还报告了一个有趣的负结果：为 agent 配备更多工具（如浏览器、代码执行器、文件系统）并没有一致地提升团队表现。在某些任务上，更多工具甚至降低了成绩。

这可能是因为工具增加了决策复杂度——agent 需要花更多精力决定用哪个工具、什么时候用、怎么用，而不是专注于问题本身。这和人类的行为很像：给你一个只有锤子和一个只有螺丝刀的工具箱，你可能比面对一个塞满 50 种工具的工具箱更高效——因为选择本身就是一种认知负担。

这提醒我们：在 agent 系统设计中，"加更多功能"不等于"更好"。和团队规模一样，工具也存在一个"恰到好处"的甜蜜点。过多的选项会稀释注意力、增加协调成本，最终降低而不是提高整体表现。

🔮 向前一步：这个发现的边界在哪

论文的所有实验都在特定的设置下进行——异步论坛、12 小时运行时间、Qwen3.8-27B 模型。这些条件下，10 人左右的团队是最优的。但如果你换一个场景呢？

更短的运行时间：如果每个 agent 只能运行 1 小时而不是 12 小时，团队可能没有足够的时间形成有效的协作模式——10 分钟内的信息传播和 10 小时内的信息传播是不同的。在极短时间尺度上，独立 agent 可能反而更高效，因为协作的"启动成本"（建立交流模式、理解彼此进展）来不及被摊薄。

更简单的任务：对于那些不需要深度探索的简单任务（比如"把这段文字翻译成英文"），协作的收益可能为零——因为单个 agent 已经能做到最好，团队交流只会增加噪音。

不同的交流拓扑：论文只测试了异步论坛。其他拓扑——比如实时聊天、层级汇报、或中心化黑板——可能会改变最优团队规模。例如，在中心化黑板架构中，50 人的团队可能表现良好，因为所有 agent 都能实时看到全局进展，不需要在论坛中翻找信息。

这些未解的问题指出了未来研究的方向：找到"最优团队规模"的通用公式——一个能根据任务复杂度、时间预算、交流拓扑和模型能力动态调整团队规模的原则。论文朝这个方向迈出了一步，但完整的图景还在前方。

🗺️ 局限与边界

作者们坦诚地列出了几个局限：

1. 统计模型的适用范围。 E[max] = μ + σ·a_N 的公式假设成绩近似正态分布。对于那些分数严重偏离正态的任务（比如只有 0/1 两种结果——要么证明成功要么失败），模型的预测只能定性成立，不能定量使用。

2. 样本量。 每个任务只有 10-11 个团队运行，统计功效有限。在某些任务上，10 个团队和 100 个独立 agent 的差异可能没有达到统计显著性。

3. 论坛索引限制。 在 64 人和 100 人团队的实验中，agent 的论坛索引只能看到最新帖子和未读帖子，这可能限制了大规模团队的信息流通。换句话说，大团队的表现可能比论文报告的还要差——如果它们能更好地共享信息的话。

4. 单一 harness。 只测试了一种 agent harness（异步论坛），其他交流拓扑（如层级汇报、点对点私信、会议室式实时讨论）未验证。不同的交流结构可能会产生不同的最优团队规模。

5. 无验证器时的选择问题。 在真实场景中，如果你不知道正确答案，如何从多个团队中选出最好的那个？论文假设有一个"选择器"可以做这件事，但构建一个可靠的选择器本身就是一个未解决的挑战。如果选错了团队，那并行团队的优势就打了折扣。

6. 成本模型的简化。 论文的成本模型假设 agent 数量线性映射到成本，但在实际部署中，大团队可能需要更多的协调基础设施（更大的上下文窗口、更多的通信带宽），这些隐性成本没有被完全建模。

💡 启示：三个层面

对系统设计者： 不要把所有推理预算花在独立采样（Best-of-N）上，也不要把所有 agent 塞进一个大团队。把 agent 分成 5-15 人规模的小团队，并行运行多个团队，取最好成绩。这是一个简单、无需训练、即插即用的改进。如果你的 agent 框架目前只支持单 agent 运行，加一个"团队层"可能是最具性价比的升级。

对模型选择者： 模型规模不是唯一决定因素。一个中等模型 + 好的协作结构，可以在特定任务上挑战更大的模型。如果你的预算有限，在协作结构上花心思可能比买更大的 API 更划算。这可能会改变你对"哪个模型最好"的判断——最好的模型，可能不是最大的那个，而是"在你的任务上配合最佳协作策略"的那个。

对多 agent 研究者： 不要过度设计协作协议。给 agent 一个简单的交流基础设施，有用的行为会自发涌现。扁平团队优于有经理的团队——中央协调的代价在开放式任务中超过了收益。但同时也要注意，这个结论可能只适用于"探索密集型"任务；对于"流程密集型"任务，适当的协调可能仍然有必要。关键是理解你的任务类型，然后选择匹配的协作拓扑。

尾声：抽奖的智慧

回到开头的彩票比喻。

这篇论文教我们的，其实不是"怎么买彩票"，而是一个更普适的道理：当你面对不确定性时，"分散投资"和"集中优势"不是对立的——你可以两者兼顾，只要找到正确的粒度。

太大的一团，失去的是多样性。太散的点，失去的是协作力。10 个人一群，不多不少——刚好让每个 agent 都能贡献、都能受益，同时又保留了足够多的独立样本可以从方差中获益。

三个臭皮匠赛过诸葛亮。但前提是——三个皮匠得在一间屋子里。

而当这间屋子不需要经理、不需要工头、不需要有人拿着喇叭喊"大家注意了"的时候，三个皮匠的效率反而最高。

也许，最好的团队管理，就是没有管理——只有共同的目标和畅通的交流。这个道理，AI 已经先我们一步学会了。

参考文献

Wang, J., Chen, H., Li, A., Chalamala, R., & Liu, Z. (2026). Test-Time Compute Scales Better with Parallel Agent Teams. arXiv:2611.09798.

#每日论文 #论文精读 #Agent协作 #MultiAgent #推理计算 #AIScaling #智柴外脑