ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

Spring之父Rod Johnson携Embabel归来:Java程序员的Agent时代正式开启

2026/9/10 23:51:13 拓冰建站 浏览量
Spring之父Rod Johnson携Embabel归来:Java程序员的Agent时代正式开启 title: Spring之父Rod Johnson携Embabel归来Java程序员的Agent时代正式开启 description: Rod Johnson——那个写出Spring、把Java从EJB泥潭里救出来的男人带着全新的Java Agent框架Embabel回来了。用GOAP算法做确定性规划、强类型Action、Spring原生集成Java程序员不用转Python也能写生产级Agent。 tags: [Java, Agent, Spring, Embabel, AI工程化, Rod Johnson] image: ./images/embabel-rod-johnson-java-agent-cover.jpgSpring之父Rod Johnson携Embabel归来Java程序员的Agent时代正式开启开篇「Java已死」这句话我听了快十五年了。每次技术变革都有人念一遍——微服务时代念过一次云原生时代念过一次现在AI时代又有人拿出来说。但有意思的是每次喊「Java不行了」的时候总有一个人站出来给Java续上十年命。上一次是2002年的Spring这一次是2026年的Embabel。一、从EJB到Agent历史总是惊人地相似1.1 当年Rod Johnson干了什么如果你是个有十年以上工龄的Java老炮应该对EJB这个词有心理阴影。零几年的时候企业级Java的「官方标准答案」就是EJB。写一个业务组件得继承一堆接口配一堆XML部署一次等半天。那时候说Java臃肿、说Java要完真不是造谣是实打实的难用。2002年一个叫Rod Johnson的澳洲人写了本书叫《Expert One-on-One J2EE Design and Development》。书的核心观点就一句话官方那套不行我给你们写个更好的。书里附的那套代码后来长成了Spring Framework。Spring干的事很简单普通Java对象POJO就能干活不用继承什么特定接口配置简单测试好写。然后呢然后Spring赢了EJB那套直接被扫进了历史的垃圾堆。再往后Spring Boot、Spring Cloud一路铺开全家桶把企业Java的命一路续到今天。说Spring给Java续命十年一点都不夸张。1.2 今天的处境和当年太像了说回现在。打开GitHub搜Agent框架LangChain、LangGraph、CrewAI、AutoGPT……清一色Python。公司要做AI不少技术负责人的第一反应也是招Python的人或者让Java的人去学。我自己是Java出身写了十几年Spring。这两年看着Python圈热热闹闹说心里没落差是假的。不是说Python不好但你让一个写了十年Java、对JVM生态门儿清的工程师转头去跟Python的动态类型、缩进语法、虚拟环境打交道那酸爽谁试谁知道。Rod Johnson在访谈里聊到这事的时候火气比我还大。他说很多人爱拿Java当靶子假装这门语言二十年没动过。但他倒也没把Python框架贬得一文不值原话很公允「那些框架不差但JVM上有它们给不了的东西——几十年攒下来的类型安全的业务代码成熟的IDE和重构工具还有一大群写Java顺手、写Python别扭的工程师。」这句话我深以为然。Java的护城河从来不是语言本身是生态、是工具链、是几千万开发者积累的最佳实践。二、Embabel的核心思路规划这件事不让大模型碰2.1 从游戏行业借来的GOAP算法Embabel最核心的设计是从游戏行业借来的一个算法——GOAPGoal-Oriented Action Planning目标导向行动规划。早年是给游戏里的NPC规划行为用的比如《F.E.A.R.》里的敌人AI用的就是这套东西。我第一次看到的时候挺意外的没想到一个Java Agent框架会跑去游戏行业找答案。但仔细一想这招真的妙。用GOAP写Agent你只定义两样东西ActionAgent能干的每个动作Goal最终要达成什么目标动作按什么顺序串不用你写死也不是大模型现场拍的是框架里的规划器Planner算出来的。每执行完一步它根据最新的状态重新算一遍再决定下一步。Embabel GOAP 工作流程 ┌─────────────────────────────────────────────────────┐ │ Goal目标 │ │ 写一篇技术博客并审校发布 │ └──────────────────────────┬──────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────┐ │ Planner确定性规划器 │ │ 输入当前状态 可用Actions Goal │ │ 输出Action 执行序列A*搜索算法 │ │ 特点不调大模型纯代码计算可复现、可审计 │ └──────────────────────────┬──────────────────────────┘ ↓ ┌────────────────┴────────────────┐ ↓ ↓ ┌───────────────────┐ ┌───────────────────┐ │ Action 1: 调研 │ │ Action 2: 写稿 │ │ 输入Topic │ │ 输入Research │ │ 输出Research │ │ 输出Draft │ └─────────┬─────────┘ └─────────┬─────────┘ ↓ ↓ └────────────────┬────────────────┘ ↓ ┌─────────────────────────────────────────────────────┐ │ 状态更新 → 重新规划 → 下一步 │ │ 每一步执行完都重新评估动态调整路径 │ └─────────────────────────────────────────────────────┘2.2 为什么说这才是生产级的思路我最看重Embabel的一点是这个规划过程完全不调大模型就是一段确定性代码在跑。这意味着什么特性大模型驱动的规划Embabel确定性规划可复现性同样的输入两次结果可能不一样同样的输入路径永远一样可审计性为什么选这一步答不上来每一步为什么执行日志写得明明白白成本规划过程烧token规划不花一分钱token调试难度玄学靠prompt工程跟调试普通Java代码一样出问题追责「模型幻觉了」能精确到哪一步逻辑有问题我之前用Python框架搭过demo跑得确实漂亮。但你要问我敢不敢直接放生产环境心里真有点发怵。原因不复杂——大部分框架是让大模型自己决定下一步干什么模型今天这么走明天那么走出了问题没法复盘。审计问你这一步为什么执行你总不能说「大模型觉得该这么干」吧Rod Johnson盯上的就是这条缝。大模型负责不确定的那部分写文案、做总结、搞分类规划和流程交给确定性的代码。这个分工一摆出来Java程序员二十年在工程化上攒的东西——类型、测试、审计、监控——突然全都用上了。2.3 Java程序员最爱的强类型还有一点特别对Java程序员的胃口强类型。在Python的Agent框架里Action之间传的基本上是字典和字符串。你传了个什么进去、期望得到什么出来全靠文档和约定。改个字段名你得全局搜索慢慢找漏了一个就是线上bug。Embabel不一样。Action之间传的不是字典是真正的领域对象——Java Record或者Kotlin data class。输入什么类型输出什么类型编译期就给你卡住。改个字段名IDE能把受影响的Action全找出来一键重构。// 定义领域对象Java Record编译期类型安全 public record Topic(String title, String category) {} public record Research(String summary, ListString references) {} public record BlogDraft(String content, String title) {} public record Review(ListString suggestions, int score) {} // 定义Action —— 输入输出都是强类型 Action(description 根据主题调研并写出初稿) public BlogDraft writeDraft(Topic topic) { // 调模型写稿 return aiService.generateDraft(topic); } Action(description 审校初稿并给出修改意见) public Review reviewDraft(BlogDraft draft) { // 调模型审校 return aiService.review(draft); }对比一下Python版本的感觉# Python 框架里常见的写法 —— 字典传参全靠约定 def write_draft(state: dict) - dict: topic state.get(topic) # 有没有这个key运行时才知道 content llm.generate(topic) return {draft: content} # 下游能不能取到全靠文档我之前写Python Agent重构基本靠全局搜索人肉检查对比太强烈了。对于有几十万行业务代码的企业来说类型安全不是「好不好用」的问题是「敢不敢上生产」的问题。三、上手体验Spring开发者的舒适区3.1 跟Spring AI的关系Servlet API和Spring MVC的区别Rod Johnson自己打过一个比方我觉得挺准的Spring AI 相当于 Servlet API—— 管的是怎么接模型、怎么调向量库这些底层的事Embabel 相当于 Spring MVC—— 是在上面组织业务逻辑、编排Agent的那一层这个比喻太到位了。你直接用Spring AI也能写Agent就像你直接用Servlet也能写Web应用一样——不是不能写是写起来费劲所有流程都得自己拼。Embabel就是在Spring AI上面给你搭好了MVC那一层。所以Embabel整个建在Spring AI上面项目里原来配的模型接入、向量数据库全都不用动。你原来怎么调大模型现在还怎么调Embabel只管编排。3.2 写一个Agent有多简单熟悉Spring的人看一眼代码就懂了Agent(description 写一个主题的技术博客并审校发布) public class BlogWriterAgent { Autowired private AiService aiService; Action(description 根据主题调研相关资料) public Research doResearch(Topic topic) { return aiService.research(topic); } Action(description 根据调研结果写出初稿) public BlogDraft writeDraft(Research research) { return aiService.generateDraft(research); } Action(description 审校初稿并给出修改意见) public Review reviewDraft(BlogDraft draft) { return aiService.review(draft); } Action(description 根据修改意见润色终稿) public FinalDraft polishDraft(BlogDraft draft, Review review) { return aiService.polish(draft, review); } Goal public boolean isPublished(FinalDraft draft) { return draft ! null draft.isPublished(); } }几个关键点Agent直接就是个Spring注解你的类照常走组件扫描和依赖注入每个Action用Action标注描述给规划器看Goal定义终止条件——什么时候算干完了先调研还是先写稿、要不要润色、需不需要返工规划器看着当前状态自己定你不用写if-else串流程也不用写prompt让大模型自己想下一步。框架替你把确定性的部分扛了你只需要专注每个Action具体干什么。3.3 调用方式也很SpringService public class BlogService { Autowired private AgentRunner agentRunner; public void publishBlog(String topic) { var goal new PublishBlogGoal(new Topic(topic, tech)); var result agentRunner.run(BlogWriterAgent.class, goal); // result 里有完整的执行轨迹、每一步的输入输出 } }跟调用一个普通Spring Bean没什么区别。而且因为规划是确定性的你甚至可以给Agent写单元测试——这在Python框架那边基本是想都不敢想的事。四、「生产级」这三个字靠什么支撑框架上个月刚发正式版Apache 2.0协议随便商用Maven中央仓库直接拉。但真正让我觉得「这玩意儿能上生产」的是下面这几件事。4.1 可测试性Agent也能写单元测试官方把「Agent可以像Spring Bean一样写单元测试」当成核心卖点我觉得这才是真正懂企业开发的人会关心的事。SpringBootTest class BlogWriterAgentTest { Autowired private AgentTestRunner testRunner; Test void should_research_before_writing() { // Mock 掉模型返回 var mockAi mock(AiService.class); when(mockAi.research(any())).thenReturn(new Research(..., List.of())); when(mockAi.generateDraft(any())).thenReturn(new BlogDraft(..., ...)); // 运行Agent var trace testRunner.run( BlogWriterAgent.class, new PublishBlogGoal(new Topic(test, tech)) ); // 断言执行顺序 assertThat(trace.getActions()) .extracting(ActionExecution::getName) .containsExactly(doResearch, writeDraft, reviewDraft, polishDraft); // 断言发给模型的prompt里有关键词 assertThat(trace.getPromptFor(writeDraft)) .contains(test); // 甚至能验温度参数设了多少 assertThat(trace.getAction(writeDraft).getTemperature()) .isEqualTo(0.7); } }给Agent写单测这件事我在Python那圈框架里基本没见过有人认真做。大部分人的做法是「跑几次看看效果」然后就祈祷上线别出问题。4.2 成本控制每一步都能选不同的模型Embabel支持每一步动作单独选模型。这个功能看起来不起眼实际上在生产环境里能省大钱。任务类型建议模型成本对比写长文、复杂推理GPT-4o / Claude Opus高分类、提取、摘要GPT-4o Mini / DeepSeek Flash低10-50倍涉及客户数据的敏感操作本地部署模型Ollama等数据不出内网Embedding本地ONNX模型零成本Action(description 分类用户反馈) ModelConfig(model deepseek-chat, temperature 0.1) // 便宜的小模型就行 public FeedbackCategory classifyFeedback(String feedback) { return aiService.classify(feedback); } Action(description 生成复杂的技术方案) ModelConfig(model claude-opus, temperature 0.7) // 吃能力的用大模型 public TechnicalSolution generateSolution(Requirements req) { return aiService.generateSolution(req); }token省了合规上也好交代。对于企业级应用来说这不是锦上添花是刚需。4.3 生态兼容度国内团队友好模型支持方面除了OpenAI、Anthropic、Google这些国际大厂DeepSeek、智谱GLM、MiniMax都在支持列表里Ollama本地部署也直接认。国内团队用起来没什么门槛。工程化配套也补得挺齐✅RAG接口转正—— 不是实验性API不怕半路改✅MCP双向支持—— 既能调别人的MCP工具也能把自己的Agent发布成MCP Server✅A2A协议—— Agent之间能互相通信、协作✅Spring Boot Actuator—— 健康状态、指标直接挂上去统一监控✅ONNX本地Embedding—— 隔离网环境也能用✅Observability—— 完整的执行轨迹、token用量统计、延迟监控官方文档里有个数字我印象很深大约七成的生产应用跑在JVM上。这些公司几十年的业务逻辑全在Java里做AI的正确姿势是把能力接进现有系统不是把系统换成Python重写一遍。五、说几句实话框架不是完美的5.1 目前的短板当然这框架不是没毛病我照实说。方面现状影响语言核心代码是Kotlin写的Java调用完全无感但想读源码得适应一下Kotlin语法Spring Boot版本目前停在Boot 3.5Boot 4还没正式支持迁移指南已经有了生态成熟度GitHub Star跟LangChain十万级没法比社区案例少踩坑可能得自己摸适用场景适合有Spring体系的企业不在Spring生态里的话LangChain4j可能更顺手5.2 谁该关注谁可以再等等强烈建议关注的- 已经在Spring体系里跑了很多年、现在想往业务里塞Agent的团队 - 对可测试性、可审计性、可观测性有硬性要求的企业级应用 - Java/Kotlin为主技术栈、不想为了写Agent特意转Python的团队可以再等等的- 纯Python技术栈的团队——LangChain生态更成熟 - 不在Spring体系里的Java项目——LangChain4j可能更轻量 - 需要最前沿的Agent玩法的——新框架功能跟进需要时间六、我的看法这可能是Java在AI时代的关键一战Embabel能不能复制Spring当年的奇迹我不下结论。Agent这个领域变得太快框架能不能活到格局稳定那天谁也说不准。但Rod Johnson自己有句话我印象很深「Embabel可能是最后一波由人类亲自选择的框架——因为以后挑框架、搭技术栈这种事可能越来越多是AI工具替人做决定。」这句话有点扎心但可能是对的。不过在那一天到来之前我觉得Embabel的方向是对的确定性和不确定性要分开—— 流程交给代码创意交给模型工程化是底线—— 测试、监控、审计一个都不能少拥抱现有生态—— 不是推翻重来是给Java程序员递一把新工具当年Spring把Java从EJB的泥潭里捞出来这回Rod Johnson想捞的是我们这些被Python圈在外面的Java程序员。从EJB到Spring从Servlet到Spring MVC从JDBC到Spring Data——Rod Johnson好像特别擅长干一件事在大家都觉得Java不行了的时候用一个更优雅的方案告诉所有人不是Java不行是之前的方案太烂。反正我Star先点了。值不值得跟看后续。但作为一个写了十几年Java的老程序员看到有人还在为JVM生态认真做事心里挺暖的。写在最后Java会不会死这个问题争论了十几年。我的答案一直是只要还有人在给Java生态创造好东西它就死不了。从Spring到Spring Boot从Hibernate到MyBatis从Dubbo到Spring Cloud——每一次「Java不行了」的唱衰背后都有新的框架、新的思路在冒出来。Embabel会不会成为AI时代的Spring我不知道。但有人在尝试这件事本身就很有价值。你觉得Embabel能成吗欢迎在评论区聊聊你的看法。参考资料本文基于「Java知音」公众号文章《Rod Johnson又来给Java续命了》整理与扩展技术解读为作者独立观点。Embabel开源地址https://github.com/embabel/embabel-agent 延伸阅读 · 我的付费专栏觉得这篇文章对你有帮助我把同类主题的系统化内容沉淀成了付费专栏欢迎订阅支持持续输出专栏定价内容大模型工程师修炼手记9.9 元51 篇 AI 编程 / Agent 深度实战AI时代程序员的自我提升89.9 元27 篇 AI 时代成长方法论 一杯咖啡的价格换来系统化的知识体系你的订阅是我持续创作的最大动力。