先把判断说清楚：为什么在 AI Agent 时代写 Martin Fowler

很多人想到 Martin Fowler，脑子里先跳出来的还是《Refactoring》或者企业应用架构模式。这当然没错，但如果只停在这里，会很容易把他误放进“经典人物回顾”那一栏。问题是，Martin Fowler 并没有真的离开当下。你去看他的网站，会有一种很奇妙的感觉：像是书架、白板和实验台被放进了同一个房间。

到了 AI Agent 时代，这一点反而更清楚。因为系统一旦开始让代理参与执行、生成和编排，复杂度就会更容易在你看不见的地方长出来。边界会模糊，集成会增多，临时拼接的流程会越来越像永久系统，技术债也会更快伪装成“先跑起来再说”。这种时候，Fowler 这类长期研究架构演化和设计判断的人，重要性不是下降，而是上升。

所以，这篇小传真正想回答的，是这样一个问题：为什么一个长期讲重构、模式和架构边界的人，在今天这个看起来一切都被模型刷新了的时代，反而又变得非常有现实感。

他的底色，是把工程判断翻译成人类团队听得懂的话

Martin Fowler 在公开自述里把自己形容成“author, speaker… essentially a loud-mouthed pundit”，这当然有他一贯的幽默。但如果认真看，会发现这是个非常准确的自我定位。他真正擅长的，不只是提出概念，而是把分散在行业里的好实践识别出来、命名出来，再整理成团队可以采用的语言。能把自己写成“嘴很碎的评论员”，同时还持续被工程团队认真引用，这本身就说明他有点本事。

这件事在软件行业非常重要。因为大量技术问题并不是因为没人能解决，而是因为多数团队没有足够清楚的概念工具来讨论它。重构、模式、演化式架构、持续交付、技术债，这些今天几乎已经变成基础词汇的概念，之所以能广泛进入工程共同语境，Martin Fowler 这种“整理并传播判断”的人物作用很大。

也正因为如此，他对今天依然有价值。AI Agent 时代并不缺更响的口号，缺的是能把变化拆解成工程问题的人。Fowler 恰好一直在做这个角色。

为什么 Agent 时代反而更需要“重构派”

AI Agent 让很多团队第一次感受到一种很强的生产幻觉：因为生成速度变快了，所以结构问题也许可以后面再说。反正先连起来，先让代理跑起来，先把流程串通，等真的大了再重做。这种想法听起来很现实，实际上非常危险。

因为代理系统的复杂度，常常不是直接体现在代码行数上，而是体现在行为路径、工具边界、状态漂移和异常恢复上。一个看似可用的 agent 工作流，很可能在你没有明确设计边界时，悄悄演变成难以测试、难以观察、难以回滚的系统。这时候，重构就不再是“代码写完后的美化”，而是维持系统可演化性的基本手段。

Martin Fowler 这类人之所以重要，恰恰因为他们长期提醒行业：结构不会自己长好，命名不会自己变清楚，边界不会因为需求变急就自动合理。AI Agent 时代只是让这些老判断变得更快兑现而已。

他今天依然重要，还因为他没有停止理解新工具

写 Martin Fowler 最容易犯的错误，是把他写成老派架构师的象征，好像他的价值只存在于书单里。但实际上，他的网站这些年一直在吸收和整理新变化，最近也持续出现 generative AI、coding agent、function calling 等相关内容。

这件事很关键。它说明他并不是站在新技术的对面发评论，而是仍然试图把这些新东西放回软件工程的长期语境里理解。像“Building your own CLI Coding Agent with Pydantic-AI”这样的文章，或者更近的“Agentic Email”，都能看出一个熟悉架构的人在看新工具时最关心什么：边界、上下文、风险、可控性，以及它到底会怎样嵌进人的工作流。

对读者来说，这种姿态比“是否亲自写某个 AI 爆款产品”更值得重视。因为能陪行业一起理解变化的人，往往比只制造一次热点的人更耐久。

顺手记两个小趣事

Martin Fowler 这类人物，也有两个很能让人放松下来的小细节。

  • 他会在个人介绍里直接叫自己 loud-mouthed pundit。

这其实挺可爱。因为很多行业长辈会尽量把自我介绍写得端正，而 Fowler 是那种先替你把吐槽说掉的人。

  • 他的网站看久了，会发现一种很特别的混搭感。

一边是几十年都在更新的软件架构与重构文章，一边又在认真写 generative AI、coding agent 和 function calling，像是在告诉大家：别急着把新东西和老问题分桌坐，它们迟早还要一起开会。

普通读者今天最值得从他身上学到什么

如果你正在做 Agent 产品、AI 内部平台，或者只是开始把代码代理引入团队流程，那么 Martin Fowler 至少有三点值得重新带走。

  • 先想边界，再想连接。能连起来不等于应该连，系统最贵的成本常常在边界模糊之后才开始出现。
  • 把重构当成持续治理，而不是版本上线后的装修。尤其在 Agent 场景里，很多复杂度是会偷偷积累的。
  • 给团队一套足够清楚的概念工具。技术判断一旦没有共同语言，就很容易退化成“先试试看”的惯性。

这也是为什么 Fowler 这种人物，在今天反而会显得越来越有用。他不一定提供最炫的 demo，但他很擅长帮团队避免把 demo 错当成系统，把短期顺滑误认成长期稳固。

结尾：他代表的是一种对复杂度的长期警觉

Martin Fowler 最难得的地方，也许不是他写过多少书，而是他几十年如一日地维持着一种对复杂度的警觉。他知道软件系统的麻烦，往往不是在功能最少的时候出现，而是在系统逐渐成功、逐渐扩张、逐渐接入更多上下文之后开始显形。

AI Agent 时代只会让这个规律更加明显。因为新机器的确能帮我们更快生成、更快连接、更快试验，但这些“更快”也意味着系统更容易在我们还没反应过来的时候变得不透明。这个时候，Fowler 这种持续讲边界、讲演化、讲重构的人，反而像一根很稳的地桩。

把 Martin Fowler 放在“机器上桌之后”的最后一篇，也很合适。这个系列写了不少机器真正进入工作台以后变得更重要的人，而 Fowler 代表的是另一种必要角色：当大家都在向前冲的时候，始终提醒行业看看地基、边界和结构的人。一个团队里如果没人扮演这个角色，系统最后通常会自己来扮演，而且方式不会太温柔。

附注：重要视频访谈

如果你想更快建立 Martin Fowler 的人物感，而不是只停在“《Refactoring》作者”这个标签，我建议优先看下面 3 场。它们分别对应他的三种典型角色：解释者、对谈者和现场思考者。

这场最适合看他如何把 AI、技术债、工程成长和长期软件设计放在同一张图里讲清楚。

这场更像近距离状态更新，适合看他今天仍然在关心哪些趋势、哪些老问题又回来了。

这场更适合回到《Refactoring》这条主线，理解他为什么始终把“可演化性”看得那么重。

更新附注

  • 版本：v1.3

更新日期：2026-03-15 更新原因：补充两则人物趣事，并将整篇语气调轻，让小传更有可读性和一点幽默感。

  • 版本：v1.2

更新日期：2026-03-15 更新原因：补充 3 条重要视频访谈，并将对应链接加入参考来源。

  • 版本：v1.1

更新日期：2026-03-15 更新原因：调整系列标题命名，将文章归入“机器上桌之后”专题。