2026年6月，Spring生态迎来了两个里程碑级的发布：6月10日Spring Boot 4.1正式发布，6月12日Spring AI 2.0.0 GA同步上线。
这不是一次普通的版本迭代。Spring AI 2.0从1.0时代“能接模型”的基础框架，全面转向“能构建可组合、可校验、可观察的Agent应用”的工程化平台；而Spring Boot 4.1则是在4.0“代际重置”基础上，补全了生产级微服务基础设施的最后几块拼图。
两者合流，标志着Java开发者终于可以用一套“原生、一致、生产就绪”的技术栈，大规模构建企业级AI应用。
一、Spring Boot 4.1：生产底座的“精装修”
Spring Boot 4.0在2025年11月伴随Spring Framework 7.0一同发布，完成了一次“代际重置”：Jakarta EE 11基线、Jackson 3、JSpecify空安全注解、API版本化管理。4.1则是在这个坚实底座上的精细化打磨。
gRPC进入原生支持范围是4.1最引人注目的变化。Spring Boot 4.1开始提供编写和测试gRPC server/client的自动配置，支持独立Netty和Servlet HTTP/2两种传输方式，并新增了@GrpcAdvice用于集中式异常处理。对Spring开发者而言，这意味着内部高频调用、强契约接口和跨语言服务可以更自然地纳入Spring技术栈。
HTTP客户端SSRF防护则精准回应了AI时代的现实风险。Boot 4.1新增的InetAddressFilter可以拦截阻塞式和响应式HTTP客户端向特定地址范围的出站请求。当AI Agent、工作流、插件系统开始根据用户输入或模型输出动态访问外部URL时，SSRF不再只是安全团队嘴里的抽象风险，而是每天都在发生的真实威胁。
此外，OpenTelemetry观测能力的增强同样值得关注——@Async方法上下文传播、Kafka/RabbitMQ的observation convention自动应用、OTLP exporter支持SSL bundle等。在AI应用里，一次请求可能经过HTTP接入、模型调用、工具调用、数据库、消息队列和异步任务，链路观测不是“锦上添花”，而是“生存刚需”。
二、Spring AI 2.0：从“模型集成”到“Agent工程化”
如果说Spring Boot 4.1解决的是“AI应用跑在哪里”的基础设施问题，那么Spring AI 2.0解决的则是“AI应用如何构建”的架构范式问题。
1. 全新的基线：Spring Boot 4 + Framework 7 + Jackson 3 + JSpecify
Spring AI 2.0被设计为与Spring Boot 4.0/4.1和Spring Framework 7.0配合使用。Jackson 2到Jackson 3的升级大幅改善了JSON序列化体验；代码库全面采用JSpecify空安全注解，在运行时防止空指针异常的同时，也为Kotlin提供了更地道的API。配置属性处理方式也经过重构——选项（Options）现在通过构建器创建，一旦实例化即不可变，并提供了统一、无反射的合并能力。
2. 工具调用（Tool Calling）升为一等公民
这是Spring AI 2.0最核心的架构变更。在1.x时代，工具调用逻辑分散在各个ChatModel实现中。2.0将所有模型的内置工具执行循环全部移除，统一交由ChatClient配合ToolCallingAdvisor处理。工具不再通过Bean名称在请求时解析，而是必须显式注册为ToolCallbackBean并通过.tools()传递。
更重要的是，Spring AI 2.0引入了Tool Search Advisor——通过向量库、Lucene或正则表达式三种ToolIndex实现，让LLM可以按需发现和调用工具，而非一次性加载所有工具定义。这使得Agent可以面对成百上千的工具库，仍然保持高效的决策能力。
3. 自纠错结构化输出
Spring AI从第一天起就支持通过ChatClient.call().entity(...)获取结构化输出。2.0在此基础上增加了两个“旋钮”：提供商原生结构化输出和自纠错Schema校验。
自纠错机制尤为精妙：当模型返回的JSON不符合目标Schema时，Spring AI会将具体的校验错误（如“缺失字段actor”、“期望数组却得到字符串”）附加到用户提示中，重新发起调用——最多重试3次。第二次尝试不是盲目重试，模型看到了上一次的错误原因，能够有针对性地修正输出。
4. 模型提供方收敛
Spring AI 2.0将支持的Chat Model提供方收敛为一组明确定义的核心集：OpenAI（从3种变体统一为1种SDK，同时兼容OpenAI API的其他模型）、Anthropic（从2种变体统一为1种SDK）、Amazon Bedrock、Google GenAI等。这种收敛降低了维护成本，也让开发者面对的选择更清晰。
三、合流的意义：Java开发者的“AI原生”技术栈
Spring Boot 4.1 + Spring AI 2.0的合流，对Java开发者意味着什么？
统一抽象：无论是OpenAI、Anthropic还是兼容API的国产模型，开发者使用同一套ChatClientAPI-。就像JDBC统一了数据库访问一样，Spring AI正在统一AI模型的访问方式-。
类型安全：从ChatClient.entity(ActorsFilms.class)获得的是强类型的Java对象，而非散落在字符串解析中的脆弱数据。整个调用链从提示词构造到工具参数传递，都在编译期获得类型检查的保护。
可观测性：Spring Boot 4.1增强的OpenTelemetry支持，配合Spring AI 2.0的Advisor链，让每一次AI调用——从用户请求到模型推理到工具执行再到最终响应——都可以被追踪、度量和排查。
生产就绪：gRPC支持让微服务间通信更高效；SSRF防护让AI Agent访问外部资源更安全；懒加载数据源连接让启动更快速。这些不是“炫技”功能，而是大规模企业级应用必须面对的工程问题。
四、国产中间件的“AI时代”站位
在这一轮技术变革中，国产中间件厂商同样在快速跟进。2026年6月，金蝶Apusic应用服务器（AAS）V10正式通过Jakarta EE 11国际认证。
Jakarta EE 11于2025年6月发布，在保持企业级稳定性的同时进一步向云原生和现代开发范式靠拢。AAS V10通过这一认证，意味着国产应用服务器在Java企业级技术标准层面与国际主流保持同步。对于采用Spring Boot 4.1 + Spring AI 2.0构建AI应用、同时又需要部署在国产中间件环境中的政企客户而言，AAS V10提供了一个经过国际权威验证的可靠底座。
金蝶天燕AAS历经20余年发展，已具备微内核架构、国密算法支持、国产软硬件生态适配、企业级集群高可用等核心能力。随着Spring生态全面拥抱AI，国产中间件是否能在“AI应用服务器”这一新赛道上持续跟进，将是值得长期观察的命题。
五、结语
Spring Boot 4.1 + Spring AI 2.0的组合，标志着Java企业级AI开发走出了“Demo容易、上线难”的困境。这不是在Spring Boot应用里“加一个AI功能”，而是让AI成为Spring技术栈的一等公民——像JDBC连接数据库、像JMS收发消息一样，自然地融入企业应用的每一个角落-。
正如Spring团队所言，Spring AI 2.0的使命是“连接企业数据和API与AI模型”-。当这套连接建立在Spring Boot 4.1提供的生产级基础设施之上，Java开发者终于可以用自己最熟悉的方式，大规模构建可靠、可观测、可维护的AI应用——无需切换技术栈，无需Python背景。
这或许就是“让Java再次伟大”的真正含义。
