为什么 AI Agent 团队也逃不过“人多了反而慢”?
2021 年 4 月,笔者写过一篇《为什么现代软件工程离不开项目管理》;2022 年 9 月,写了《你的团队在正确实践敏捷吗》;同年 12 月,又写了《为什么需要在软件项目中考虑复杂度》。当时觉得这是三个不同的话题:一篇讲流程,一篇讲方法论,一篇讲架构。最近把它们翻出来重读,才发现它们其实在绕着同一个问题打转:人多了,为什么反而慢了? 复杂度那篇的引言甚至直接写着:"随着项目规模的增长,复杂度会以指数级的速度增加,如果不加以控制,最终会导致项目的失败。"
这些年带团队,这个问题也从纸面落到了身上。项目延期,第一反应是加人;人加进来了,进度反而更糟——新人要熟悉上下文,老人要停下来带新人,会议多了一倍,对齐的成本涨得比产出快。五十年前 Fred Brooks 在《人月神话》(The Mythical Man-Month,1975)里就把这个现象说透了:"往一个已经延期的软件项目里加人,只会让它更晚交付。"这句话程序员都听过,也都点头。但严格说,它一直只是一句格言,算不上一条定律——没有哪家公司能拿自己的团队做对照实验,去验证它到底有多准。
有意思的是,最近这件事出现了转机,而带来转机的不是管理学,是 AI。2025 年底,MIT 和 Google Research 的研究者测了 180 种 agent 系统配置,结果活脱脱是《人月神话》的复刻:在必须一步接一步完成的任务上,每一种多 agent 方案都比单个 agent 更差,差 39% 到 70%;集群规模超过三四个 agent,加得越多越糟。人月神话诞生五十年,第一次有了对照实验——只不过被试不是人,是 agent。
这就是本文想讲的事:AI agent 团队正在精确复刻人类组织的老毛病;而更有意思的另一半是,它是历史上第一个能把这笔账完全算清楚的组织形态。



