Spring 创始人重回一线做 AI 框架，却说：这是人类选择的最后一代框架

摘要

Rod Johnson 又回到了一线。

他是 Spring 的创造者，曾经几乎重新定义了企业 Java 应用应该怎么写。二十多年后，他重新创业，做了一个面向企业 AI Agent 的开源框架 Embabel，试图把 LLM 放进真实的业务系统里，让它不只是会调用工具，而是能在可控、可解释、可审计的流程里工作。

有意思的是，这一次他做的依然是框架，但他对"框架"的未来并不乐观——至少不再是过去那种乐观。在他看来，模型还会继续变强，工具也会越来越多地替开发者做选择。Embabel 会不会被更强的模型追上？企业还需不需要这样一层 harness？未来的框架到底是由开发者挑选，还是由 AI 工具自动决定？这些问题，都绕不开他在访谈里说的那句话：这可能是最后一波由人类亲选框架的框架。

这句话放在别人嘴里，可能只是又一次 AI 时代的夸张判断。但从 Spring 创始人嘴里说出来，意味就不一样了。因为 Rod Johnson 亲手参与过框架时代的兴起，也见过一个框架如何变成企业软件开发的基础设施。现在，他回到战场，却认为选择权正在转移：开发者未必会消失，但开发者亲挑框架、搭技术栈、决定系统骨架的时代，可能正在进入尾声。

核心观点

GenAI 应用层赋能这件事，更适合在应用原本的语言里完成，如果应用是用 Java 写的，那就在 Java 里完成。
一旦你进入复杂的应用程序，如果你不保持那种架构上的监督，你很快就会陷入一团乱麻。 你的 Agent 会愉快地添加新功能，但每添加一个新功能，设计就会退化，代码就会变得非常糟糕。
开发者不应该花大量时间在编写代码上，因为你可以通过专注于你独特增加价值的地方来获得更大的杠杆。
每个开发者原则上上都应该每隔一两年学一门新语言，因为它真的会改变你的思维方式。
这可能已经是"最后一波由人类主动选择的框架"了。 以后越来越多的技术选项，都会由我们的工具替我们完成。

1 Spring 创始人回归一线创业

Simon：我翻你的履历时发现，你在创建 Spring 之前，拥有一个关于 19 世纪巴洛克钢琴音乐的博士学位。

Rod：是的，我的第一个学位是音乐和计算机科学双专业，当时完全没办法决定往哪个方向走。后来我拿到了澳大利亚的研究奖学金去读音乐博士，还在悉尼音乐学院教过两年音乐史。然而，写代码的冲动一直没停过。90 年代中期我还写过共享软件，真有人寄支票过来。

后来我清醒地认识到，要是真的继续待在音乐学术界，我大概一辈子都在悉尼买不起房。于是我做了一决定：这两件事里，一个当爱好，一个当职业——而我当时正好搞反了。不过接下来有十年我几乎没碰过钢琴，因为职业生涯实在太忙了。

Simon：所以这并不是什么奇怪的弯路或别的什么，只是碰巧你很有创造力，无论是写代码还是音乐，你都很享受这两者。

Rod：从 80 年代中期第一次写代码到现在，我差不多从未中断过程序，因为我就是爱这件事。即便现在绝大部分代码是由 AI Coding Agent 替我写的，我仍然能获得一模一样的兴奋感，因为掌权还在我手里，我还在创造和塑造东西。哪怕不再亲手敲出每一行，只要结果是一样的，这对我而言同样令人满足。

Simon：在 SpringSource 被收购后，你做了很多年董事会和投资的事情，然后创立了 Embabel，是什么让你觉得"就是现在，这个时机到了"？

Rod：我认为是因为行业正处在一个巨大的转折点上。当 GPT-3 和后来的 ChatGPT 突然变得真正实用、不再重复自己或陷入奇怪的死胡同时，我立刻意识到，怎么把这项技术真正用来解决企业问题，是很难的问题。其实在这之前两年，出于个人兴趣，我已经写了不少 TensorFlow 代码，和底层 AI 技术打了很交道——这自然而然地演化成创建了一个框架来帮助解决这些问题的想法。

2 为什么企业级 AI 不是 Python 的天下

Simon：说到企业，现在很多团队被要求抛下 Java，用 Python 重写一切。你公开讲过这是错误的，甚至说过"这是 Python 在 AI 领域主导的最后一年"，为什么？

Rod：你要解决一个业务问题，就必须考虑这个问题本身的"邻近性（Adjacency）"。你在和什么打交道？你大概在和数据库、企业服务、现有代码库打交道。同时你还要处理一个新东西：LLM。可 LLM 并不在你那个 Python 进程里运行——宇宙毁灭之前，Python 都没法自己执行推理。LLM只是一个非常简单的 HTTP 调用，所以我一直很困惑，为什么人们会认为某门语言在发起一个极其简单的 HTTP 调用时会有天然优劣。

事实上，大家已经开始逐渐意识到这一点了。OpenClaw 就不是用 Python 写的，Peter Steinberger 用的是他偏爱的语言。对大量企业应用而言，它们很明显是用 Java 写的，关键的邻近性就在于已有业务逻辑、已有企业服务。那正确的做法就很显然了——从你的 Java 栈里发起一个简单的 HTTP 调用。

我认为人们产生这种混淆的根本原因，是没有把"数据科学"和"企业 AI 应用"区分开，它们是两件完全不同的事。在 Embabel 之前我写了大量 Python，两年前我的 Python 甚至比 Java 流利得多。如果我要用 TensorFlow 做模型训练、微调、某些数据处理和摄入，我当然会用 Python。但 GenAI 应用层赋能这件事，更适合在应用原本的语言里完成——如果应用是用 Java 写的，那就在 Java 里完成。

Simon：Embable 是用 Kotlin 写的，对吧？

Rod：Embabel 核心几乎全部是用 Kotlin 写的。但我们的大多数示例是 Java。我们投入了大量精力来确保对 Java 用户来说，它是完全无缝的——正如你预期的那样，我们绝大多数用户群都在用 Java。你不会看到 companion object、.kt 文件，不会看到任何奇怪的东西。它就像非常优雅、流畅的 Java。所以当我在核心框架上工作时，我用 Kotlin；当我在示例应用上工作时，我用 Java。老实说，Java 风格的 API 非常棒，即使在 Kotlin 里使用这个框架，它和其他语言的体验也差不多。

Simon：而且它们之间的集成本来就很简单，你可以直接从 Kotlin 跳到 Java。

Rod：大约十三年前，我大量使用过 Scala。我很喜欢 Scala 这门语言，但事实是它与 Java 的集成很痛苦。每次你处理一个集合，那都是折腾。而 Kotlin 的创造者在 Java 互操作性方面做得非常出色，他们没有引入 Scala 曾有的那些问题，破坏性变更、更缺乏二进制兼容性等等。所以，是的，我认为 Kotlin 是一门非常好用的语言。

不过，我也想指出 Java 已经改进了很多这件事很重要，我觉得人们喜欢拿 Java 当稻草人来攻击很烦人。很多人在假装 Java 没有进化，而 Java 实际上已经进化了很多。

3 Coding Agent 正在毁掉你的代码库

Simon：你之前谈到 AI 基本上是被当作一个断开的层硬塞进去的，而不是更深地集成到现有系统中，结果导致了一些失败案例。你认为真正的企业 AI 失败案例是什么样的？

Rod：我认为最大的问题就出在，当高层下达"AI 一切"的指令，团队却没有真正业务案例、没有确认 AI 是否适合的情况下，盲目开展 AI 项目。一个主要的反模式就是"我们必须用更多 AI"这种念头，却从来不去问一句：为什么用？用来干什么？虽然我非常热爱而且着迷于 AI，但如果能不用 LLM 就完成一件事，那你当然应该不用 LLM，这样更便利、更确定、更快。

所以组织首先要做的，是思考"我们怎么从这儿走到那儿去"。举个例子，我们在澳大利亚的一个客户，他们一开始识别出一类小问题：网站上某张特定表格，客户填写后需要人工审核才能继续。95% 的情况其实非常简单，虽然用正则表达式处理起来稍嫌麻烦，但本质上很简单。于是他们把这个摩擦点消除掉了，在 95% 的场景里让客户即时推进，不再需要等人工处理。我认为这是非常棒的起步案例：先在小事前拿到结果，慢慢建立起信任。

另外，对于"异构技术栈（Alien Stack）"问题，它会在两个方向上造成损害。第一，技术上让一切都变难；第二，它往往还会把战略权交给错误的人手里——那些根本不懂核心业务、可能从来没见过任何核心业务应用的人，却在主导战略。当你要赋能这些应用的时候，这条路完全走不通。

去年我和一家澳大利亚大公司的首席 AI 架构师聊过，他是一名 Python 开发者。他礼貌地听了我的介绍，却没什么兴趣。通话说结束时，他试图表现友善一点，说："我敢肯定我们公司什么地方有 Java，我回去问问看。"我从来在那家公司工作过，但作为业内人我太清楚了，那家公司大约 70% 的代码是 Java 写的，剩下的是 .NET，而且他们正在逐步淘汰 .NET。这人入将近一年了，却从来没想过要去问一句："顺便问一下，我们的软件是用什么语言写的？"对他来说，这似乎根本不重要。

Simon：现在有一种越来越普遍的现象，我们作为开发者，与实际编写的代码实现之间出现了巨大的脱节。因为我们对 AI 过度依赖或授权，让 AI 做了太多决策，把太多东西都外包出去了。很多知识实际上在 AI 那边，而我们却被抽象掉了。你认为这个问题有多严重？

Rod：我认为开发者需要掌握的一项核心技能，就是以这种新方式工作，同时保留那些真正重要的控制权。确实可以用 Vibe Coding 来做某些事情，比如某些类型的 UI 应用，它们本来就是一次性的，Agent 在这方面非常非常擅长。

但你无法用 Vibe Coding 来编写严肃的软件。

我是一个 Coding Agent 的积极用户，我可能最多只写 5% 的代码，也许更少，但我牢牢掌握着控制权。我发现，从设计的角度来看，Agent 出错的时候比正确的时候多。

我们仍然需要理解架构、清楚正在发生什么，而且不要过于信任。因为一旦你进入复杂的应用程序，如果你不保持那种架构上的监督，你很快就会陷入一团乱麻。你的 Agent 会愉快地添加新功能，但每添加一个新功能，设计就会退化，代码就会变得非常糟糕。

Simon：你提到你只写 5% 的代码，其余是 AI 生成的你这样做是有意为为之吗？是因为你不想写更多，因为你想对写出来的东西有更多控制权？

Rod：在开源项目里，我手写的比例更高一些，可能会更保守。但，在我们的一些内部应用中，AI 生成的比例接近 95%。要是你读那些代码，你会觉得那是我写的，设计风格非常清晰。我会坐在那里看 diff、看输出，然后经常停下来纠正它："不对，你把这个硬编码了，这里应该是一个策略，提炼出来。"

我相心这种模式有可能产生比纯手工或者纯靠 Coding Agent 更好的结果。我用 Coding Agent 写代码的速度比我手动快得多，而且质量也更好。但要是反过来，我把一切完全交给 Coding Agent，我深信质量会大幅下降，最终连速度也会下降。

4 Embabel 的核心：来自游戏 NPC 规划算法

Simon：我们来聊聊 Embabel 里面的核心组件"规划器（planner）"。这是一个叫 GOAP（Goal-Oriented Action Planning）的搜寻路径算法，最早是为游戏里的 NPC 设计的吧？关键点是，它是确定性的。而其他框架比如 LangChain、Crew.ai，则更多的是由 LLM 来决定下一步做什么、怎么规划。为什么你会从游戏 NPC 领域里挑出这个算法？

Rod：我最开始考虑的确实是最显而易见的方法——状态机（state machine）。平心而论，LangGraph 就是确定性的，你提前定义好状态机。所以我也一度用过那种办法。不过我们先退一步，聊聊为什么要做规划。

当然，你可以直接把一堆工具扔给模型，让一个 Agent 循环来全权处理一切，在某些场景下这确实合理。但对于自动化业务流程这类需要一致性和可预测性的场合，这远远不够，因为你根本不知道 LLM 会以什么顺序调用你给它的工具，也不知道它会传什么参数给那些工具。

所以我们的想法是，让用户把流程拆成多个步骤。这些步骤可能是调用一个或多个 LLM，也可能是纯代码步骤。在这一层面上，LangGraph、Crew.ai、Microsoft Semantic Kernel 做的都是类似的事——把大问题切分成小步骤。这也意味着，如果你在某一步中使用 LLM，可以为不同需求使用不同模型。比如你可以在自己的防火墙后面使用本地 LLM 来处理那些足够小、且高度敏感的任务，从而永远不让客户数据流出企业边界，这里面有大量好处。

但问题回到了：怎么规划这些步骤，怎么确定执行顺序？你可以用状态机，但我发现，当我在做类似 LangGraph 的东西时，修改状态机，比如增加更多状态和转换，非常麻烦，你必须重新连线来扩展它。其次，状态转换和每个动作状态所需的类型，通常都是正直交的，这会在类型系统上制造麻烦。

GOAP 规划方式有两个很不一样的点。第一，它是动态的，规划发生在运行时。第二，它与类型系统完全集成。我们允许用户创建自定义条件，但动作的排序通常由 Java 方法的参数类型和返回类型决定，这意味着一个动作永远不会再缺少所需参数时被调用。

GOAP 本质上是一个 A* 算法。我们识别出目标，然后查看从当前世界状态出发，哪些步骤可以通向目标。目标有前置条件，世界状态中必须满足某些条件。动作也有前置条件和它承诺的后置条件。前置条件是绝刚硬性的，除非条件被满足，否则你不能声明目标已达成，也不能调用某个动作；而后置条件则是动作承诺会产生副作用。

规划器从当前世界状态出发，找到一条通往目标的路径。它也可能告诉你"不存在可行动作路径"，这本身就是一个很有价值的信息。然后它执行第一个动作，再重新规划，在执行每个动作之后，查看世界状态，重新评估怎么到达目标。大多数情况下，快乐路径会照常运作，动作承诺的后置条件得到满足，规划器确认一下，然后迈进下一步。

Simon：这一切都是自动化的？

Rod：完全自动化。通常 Java 开发者不需要了解规划器的内部细节，他们只需要定义"动作方法"来提供输入，用注解标记 Java 方法，方法的参数和返回类型就给规划器提供了链式调用的信息。在某些情况下，你还可以定义自定义条件来进一步控制工作流。这意味着可能存在多条路径能达到同一个目标，而规划器可以选择成本最低的那条路径，因为你可以给每个动作分配成本。成本甚至是可以是动态的，如果某个动作需要调用一个负载很高的系统，你就可以将其反映为一个动态成本值，这样一来，规划器也就可能会自动选择另一条路线。

Simon：基于当前世界状态在运行时做动态决策，这非常有意义。另一个好处是，因为它是确定性的，当被问到"为什么会做出这个决定"时，你能提供非确定性规划器无法给出的诊断信息。

Rod：我们可以完整展示规划的整条路径，以及我们观察到的世界状态，是如何导致我们制定出那份计划的。规划器和整个 Embabel 会发出大量事件，你可以编写监听器来持久化这些信息，或者把它们用于审计日志。所以你完全可以解释它为什么做了某件事，并且确保它每次都做同样的事。

总结

Rod Johnson 回归一线带来的 Embabel，本质上是对企业 AI 应用的一次框架级思考。他选择从游戏 NPC 领域引入 GOAP 规划算法，为的是解决 LLM 在企业级自动化流程中的不确定性问题——让 AI Agent 的每一步决策都可追踪、可解释、可审计。

他的核心判断是：模型会越来越强，工具会越来越多地替开发者做选择，但框架作为人类理解和控制系统的最后一层，依然有其价值——只不过，它可能真的是最后一波由人类亲选的了。

对于企业而言，与其盲目追逐 AI，不如先在小事上拿到结果、建立起信任，再用合适的框架将人类判断与 AI 能力有机结合。这才是 Rod Johnson 二十多年经验给出的答案。

本文基于该播客访谈整理，经 InfoQ 编辑。