📌 项目地址：embabel/embabel-agent
| ⭐ 4,054 颗星 | 🔧 Kotlin | 📜 未标注
JVM 上的 Agent 框架不少，但 Embabel 选了一条不同的路：规划不靠 LLM 的
prompt 技巧，而是用一个非 LLM 的 AI 算法。这个项目目前在 GitHub 上有
4054 个 star，仓库是 embabel/embabel-agent，由 Spring 框架的作者 Rod
Johnson 开发，用 Kotlin 写成，也考虑了 Java 调用方的使用习惯。
核心设计：Agentic Loop
而不是状态机
Embabel 把 Agent
流程建模成五个概念：Actions、Goals、Conditions、Domain
model、Plan。Actions 是 Agent 执行的步骤，Goals 是目标，Conditions
是执行动作前或判定目标完成前需要检查的条件，Domain model
是支撑整个流程的对象模型，Plan 是达成目标的一系列动作。
这些概念本身不特别，特别的是 Plan
的生成方式：系统动态规划，不是程序员预先写死。每完成一个动作，系统就重新评估条件和计划，再生成下一步。这个循环对应的是
OODA
loop（观察-定向-决策-行动），不是传统的有限状态机，也不是顺序执行加嵌套。
有个细节值得注意：应用开发者通常不需要直接接触这些概念。大多数
Conditions
来自代码里定义的数据流，系统可以推断出前置和后置条件，不用开发者显式声明。
规划算法是核心差异点
主流 Agent
框架处理复杂任务的方式有两种：一种是把流程写成有向图，节点是 LLM
调用，边是转移条件；另一种是让 LLM 自己决定下一步做什么。Embabel
两种都不是。
它的规划步骤由一个非 LLM 的 AI
算法完成。这个算法能组合已知的动作步骤，生成一个它从未被明确编程过的行动序列，能决定哪些步骤可以并行，能根据执行结果调整计划。相比之下，LLM
做规划的主要限制是上下文窗口有限、token
成本高、输出不稳定。用专门的算法做规划，决策路径更可控，也更容易测试。
这意味着 Embabel 的能力边界不是由 prompt 决定的。你说“我要完成
X”，系统会自己去动作库里找可用的步骤，组合出一条路径。动作库越丰富，它能完成的任务种类就越多。这就是
README 里说的“extensibility and
reuse”——添加新的领域对象、动作、目标和条件，就能扩展系统能力。
和 LangChain、FSM
框架的简单对比
| 维度 | Embabel | 典型 FSM 框架 | LLM 自主决策框架 |
|---|---|---|---|
| 流程控制 | 算法动态规划 | 开发者硬编码 | LLM 每次调用决定 |
| 状态描述 | Domain model + Conditions | 显式状态枚举 | 隐含在 prompt 里 |
| 失败处理 | 重规划 | 需要开发者写转移 | LLM 随机应变 |
| 可预测性 | 中等（算法可复现） | 高 | 低 |
| 扩展方式 | 添加 Actions/Goals/Domain objects | 添加状态和转移 | 改 prompt |
FSM
的问题不在表达能力，而在维护成本：状态一多，转移条件就变成意大利面。LLM
自主决策的问题在于不可预测，同一个任务跑十次可能走十条不同的路。Embabel
的规划算法走的是中间路线：路径是算出来的，不是写死的，也不是“感觉”出来的。每条路径都能追溯，因为它是一个确定性算法（至少在相同输入下）。
上手路径
README 没有提供代码示例。项目提供了三个入口：
- 文档指南：docs.embabel.com/embabel-agent/guide/1.5.0-SNAPSHOT/
- Maven 依赖：
com.embabel.agent:embabel-agent-api，可在
mvnrepository.com 查到具体坐标 - 交互式文档问答：hub.embabel.com，一个由 Embabel 本身驱动的
Agent，可以用自然语言问它框架怎么用
我建议按这个顺序看：先看文档指南里的架构概览，搞清楚
Actions、Goals、Conditions 在代码里怎么声明；然后去 Maven 仓库看
embabel-agent-api 的版本列表和依赖关系；遇到文档里没写清楚的问题，去
hub.embabel.com 问那个 Agent。
README 还提到项目有 Discord 社区（discord.gg/t6bjkyj93q）和
SonarCloud 代码质量看板。SonarCloud 的 badge 在 README 被注释了，可能是
badge 地址还没配置好。
需要注意的几点
- 版本号是 1.5.0-SNAPSHOT，说明 API
还在演进。生产环境用之前要确认版本稳定性，或者锁定一个已知可用的版本。 - Apache 2.0 许可证，商业使用没有障碍。
- 它不是低代码平台。你需要理解 Kotlin/Java 的领域建模方式，需要清楚
Action、Goal、Condition
的语义边界。规划再聪明，动作库本身还是要你写。 - 动态重规划的行为比传统状态机难调试。系统每执行一步就重新规划，中间态会多很多。测试策略需要考虑：固定随机种子、录制规划轨迹、对规划结果做断言。
- README 里提到了 YourKit 和 JProfiler
的链接，说明项目团队关注性能分析。对于这种每步重规划的设计，推理开销和
GC 行为值得在选型时评估。
如果你在 JVM
上构建需要自主决策的系统——比如运维自动化、复杂业务流程编排、需要动态应对环境变化的后台任务——Embabel
是少数把规划算法作为核心组件的框架。它不完美，但方向对：Agent
的智能应该来自可计算的规划逻辑，而不是让 LLM 在每一步都“即兴发挥”。