从固定拓扑到动态编排
多智能体系统正在从写死的固定交互拓扑，走向运行时动态编排的 Agent Swarm。但现有基准大多仍停留在单智能体或通用智能体任务上，给一个任务、给一个智能体、判最终答案。SwarmBench 的出发点很直接：当模型要协调一堆智能体、且它们之间的连接关系是动态变化的时候，原来那套评测量错了东西。论文由 Jinshan Gao、Zhuoran Jin、Tianyi Men、Kang Liu、Jun Zhao 完成，8 月 31 日提交，收录于 EMNLP 2026 Findings。
四个维度：accuracy / efficiency / cost / process quality
SwarmBench 从四个视角打分。accuracy、efficiency、cost 三者大家熟悉，真正新增的是 process quality——它衡量编排器怎么组织整个 swarm 的工作流：该生成几个智能体、该不该及时终止多余的、通信有没有出现瓶颈。论文的洞见是，process quality 不是软指标，而是成本驱动：生产环境里一个用 50 个智能体、其实 5 个就够的 swarm，即便最终答案正确，也是失败。效率维度用 Parallelism Gain 衡量——串行执行时间与实际墙钟时间的比值，值越大说明编排器构造的并行结构越有效；成本则用真实美元计算主智能体与所有子智能体的总调用费用，而非原始 token 数。
process quality 到底测什么
process quality 用一套基于 LLM 的评估框架从三个子维度打分（0 到 100）。其一是任务分解（Decomposition）：是否把任务拆成有意义、不重叠、难度匹配的子问题，是否考虑依赖关系与搜索顺序。其二是子智能体创建与委派（Delegation）：角色描述是否具体、必要、不重叠；模型选择是否参考 model card；子任务是否具体、有界、可操作。其三是结果聚合（Aggregation）：是否等待相关子智能体输出；是否比较而非盲信单一输出；是否把证据整合成连贯结论；出现冲突证据时是否会调整方向。这三问恰好戳中多智能体系统最常见的三种翻车：拆得太碎、委派重叠、聚合时只取第一个答案。
轻量框架：逼主智能体靠子智能体
为保证公平可比，SwarmBench 设计了一个统一轻量框架。主智能体只负责分解、创建、分配与聚合，不允许自己直接调工具或直接答题；部分任务上下文对主智能体隐藏，强制它依赖子智能体去取信息；子智能体 backbone 从共享模型池里选，每个模型附带公开编写的模型描述，主智能体要动态挑选；所有模型的工具接口与输出格式保持一致。这样测的纯粹是编排能力，而不是模型自身知识或工具使用能力。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
SwarmExp：把经验抽出来回放
基于 SwarmBench 的实验发现，论文进一步提出 SwarmExp——一种简单却有效的经验提取与回放方法。它分三阶段：先用基础 Agent Swarm 框架在 SwarmBench 上跑、收集完整轨迹；再从轨迹里抽取三类可复用知识——Skill（高层工作流模式，组织成 SKILL.md，描述某类任务怎么分解、怎么组织子智能体、怎么聚合局部结果）与 Trick（更细粒度的操作经验，比如怎么减少冗余信息、怎么更合适地分配子任务）；最后做经验回放。结果显示，这套经验增强能稳定提升大模型的编排表现，说明编排能力本身是可被沉淀、被复用的。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
行业含义：编排能力成为新的卖点
SwarmBench 的潜台词是：固定交互图的厂商会被暴露，优化编排效率的厂商会被奖励。当评测把「过程质量」也量化进来，卖多智能体框架的供应商就不能只晒最终准确率，还要回答「你用了多少智能体、烧了多少钱、过程干不干净」。对工程团队，启示是尽早建立自己的编排度量——在把任务丢给 swarm 之前，先想清楚并行增益、成本与聚合策略，而不是默认「多叫几个智能体总没错」。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
结语
SwarmBench 把评测指针从「智能体答得对」拨到「编排过程好不好」。在智能体数量与复杂度持续上涨的当下，process quality 这类指标很可能从论文走进采购清单。能带好一个 swarm 的模型，比能当好一个员工的模型，更接近生产级多智能体的真实门槛。