「多叫几个智能体一起干，是不是就更准？」这问题听起来理所应当，但 9 月提交的论文「An Exact Generate - Transform Decomposition of Small-LLM Team Scaling Across Orchestration Architectures」（编号 2609.36104）用一组大扫描把它钉出了裂缝：团队扩展小模型（7-9B）的收益，高度依赖任务类型，而且常被一个平均数悄悄抹平。
论文的扫法很狠。它横扫 8 种多智能体编排架构，跑在 5 个指令微调的小模型上，覆盖 5 个短答基准加 1 个可执行代码基准，调用次数上限拉到 30。结论的分叉很刺眼：从 3 次调用扩展到 30 次，在 GSM8K 和 GSMHard 这两个算术应用题上准确率最多涨 17 分；但在 ARC、GPQA、MMLU 这类知识问答上，不管怎么加人，最多只动 4 分。同一个「团队扩展」操作，在不同任务上走出完全不同的曲线。
为什么平均数会骗人？作者点破的是度量口径：行业习惯报「任务平均准确率」，而任务平均会把算术题的大涨和知识题的纹丝不动搅在一起，得到一个「还行」的中间值。于是团队扩展看起来「有点用但有限」，真实情况却是「对某些任务极有用、对另一些几乎无效」。这对工程决策是致命的误导——你以为在 uniform 地提效，其实只在一条窄带上发力。
方法上值得记一笔的是，它把「架构」「模型尺寸」「任务类型」三轴拆开扫，而不是只动一个旋钮。编排架构（含 Proposer-Critic 这类）之间差异被任务类型盖过：真正决定增益的，是任务本身是不是可分解、是不是靠多步推理取胜，而不是你用了哪种拓扑。换句话说，小模型组队的价值上限，由任务结构定，不由编排花活定。
落到选型，这条线给了一个反直觉的提醒：如果你的场景主要是知识问答或单步判断，多叫几个小模型几乎不会带来边际收益，省下的算力不如投到更好的检索或提示工程；而如果你的场景是分步推理、能拆成多步验证的题，多个小模型组队才真正值得。换句话说，「多智能体团队」不是规模越大越好，而要先把任务钉在它吃增益的那条曲线上。对已经在用小模型编排的团队，最该做的不是加节点，而是回头重新划分任务——把可分解、靠多步推理取胜的子问题挑出来组队，把知识类子问题留给更强的单模型。
放到本月这两条多智能体研究线一起看，对照更清楚。上一篇 Planner-as-Router 关心的是「同一工作流里怎么分模型档位最省钱」，这篇关心的是「小模型组队到底在哪些任务上真增值」。两篇合起来指向同一个朴素结论：多智能体不是默认增益，而是一把有适用面的扳手。架构选择、模型档位、任务类型，三者得配套看。
冷静部分照例：扫描基于特定的 5 个 7-9B 模型和 5 加 1 个基准，跨到更大模型或长文任务的表现待复现；「调用次数上限 30」下的增益曲线是否还会继续抬头，论文没给更长程的数据；知识类任务加 4 分的封顶是否源于基准本身的天花板，也需另验。但给工程团队的提醒够直接：下次想「加几个智能体提提效」，先问一句——这个任务，是算术应用题，还是知识问答？当答案是后者，与其继续加人扩队，不如先换更强的单模型或补好检索与提示——架构的边际收益在那里本就逼近天花板。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。