Spring 之父再创业：企业 Agent 别让 LLM 拍脑袋

这是什么

23 年前 Rod Johnson 写了本关于 J2EE 的书，随后开源 Spring，把企业 Java 从 EJB 泥潭里捞出来。现在他带着新框架 Embabel 回归，赌一件更狠的事：企业 Agent 不该让 LLM 决定下一步。

Embabel 不是新模型，也不替代 Spring AI。它是 Spring AI 之上的编排层——一个管接模型和向量库，一个管动作顺序和流程可控。

最反直觉的设计：不让 LLM 决定动作序列。它借用了游戏 AI 里的 GOAP（Goal-Oriented Action Planning）算法——2005 年 F.E.A.R. 给 NPC 决策用的就是它。开发者声明目标和动作，规划器用确定性算法算出动作序列；LLM 只在每个动作内部干活。Rod Johnson 原话：相同起点和目标，每次都生成同样的计划，不像 LLM 让你根本没法解释。

框架 95% 用 Kotlin 写，Java 开发者写业务时不用碰 .kt 文件。

行业怎么看

支持方看到的是企业 Agent 的真实痛点：主流框架（LangChain、AutoGen 等）Demo 漂亮，一上生产就露馅——动作靠 LLM 幻觉编排、流程不可解释、出错无法回溯。金融、电信、政务容不得 10% 随机性。Rod Johnson 自评这是「创立 Spring 以来最确信的项目」，分量不轻。Spring 在企业 Java 生态二十多年的积累，也让老用户迁移成本变低。

反对意见同样值得听：AI Agent 主战场在 Python，Embabel 想从 Python 嘴里抢市场不容易；框架刚发布，没有生产验证；「确定性规划」本身有代价——它牺牲了 LLM Agent 的灵活性和自主探索能力；Rod Johnson 自 2017 年从 Pivotal 淡出，对一线 Java 社区的实际影响力还要打问号。

对普通人的影响

对企业 IT：银行、保险、电信等 Java 技术栈深厚的传统行业，多了一条相对可控的 Agent 落地路径。但框架刚出，从评估到生产至少要走两三年，存量系统不会一夜替换。

对个人职场：Java 工程师在 AI 浪潮里没被甩下车，多了一个值得跟进的方向。但纯 Java 不碰 Python 的人，长期看仍需补课——大量前沿创新仍在 Python 生态。

对消费市场：短期内看不到直接影响。Embabel 做出来的东西会以企业服务形式渗透到 C 端（银行客服、保险理赔、政务热线会更稳定），但我们日常用的消费级 AI 产品，仍由 Python 阵营主导。