Java AI 应用别再把供应商细节拖进业务层：Spring AI M4 和 Modulith M4 的提示很直接

Java

发布日期: 2026-04-06

导语：
截至 2026 年 4 月 6 日，Java 生态过去两周最值得企业团队注意的一组更新，来自 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.1.0-M4 / 4.0.5。这些更新表面上看分属不同项目，实际上都在提醒同一件事：Java AI 应用现在最该优先治理的，不是“再接一个模型”，而是把供应商细节、编排逻辑和业务规则彻底拆开。

这不是学院派洁癖，而是非常现实的工程需求。Spring AI M4 里已经明确提到部分模型集成类进入弃用轨道；Boot 版本会继续拉动基础依赖；Modulith 又在帮你把事件外化和模块边界拉直。
如果业务层还直接依赖模型 SDK 和 provider 类型，后面每次升级都会像拆炸弹。

1. 为什么 M4 这批变化值得警惕

Spring AI M4 不是简单修 bug。
它包含动态 structured output control、多个依赖升级、稳定性增强，同时还明确提示部分 provider integration 将来会移除。对 Java 团队来说，这意味着：

模型接入层还在快速演化；
供应商相关 API 不适合作为稳定边界；
你越早把这些变化隔在业务层之外，后面越轻松。

Modulith 这边则更像在回答“那你到底该怎么隔”。
事件外化、命名接口、模块测试这些能力，本质上都在帮你把复杂系统拆出更稳的边界。

2. 真正该优先治理的三条边界

第一条，是领域边界。
订单规则、权限规则、审批规则、状态流转，不该知道模型供应商是谁。领域层一旦依赖 provider SDK，就已经开始埋未来的迁移债。

第二条，是能力边界。
Prompt、RAG、tool orchestration、结构化输出，这些属于能力编排层。它们可以依赖 Spring AI，但不该和控制器、实体、仓储搅成一团。

第三条，是供应商边界。
OpenAI、Anthropic、Gemini、Vertex、向量库、搜索、外部工具，这些都应该放在最外层适配层。它们生来就是变化最快的一层。

如果这三条边界没拉开，今天你只是换个 provider，明天就会变成全仓库到处改。

3. 一套更稳妥的执行路径

第一步，先画依赖图。
找出所有直接依赖模型 SDK、Prompt 模板、向量库客户端的业务模块。很多团队直到画图时才会意识到自己绑得有多深。

第二步，把编排逻辑抽出来。
任何“模型怎么调、工具怎么挂、结构化输出怎么转”的逻辑，都应该从领域服务里剥离出来。

第三步，用 Modulith 收口模块。
对 Java 团队来说，边界不是嘴上说说而已。最好让模块测试、命名接口和事件发布真正帮你守边界。

第四步，把 Boot 升级和 AI 升级拆开。
这类大系统最怕多件事一起动。先分清是平台依赖变化，还是 AI 层变化，再做迁移。

第五步，给 provider 变化留缓冲。
既然 Spring AI 官方已经明确某些集成会弃用，组织就别再把“当前能跑”误当成“长期稳定”。

4. 最容易踩的坑

一个坑是 demo 写法直接进生产。
demo 为了快，天然会把控制器、Prompt、provider 配置、工具注册写在一起。生产如果还照这个方式堆，只会让后续演进越来越难。

另一个坑是把 Modulith 只当文档化工具。
它真正有价值的地方，是帮你把模块边界做成可测试、可演化的结构，而不是画漂亮图。

5. 建议本周执行的动作

盘点现有 Java AI 应用中直接依赖供应商 SDK 的模块。
把编排逻辑和领域逻辑分层。
用 Modulith 或等效方法定义模块边界。
把 Spring AI 升级和 Boot 升级拆成独立回归任务。
为 provider 迁移预先留一层适配封装。

6. 结语

Java 团队的优势，从来不在“追得最快”，而在“能把复杂系统长期维护下去”。到了 2026 年 4 月，这个优势在 AI 应用里格外重要。Spring AI M4 和 Modulith M4 给出的提示其实很直接：别让变化最快的那层直接碰到业务层。边界守住了，升级才是常规动作；边界没守住，升级就会一次比一次痛。