Embabel：Java 团队做 Agent，关键不是换语言而是重建执行边界

Java 做 Agent，真正缺的不是再包一层模型 API，而是把不确定的模型能力放回一套能测试、能审计、能恢复的工程系统里。Embabel 的判断很明确：LLM 处理开放式问题，目标、动作、条件和状态转移由 JVM 的类型与规划机制组织。

Embabel 不是聊天封装。应用先定义允许执行的动作、完成条件和领域对象，再让规划器依据当前状态选择下一步。模型仍然重要，但不再独自握着方向盘。

规划层站在 Spring AI 之上

Spring AI 负责模型、供应商、Embedding 和向量库接入。Embabel 站在更上层，用 Action、Goal、Condition 和 AgentPlatform 组织 agentic flow。项目主体用 Kotlin 编写，但面向 Java 的注解式用法保持自然。

GOAP：规划与执行分开

Embabel 默认规划方式借鉴游戏里的 Goal-Oriented Action Planning。规划器根据动作的前置条件和结果，计算从当前状态到目标的路径；执行一步之后，系统拿新状态重新计算，而不是把一条未经验证的长计划执行到底。规划是确定性代码，真正需要语言理解的部分放在 Action 内部。

这带来三个工程收益：规划选择不必每一步都调用模型；日志可以解释为什么选中某个动作；动作失败后，系统有机会按新状态换路，而不是为所有恢复分支手写 if/else。

类型系统是生产边界

Action 的输入输出如果都是领域对象，编译器、重构工具和测试就能参与约束流程。Draft 可以进入 Review，审核结果才能进入 Publish；这比“请模型输出 JSON”更接近业务规则。

@Agent(description = "Write and review a technical article")
public class BlogAgent {
    @Action
    public Draft write(Topic topic) { /* model call */ }
    @Action
    public Review review(Draft draft) { /* model call */ }
}

这只是流程骨架。真正上线还要补权限、超时、幂等、人工审批、失败重试和输出验证。框架提供落点，不会替团队承担设计责任。

从模板项目开始

官方 README 建议使用 Java 或 Kotlin 模板创建项目，安装 Maven，配置 OPENAI_API_KEY 后启动。稳定依赖可从 Maven Central 获取；版本号应以模板和发布信息为准，不要机械照抄二手文章。

git clone https://github.com/embabel/java-agent-template.git
cd java-agent-template
export OPENAI_API_KEY=...
./mvnw spring-boot:run

第一次验证应使用封闭任务：固定主题生成草稿，再执行结构化审校，暂时不要写生产数据库或自动发消息。记录规划选择、模型调用、状态变化、失败原因和最终对象，先证明流程可重复、可回放。

生态清单不是成熟度证明

仓库包含模型供应商集成，以及 MCP、A2A、可观测性、ONNX 等模块。GitHub 元数据显示约 4.3k stars、Apache-2.0 许可和近期提交，这说明项目活跃，但不能等价于所有集成都适合生产。还要验证版本兼容、恢复行为、示例、测试覆盖和团队接手成本。

适合谁

• 已经使用 Spring Boot 和 JVM 领域模型、希望加入 Agent 流程的团队。
• 需要显式表达目标、动作、状态和审计证据的系统。
• 只需一次模型调用的项目不必上这么重的编排层，Spring AI 可能更直接。
• 无法消化 Kotlin 源码和快速迭代生态的团队，应先把实验隔离。

Embabel 的下注不是“Java 也能做 Agent”，而是把 Agent 拉回软件工程的责任链：模型处理不确定性，类型系统承载约束，规划器管理路径，运行时记录证据。验收标准应是故障时能否回答“为什么这样做、失败后怎么办”，而不是演示能否生成漂亮答案。