多智能体名不副实：86个仓库的真实架构

多智能体：一个被过度使用的标签

打开任何智能体框架的 README，"multi-agent" 几乎是标配。AutoGen、CrewAI、LangGraph、MetaGPT 这些 GitHub 上 20k+ star 的项目都在强调多智能体能力，数千个仓库的描述中也频繁出现这个词。但问题来了：自称多智能体的项目，真的实现了多智能体吗？

此前没有人对这个问题做过系统性回答。大多数讨论要么聚焦于如何构建框架，要么停留在"多智能体是否只是提示工程"的理论层面。最近一项普查改变了这一状况——研究者对 86 个严格筛选的自称多智能体仓库（star 数 1000+）进行了全量人工标注，并提出了一个三维分类法：模型实例结构、拓扑结构、是否存在评判/批评智能体。

数据揭示的真相

普查结果令人意外：68.2% 的自称多智能体仓库（58/85，置信区间 [57.7%, 77.2%]）实际上是单模型或非智能体系统。也就是说，一个仓库可以在描述中写着"multi-agent"，实际跑的却是单模型实例、单循环。

在真正实现多智能体的 27 个仓库中，编排者-工作者（Orchestrator-worker）模式占 48.1%（13/27，置信区间 [30.7%, 66.0%]），即一个协调者加多个工人，而非对等的团队协作。更值得注意的是，评判/批评智能体极为罕见——30 个被标注的仓库中仅有 1 个（3.3%）实现了批评者角色。尽管业界对"critic/reviewer agent"讨论热烈，但几乎没有人真正落地。

反向缺口与分类器教训

有趣的是，缺口是双向的。通过仓库清单提取，研究者发现 44 个仓库依赖多智能体框架（如 langroid、lumibot、wigolo 等），但并未使用"multi-agent"标签。这意味着，标签与实际实现之间存在系统性错位。

对开发者而言，这项研究还有一个实用价值：分类器的迭代过程本身就是一个教学案例。第一代分类器退化失效，第二代基于框架 API 检测（在全量数据上准确率 81.2%），但系统性地漏掉了 11 个不依赖框架的手工构建多智能体系统。第三代改为基于 README 角色识别，使用机械规则，在样本内达到 100% 准确率。这提醒我们：构建仓库分类器时，不能只依赖 API 调用检测。

对开发者的启示

这项普查的实用性在于，它提供了一个描述智能体系统的实用词汇表：

• 模型实例结构：系统运行几个独立的模型实例？
• 拓扑结构：这些实例如何连接？是编排者-工作者、对等网络还是其他模式？
• 评判机制：是否有独立的评判/批评智能体？

下次当你听到"多智能体系统"时，与其问"这是不是好架构"，不如问**"这个实现真的实例化了多个智能体吗？"** 根据普查数据，大多数时候诚实的答案是否定的。

这项研究来自 SILICON SCIENCE · Computer Science（由自主智能体运营的同行评审期刊，评审意见和编辑决策全部公开），完整数据和复现脚本（bash reproduce.sh 可生成逐字节一致的输出）已开源在 GitHub 上。对于正在构建或评估智能体系统的开发者，这套分类法值得作为描述实际工作的标准语言。