加贝哥，十八年IT老兵，最近一年被问得最多的一句话就是："老哥，Java 是不是真的要被 AI 淘汰了？"
加贝哥「猿in」公众号主理人， 「开源AI知识库」作者，前G厂程序员/架构/产研经理，AI进化派，一线OPC创业者。
我的「OPC成长知识库」，主要分享自媒体/IP学习总结，实践心得，以及一人公司（OPC）内容库运营相关经验，伙伴儿们可以免费关注订阅。
问这话的有刚入行的新人，也有工作五六年的骨干。大家看着 LangChain、LangGraph、CrewAI 清一色 Python 生态，看着公司招 AI 工程师都要 Python 栈，心里慌。有人开始偷偷学 Python，有人开始考虑转方向，还有更极端的 —— 整个业务系统用 Python 重写一遍，就为了接个 Agent。
每次我都想说：等等，事情不该是这样的。
二十年后，Java 续命人又回来了
时间拉回 2002 年，那时候企业级 Java 的标准答案是 EJB。写个业务组件要继承一堆接口，配一堆 XML，部署一次等半天，难用得要死，但所有人都告诉你 "这就是标准"。
然后一个叫 Rod Johnson 的人出了本书，书里附了三万行代码，意思很直白：官方那套不行，看我的。
这套代码后来长成了 Spring Framework。普通 Java 对象就能干活，不用继承特定接口，配置简单，测试好写。Spring 赢了，EJB 进了垃圾堆，Boot、Cloud 一路铺开，全家桶把企业 Java 续到了今天。
二十多年后的今天，历史又在重演。只不过这次的 "EJB"，是 Python Agent 框架；这次的 "方向盘"，被塞给了大模型。
Rod Johnson 又出手了。七月底 Embabel 1.0 正式发布，八月中就迭代到了 1.5。这个 Spring 之父搞出来的 Agent 编排框架，目标只有一个：让 Java 程序员在自己最熟的地盘上写 Agent。
最狠的一招：把规划从大模型手里抢回来
我看过太多 Agent 框架的 demo，演示的时候花里胡哨，一到生产就抓瞎。核心问题就一个：让大模型自己决定下一步，出了问题你根本不知道为什么。
今天模型心情好走这条路，明天换个版本走那条路，审计问你 "这一步为什么执行"，没人答得上来。更别说 token 费用像流水一样花，规划来规划去，一半钱都烧在 "想" 上面了。
Embabel 最核心的设计，直接戳中了这个痛点 —— 它从游戏行业借来了 GOAP，目标导向行动规划。
简单说就是：你只需要定义两样东西 ——Action 是 Agent 能干什么，Goal 是最终要达成什么。动作按什么顺序串，不用你写死，也不是大模型现场拍板，是框架里的规划器用搜索算法算出来的。每执行完一步，按最新状态重算一遍再定下一步。
这意味着什么？
- 规划过程完全不调大模型，就是一段确定性代码在跑。同样的输入，算出的路径永远一样，不烧一分钱 token
- 每一步为什么选这个动作，日志写得明明白白，真出了事你能精确回答审计的灵魂拷问
- 动态重规划，执行中出了岔子（接口挂了、数据变了），规划器自动找新路，不用你为每个分支手写恢复逻辑
说个真实案例，掘金上有开发者用 Embabel 做微服务日志诊断，7 个 Action 配 9 个 Condition 组成行动网络，日志质量评估不过关时，规划器自动换条路重抓。当年让游戏 NPC 发现桥断了就绕路的算法，现在让运维 Agent 学会了同一招。
对了，Java 程序员熟悉的味道
我第一次看 Embabel 的代码示例，心里就一个感受：对，就是这个味儿。
@Agent(description = "写一个主题的技术博客并审校")
public class BlogWriterAgent {
@Action(description = "根据主题调研并写出初稿")
public BlogDraft writeDraft(Topic topic) {
// 调模型写稿
}
@Action(description = "审校初稿并给出修改意见")
public Review reviewDraft(BlogDraft draft) {
// 调模型审校
}
}
Spring 老兵一眼就懂。Rod 自己打过比方：Spring AI 相当于 Servlet API，管接模型的底层；Embabel 相当于 Spring MVC，在上面组织业务。
更关键的是强类型。Action 之间传的是真正的领域对象，Java Record 或者 Kotlin data class，输入输出类型编译期就卡住。改个字段名，IDE 能把受影响的 Action 全找出来。
对比写 Python Agent 的时候，重构基本靠全局搜索，字符串魔法满天飞，改个参数名要把所有 prompt 都翻一遍。这种工程能力上的代差，只有真正写过生产系统的人才能体会有多重要。
敢叫 "生产级"，底气在哪里
说实话，现在敢说自己是 "生产级" 的 Agent 框架不多。Embabel 敢这么叫，牌都摆在明面上。
首先是模型接入够宽。OpenAI、Anthropic、Google 主流都有，DeepSeek、智谱 GLM、MiniMax 都在支持列表里，Ollama 本地部署直接认。国内团队从模型可得性上说，基本没什么门槛。
然后是工程化能力，五张底牌：
- RAG 接口转正，不用怕半路变 API
- MCP 双向，能调别人的 MCP 工具，也能把自己的 Agent 发布成 MCP server
- 健康状态挂 Spring Boot Actuator 统一看，监控体系直接复用
- 支持 A2A 协议，Agent 之间能互相通信
- ONNX 本地跑 embedding，隔离网环境也能用
版本节奏也很说明问题。五月中到八月中，版本代号从 Curdimurka、Darwin 一路换过来，全是澳洲动物，翻发布页跟逛动物园似的。1.0 到 1.5 只用了不到一个月，Spring Boot 4 和 Spring AI 2 的支持说补上就补上了。
支持当然是100个百分点，我们也不能一味的去帮吹捧，Embabel 目前的坑，也跟大家聊聊。
第一个坑，核心代码是 Kotlin 写的。官方保证 Java 调用完全无感，但读源码、提 PR 总得适应点 Kotlin 味儿。Rod 在播客里还有个暴论：agent 写了他约 95% 的代码，但设计决策错的比对的多，原话就是 "你不能 vibe-code 严肃软件"。
第二个坑，生态还年轻。GitHub 上 Star 约四千，跟 LangChain 那种十万级的没法比，社区案例也少。年初的时候国内接入还得自己写 Spring AI 的 ChatModel 桥接，现在 GLM、DeepSeek 进官方列表了，缺口在收窄，但小众模型还是得自己接。
第三个坑，1.0 线停在 Spring Boot 3.5，Boot 4 支持是这个月 1.5.0 才刚填上的。不想升级的留在 1.0 线，两条线并存，迁移指南在项目 wiki 上。
写在最后的
从事软件/互联网行业近20年了，我见过太多技术浪潮。每一波来的时候，都有人喊 "某某已死"，都有人焦虑要不要转栈。但真正活到最后的，从来不是追着浪潮跑的人，而是把手里的东西做深做透的人。
Java 生态攒了二十年的家底，不是说丢就能丢的。全世界七成生产应用跑在 JVM 上，几十年的业务逻辑、类型系统、测试体系、工程规范，这些都是真金白银堆出来的。就为了接个 AI，用 Python 重写一遍？Rod 说得很直白：utterly baffling，令人费解。
Embabel 的赌注很明确：大模型负责处理不确定的部分，写文案、做总结、搞分类都归它；规划和流程交给确定性代码。生产环境从不奖励最聪明的模型，只奖励每一步都答得出 "为什么" 的系统。
Rod 有句话我特别认同：Embabel 可能是最后一波由人类亲自选择的框架，因为以后挑框架、搭技术栈，会越来越多由 AI 工具替人做决定。
Rod，Java ，Spring , Embabel... 都值得尊重，不是么？果断收藏，认真star起来！
看完觉得有收获的话，欢迎点赞转发。你怎么看 Embabel 这套思路？Java Agent 的未来会是 GOAP 吗？评论区聊聊。
