深度解读：Embabel智能体框架发布1.0版本

Embabel 是一个用于在 Java 上构建 AI 智能体的框架，目前发布了 1.0 正式可用版本。

Embabel 能够让 Java 与 Kotlin 开发者以类型化的领域对象（目标、动作及其连接条件）来声明智能体，而不是手工编码一系列的提示词与工具调用，并且能够在运行时通过规划步骤确定如何从当前状态到达目标。

该规划步骤借鉴了电子游戏 AI 中的目标导向动作规划（Goal-Oriented Action Planning，GOAP）的理念。

它不是按照脚本或预先连线的图来执行，而是为智能体提供了一组可用的动作（action），每个动作都带有前置条件与效果，规划器搜索满足目标的动作序列。

如果执行过程中发生了变化（比如，工具调用失败、新信息到达），规划器可以重新评估并寻找新的路径，而不是崩溃或要求工作流提前考虑该分支。

Embabel 并不是要替代 Spring AI，后者是 Spring 团队用于调用模型、管理嵌入向量与调用工具的库，Embabel 是构建在 Spring AI 之上的一层。

Embabel 的联合创建者是 Spring 框架的创建者 Rod Johnson， 他发布了该版本的消息 并表示“Embabel 1.0.0 GA 已经基本就绪了，这非常令人振奋”。

项目的 README 文件也将其比作 Spring MVC 与 Servlet API 的关系：原始的 servlet 就是可用的，但每个应用都要重复解决解析请求参数、分发处理器、对象与 HTTP 之间转换等问题。

Spring MVC 并没有替换 servlet。

它构建在 servlet 之上，让开发者可以编写类型化的方法签名，而无需手工解析 HttpServletRequest 。

Embabel 在智能体领域做了类似的抽象：Spring AI 提供了与模型交互的底层管道，Embabel 提供一层让开发者声明“这些是我的目标及达到目标可用的类型化动作”，由框架负责推断执行顺序。

这种与 Spring AI 的分层关系也体现在模型选择上。

由于 Embabel 构建于 Spring AI 之上，它继承了 Spring AI 对大多数模型提供商的支持（OpenAI、Anthropic、Gemini、Bedrock、Mistral、DeepSeek），并通过 Ollama、Docker 或兼容 OpenAI 的 LMStudio 端点支持本地或自托管方案。

在模型选择方面，不必为整个智能体一次性固定某个模型：开发者可以

🔗 原始来源

如果你要核对细节，可以再看原文： InfoQ AI原文链接