作者丨 Wes McKinney
译者丨明知山
策划丨 Tina
和很多人一样，我发现 AI 已经严重打乱了我的睡眠作息。以前我凌晨四点或四点半醒来，喝口水、上个厕所，转头就能接着睡，现在却很难再次入睡，总觉得还有事情可以去做。以前我每晚能睡足七八个小时，如今能睡够六个小时都算幸运了。我差不多已经放弃抵抗了：现在每当凌晨五点零七分，我躺在床上辗转反侧，脑子里全是喂给 AI 编程助手的灵感时，就索性直接起床，开启新的一天。
在我的工程师和数据科学家圈子里，大家都在热烈讨论人类的技术优势还能维持多久。当 AI 智能体已经能自主生成更出色的创意时，拥有好点子——甚至大量点子——是否还重要？现在要让智能体产出好结果，似乎仍离不开人类专家的参与，但这种局面又能持续多久？直到我们最天马行空的创意能在睡梦中自动变成优雅可用的软件？这会是一个温和的淘汰过程，让我们欣然交出主导权，还是别的什么？
目前，我感觉自己还有用武之地。我不愿将当下的工作方式称作“氛围编程”（Vibe Coding），因为这个词听起来带有贬义，像是在说靠“提示词 + 放松”做出一堆劣质的 AI 项目。我一直在开发 RoboRev 这类工具，为并行的 AI 智能体会话引入严谨逻辑与持续监督，并对它们的产出进行严格审核。面对这种颠覆性的全新工作模式，我很难不去思考软件工程的未来。
我职业生涯中引用最多的书，大概就是 Fred Brooks 的《人月神话》。书中著名的布鲁克斯定律指出：“向进度落后的软件项目增加人手只会让进度更加落后。”最近我不断自问：这本书里提到的教训，在这个 AI 智能体开发的新时代是否依然适用？一名优秀的开发者指挥一群 AI 智能体是否就能更快、更好地构建复杂的软件？短期的生产力提升是否能带来长期的项目成功？还是说，我们依然会撞上那些困扰软件团队数十年的老瓶颈——范围蔓延、架构漂移与协调成本？
再探《人月神话》
布鲁克斯的核心观点之一是：由精英组成的小团队胜过由普通人组成的大团队，就像一位“主刀医生”搭配一众专家辅助。这能带来高度的概念完整性，让整个系统“虽由多人实现，却如同一人设计”。
智能体工程似乎反而放大了这些问题。如今软件质量完全依赖于回路中的人类——由他们来规划和完善规范、对功能做取舍、克服不必要的代码与架构复杂性。《人月神话》里有一个著名的“焦油坑”比喻：“所有人都能看见野兽在其中挣扎，看似谁都能轻易脱身，但焦油却把它们牢牢粘在一起。”而我们现在正面临一个新的“智能体焦油坑”：并行的 Claude Code 会话与 Git 工作树，跟虚拟同事产生的代码膨胀和偶发复杂性持续对抗。你可以系统性地进行重构，但由智能体生成的代码库比人类纯手工编写的更庞大、更繁琐。这是前所未有的技术债务，正以机器生成的速度不断累积。
布鲁克斯在《人月神话》中指出：一个能运行的程序或许只完成了软件产品的九分之一，真正成熟的产品还需要经过充分测试、完善文档、处理边缘情况并能被原作者之外的人维护。如今，AI 智能体让“能运行的程序”——更准确地说是“看起来能运行的程序”——变得唾手可得，但很多刚接触 AI 氛围编程的人显然都低估了从原型到上线投产所需的工作量。
如果结合与之密切相关的康威定律，这些问题会变得更加复杂。康威定律指出，软件系统的架构往往与组织内部的团队结构和沟通结构相似。可当这套定律用在没有持久记忆、对正在构建的系统缺乏共同认知的虚拟“智能体团队”身上时，又会是怎样一番景象？
《人月神话》中另一个令人印象深刻的核心观点是团队规模扩大时所带来的 n(n-1)/2 协调成本问题。在智能体工程中，参与的人类变少了，但协调问题并没有消失，只是变成了另一种形态。不同的智能体会话可能会产生相互矛盾的方案，需要人类来统一调和。我将这个智能体编排问题留到另一篇文章中讨论。
没有银弹
“无论是技术上还是管理方法上的任何单一进步，其本身都无法保证在十年内让软件开发的生产力、可靠性或简洁性实现数量级的提升。” ——《没有银弹》（1986）
布鲁克斯为《人月神话》撰写了一篇后续文章，从本质复杂性与偶发复杂性的视角重新审视软件设计。本质复杂性是实现目标所固有的复杂性：如果把系统简化，它就无法满足需求。偶发复杂性则是由工具与流程额外强加的一切：编程语言、开发工具，以及为了让工程师理解系统而进行的设计和文档层。
编码智能体或许是应对偶发复杂性最强有力的工具。试想：我现在几乎不再手写代码，却用一门从未亲手写过的语言——Go——生成了大量代码。业内已经有不少讨论：一两年后，IDE 是否还有存在的必要？也许我们只需要一个文本编辑器来审查代码差异即可。生产力的提升是巨大的，我之所以这么说，是因为我每个月在 Claude、Codex 和 Gemini 上消耗的 Token 早已超过 100 亿。
但布鲁克斯“没有银弹”的论点精准预言了我在智能体工程中遇到的困境：偶发复杂性已不再是难题，但本质复杂性依旧是难点所在。AI 智能体无法可靠地分辨这两者。大语言模型是在全人类开源代码上训练出来的非凡模式匹配器，因此它们擅长处理偶发复杂性——重构代码、编写测试、清理混乱，却在更微妙的本质设计问题上举步维艰，因为这类问题往往没有现成先例可供匹配。它们还常常引入多余的复杂性，生成大量防御性的样板代码，而这些在实际应用中极少是真正需要的。
换句话说，智能体太擅长解决偶发复杂性，反而会制造出新的偶发复杂性。在我最近做的 RoboRev、MsgVault 这类新项目里，当代码量接近十万行时，我就已经开始遇到这个问题——眼看着智能体开始原地打转，在自己生成的臃肿代码库里举步维艰。超过某个临界点（下一个十万行或是二十万行）后，系统就开始走向崩溃：每一次新改动都要在之前的智能体留下的代码丛林里强行开路。我们不妨称之为“棕地屏障”。在 Posit，我们看到智能体在超百万行的代码库（比如基于 VSCode 分支的 Positron）中表现得更加吃力。这似乎也印证了布鲁克斯关于复杂性会随规模扩张的观点。
我不敢断言这究竟是暂时的瓶颈还是行业的天花板。模型显然在飞速进步，我现在描述的这些问题或许在两年后再看会显得格外天真。但布鲁克斯对本质复杂性与偶发复杂性的划分让我有理由相信，这并非只是当前技术的局限。早在大语言模型出现之前，搞清楚“究竟要构建什么”就一直是最难的部分，我不认为一个完美的编码智能体能改变这一点。
智能体式范围蔓延
当生成代码变得免费时，知道何时说“不”是你最后的防线。
随着生成代码的成本趋近于零，几乎没有什么能阻止智能体及其人类任务发起者去探索所有此前受成本或时间限制而无法尝试的路径。一整天都在用“现在你能不能……”这样的提示词，这种诱惑令人难以抗拒。但任何新生成的功能或子系统，尽管创建成本低廉，维护、测试、调试与后续理解却并非没有代价。如今看似免费的东西，会在未来的智能体对话中带来上下文负担；每一项新功能、每一个花哨设计都可能成为新的脆弱点或隐患，最终给用户带来损害。
从这个角度看，构建优秀的软件项目从来都不在于打字速度有多快。有了智能体，我们“编码”的效率可能是过去的 10 倍、甚至 100 倍。但我们依然需要做出优质的设计决策，对大多数产品创意说“不”，保持概念完整性，并懂得何时“收手”。智能体正在加速那些“简单的部分”，却反而让那些“困难的部分”变得更加艰难。
智能体带来的范围蔓延也在冲击开源软件世界。如今贡献者参与的门槛空前降低，许多项目正被大量包含 3000 行“有用”新功能的 PR 所淹没。随着开发者越来越放手、逐渐脱离设计与规划环节，由智能体引发的范围失控问题正在快速恶化。当提交 PR 的人既没有编写代码也没有完整阅读代码时，很可能就没有人真正为这些设计决策负责了。
在我自己的 RoboRev 和 MsgVault 项目中，我发现智能体常常会给出过度复杂的解决方案，而实际上简单方案就足够解决问题。我们需要具备判断力，知道何时介入、如何约束智能体。
设计与品味是我们最后的据点
布鲁克斯曾提出，设计能力与良好的品味是最稀缺的资源。如今在智能体承担大量编码工作的情况下，我认为这些能力比以往任何时候都更加重要。瓶颈从来不是敲键盘的双手。即便现在有了全新的“人月神话”，我们依然可以确定：设计、产品范围界定与审美判断力依旧是交付高质量软件的真正约束。
在这个全新的智能体时代，真正优秀的开发者不会是那些开启最多并行会话、消耗最多 Token 的人，而是那些能在脑中牢牢把握项目概念模型的人，那些能果断决定要构建什么、舍弃什么的人，以及能在海量输出中坚守品味的人。
《人月神话》自 1975 年出版至今已逾半个世纪。这期间行业发生了翻天覆地的变化：硬件性能飞跃、编程语言迭代、开发环境升级、云计算普及，乃至如今大语言模型的出现。工具一直在变，但核心约束始终未变。
也许我只是在为自己的持续价值寻找理由，但现实远比这更复杂。并非所有软件都一样：CRUD 类业务应用与数据库及其他关键系统软件有着本质区别。我认为普通的软件咨询工作室已经走到了尽头。但我的观点更多聚焦于那 1% 的尾部开发工作——那些绝大多数工程师难以触及的问题。这类工作仍然需要人类专家参与其中，即便他们不再进行大量甚至任何手动编码。举个近期的例子：我的朋友 Alex Lupsasca 与他世界级的物理学家合作伙伴在 OpenAI 合作，构建复杂物理问题的描述，并在 AI 的帮助下找到解决方案。如果没有这类专家参与，大语言模型是否既能提出问题又能给出答案就远没有那么确定了。
目前，以及在可预见的未来，我大概仍会在凌晨五点起床，去喂养、驯服我的智能体。编码变得更简单了，说实话也更有趣了，我可以把时间花在思考要构建什么上，而不是和工程流程里的各种工具与系统较劲。
https://wesmckinney.com/blog/mythical-agent-month/
声明：本文由 InfoQ 翻译，未经许可禁止转载。