Spring 创始人回归一线创业Rod Johnson 又回到了一线。他是 Spring 的创造者曾经几乎重新定义了企业 Java 应用该怎么写。二十多年后他重新创业做了一个面向企业 AI Agent 的开源框架 Embabel试图把 LLM 放进真实的业务系统里让它不只是会调用工具而是能在可控、可解释、可审计的流程里工作。有意思的是这一次他做的仍然是框架但他对“框架”的未来并不乐观至少不再是过去那种乐观。在他看来模型还会继续变强工具也会越来越多地替开发者做选择。Embabel 会不会被更强的模型追上企业还需不需要这样一层 harness未来的框架到底是由开发者挑选还是由 AI 工具自动决定这些问题都绕不开他在访谈里说出的那句话这可能是最后一波由人类亲自选择的框架。 这句话放在别人嘴里可能只是又一次 AI 时代的夸张判断。但从 Spring 创始人口中说出来意味就不一样了。因为 Rod Johnson 亲手参与过框架时代的兴起也见过一个框架如何变成企业软件开发的基础设施。现在他回到战场却认为选择权正在转移开发者未必会消失但开发者亲自挑框架、搭技术栈、决定系统骨架的时代可能正在进入尾声。核心观点如果要用 TensorFlow 做模型训练、微调、某些数据处理和摄入当然会用 Python。但 GenAI 应用层赋能这件事更适合在应用原本的语言里完成如果应用是用 Java 写的那就在 Java 里完成。一旦进入复杂的应用程序若不保持架构上的监督很快就会陷入一团乱麻。Agent 会愉快地添加新功能但每添加一个新功能设计就会退化代码就会变得非常糟糕。开发者不应该花大量时间在编写代码上因为可以通过专注于独特增加价值的地方来获得更大的杠杆。每个开发者原则上都应该每隔一两年学一门新语言因为它真的会改变思维方式。这可能已经是“最后一代由人类主动选择的框架”了。以后越来越多的技术选型都会由工具替我们完成。对话职业选择与创业契机Simon 翻 Rod 的履历时发现他在创建 Spring 之前拥有一个关于 19 世纪巴黎钢琴音乐的博士学位。Rod 表示他的第一个学位是音乐和计算机科学双专业当时完全没办法决定往哪个方向走。后来他拿到了澳大利亚的研究奖学金去读音乐博士还在悉尼音乐学院教过两年音乐史。然而写代码的冲动一直没停过。90 年代中期他还写过共享软件真有人寄支票过来。后来他清醒地认识到要是继续待在音乐学术界大概一辈子都在悉尼买不起房。于是他做了一个决定这两件事里一个当爱好一个当职业——而他当时正好搞反了。不过接下来有十年他几乎没碰过钢琴因为职业生涯实在太忙了。Simon 认为这并非奇怪的弯路只是 Rod 很有创造力无论是写代码还是音乐他都很享受。Rod 称从 80 年代中期第一次写代码到现在他差不多从未中断过编程因为他就爱这件事。即便现在绝大部分代码是由 AI Coding Agent 替他写的他仍然能获得一模一样的兴奋感因为掌控权还在他手里他还在创造和塑造东西。哪怕不再亲手敲出每一行只要结果是相同的这对他而言同样令人满足。在 SpringSource 被收购后Rod 做了很多年董事会和投资的事情然后创办了 Embabel。他认为行业正处在一个巨大的转折点上。当 GPT - 3 和后来的 ChatGPT 突然变得真正实用、不再重复自己或陷入奇怪的死胡同时他立刻意识到怎么把这项技术真正用来解决企业问题是很难的问题。其实在这之前两年出于个人兴趣他已经写了不少 TensorFlow 代码和底层 AI 技术打了很多交道这自然而然地演化成了创建一个框架来帮助解决这些问题的想法。语言之争Java 与 Python现在很多团队被要求抛下 Java用 Python 重写一切。Rod 公开讲过这是错误的甚至说过“这是 Python 在 AI 领域主导的最后一年”。他认为要解决一个业务问题就必须考虑这个问题本身的“邻接性Adjacency”。大概率在和数据库、企业服务、现有代码库打交道同时还要处理一个新东西LLM。可 LLM 并不在 Python 进程里运行——宇宙毁灭之前Python 都没法自己执行推理。LLM 只是一个非常简单的 HTTP 调用所以他一直很困惑为什么人们会认为某门语言在发起一个极其简单的 HTTP 调用时会有天然优势。事实上大家已经开始逐渐意识到这一点了。OpenClaw 就不是用 Python 写的Peter Steinberger 用的是他偏爱的语言。对大量企业应用而言它们很明显是用 Java 写的关键的邻接性就在于已有业务逻辑、已有企业服务。那正确的做法很显然就是从 Java 栈里发起一个简单的 HTTP 调用。 Rod 认为人们产生这种混淆的根本原因是没有把“数据科学”和“企业 AI 应用”区分开它们是两件完全不同的事。在 Embabel 之前他写了大量 Python两年前他的 Python 甚至比 Java 流利得多。如果要用 TensorFlow 做模型训练、微调、某些数据处理和摄入当然会用 Python。但 GenAI 应用层赋能这件事更适合在应用原本的语言里完成如果应用是用 Java 写的那就在 Java 里完成。Embabel 核心几乎全部是用 Kotlin 写的但大多数示例是 Java。团队投入了大量精力来确保对 Java 用户来说它是完全无缝的。当 Rod 在核心框架上工作时他用 Kotlin当他在示例应用上工作时他用 Java。老实说Java 风格的 API 非常棒即使在 Kotlin 里使用这个框架时它和其他语言的体验也差不多。大概十三年前Rod 大量使用过 Scala。他很喜欢 Scala 这门语言但事实是它与 Java 的集成很痛苦。每次处理一个集合那都是折磨。而 Kotlin 的创造者在 Java 互操作性方面做得非常出色他们没有引入 Scala 曾有的那些问题破坏性变更、缺乏二进制兼容性等等。所以Rod 觉得 Kotlin 是一门非常好用的语言。 不过他也认为指出 Java 已经改进很多这件事很重要他觉得人们喜欢拿 Java 当稻草人来攻击很烦人。很多人在假装 Java 没有进化而 Java 实际上已经进化了很多。Coding Agent 与代码库问题Rod 认为当高层下达“AI 一切”的指令团队却在没有真正业务案例、没有确认 AI 是否合适的情况下盲目开展 AI 项目这是企业 AI 失败的最大问题。一个主要的反模式就是“我们必须用更多 AI”这种念头却从来不去问一句为什么要用用来干什么虽然他非常热爱并且着迷于 AI但如果能不用 LLM 就完成一件事那当然应该不用 LLM这样更便宜、更确定、更快。组织首先要做的是思考“我们怎么从这儿走到那儿去”。比如在澳大利亚的一个客户他们一开始识别出一类小问题网站上有某张特定表单客户填写完后需要人工审核才能继续。95% 的情况其实非常简单虽然用正则表达式处理起来稍微麻烦了点但本质上很简单。于是他们把这个摩擦点消除掉了在 95% 的场景里让客户即时推进不再需要等人工处理。Rod 觉得这是非常棒的起步案例先在小事上拿到结果慢慢建立起信任。对于“异构技术栈Alien Stack”问题它会在两个方向上造成伤害。第一技术上让一切都变难第二它往往还会把战略权交到错误的人手里——那些根本不懂核心业务、可能从来没见过任何核心业务应用的人却在主导战略。当要赋能这些应用的时候这条路完全走不通。去年 Rod 和一家澳大利亚大公司的首席 AI 架构师聊过他是一名 Python 开发者。他礼貌地听完了 Rod 的介绍却没什么兴趣。通话结束时他试图表现得友善一点说“我敢肯定我们公司什么地方有 Java我回去问问看。”Rod 从来没在那家公司工作过但作为业内人士他太清楚了那家公司大约 70% 的代码是 Java 写的剩下的是.NET而且他们正逐步淘汰.NET。这个人入职将近一年了却从来没想过要去问一句“顺便问一下我们的软件是用什么语言写的”对他来说这似乎根本不重要。现在开发者与实际编写的代码实现之间出现了巨大的脱节。因为对 AI 过度依赖或授权让 AI 做了太多决策把太多东西都外包出去了。很多知识实际上在 AI 那边而开发者却被抽象掉了。Rod 认为开发者需要掌握的一项核心技能就是以这种新方式工作同时保留那些真正重要的控制权。确实可以用 Vibe Coding 来做一些事情比如某些类型的 UI 应用它们本来就是一次性的Agent 在这方面非常非常擅长。但无法用 Vibe Coding 来编写严肃的软件。Rod 是一个 Coding Agent 的积极用户他可能最多只写 5% 的代码也许更少但他牢牢掌握着控制权。他发现从设计的角度来看Agent 出错的时候比正确的时候多。仍然需要理解架构、清楚正在发生什么、并且不要过于信任。因为一旦进入复杂的应用程序若不保持架构上的监督很快就会陷入一团乱麻。Agent 会愉快地添加新功能但每添加一个新功能设计就会退化代码就会变得非常糟糕。在开源项目里Rod 手写的比例更高一些可能会更保守。但在一些内部应用中AI 生成的比例接近 95%。要是读那些代码会觉得那是他写的设计风格非常清晰。他会坐在那里看 diff、看输出然后经常停下来纠正它“不对你把这个硬编码了这里应该是一个策略提取出来。” 他相信这种模式有可能产生比纯手工或者纯靠 Coding Agent 更好的结果。他用 Coding Agent 写代码的速度比手动快得多而且质量也更好。但如果反过来把一切完全丢给 Coding Agent他深信质量会大幅下降最终连速度也会降下来。Embabel 的核心规划器算法Embabel 里面的核心组件“规划器planner”是一个叫 GOAP Goal - Oriented - Action - plann的寻路算法最早是为游戏里的 NPC 设计的关键点是它是确定性的。而其他框架比如 LangChain、Crew.ai则更多是由 LLM 来决定下一步做什么、怎么规划。Rod 最开始考虑的是状态机state machine。平心而论LangGraph 就是确定性的提前定义好状态机。所以他也一度用过那种办法。不过要做规划直接把一堆工具扔给模型让一个 Agent 循环来全权处理一切在某些场景下这确实合理。但对于自动化业务流程这类需要一致性和可预测性的场合这远远不够因为压根不知道 LLM 会以什么顺序调用工具也不知道它会传什么参数给那些工具。想法是让用户把流程拆成多个步骤。这些步骤可能是调用一个或多个 LLM也可能是纯代码步骤。在这一层面上LangGraph、Crew.ai、Microsoft Semantic Kernel 做的都是类似的事——把大问题切分成小步骤。这也意味着若在某一步中使用 LLM可以为不同需求使用不同模型。比如可以在自己的防火墙后面使用本地 LLM 来处理那些足够小、且高度敏感的任务从而永远不让客户数据流出企业边界这里面有大量好处。但问题回到了怎么规划这些步骤怎么决定执行顺序用状态机的话修改状态机比如增加更多状态和转换非常麻烦必须重新连线来扩展它。其次状态转换和每个动作状态所需的类型通常都是正交的这会在类型系统上制造麻烦。GOAP 规划方式有两个很不一样的点。第一它是动态的规划发生在运行时。第二它与类型系统完全集成。允许用户创建自定义条件但动作的排序通常由 Java 方法的参数类型和返回类型决定这意味着一个动作永远不会在缺少所需参数时被调用。 GOAP 本质上是一个 A* 算法。识别出目标然后查看从当前世界状态出发哪些步骤可以通向目标。目标有前置条件世界状态中必须满足某些条件。动作也有前置条件和它承诺的后置条件。前置条件是绝对硬性的除非条件被满足否则不能声明目标已达成也不能调用某个动作而后置条件则是动作承诺会产生的副作用。规划器从当前世界状态出发找到一条通往目标的路径。它也可能告诉你“不存在可行动路径”这本身就是一个很有价值的信息。然后它执行第一个动作再重新规划在执行每个动作之后查看世界状态重新评估怎么到达目标。大多数情况下快乐路径会照常运作动作承诺的后置条件得到满足规划器确认一下然后迈进下一步。这一切都是自动化的。通常 Java 开发者不需要了解规划器的内部细节他们只需要定义“动作方法”来提供输入用注解标记 Java 方法方法的参数和返回类型就给规划器提供了链式调用的信息。在某些情况下还可以定义自定义条件来进一步控制工作流。这意味着可能存在多条路径能到达同一个目标而规划器可以选择成本最低的那条路径因为可以给每个动作分配成本。成本甚至可以是动态的如果某个动作需要调用一个负载很高的系统就可以将其反映为一个动态成本值这样一来规划器也许就会自动选择另一条路线。基于当前世界状态在运行时做动态决策这非常有意思。另一个好处是因为它是确定性的当被问到“为什么会做出这个决定”时能提供非确定性规划器无法给到的诊断信息。可以完整展示规划的整个路径以及观察到的世界状态是如何导致制定出那份计划的。规划器和整个 Embabel 会发出大量事件可以编写监听器来持久化这些信息或者把它们用于审计日志。所以完全可以解释它为什么做了某件事并且确保它每次都做同样的事。当然一旦进入动作步骤内部若调用了 LLM那部分就不会是完全确定性的但这也让能够“适度”地调用 LLM。如果像聊天机器人那样用长达三页纸的提示词和 30 个工具来工作永远不可能获得完全的可预测性。而如果用一段小提示词加上三个工具去完成一件事可预测性就会非常高。虽然不可能 100% 确定但会发现花在提示工程上的时间会大幅减少。所以整体上系统会变得可解释得多也确定和可预测得多。对 MCP 的怀疑态度每个人似乎都把 MCP 当作灵丹妙药好像它能解决 Agent 的所有问题。Rod 认为 MCP 在赋能整个生态系统方面发挥了极其重要的作用它确实是一个催化剂让更多的人了解到可以用工具实现什么。然而他出于几个原因对 MCP 持怀疑态度。首先如果在做“用 AI 赋能企业系统”这件事为什么要通过 MCP 来运行可以用 Embabel、Spring AI 或 LangChain4J任何框架都可以轻松地将一个 Java 方法暴露为工具。所以必须问一个问题如果做起来这么容易为什么还要多此一举特别是当可以在领域对象上暴露工具时先通过仓库调用检索到了正确的领域对象然后暴露这个对象上的方法这是 MCP 不那么容易做到的事。所以很多时候在暴露任何工具时第一个想法应该是“我能用我的技术栈直接暴露它。”“我为什么不直接暴露一个 Java 方法或 Python 函数呢”完全可以做到。其次MCP 的卖点是“一个专门为 Agent 设计的 API 规范”。但如果它是 API 规范已经有了 OpenAPI、Swagger、GraphQL为什么还需要一个新的MCP 的论点是“因为它是专门为 Agent 设计的”。但 Rod 最近开始得出一个结论对于一个特定 Agent 来说唯一完美适合的东西很可能就是这个 Agent 独有的。比如可以有一个 MCP 服务器去暴露服务但如果已经存在一个 OpenAPI 规范也可以连接到那个规范然后根据特定 Agent 循环的需求来塑造自己的工具。Rod 认为 MCP 对推动行业进步有巨大贡献但它不是那种一刀切的解决方案。在很多场景下直接使用现有的 API 规范更有意义而永远放在首位的方案应该是从当前的技术栈里直接暴露逻辑。AI 与模型的关系有人认为模型正在跑在基于模型构建出来的产品前面。现在在 Embabel 构建的是编排层。Rod 认为这是一个有意思的问题。当然从现在构建软件的情况看coding agent 的规划能力提升得比原本预期要明显得多。大概在去年 11 月底、12 月那段时间确实出现过一次非常剧烈的跃迁。他认为模型肯定在变得更好但也认为很多根本问题仍然存在。如果在自动化业务流程那么把规划从模型的控制之外移出来转而使用某种确定性方法他认为这仍然有价值。可解释性依然很重要。所以他确实认为即使模型继续进步模型之上的框架、agent harness、各种框架仍然非常重要。一个很好的例子是 Claude Code。当然Sonnet 4.6 比之前的模型强得多。但 Claude Code 本身也强得多。如果把今天的 Claude Code 和四五个月前的 Claude Code 相比它的工作方式已经完全不同而这种不同确实让它更有效。所以他其实并不认为模型变聪明和 harness 变聪明之间存在冲突。他认为需要在两个地方同时推进。他认为会看到一些模型“吃掉 harness”的场景也就是在那些是否确定并不那么重要的地方。可以直接给模型一堆工具即使它有点不可预测也没关系。所以他确实认为有一块空间里模型会需要更少的外围基础设施。但他认为那块空间与企业应用并没有特别大的关系。AI 的表现与局限今年一月Rod 提到他的 Claude Code 工作流程涉及很多设计对话和 Claude Code 来回讨论、长时间的规划然后才开始编码结果往往比手写更好。但 Claude 并不理解某些事情比如 companion objects。当用 Claude Code 构建 Embabel 而 Claude 不完全理解架构的某些部分时Rod 认为它工作得很好因为他完全理解架构并且经常纠正它。他确实想知道如果开发者越来越多地选择“不理解架构”那条简单的路会发生什么。他处于一个非常有利的位置他完全理解代码库中的架构他非常了解 Kotlin 这门语言团队构建在 Spring 之上他对 Spring 也很了解。他实际上非常了解技术栈的每一个部分这使他能够有效地掌控局面。他个人会非常担心那些不理解这些的人保持控制权非常重要。他认为开发者不应该花大量时间在编写代码上因为可以通过专注于独特增加价值的地方来获得更大的杠杆。AI 不经常给出让 Rod 惊讶的设计或架构建议但来回的讨论一直很有用它确实有很多次想到了 Rod 没想到的问题。比如在讨论一个提议的变更时它指出了 Rod 没想到的一点。它更擅长批评而不是提出原创想法。过去几天Rod 试图为一个内部产品构建一套相当复杂的测试基础设施在测试容器里用真实 LLM 进行测试伪造所有工具等等而 Claude Code 表现得非常糟糕。他认为原因之一是它以前没见过这种场景这可能是一种相当新的测试形式。 要让 Coding Agent 获得最大的自主性需要对测试非常执着。而他这次碰到的既是它见过的更极端的测试量而且某些类型的测试可能也是它以前没见过的。尽管有明确的指示它似乎还是出奇地挣扎。Rod 试过用 Skills 和 Claude.md 来配置 Coding Agent 的行为但有点不幸的是当上下文越变越大Coding Agent 就会开始忘东西。有个特别奇怪的现象它老是想在代码体里写全限定名可 Rod 非常讨厌这个他更喜欢用 import。他已经把这个偏好写进了 claude.md 配置文件里但大概有 50% 的时间它还是照忘不误。而且 Agent 做不到渐进式学习注意力就是会衰减。语言格局与选择Rod 曾经说 TypeScript 是当今最重要的语言因为它能让一个普通 JavaScript 开发者的水平翻倍。但他认为这得看应用的类型。如果从零开始写很多类型的应用很可能会用 TypeScript 去写服务端和 React。但企业级应用没多少是用 Node 写的也不应该用 Node 去写。在 JVM 上Java、Kotlin 会给一堆对这个类别的应用极有价值的东西。TypeScript 再漂亮在这件事上也帮不上什么忙。他认为第一现代 Java 肯定比他当初说那些话的时候好得多第二Kotlin 是一门值得认真考虑的出色语言。Kotlin 和 TypeScript 大概旗鼓相当他仍然会想念联合类型他可以长篇大论地论证密封层级绝对不如联合类型好但 Kotlin 同样有很多比 TypeScript 强的地方。TypeScript 的另一个问题是尽管他们做得非常好底层仍然有一层疯狂的东西偶尔就会撞见而且没法掩盖。而 Kotlin 是一门现代化语言它建立在更健壮、更可预测的基础之上。对于 AI 的进步是否会在五年内改变这些语言格局Rod 表示不知道自己的观点是什么他可以说服自己语言不重要也可以说服自己语言很重要。很多人想象训练语料库会让热门语言拥有天然优势然后这种优势会被固化下来这绝对不对。他使用 Coding Agent 的三种语言是 Java、Kotlin 和 Python而毫无悬念Coding Agent 做得最好的恰恰是 Kotlin这完全超乎预想。 Java 和 Python 都存在了很久而且最近几年进化得都很快。不应该写出 2019 年的 Java当然也不应该写出 2019 年的 Python。训练数据太多了实际上是在对抗它。Java 和 Python 仍然非常好但 Kotlin 更好这让他非常吃惊因为 Kotlin 的语料库并不大。Kotlin 本身也没怎么进化因为它从一开始就是一门现代语言。其次早期用 Kotlin 的大概率是技术非常娴熟的人因此没有那么多糟糕的 Kotlin 代码不像 Java 或 Python 那样。他不认为热门语言会因为训练数据就被固化。LLM 对任何它们见过足够多的东西都极其擅长而听说过的所有编程语言它们都见过很多。但这就引出了另一个问题既然如此干嘛不用完美的语言去写每一件事但这就像曾经看到过的微服务狂热——还有其他成本。现在会引入极为庞大的维护成本除非愿意完全信任机器但他不觉得该那样做他不认为那是个好主意。至少就目前而言选择语言和技术栈的根本性理由可能不会改变太多。因为当把它们投入生产、为它们背书的时候那些最根本的东西并没有变。开源项目的商业模式与发展Rod 认为开源项目背后的公司需要从第一天起就有商业模式Embabel 最可能的模式是开放核心。他认为开源的纯支持模式一直就非常困难有了 Coding Agent 之后还会难得多所以他觉得会存在比框架层面更上一层的产品。目前的思路是把框架作为一种竞争优势去构建可能甚至不针对软件开发者的产品而是针对更广泛的知识工作者。框架本身是 Apache 许可证和 Spring 一样。团队欢迎社区贡献有活跃的 Discord、GitHub 和问题跟踪器欢迎任何感兴趣的人来贡献和加入社区。Spring 前后经历了 VMware、Pivotal 再到如今 Broadcom 的收购。Rod 觉得在 2009 年底那笔首次收购发生时Spring 已经是一个庞然大物了它已经是事实上的标准。早期的采用率和围绕它建立的社区显然有着巨大的惯性。 但有帮助的一点是有相当多技术娴熟的开发者被全职雇来开发 Spring。这意味着那些不那么令人兴奋的事情也会有人去修因为这是某个人工作的一部分不管他们感不感兴趣。他仍然坚信开源确实能从背后的商业支持中受益。让 Spring 变得可靠的关键它非常健壮任何严重问题都会迅速被修复部分正反映了不依赖志愿者。社区贡献当然很棒但他认为背后的这种专业性至关重要它给出了那种完整产品式的开发方法。其他观点与建议Rod 认为 JVM 最被低估的是运行在它上面那些代码业务逻辑、领域模型对于理解关键业务有着难以估量的价值。他对 MCP 持有一种相对怀疑的态度。倒不是说他觉得 MCP 不好而是觉得现在大家已经把 MCP 当成了“万能锤子”于是看什么都像钉子。如果有 Java 开发者被老板命令“去学 Python因为 AI 要用 Python”Rod 会让他去读读自己的博客。他写了一系列文章用完全相同的任务来对比 Python 和 Java 的实现——文件处理、API 调用、数据管道。结果非常清楚Java 代码在性能、可读性和生态成熟度上完全不输 Python。可以直接把其中一篇文章甩给老板或者更好一点自己亲手写一段。很多时候会发现Java 的代码竞争力其实一点不差。如果是 Java 项目在线上生产环境跑着的项目Rod 肯定选 Embabel。否则就是在往系统里硬塞一个 “Alien Stack”。现在 Embabel 已经到 0.3.5 了离 API 稳定其实非常近。他会很惊讶如果从现在到 1.0 之间还有什么重大 breaking changes估计再过四到六周就会到 1.0。所以说实话他不觉得现在采用 Embabel 是什么高风险的事。反倒是如果有一个 Java 项目却要引入一整套完全不同的技术栈再让它去和现有 Java business logic 对接会觉得这风险大得多。等把这一大堆东西折腾完Embabel 可能都已经 1.0 了到时候只会特别懊恼“我当初到底为什么要这么搞。”启动一个全新的企业项目用 Kotlin 还是 Java取决于团队规模。如果团队少于 20 人会认真考虑 Kotlin。如果团队更大而且大家原本也不熟 Kotlin那可能还是会继续用 Java。关于 Java 转 Kotlin 的学习曲线Rod 表示不太确定。因为他接触 Kotlin 的时候其实已经写了很多别的语言尤其是 Python。他虽然也写过几个月 Java但后来又回到了 Kotlin。所以他并不是一个“纯 Java 背景”转过去的人。不过他可以明确地说Kotlin 绝对比 Scala 容易学Kotlin 本身其实是一门相当容易上手的语言。他觉得每个开发者原则上都应该每隔一两年学一门新语言因为它真的会改变思维方式。而且现在学习新语言的门槛已经低到前所未有LLM 可以极快地帮助掌握任何语言所以整体门槛其实已经被大幅降低了比如他从来没读过 Kotlin 的教程书。对于让 LLM 去批判代码有时候相比让它“直接生成”这种方式反而更值。尤其是在学习新语言的时候让 LLM 给解释“这里为什么这么写”“背后的机制是什么”很多时候比直接说“帮我生成一段代码”更有效。否则最后只能对着生成结果猜“它为什么要这么写”对于有经验的开发者来说更是这样。学新语言的时候经常会问 LLM“这个语言里有没有某个特性的等价实现”比如会问Python 里有没有类似 TypeScript type guard 的东西如果本身已经理解这些概念那 LLM 特别擅长帮把这些概念映射到另一门语言上。Rod 每天都会用、最喜欢的 AI 工具除了 Claude Code 之外大概率还是 Claude Desktop。主要是它能让他同时调用一堆工具做 competitive research很多事情都会用它来处理。关于 SpringRod 觉得有个挺小、但挺有趣的点。当年他一直想给 Spring retrofit 一套“基于事件的 logging 机制”但那个时候已经太晚了架构上不好再改。但在 Embabel 里一开始就这么设计了。这样做的好处是所有 event 都是完整的。可以通过 SSH stream 出去可以监听可以订阅。而且更有意思的是甚至可以修改“logging personality”比如让日志全都用尤达大师的语气输出。 某种程度上Embabel 的整体风格其实是建立在现代 Spring 的经验之上只是加了一些在 Kotlin 里更容易实现的东西。比如基本不怎么用 builder pattern因为 Kotlin 可以把这些东西写得更优雅哪怕最后还是给 Java 用户使用也一样。Rod 完全不知道五年后 Embabel 是否还会存在。五年后人们还会亲手写应用吗还是他们违背了他的建议让机器完全接管了一切他甚至会说这可能已经是“最后一代由人类主动选择的框架”了。以后越来越多的技术选型都会由工具替我们完成。但说实话正处在一个几乎独一无二的时代。别说五年一两年后的预测都可能是错的。
Spring 创始人 Rod Johnson 回归一线创业，Embabel 或引领企业 AI Agent 框架新潮流？
Spring 创始人回归一线创业Rod Johnson 又回到了一线。他是 Spring 的创造者曾经几乎重新定义了企业 Java 应用该怎么写。二十多年后他重新创业做了一个面向企业 AI Agent 的开源框架 Embabel试图把 LLM 放进真实的业务系统里让它不只是会调用工具而是能在可控、可解释、可审计的流程里工作。有意思的是这一次他做的仍然是框架但他对“框架”的未来并不乐观至少不再是过去那种乐观。在他看来模型还会继续变强工具也会越来越多地替开发者做选择。Embabel 会不会被更强的模型追上企业还需不需要这样一层 harness未来的框架到底是由开发者挑选还是由 AI 工具自动决定这些问题都绕不开他在访谈里说出的那句话这可能是最后一波由人类亲自选择的框架。 这句话放在别人嘴里可能只是又一次 AI 时代的夸张判断。但从 Spring 创始人口中说出来意味就不一样了。因为 Rod Johnson 亲手参与过框架时代的兴起也见过一个框架如何变成企业软件开发的基础设施。现在他回到战场却认为选择权正在转移开发者未必会消失但开发者亲自挑框架、搭技术栈、决定系统骨架的时代可能正在进入尾声。核心观点如果要用 TensorFlow 做模型训练、微调、某些数据处理和摄入当然会用 Python。但 GenAI 应用层赋能这件事更适合在应用原本的语言里完成如果应用是用 Java 写的那就在 Java 里完成。一旦进入复杂的应用程序若不保持架构上的监督很快就会陷入一团乱麻。Agent 会愉快地添加新功能但每添加一个新功能设计就会退化代码就会变得非常糟糕。开发者不应该花大量时间在编写代码上因为可以通过专注于独特增加价值的地方来获得更大的杠杆。每个开发者原则上都应该每隔一两年学一门新语言因为它真的会改变思维方式。这可能已经是“最后一代由人类主动选择的框架”了。以后越来越多的技术选型都会由工具替我们完成。对话职业选择与创业契机Simon 翻 Rod 的履历时发现他在创建 Spring 之前拥有一个关于 19 世纪巴黎钢琴音乐的博士学位。Rod 表示他的第一个学位是音乐和计算机科学双专业当时完全没办法决定往哪个方向走。后来他拿到了澳大利亚的研究奖学金去读音乐博士还在悉尼音乐学院教过两年音乐史。然而写代码的冲动一直没停过。90 年代中期他还写过共享软件真有人寄支票过来。后来他清醒地认识到要是继续待在音乐学术界大概一辈子都在悉尼买不起房。于是他做了一个决定这两件事里一个当爱好一个当职业——而他当时正好搞反了。不过接下来有十年他几乎没碰过钢琴因为职业生涯实在太忙了。Simon 认为这并非奇怪的弯路只是 Rod 很有创造力无论是写代码还是音乐他都很享受。Rod 称从 80 年代中期第一次写代码到现在他差不多从未中断过编程因为他就爱这件事。即便现在绝大部分代码是由 AI Coding Agent 替他写的他仍然能获得一模一样的兴奋感因为掌控权还在他手里他还在创造和塑造东西。哪怕不再亲手敲出每一行只要结果是相同的这对他而言同样令人满足。在 SpringSource 被收购后Rod 做了很多年董事会和投资的事情然后创办了 Embabel。他认为行业正处在一个巨大的转折点上。当 GPT - 3 和后来的 ChatGPT 突然变得真正实用、不再重复自己或陷入奇怪的死胡同时他立刻意识到怎么把这项技术真正用来解决企业问题是很难的问题。其实在这之前两年出于个人兴趣他已经写了不少 TensorFlow 代码和底层 AI 技术打了很多交道这自然而然地演化成了创建一个框架来帮助解决这些问题的想法。语言之争Java 与 Python现在很多团队被要求抛下 Java用 Python 重写一切。Rod 公开讲过这是错误的甚至说过“这是 Python 在 AI 领域主导的最后一年”。他认为要解决一个业务问题就必须考虑这个问题本身的“邻接性Adjacency”。大概率在和数据库、企业服务、现有代码库打交道同时还要处理一个新东西LLM。可 LLM 并不在 Python 进程里运行——宇宙毁灭之前Python 都没法自己执行推理。LLM 只是一个非常简单的 HTTP 调用所以他一直很困惑为什么人们会认为某门语言在发起一个极其简单的 HTTP 调用时会有天然优势。事实上大家已经开始逐渐意识到这一点了。OpenClaw 就不是用 Python 写的Peter Steinberger 用的是他偏爱的语言。对大量企业应用而言它们很明显是用 Java 写的关键的邻接性就在于已有业务逻辑、已有企业服务。那正确的做法很显然就是从 Java 栈里发起一个简单的 HTTP 调用。 Rod 认为人们产生这种混淆的根本原因是没有把“数据科学”和“企业 AI 应用”区分开它们是两件完全不同的事。在 Embabel 之前他写了大量 Python两年前他的 Python 甚至比 Java 流利得多。如果要用 TensorFlow 做模型训练、微调、某些数据处理和摄入当然会用 Python。但 GenAI 应用层赋能这件事更适合在应用原本的语言里完成如果应用是用 Java 写的那就在 Java 里完成。Embabel 核心几乎全部是用 Kotlin 写的但大多数示例是 Java。团队投入了大量精力来确保对 Java 用户来说它是完全无缝的。当 Rod 在核心框架上工作时他用 Kotlin当他在示例应用上工作时他用 Java。老实说Java 风格的 API 非常棒即使在 Kotlin 里使用这个框架时它和其他语言的体验也差不多。大概十三年前Rod 大量使用过 Scala。他很喜欢 Scala 这门语言但事实是它与 Java 的集成很痛苦。每次处理一个集合那都是折磨。而 Kotlin 的创造者在 Java 互操作性方面做得非常出色他们没有引入 Scala 曾有的那些问题破坏性变更、缺乏二进制兼容性等等。所以Rod 觉得 Kotlin 是一门非常好用的语言。 不过他也认为指出 Java 已经改进很多这件事很重要他觉得人们喜欢拿 Java 当稻草人来攻击很烦人。很多人在假装 Java 没有进化而 Java 实际上已经进化了很多。Coding Agent 与代码库问题Rod 认为当高层下达“AI 一切”的指令团队却在没有真正业务案例、没有确认 AI 是否合适的情况下盲目开展 AI 项目这是企业 AI 失败的最大问题。一个主要的反模式就是“我们必须用更多 AI”这种念头却从来不去问一句为什么要用用来干什么虽然他非常热爱并且着迷于 AI但如果能不用 LLM 就完成一件事那当然应该不用 LLM这样更便宜、更确定、更快。组织首先要做的是思考“我们怎么从这儿走到那儿去”。比如在澳大利亚的一个客户他们一开始识别出一类小问题网站上有某张特定表单客户填写完后需要人工审核才能继续。95% 的情况其实非常简单虽然用正则表达式处理起来稍微麻烦了点但本质上很简单。于是他们把这个摩擦点消除掉了在 95% 的场景里让客户即时推进不再需要等人工处理。Rod 觉得这是非常棒的起步案例先在小事上拿到结果慢慢建立起信任。对于“异构技术栈Alien Stack”问题它会在两个方向上造成伤害。第一技术上让一切都变难第二它往往还会把战略权交到错误的人手里——那些根本不懂核心业务、可能从来没见过任何核心业务应用的人却在主导战略。当要赋能这些应用的时候这条路完全走不通。去年 Rod 和一家澳大利亚大公司的首席 AI 架构师聊过他是一名 Python 开发者。他礼貌地听完了 Rod 的介绍却没什么兴趣。通话结束时他试图表现得友善一点说“我敢肯定我们公司什么地方有 Java我回去问问看。”Rod 从来没在那家公司工作过但作为业内人士他太清楚了那家公司大约 70% 的代码是 Java 写的剩下的是.NET而且他们正逐步淘汰.NET。这个人入职将近一年了却从来没想过要去问一句“顺便问一下我们的软件是用什么语言写的”对他来说这似乎根本不重要。现在开发者与实际编写的代码实现之间出现了巨大的脱节。因为对 AI 过度依赖或授权让 AI 做了太多决策把太多东西都外包出去了。很多知识实际上在 AI 那边而开发者却被抽象掉了。Rod 认为开发者需要掌握的一项核心技能就是以这种新方式工作同时保留那些真正重要的控制权。确实可以用 Vibe Coding 来做一些事情比如某些类型的 UI 应用它们本来就是一次性的Agent 在这方面非常非常擅长。但无法用 Vibe Coding 来编写严肃的软件。Rod 是一个 Coding Agent 的积极用户他可能最多只写 5% 的代码也许更少但他牢牢掌握着控制权。他发现从设计的角度来看Agent 出错的时候比正确的时候多。仍然需要理解架构、清楚正在发生什么、并且不要过于信任。因为一旦进入复杂的应用程序若不保持架构上的监督很快就会陷入一团乱麻。Agent 会愉快地添加新功能但每添加一个新功能设计就会退化代码就会变得非常糟糕。在开源项目里Rod 手写的比例更高一些可能会更保守。但在一些内部应用中AI 生成的比例接近 95%。要是读那些代码会觉得那是他写的设计风格非常清晰。他会坐在那里看 diff、看输出然后经常停下来纠正它“不对你把这个硬编码了这里应该是一个策略提取出来。” 他相信这种模式有可能产生比纯手工或者纯靠 Coding Agent 更好的结果。他用 Coding Agent 写代码的速度比手动快得多而且质量也更好。但如果反过来把一切完全丢给 Coding Agent他深信质量会大幅下降最终连速度也会降下来。Embabel 的核心规划器算法Embabel 里面的核心组件“规划器planner”是一个叫 GOAP Goal - Oriented - Action - plann的寻路算法最早是为游戏里的 NPC 设计的关键点是它是确定性的。而其他框架比如 LangChain、Crew.ai则更多是由 LLM 来决定下一步做什么、怎么规划。Rod 最开始考虑的是状态机state machine。平心而论LangGraph 就是确定性的提前定义好状态机。所以他也一度用过那种办法。不过要做规划直接把一堆工具扔给模型让一个 Agent 循环来全权处理一切在某些场景下这确实合理。但对于自动化业务流程这类需要一致性和可预测性的场合这远远不够因为压根不知道 LLM 会以什么顺序调用工具也不知道它会传什么参数给那些工具。想法是让用户把流程拆成多个步骤。这些步骤可能是调用一个或多个 LLM也可能是纯代码步骤。在这一层面上LangGraph、Crew.ai、Microsoft Semantic Kernel 做的都是类似的事——把大问题切分成小步骤。这也意味着若在某一步中使用 LLM可以为不同需求使用不同模型。比如可以在自己的防火墙后面使用本地 LLM 来处理那些足够小、且高度敏感的任务从而永远不让客户数据流出企业边界这里面有大量好处。但问题回到了怎么规划这些步骤怎么决定执行顺序用状态机的话修改状态机比如增加更多状态和转换非常麻烦必须重新连线来扩展它。其次状态转换和每个动作状态所需的类型通常都是正交的这会在类型系统上制造麻烦。GOAP 规划方式有两个很不一样的点。第一它是动态的规划发生在运行时。第二它与类型系统完全集成。允许用户创建自定义条件但动作的排序通常由 Java 方法的参数类型和返回类型决定这意味着一个动作永远不会在缺少所需参数时被调用。 GOAP 本质上是一个 A* 算法。识别出目标然后查看从当前世界状态出发哪些步骤可以通向目标。目标有前置条件世界状态中必须满足某些条件。动作也有前置条件和它承诺的后置条件。前置条件是绝对硬性的除非条件被满足否则不能声明目标已达成也不能调用某个动作而后置条件则是动作承诺会产生的副作用。规划器从当前世界状态出发找到一条通往目标的路径。它也可能告诉你“不存在可行动路径”这本身就是一个很有价值的信息。然后它执行第一个动作再重新规划在执行每个动作之后查看世界状态重新评估怎么到达目标。大多数情况下快乐路径会照常运作动作承诺的后置条件得到满足规划器确认一下然后迈进下一步。这一切都是自动化的。通常 Java 开发者不需要了解规划器的内部细节他们只需要定义“动作方法”来提供输入用注解标记 Java 方法方法的参数和返回类型就给规划器提供了链式调用的信息。在某些情况下还可以定义自定义条件来进一步控制工作流。这意味着可能存在多条路径能到达同一个目标而规划器可以选择成本最低的那条路径因为可以给每个动作分配成本。成本甚至可以是动态的如果某个动作需要调用一个负载很高的系统就可以将其反映为一个动态成本值这样一来规划器也许就会自动选择另一条路线。基于当前世界状态在运行时做动态决策这非常有意思。另一个好处是因为它是确定性的当被问到“为什么会做出这个决定”时能提供非确定性规划器无法给到的诊断信息。可以完整展示规划的整个路径以及观察到的世界状态是如何导致制定出那份计划的。规划器和整个 Embabel 会发出大量事件可以编写监听器来持久化这些信息或者把它们用于审计日志。所以完全可以解释它为什么做了某件事并且确保它每次都做同样的事。当然一旦进入动作步骤内部若调用了 LLM那部分就不会是完全确定性的但这也让能够“适度”地调用 LLM。如果像聊天机器人那样用长达三页纸的提示词和 30 个工具来工作永远不可能获得完全的可预测性。而如果用一段小提示词加上三个工具去完成一件事可预测性就会非常高。虽然不可能 100% 确定但会发现花在提示工程上的时间会大幅减少。所以整体上系统会变得可解释得多也确定和可预测得多。对 MCP 的怀疑态度每个人似乎都把 MCP 当作灵丹妙药好像它能解决 Agent 的所有问题。Rod 认为 MCP 在赋能整个生态系统方面发挥了极其重要的作用它确实是一个催化剂让更多的人了解到可以用工具实现什么。然而他出于几个原因对 MCP 持怀疑态度。首先如果在做“用 AI 赋能企业系统”这件事为什么要通过 MCP 来运行可以用 Embabel、Spring AI 或 LangChain4J任何框架都可以轻松地将一个 Java 方法暴露为工具。所以必须问一个问题如果做起来这么容易为什么还要多此一举特别是当可以在领域对象上暴露工具时先通过仓库调用检索到了正确的领域对象然后暴露这个对象上的方法这是 MCP 不那么容易做到的事。所以很多时候在暴露任何工具时第一个想法应该是“我能用我的技术栈直接暴露它。”“我为什么不直接暴露一个 Java 方法或 Python 函数呢”完全可以做到。其次MCP 的卖点是“一个专门为 Agent 设计的 API 规范”。但如果它是 API 规范已经有了 OpenAPI、Swagger、GraphQL为什么还需要一个新的MCP 的论点是“因为它是专门为 Agent 设计的”。但 Rod 最近开始得出一个结论对于一个特定 Agent 来说唯一完美适合的东西很可能就是这个 Agent 独有的。比如可以有一个 MCP 服务器去暴露服务但如果已经存在一个 OpenAPI 规范也可以连接到那个规范然后根据特定 Agent 循环的需求来塑造自己的工具。Rod 认为 MCP 对推动行业进步有巨大贡献但它不是那种一刀切的解决方案。在很多场景下直接使用现有的 API 规范更有意义而永远放在首位的方案应该是从当前的技术栈里直接暴露逻辑。AI 与模型的关系有人认为模型正在跑在基于模型构建出来的产品前面。现在在 Embabel 构建的是编排层。Rod 认为这是一个有意思的问题。当然从现在构建软件的情况看coding agent 的规划能力提升得比原本预期要明显得多。大概在去年 11 月底、12 月那段时间确实出现过一次非常剧烈的跃迁。他认为模型肯定在变得更好但也认为很多根本问题仍然存在。如果在自动化业务流程那么把规划从模型的控制之外移出来转而使用某种确定性方法他认为这仍然有价值。可解释性依然很重要。所以他确实认为即使模型继续进步模型之上的框架、agent harness、各种框架仍然非常重要。一个很好的例子是 Claude Code。当然Sonnet 4.6 比之前的模型强得多。但 Claude Code 本身也强得多。如果把今天的 Claude Code 和四五个月前的 Claude Code 相比它的工作方式已经完全不同而这种不同确实让它更有效。所以他其实并不认为模型变聪明和 harness 变聪明之间存在冲突。他认为需要在两个地方同时推进。他认为会看到一些模型“吃掉 harness”的场景也就是在那些是否确定并不那么重要的地方。可以直接给模型一堆工具即使它有点不可预测也没关系。所以他确实认为有一块空间里模型会需要更少的外围基础设施。但他认为那块空间与企业应用并没有特别大的关系。AI 的表现与局限今年一月Rod 提到他的 Claude Code 工作流程涉及很多设计对话和 Claude Code 来回讨论、长时间的规划然后才开始编码结果往往比手写更好。但 Claude 并不理解某些事情比如 companion objects。当用 Claude Code 构建 Embabel 而 Claude 不完全理解架构的某些部分时Rod 认为它工作得很好因为他完全理解架构并且经常纠正它。他确实想知道如果开发者越来越多地选择“不理解架构”那条简单的路会发生什么。他处于一个非常有利的位置他完全理解代码库中的架构他非常了解 Kotlin 这门语言团队构建在 Spring 之上他对 Spring 也很了解。他实际上非常了解技术栈的每一个部分这使他能够有效地掌控局面。他个人会非常担心那些不理解这些的人保持控制权非常重要。他认为开发者不应该花大量时间在编写代码上因为可以通过专注于独特增加价值的地方来获得更大的杠杆。AI 不经常给出让 Rod 惊讶的设计或架构建议但来回的讨论一直很有用它确实有很多次想到了 Rod 没想到的问题。比如在讨论一个提议的变更时它指出了 Rod 没想到的一点。它更擅长批评而不是提出原创想法。过去几天Rod 试图为一个内部产品构建一套相当复杂的测试基础设施在测试容器里用真实 LLM 进行测试伪造所有工具等等而 Claude Code 表现得非常糟糕。他认为原因之一是它以前没见过这种场景这可能是一种相当新的测试形式。 要让 Coding Agent 获得最大的自主性需要对测试非常执着。而他这次碰到的既是它见过的更极端的测试量而且某些类型的测试可能也是它以前没见过的。尽管有明确的指示它似乎还是出奇地挣扎。Rod 试过用 Skills 和 Claude.md 来配置 Coding Agent 的行为但有点不幸的是当上下文越变越大Coding Agent 就会开始忘东西。有个特别奇怪的现象它老是想在代码体里写全限定名可 Rod 非常讨厌这个他更喜欢用 import。他已经把这个偏好写进了 claude.md 配置文件里但大概有 50% 的时间它还是照忘不误。而且 Agent 做不到渐进式学习注意力就是会衰减。语言格局与选择Rod 曾经说 TypeScript 是当今最重要的语言因为它能让一个普通 JavaScript 开发者的水平翻倍。但他认为这得看应用的类型。如果从零开始写很多类型的应用很可能会用 TypeScript 去写服务端和 React。但企业级应用没多少是用 Node 写的也不应该用 Node 去写。在 JVM 上Java、Kotlin 会给一堆对这个类别的应用极有价值的东西。TypeScript 再漂亮在这件事上也帮不上什么忙。他认为第一现代 Java 肯定比他当初说那些话的时候好得多第二Kotlin 是一门值得认真考虑的出色语言。Kotlin 和 TypeScript 大概旗鼓相当他仍然会想念联合类型他可以长篇大论地论证密封层级绝对不如联合类型好但 Kotlin 同样有很多比 TypeScript 强的地方。TypeScript 的另一个问题是尽管他们做得非常好底层仍然有一层疯狂的东西偶尔就会撞见而且没法掩盖。而 Kotlin 是一门现代化语言它建立在更健壮、更可预测的基础之上。对于 AI 的进步是否会在五年内改变这些语言格局Rod 表示不知道自己的观点是什么他可以说服自己语言不重要也可以说服自己语言很重要。很多人想象训练语料库会让热门语言拥有天然优势然后这种优势会被固化下来这绝对不对。他使用 Coding Agent 的三种语言是 Java、Kotlin 和 Python而毫无悬念Coding Agent 做得最好的恰恰是 Kotlin这完全超乎预想。 Java 和 Python 都存在了很久而且最近几年进化得都很快。不应该写出 2019 年的 Java当然也不应该写出 2019 年的 Python。训练数据太多了实际上是在对抗它。Java 和 Python 仍然非常好但 Kotlin 更好这让他非常吃惊因为 Kotlin 的语料库并不大。Kotlin 本身也没怎么进化因为它从一开始就是一门现代语言。其次早期用 Kotlin 的大概率是技术非常娴熟的人因此没有那么多糟糕的 Kotlin 代码不像 Java 或 Python 那样。他不认为热门语言会因为训练数据就被固化。LLM 对任何它们见过足够多的东西都极其擅长而听说过的所有编程语言它们都见过很多。但这就引出了另一个问题既然如此干嘛不用完美的语言去写每一件事但这就像曾经看到过的微服务狂热——还有其他成本。现在会引入极为庞大的维护成本除非愿意完全信任机器但他不觉得该那样做他不认为那是个好主意。至少就目前而言选择语言和技术栈的根本性理由可能不会改变太多。因为当把它们投入生产、为它们背书的时候那些最根本的东西并没有变。开源项目的商业模式与发展Rod 认为开源项目背后的公司需要从第一天起就有商业模式Embabel 最可能的模式是开放核心。他认为开源的纯支持模式一直就非常困难有了 Coding Agent 之后还会难得多所以他觉得会存在比框架层面更上一层的产品。目前的思路是把框架作为一种竞争优势去构建可能甚至不针对软件开发者的产品而是针对更广泛的知识工作者。框架本身是 Apache 许可证和 Spring 一样。团队欢迎社区贡献有活跃的 Discord、GitHub 和问题跟踪器欢迎任何感兴趣的人来贡献和加入社区。Spring 前后经历了 VMware、Pivotal 再到如今 Broadcom 的收购。Rod 觉得在 2009 年底那笔首次收购发生时Spring 已经是一个庞然大物了它已经是事实上的标准。早期的采用率和围绕它建立的社区显然有着巨大的惯性。 但有帮助的一点是有相当多技术娴熟的开发者被全职雇来开发 Spring。这意味着那些不那么令人兴奋的事情也会有人去修因为这是某个人工作的一部分不管他们感不感兴趣。他仍然坚信开源确实能从背后的商业支持中受益。让 Spring 变得可靠的关键它非常健壮任何严重问题都会迅速被修复部分正反映了不依赖志愿者。社区贡献当然很棒但他认为背后的这种专业性至关重要它给出了那种完整产品式的开发方法。其他观点与建议Rod 认为 JVM 最被低估的是运行在它上面那些代码业务逻辑、领域模型对于理解关键业务有着难以估量的价值。他对 MCP 持有一种相对怀疑的态度。倒不是说他觉得 MCP 不好而是觉得现在大家已经把 MCP 当成了“万能锤子”于是看什么都像钉子。如果有 Java 开发者被老板命令“去学 Python因为 AI 要用 Python”Rod 会让他去读读自己的博客。他写了一系列文章用完全相同的任务来对比 Python 和 Java 的实现——文件处理、API 调用、数据管道。结果非常清楚Java 代码在性能、可读性和生态成熟度上完全不输 Python。可以直接把其中一篇文章甩给老板或者更好一点自己亲手写一段。很多时候会发现Java 的代码竞争力其实一点不差。如果是 Java 项目在线上生产环境跑着的项目Rod 肯定选 Embabel。否则就是在往系统里硬塞一个 “Alien Stack”。现在 Embabel 已经到 0.3.5 了离 API 稳定其实非常近。他会很惊讶如果从现在到 1.0 之间还有什么重大 breaking changes估计再过四到六周就会到 1.0。所以说实话他不觉得现在采用 Embabel 是什么高风险的事。反倒是如果有一个 Java 项目却要引入一整套完全不同的技术栈再让它去和现有 Java business logic 对接会觉得这风险大得多。等把这一大堆东西折腾完Embabel 可能都已经 1.0 了到时候只会特别懊恼“我当初到底为什么要这么搞。”启动一个全新的企业项目用 Kotlin 还是 Java取决于团队规模。如果团队少于 20 人会认真考虑 Kotlin。如果团队更大而且大家原本也不熟 Kotlin那可能还是会继续用 Java。关于 Java 转 Kotlin 的学习曲线Rod 表示不太确定。因为他接触 Kotlin 的时候其实已经写了很多别的语言尤其是 Python。他虽然也写过几个月 Java但后来又回到了 Kotlin。所以他并不是一个“纯 Java 背景”转过去的人。不过他可以明确地说Kotlin 绝对比 Scala 容易学Kotlin 本身其实是一门相当容易上手的语言。他觉得每个开发者原则上都应该每隔一两年学一门新语言因为它真的会改变思维方式。而且现在学习新语言的门槛已经低到前所未有LLM 可以极快地帮助掌握任何语言所以整体门槛其实已经被大幅降低了比如他从来没读过 Kotlin 的教程书。对于让 LLM 去批判代码有时候相比让它“直接生成”这种方式反而更值。尤其是在学习新语言的时候让 LLM 给解释“这里为什么这么写”“背后的机制是什么”很多时候比直接说“帮我生成一段代码”更有效。否则最后只能对着生成结果猜“它为什么要这么写”对于有经验的开发者来说更是这样。学新语言的时候经常会问 LLM“这个语言里有没有某个特性的等价实现”比如会问Python 里有没有类似 TypeScript type guard 的东西如果本身已经理解这些概念那 LLM 特别擅长帮把这些概念映射到另一门语言上。Rod 每天都会用、最喜欢的 AI 工具除了 Claude Code 之外大概率还是 Claude Desktop。主要是它能让他同时调用一堆工具做 competitive research很多事情都会用它来处理。关于 SpringRod 觉得有个挺小、但挺有趣的点。当年他一直想给 Spring retrofit 一套“基于事件的 logging 机制”但那个时候已经太晚了架构上不好再改。但在 Embabel 里一开始就这么设计了。这样做的好处是所有 event 都是完整的。可以通过 SSH stream 出去可以监听可以订阅。而且更有意思的是甚至可以修改“logging personality”比如让日志全都用尤达大师的语气输出。 某种程度上Embabel 的整体风格其实是建立在现代 Spring 的经验之上只是加了一些在 Kotlin 里更容易实现的东西。比如基本不怎么用 builder pattern因为 Kotlin 可以把这些东西写得更优雅哪怕最后还是给 Java 用户使用也一样。Rod 完全不知道五年后 Embabel 是否还会存在。五年后人们还会亲手写应用吗还是他们违背了他的建议让机器完全接管了一切他甚至会说这可能已经是“最后一代由人类主动选择的框架”了。以后越来越多的技术选型都会由工具替我们完成。但说实话正处在一个几乎独一无二的时代。别说五年一两年后的预测都可能是错的。
