🔧 框架发布 · 1.0 GA

Embabel 1.0 正式发布:Spring 之父 Rod Johnson 为 Java 打造的智能体框架

由 Spring 框架创始人 Rod Johnson 联合创建的 Embabel 正式发布 1.0.0 GA 版本,为 Java 与 Kotlin 开发者提供了一种基于 GOAP 规划的全新智能体构建方式——无需手工编排提示词,框架在运行时自动搜索动作路径,动态适应变化。

综合公开信息整理 全文约 3 分钟读完
#Embabel #Java AI Agent #GOAP #Rod Johnson #Spring AI
1.0.0 GA 正式可用版本 · 生产就绪
6+ 原生支持模型提供商
GOAP 核心规划引擎 · 目标导向动作规划

⚡ 30 秒速览

  • 谁做的:Spring 框架创始人 Rod Johnson 联合创建,专为 Java / Kotlin 开发者打造,与 Spring AI 深度集成。
  • 核心机制:采用游戏 AI 领域的 GOAP(目标导向动作规划),运行时自动搜索动作序列,而非预定义图式工作流。
  • 架构定位:构建在 Spring AI 之上,类似 Spring MVC 与 Servlet API 的关系——不替代底层,而是提供类型化声明层。
  • 多模型混合:可为单个动作指定不同模型,支持 OpenAI、Anthropic、Gemini、Mistral、DeepSeek 等,实现成本/能力最优路由。
  • 生态坐标:与 LangGraph(有向图)、Akka(Actor 运行时)、Koog(Kotlin 语言特性)走不同路线,偏向类型系统与声明式编程。

01GOAP 规划器 运行时搜索,而非预定义路径

大多数智能体框架要求开发者预先定义工作流图——节点是什么、边怎么连、条件分支怎么走。Embabel 走了另一条路。

▸ 它借鉴了电子游戏 AI 中的 目标导向动作规划(GOAP)

开发者只需声明一组可用的「类型化动作」,每个动作附带前置条件与效果。规划器在运行时搜索满足目标的最优动作序列。如果执行过程中工具调用失败或新信息到达,规划器重新评估并寻找新路径,而不是崩溃或要求提前穷举所有分支。

传统图式编排(LangGraph 等)

预定义有向图:节点为函数,边为路由逻辑,需事先穷举所有路径与条件分支。

Embabel GOAP 规划

声明类型化动作,框架在运行时搜索满足目标的动作序列,动态适应环境变化。

注:GOAP 源自游戏 AI(F.E.A.R. 等),其核心思想是让智能体根据当前状态和目标实时"推演"行动方案,而非执行固定脚本。Embabel 将其引入企业级 Java 智能体开发。

这也意味着,Embabel 并非完全排斥显式状态机——它支持在同一智能体中混合 GOAP 规划与状态机,团队在需要时仍可采用类似 LangGraph 的固定路由。

02构建在 Spring AI 之上 不替代,而是抽象

Embabel 的联合创始人 Rod Johnson 用一个类比来定位它:

Spring MVC 与 Servlet API 的关系,就是 Embabel 与 Spring AI 的关系。

Servlet API

底层管道可用,但每个应用都要重复解决解析请求参数、分发处理器、对象与 HTTP 之间转换等问题。

Spring MVC

构建在 Servlet 之上,让开发者编写类型化的方法签名,无需手工解析 HttpServletRequest。

Spring AI

提供与模型交互的底层管道:调用模型、管理嵌入向量、调用工具。

Embabel

构建在 Spring AI 之上,让开发者声明"这些是我的目标及达到目标可用的类型化动作",由框架推断执行顺序。

注:Embabel 继承了 Spring AI 对大多数模型提供商的支持,包括 OpenAI、Anthropic、Gemini、Bedrock、Mistral、DeepSeek,以及通过 Ollama、Docker 或 LMStudio 的本地方案。

对于已经运行 Spring Boot 服务的团队来说,这意味着低摩擦的集成路径——Embabel 1.0 已经从"值得关注的项目"进入到了"值得评估的项目"。

03多模型混合 每一步都可路由到不同模型

一个智能体通常需要处理多种类型的任务:有的步骤需要强推理(如代码生成、合同分析),有的步骤只需要低成本快速响应(如摘要、格式化)。Embabel 允许为单个动作指定特定的模型

▸ 开发者可以在配置中定义角色别名,动作引用角色而非硬编码的模型名称。

例如:为"推理步骤"指定最佳模型,为"常规步骤"指定最廉价的模型。框架在运行时将每一步路由到最适合成本、隐私或能力需求的模型上。

OpenAI Anthropic Gemini Bedrock Mistral DeepSeek Ollama 本地 LMStudio 本地 Docker 自托管

注:标签云展示 Embabel 通过 Spring AI 原生支持的模型提供商与本地部署方案。开发者可为每个动作单独指定模型,实现多模型混合编排。

这种粒度控制意味着,团队不必为整个智能体一次性固定某个模型,而是可以根据任务类型、数据敏感性、成本预算灵活组合。

04生态定位 与三种主流方案的对比

Java 生态中已经存在多种智能体构建方案。Embabel 的差异化在于:它把重心放在类型系统与声明式编程上,而非运行时基础设施或语言特性。

Embabel

偏向类型系统

声明目标与类型化动作,框架在运行时规划执行路径。构建在 Spring AI 之上,与 Spring Boot 生态无缝集成。

LangGraph4j

偏向有向图

将智能体工作流表示为有向图:节点为函数,边为路由逻辑,需事先定义图结构与条件分支。

Akka Agentic Platform

偏向运行时

基于 Actor 模型,每个智能体作为独立 actor 运行,自带状态、收件箱与层级化监管,侧重持久化、容错与分布。

Koog(JetBrains)

偏向语言本身

围绕 Kotlin 语言特性构建,而非依赖运行时或声明式模型,为 Kotlin 开发者提供原生风格的智能体抽象。

注:四种方案对"智能体结构应该位于何处"采取了不同的策略——Embabel 偏向类型系统,Akka 偏向运行时,Koog 偏向语言本身,LangGraph4j 偏向显式图编排。

一个诚实的注脚:Embabel 并非要替代这些方案。对于已经深度使用 Akka 的团队,Actor 模型的持久化与分布能力仍是独特优势;对于偏好显式控制流的团队,LangGraph 的图式编排依然直观。Embabel 提供的是另一种选择——让框架承担规划责任,而非开发者。

05核心能力 从声明到运行

🎯 类型化动作声明 核心抽象

  • 以类型化的 Java/Kotlin 领域对象(目标、动作、连接条件)声明智能体,而非手工编码提示词与工具调用。
  • 每个动作携带前置条件与效果,规划器据此推断执行顺序。
  • 开发者关注"做什么",框架关注"怎么做"。
类比:就像 Spring MVC 让开发者写类型化方法签名,而非解析 HttpServletRequest。

🔄 运行时规划 动态适应

  • 规划器在运行时搜索可用动作之间的路径,组合出开发者未必显式连线的动作序列。
  • 执行过程中发生变化(工具调用失败、新信息到达),规划器重新评估并寻找新路径。
  • 不崩溃,不要求提前穷举所有分支。
与 LangGraph 的静态图路由形成鲜明对比——Embabel 的图是运行时"推演"出来的。

🧩 多模型路由 成本/能力最优

  • 为单个动作指定特定模型,或在配置中定义角色别名("最佳"模型 vs "最廉价"模型)。
  • 动作引用角色而非硬编码名称,实现多模型混合环境中的灵活路由。
  • 一个智能体可以同时调用多个模型,各取所长。
对于数据敏感性高的场景,可将敏感步骤路由到本地模型,非敏感步骤路由到云端模型。
编辑核心判断

Embabel 1.0 的发布,本质上是将游戏 AI 领域验证过的 GOAP 范式引入企业级 Java 开发。它的真正价值不在于"又一个智能体框架",而在于为 Spring Boot 生态提供了一条低摩擦的智能体构建路径——让 Java 开发者用自己熟悉的类型系统和声明式风格进入 Agent 时代,而不是被迫学习图编排或 Actor 模型。对于已经运行 Spring 服务的团队,Embabel 值得认真评估。

开始评估

Embabel 1.0.0 GA 已正式可用。项目 Overview 指南演示了如何定义第一个目标与类型化动作,并进一步介绍了规划行为。适合已有 Spring Boot 服务、希望以低摩擦方式引入智能体能力的团队。

项目文档 → 快速开始