AI 时代重读人月神话：沟通成本没有消失

上周末，一位工程师看着四个人围着笔记本和屏幕手忙脚乱，全程不插手。有人叫他也来搭把手，他笑着拒绝了，理由是一句老话：加人不会更快。这句玩笑背后是 1975 年的老定律，现在轮到 agent 阵营来验证它还灵不灵。

一、发生了什么

布鲁克斯定律出自 Fred Brooks 1975 年的《人月神话》，来自他管理 IBM OS/360 项目的经验：向已经延期的软件项目加人，只会让它更延期。定律的地基是沟通成本——n 个人之间的沟通路径按 n 乘 n 减一再除以二的速度增长，新人还需要老手带教，老手的时间被吃掉，产出先降后升。人月这个单位之所以是神话，就是因为人和月不能简单相乘：一个人干十二个月，不等于十二个人干一个月。

荷兰工程师 Jan van den Berg 10 月 27 日发文追问：agent 时代这条定律还在吗。表面上看，瓶颈全消失了——agent 不用入职、不开会、不喝咖啡，毫秒级进入状态，入职培训和站立会议这些传统拖累一夜归零。

但仔细看，定律没有消失，只是变异了。书里那个著名的比喻依然成立：九个 agent 也无法在一个月内生出一个孩子，串行任务依旧串行。管理开销换了个对象——定义「完成」的标准、审代码、抓幻觉、缝合各部分的人，还是你。你不再管理人的日程，改管 agent 的任务边界。不做编排就把九个自主 agent 扔进同一个代码库，它们会高速地互相重写对方的劳动。他给 2026 年的版本是：给需求不清的项目加 agent，只会更快得到错误答案。

二、跟你有什么关系

用 agent 开发的工程师：并行数不是越多越好，编排和审查才是新瓶颈，排期按这个算。

技术管理者：人月的账换成了 token 费和审查工时，但沟通结构一点没变，估算方法得跟着换单位。

立项的人：需求写清之前不扩 agent，顺序反了就是给混乱加急。

三、怎么用

1. 给每个 agent 划清职责边界和文件范围，从源头减少互相覆盖。
2. 设一个汇总人，所有变更过同一道审查，别让改动各自为政直接合流。
3. 需求没写清之前不增加并行数——先把「造什么」定死，再谈「多快」。
4. 定期复盘 agent 之间的返工量，它就是这个团队版的沟通成本账单。

四、三个别信的说法

「AI 没有沟通成本，人月神话过时了。」 成本没消失，是从人和人之间转移到了人和 agent、agent 和 agent 之间，只是换了收银台。

「加 agent 加产出，线性关系。」 没有编排的并行会互相重写，产出可能为负。并行的收益有上限，上限由审查容量决定。

「这本书讲管理，跟写代码无关。」 书的核心是估算与沟通结构，agent 时代恰恰更要先算这两笔账，再决定开几个线程。

五、一句话结论

加人治不了延期，加 agent 也治不了需求不清。

信息来源

• Jan van den Berg：AI 时代的人月神话

文章发布于 2026 年 10 月 27 日。

功能与价格以官方公告为准。本文写于 2026 年 10 月 28 日。