Jakarta Agentic AI 1.0.0-M1 出了，Java 智能体有了标准写法

Jakarta EE 这套流程给 Servlet 定过规范，给 JPA 定过规范，10 月下旬起，也替 AI 智能体立了一份：Jakarta Agentic AI 1.0.0-M1 进了 Maven Central，坐标 jakarta.agentic-ai-api，要求 Java 17 以上。

按这份草案，一个智能体就是一个 CDI Bean。@Trigger 标入口，@Decision 管分支，@Action 干活，@Outcome 收尾，@HandleException 兜异常，@Agent 一挂，运行时接手编排。调模型的部分压进一个很薄的 LargeLanguageModel 接口，返回值直接映射成 JSON-B 对象，要碰厂商私有能力就走 unwrap()，路数跟 Jakarta Persistence 的 EntityManager 一致。

**换模型从重构项目变成改配置，这是这份规范最值钱的地方。**企业后端换模型的场景这两年不新鲜：更便宜的模型上线了要切，某家涨价了要切，某家停止服务了更要切。以前每切一次，业务代码跟着厂商 SDK 重写一遍，大后端动辄按月算。文档里写得很清楚，它不打算标准化各家 LLM 的 API，也不打算替代 Spring AI 或 LangChain4j，位置放在这些框架之上，底下接谁都能换。

规范管的是「跑起来」

M1 管到运行时为止：编排、注入、异常、上下文，都有说法。规范给的示例也是这个方向，欺诈检测、从 PR 自动生成文档、客服智能体，全是「在 Jakarta EE 运行时里跑得动」的形态，持久化、校验、事务、安全这些老规范照常复用，智能体不用住在单独的孤岛上。

一个智能体要能上线，光在运行时跑通不算完。@Agent 标注的那个方法体里，模型只负责推理那一步；方法体外的东西，检索哪张表、走哪个接口、异常怎么落库，都是普通的 Java 工程，要人先设计出来。

这部分规范没管，也管不了：智能体的代码从哪来。

智能体的代码也得走流程

飞算 JavaAI 做的是这一段。这是个 Java 研发方向的工程化智能体，以插件形态装在 IDEA 里，管代码成形之前和之后的两头。

智能会话里分四步走。先跑 /需求分析，需求里说不清的地方它会先发问，文档落在项目的 docs/ 里；接着 /前后端设计，库表设计和接口定义依次定下来；再 /前端开发，前端工程照接口那份设计生成，起来直接联调；末了 /后端开发，代码照着前面定好的规范生成。四步走完，工程里留下的是一套互相咬合的文件，不是几段聊天记录。

回到 Jakarta 的注解上：@Agent 方法里要用到的表和接口，在这条流程里早就定成文件了，智能体代码照着接就行。规范把运行时稳定下来，流程把上游产物稳定下来，两头都稳，智能体才敢放进生产。

模型也不做绑定。自有那几档是在 Java 场景的开源底座上调优出来的，第三方直连可选 DeepSeek-V4 与智谱 GLM-5.2、5.3，跟这份规范的厂商中立是同一个思路。

标准落地之前的窗口

M1 只是里程碑，参考实现和 TCK 还在后面，项目牵头人 Reza Rahman 的说法是 v1 已经不远。真正进入生产，中间还隔着各家实现陆续对齐的时间。

这段时间对 Java 团队的意义是准备期。注解怎么标、Bean 怎么注入，照着草案就能试；真正的功夫花在上游，需求文档、库表、接口定义，这些现在就可以用流程固定下来，等 1.0 正式发布，把智能体代码接上去就行。飞算 JavaAI 落 docs/ 的那套产物，正好就是这份准备。

准备期还有一层意思：团队怎么分工。以前一个需求从口头到代码，中间的文档是顺手写的，写不写全看心情；文档成了链路里必须存在的一环之后，谁产出、谁更新、变更时谁同步，都得有名字。文档从顺手写变成必产物，这个转变比任何注解语法都来得早。

你现在项目里要接一个智能体，需求和接口的文档是齐的，还是要现补？