神话般的 Agent 月（The Mythical Agent-Month）：Wes McKinney 谈 Coding Agent 时代的复杂性困境
译者注：
Wes McKinney —— pandas、Arrow 的作者，量化金融出身的工程师。他这篇文章的标题致敬了 Brooks 的《人月神话》（The Mythical Man-Month），讨论的是：当 AI Agent 让写代码的成本趋近于零时，软件工程的本质困难到底有没有变？
这篇文章跟之前翻的 Harness Engineering 可以对照着看：Birgitta 在 Thoughtworks 给企业级 Agent 做 Harness，Wes 则自己开公司做 roborev 和 msgvault，是两个真实的实战视角。斜体部分是我们的注解。
Wes McKinney 2026 年 2 月 17 日
标签：AI, Agent, 思考
跟很多人一样，我发现 AI 对我的睡眠太糟糕了。过去我可能会在凌晨 4 点或 4:30 短暂醒来喝口水或上厕所；现在我很难再睡着了——我在想可以做些什么。以前我每晚能睡 7-8 个小时，现在睡 6 个小时就算幸运了。我基本已经不挣扎了：现在当我在凌晨 5:07 在床上辗转反侧，脑子里全是喂给我的 AI Coding Agent 的想法时，我就直接起床开始新的一天。
在我的工程和数据科学家朋友圈子里，有很多关于我们作为人类的竞争优势还能持续多久的讨论。当 Agent 自己开始产生更好的想法时，有好主意（以及很多好主意）还重要吗？人肉专家在循环中（human-expert-in-the-loop） 对于从 Agent 那里获得好的结果感觉至关重要，但这能持续多久？直到我们最大胆的想法都可以在我们睡觉时被转化成可用的、有品味的软件？这将是一种温和的过时——我们愉快地交出缰绳——还是别的什么？
就目前而言，我觉得自己还是被需要的。我不把现在的工作方式称为”vibe coding”——这听起来像是一种贬义的”提示词然后躺平”式构建 AI slop 软件项目的方式。我一直在构建像 roborev 这样的工具，为我的并行 Agent 会话带来严谨性和持续监督，并严格审查我的 Agent 所做的工作。在这种全新的工作方式下，很难不去思考软件工程的未来。
我职业生涯中引用最多的书可能就是 Fred Brooks 的《人月神话》（The Mythical Man-Month），他著名的布鲁克斯法则认为”给一个延迟的软件项目增加人手，只会让它更延迟”。最近，我发现自己不断在问：这本书的教训在这个 Agent 开发的新时代是否仍然适用？一个有才华的开发者编排一群 AI Agent 能否更快更好地构建复杂软件？短期的生产力提升能否带来长期的项目成功？还是我们会遇到同样的瓶颈——范围蔓延、架构漂移、协调开销——这些困扰软件团队几十年的问题？
重读《人月神话》
Brooks 的核心论点之一是：少数精英组成的小团队胜过大量普通人的大团队，由一位”主刀医生”带领专家团队支持。这使得系统设计具有高度的概念完整性——仿佛”由一个人设计，尽管许多人建造了它”。
Agent 工程似乎在放大这些问题——因为正在构建的软件质量现在只取决于参与循环的人的能力：他们策划和完善规格说明、对功能说是或否、驯服不必要的代码和架构复杂性。TMMM 中的一个比喻是**“焦油坑”**（tar pit）——“每个人都能看到困在里面的野兽，看起来任何一个都可以轻易挣脱，但焦油把它们粘在了一起”。现在我们有了一个新的”Agent 焦油坑”——我们的并行 Claude Code 会话和 git worktrees 在与它们虚拟同事产生的代码膨胀和偶发复杂性搏斗。你可以系统地重构，但一个 Agent 生成的代码库不可避免地会比任何手工构建的要大得多、冗余得多。这是前所未有的技术债务，以机器的速度在累积。
在 TMMM 中，Brooks 观察到：一个能运行的程序可能只完成了到”编程产品”的 1/9——一个编程产品还需要必要的测试、文档、对边缘情况的加固，以及由作者以外的人维护的能力。Agent 现在让”能运行的程序”（更准确地说是”看起来能运行的程序”）变得极其容易实现，尽管许多初出茅庐的 AI vibe coder 明显低估了从原型到生产环境所需的工作量。
这些问题在考虑到密切相关的康威定律时更加复杂——该定律断言软件系统的架构往往反映组织的团队或沟通结构。当将其应用于一个由没有持久记忆、没有对正在构建的系统的共享理解的 Agent 组成的虚拟”团队”时，这看起来像什么？
TMMM 中另一个让人铭记的”大想法”是团队扩张时的 n(n-1)/2 协调问题。在 Agent 工程中，参与的人类更少，所以协调问题并没有消失，而是改变了形态。不同的 Agent 会话可能产生相互矛盾的计划，需要人类去调和。我把这个 Agent 编排问题留到另一篇文章再谈。
这段太对了。我在字节做 Agent 时最大的感受就是：代码膨胀的速度远超人的控制能力。 一个 Agent 做一个”看起来能跑”的功能只要 15 分钟，但产生的冗余代码、防御性检查、从上下游复制过来的重复逻辑，需要反复 review 才能清理干净。Brooks 的 1/9 比例在 Agent 时代可能更夸张——因为”运行”到”可维护”之间的差距，Agent 自己填不上。
没有银弹
“没有任何单一的技术或管理方法，能够在一个十年内，使生产力、可靠性、或简洁性获得一个数量级的提升。” ——《没有银弹》（1986）
Brooks 在 TMMM 之后写了一篇后续文章，通过本质复杂度（essential complexity） 和偶发复杂度（accidental complexity） 的视角来审视软件设计。本质复杂度是实现目标所固有的：如果你把系统做得更简单，它就无法满足问题陈述。偶发复杂度则是由我们的工具和过程强加的一切：编程语言、工具、以及为了让工程师能理解系统而添加的设计和文档层。
Coding Agent 可能是有史以来应对偶发复杂度的最强大工具。想想看：我基本上不再写代码了，现在却在一个我从未手动写过代码的语言（Go）中写大量的代码。有很多讨论说 IDE 在一两年内是否还会相关——也许我们需要的只是一个用来审查 diff 的文本编辑器。生产力的提升是巨大的——作为一个每月烧掉 100 亿 token（Claude、Codex、Gemini 加起来）的人，我这么说是有底气的。
但 Brooks 的”没有银弹”论证恰恰预测了我正在经历的 Agent 工程问题：偶发复杂度不再是问题了，但剩下的本质复杂度——从来就是最难的部分——Agent 根本搞不定。 LLM 是在全人类开源软件上训练出来的非凡的模式匹配器，所以它们处理偶发复杂度游刃有余（重构这段代码、写这些测试、清理这些混乱），但它们在更微妙的本质设计问题上挣扎——这些问题往往没有可以匹配的先例。而且它们往往倾向于引入不必要的复杂度，生成大量在实际使用中很少需要的防御性样板代码。
换句话说：Agent 在攻击偶发复杂度方面太强了，以至于它们会产生新的偶发复杂度——这些复杂度反而妨碍了你试图构建的本质结构。
在我的几个新项目 roborev 和 msgvault 中，我已经开始处理这个问题了。当代码量接近 10 万行时，我眼看着 Agent 开始追着自己的尾巴跑，在它们自己生成的臃肿代码库中上下文窒息。在某个临界点之后（下一个 10 万行，或 20 万行），事情开始崩溃：每一个新的变更都必须在之前的 Agent 制造的代码丛林中披荆斩棘。 我叫它”棕地屏障”（brownfield barrier）。在 Posit，我们看到 Agent 在超过 100 万行的代码库（如 Positron，一个 VS Code 分支）中挣扎得多得多。这似乎印证了 Brooks 的复杂度扩展论点。
我不太愿意下注说当前是天花板还是平台期。模型显然在快速变得更好，我今天描述的这些问题在两年后看起来可能相当可爱。但 Brooks 的本质/偶发区分让我有一些信心——这不仅仅是技术的当前限制问题。在我们有 LLM 之前很久，弄清楚要构建什么就是最难的部分，我看不出一个完美的 Coding Agent 如何改变这一点。
“棕地屏障”这个观察太精辟了。我们现在正在经历这个——项目初期 Agent 效率奇高，但随着代码增长到一定规模，Agent 开始产生越来越多”与已有代码矛盾的变更”。不是模型变差了，是它自己之前产生的代码变成了障碍。
Agent 驱动的范围蔓延
当生成代码是免费的，知道什么时候说”不”就是你最后的防线。
随着生成代码的成本趋近于零，几乎没有什么能阻止 Agent 和它们的人类工头去追逐那些以前因成本或时间限制而无法涉足的方向。花一天时间提示”现在你能不能……”的诱惑是压倒性的。但任何新生成的功能或子系统，虽然创建时便宜，但维护、测试、调试和未来的推理并不免费。现在看起来免费的东西，会给未来的 Agent 会话带来上下文负担，每一个新的花哨功能都会成为一个新的脆弱性或 bug 的源头，伤害用户。
从这个角度看，构建优秀的软件项目也许从来就不是关于你打代码的速度有多快。我们打代码的速度比以前快了 10 倍，也许是 100 倍。但我们仍然需要做出好的设计决策，拒绝大多数产品想法，保持概念完整性，并知道什么时候算是”完成了”。
Agent 正在加速”简单的部分”，而矛盾的是让”困难的部分”可能变得更加困难。
Agent 驱动的范围蔓延似乎也在积极摧毁开源软件世界。现在贡献者参与并帮助的门槛前所未有地低——项目在泛滥的 3000 行”有帮助的”PR 中挣扎，这些 PR 添加新功能。随着开发者越来越放手、越来越脱离设计和计划过程，Agent 的失控范围蔓延可能迅速失控。当一个提交 PR 的人没有编写或完整阅读其中的代码时，可能就没有任何人真正对所涉及的设计决策负责。
我在自己的 roborev 和 msgvault 工作中也看到：Agent 会提出过度复杂的解决方案来解决一个简单方案就完全足够的问题。知道何时干预以及如何控制 Agent，需要判断力。
这段跟上一篇文章的 “行为 Harness” 部分呼应了——这是目前最难解决的问题。“知道什么时候说’不’” 不是能写进 Skill 文档的东西，是一种积累出来的判断力。
设计与品味作为我们的最后立足点
Brooks 的论点是设计天赋和好品味是最稀缺的资源，而现在在 Agent 做所有编码工作的情况下，我认为这些技能比以往任何时候都更重要。瓶颈从来不是键盘上的手。现在，有了新的”神话般的 Agent 月”（Mythical Agent-Month），我们可以有把握地得出结论：设计、产品范围界定和品味，仍然是交付高质量软件的真正约束。
在 Agent 新时代中蓬勃发展的开发者，不会是那些运行最多并行会话或烧掉最多 token 的人。他们会是那些能够在脑海中保持项目的概念模型、精于决定构建什么和放弃什么、对巨大的输出量行使品味判断的人。
《人月神话》出版于 1975 年——五十多年前。在这段时间里，发生了很多事情：硬件性能、编程语言、开发环境、云计算以及现在的大语言模型的巨大进步。工具变了，但约束条件依然相同。
也许我是在试图证明自己仍然存在的价值，但现实比这更复杂。并非所有软件都是平等的：CRUD 业务生产力应用跟数据库和其他关键系统软件不一样。我认为中位数的软件咨询公司完全完了。但我的论点更多的是关于分布中 1% 尾部的开发工作：大多数工程师无法触及的问题。这将持续需要专家人类在循环中，即使他们没有做太多或任何手动编码。作为一个最近的邻近例子，我的朋友 Alex Lupsasca 在 OpenAI 和他世界级的物理学家合作者能够用 AI 的帮助下创造出一个难题的表述并得出解决方案。没有这样的专家在循环中，LLM 是否能够既提出问题又得出解决方案，这一点远远不那么确定。
就目前而言，在可预见的未来，我可能仍然会在早上 5 点起床喂养和驯服我的 Agent。编码现在更容易了，老实说也更有趣了，我可以把时间花在思考要构建什么上，而不是与工程过程周围的工具和系统搏斗。
感谢 Martin Blais、Josh Bloom、Phillip Cloud、Jacques Nadeau 和 Dan Shapiro 对本文草稿的反馈。
译者后记
这篇文章跟上一篇（Harness Engineering）有很强的互补性。如果说 Birgitta 给的是**“怎么给 Agent 设计控制系统”的方法论，那 Wes 给的是”什么需要被控制”**的问题清单：
- 代码膨胀 — Agent 天然倾向于产生超过必要规模的代码，在大代码库中开始追自己尾巴
- 范围蔓延 — 生成代码的成本趋近零，导致”加一个小功能”的诱惑失控
- 概念一致性丧失 — 没有持久记忆和共享理解的 Agent 群无法保持设计一致
- 棕地屏障 — Agent 自己制造的代码丛林成为后续变更的最大障碍
他说了句狠话：“我认为中位数的软件咨询公司完全完了。” 这话不是耸人听闻。CRUD 业务的 Agent 化已经在发生。真正留下来的只有两样东西：1% 尾部的深问题 + 人类的设计品味。
对于做 Coding Agent 的我们来说，他的结论其实是个好消息——它告诉我们：不是往代码生成的方向卷，而是在”设计判断力”和”控制膨胀”的方向上卷。 这才是 Agent 工程的核心矛盾。