Java 团队做 AI，长期处于一种结构性尴尬：并非能力缺失，而是工程体验始终差一截。手写 HTTP 调用、适配各家模型格式、工具调用逻辑散落各处、JSON 输出不敢直接信任。2026 年 6 月 12 日，Spring AI 2.0 GA，开始改变这个局面。
工具调用此前分散在各 ChatModel 实现中，审计、限流、脱敏均无统一入口。2.0 将其提升至 ChatClient 的 Advisor 链，由 ToolCallingAdvisor 接管完整生命周期。Advisor 链是一组可插拔的拦截器，位置决定观察粒度------放在 ToolCallingAdvisor 之前，只能看到最终请求和响应；放在之后，则能介入每一轮工具调用。原本封闭的循环变得透明可控。官方基准显示，OpenAI、Anthropic、Gemini 上 Token 消耗降低 34%--64%，因为中间状态不再全部塞进上下文，Advisor 链可精确控制每轮发给模型的内容，直接转化为成本下降。
结构化输出方面，.entity() 在 1.x 中仅是"请求模型返回 JSON"，解析失败便中断。2.0 引入 validateSchema()，自动校验返回结构。例如目标类型是 int age，模型却返回字符串 "30"，校验会失败，框架将具体错误回填 prompt 重新请求，默认重试三次。过去需要大量 try-catch 与正则清洗的工作，现由框架承担。这不是花哨功能，却是从演示到生产的关键门槛。
底座全面更替：依赖 Spring Boot 4、Spring Framework 7、Jakarta EE 11，Jackson 升至 3.x（包名变为 tools.jackson），全库引入 JSpecify 空安全标注，编译期即可发现潜在空指针。Boot 3.x 无法直接使用，1.1.x 继续维护 3.5 分支。配置中 .options 段被移除，部分旧键静默忽略，启动成功不等于配置生效，升级后应逐行核对 yml。官方提供 OpenRewrite recipe 处理包名与依赖坐标，但配置键需人工确认。仍停留在 Boot 3.x 的团队，迁移不是可选项，而是时间问题。
已有 Spring Cloud 团队以"加依赖、写服务、接网关"的方式，在一个下午内跑通流式对话，密钥管理、指标采集、服务注册均正常接入。流式链路经过网关、多租户工具权限、RAG 质量仍是难点，但至少不再需要切换语言或维护双栈。使用 Boot 4 的团队可直接引入；仍停留在 3.x 的，应尽早规划迁移。当对手用 AI 压低成本时，不应还在纠结包名。
Spring AI 2.0 把 Java 的 AI 开发从"能用"推到了"可治理"的层面。对于长期困在 Spring 生态里的团队，这可能是最务实的一步。