Java 团队做 AI 应用，先稳住模块边界再追新版本：Spring AI M4 和 Modulith 给出的答案

Java

发布日期: 2026-03-31

导语：
截至 2026 年 3 月 31 日，Java 生态这一周给企业团队的信号非常密集。Spring 在当日发布的 This Week in Spring - March 31st, 2026 里集中点名了 Spring AI 2.0.0-M4 / 1.1.4 / 1.0.5、Spring Modulith 2.1 M4 / 2.0.5 / 1.4.10、Spring Boot 4.0.5 和 Spring Boot 4.1.0-M4。如果把这些发布连起来看，会发现一个很清楚的方向：Java 团队做 AI 应用，最先要解决的已经不是“能不能接上模型”，而是“模块边界能不能稳住，供应商变化和框架升级会不会把业务层一起拉乱”。

这件事在 Java 世界里尤其重要。因为 Java 项目活得久、依赖多、团队大，任何一次版本演进都不是单兵冒险，而是组织性迁移。

1. 为什么这周这些发布值得一起看

Spring AI M4 带来的不是单点新功能，而是继续在结构化输出控制、稳定性修复和依赖升级上推进，同时还明确提示某些模型集成类已经进入弃用轨道。
Spring Modulith 2.1 M4 则继续强化模块化建模和事件外化能力，还把 JobRunr 作为事件外化的一个方向纳入进来。
Spring Boot 4.1.0-M4 和 4.0.5 一边修回归，一边继续拉平台依赖。

这三条线合在一起看，给 Java 团队的建议非常一致：别把 AI 接入写成一团紧耦合 glue code，不然每次 SDK、模型、框架和运行平台一动，业务逻辑就跟着一起抖。

2. 真正该优先治理的，不是模型数，而是边界

我更建议 Java 团队先把应用拆成三层：

第一层，领域与业务层。
这层只处理业务规则、权限、状态变化和最终交付结果，不直接依赖某个具体模型 SDK。

第二层，能力编排层。
负责 Prompt、工具调用、结构化输出、RAG、代理协作、任务编排。Spring AI 更适合留在这一层。

第三层，外部适配层。
负责具体模型供应商、MCP、向量库、搜索引擎、事件外化、队列和存储。任何供应商弃用或 SDK 替换，都应该尽量被限制在这里。

一旦这三层边界拉开，Spring AI 的版本升级就不会那么像一场系统性地震。

3. 结合这周更新，更稳妥的执行路径

第一步，别急着全量上 M4。
先判断你的项目处在什么阶段。如果已经生产化，优先吃稳定线修复；如果是试点或平台能力开发，再评估 M4 的新能力是否值得承担变更成本。

第二步，用 Modulith 收口模块关系。
很多 Java AI 项目真正的问题不在模型，而在模块边界太乱。Prompt、工具定义、领域服务、审计逻辑、消息分发全缠在一起，最后谁都不敢动。

第三步，把模型供应商适配做薄。
Spring AI 这次已经明确提示部分集成类将来会移除。对团队来说，正确姿势不是抱怨官方变化快，而是自己别把业务代码直接绑死在这些类上。

第四步，把事件外化和异步任务独立治理。
AI 应用一旦进入真实业务，很多动作都天然异步：生成、审批、回填、通知、补偿、审计。Modulith 和 JobRunr 这类组合，正好适合把这些流程从控制器和服务实现里抽出来。

第五步，把 Boot 升级和 AI 升级分阶段。
别一轮改动里既升级 Boot，又换 Spring AI，又切模型集成。那样一旦出问题，根本不知道是谁的锅。

4. 我会优先检查的几个点

业务层是否直接依赖了模型 SDK 类型。
结构化输出是否已经有统一的 DTO 和校验层。
事件外化、重试和补偿是否与 HTTP 接口逻辑解耦。
模型供应商替换是否只需要改适配层，而不是全仓搜关键字。

如果这四个问题里有两个答不上来，说明团队的 AI 应用还没有脱离 demo 阶段。

5. 建议本周执行的动作

画一张现有 Java AI 项目的模块依赖图。
找出所有直接引用模型 SDK 的业务代码。
用 Modulith 或等效方式重新梳理边界。
把异步任务和事件外化单独拉出治理。
给 Spring AI 与 Boot 升级分别建立独立回归计划。

6. 结语

Java 团队最大的优势，从来不是追新快，而是能把一套复杂能力长期维护下去。到了 2026 年 3 月底，这个优势在 AI 应用里尤其明显。Spring AI、Modulith 和 Boot 这一周的更新，真正提示大家的，不是“有多少新特性”，而是“你有没有把边界守住”。边界守住了，版本迭代才是生产力；边界没守住，每次升级都只会放大混乱。