接入模型之前有个很普通的问题值得先问这段示例到底属于哪一版文档能打开、依赖能下载、项目能启动是三件不同的事。把它们混在一起后面遇到消息丢失或工具调用差异很容易误判成模型不稳定。这篇写给准备把AI接进现有Java服务的同学。1024是文章节点文中没有当天活动或生产战报。把三个版本分别记下来本轮打开的Spring AI Tool Calling参考页页首标为2.0.2。9月25日发布的2.1.0-M1则是另一条里程碑线不能因为数字更大就当成稳定补丁直接替换。Tool Calling参考页、M1公告分别支持这两个判断。后者是九月材料不是十月新发布。至少记录这张表对象从哪里取得不能据此推断什么应用实际依赖构建解析后的依赖树不能拿文档页首代替所读参考文档页面版本及访问日期不能证明旧应用已有新API供应商接口API版本、SDK、模型ID不能因客户端抽象相同就认为能力相同10月23日的Spring Boot发布公告同时出现4.1.2与4.2.0-RC1。前者是维护版本后者是候选版本“都能在仓库找到”不是相同的升级理由。4.1.2公告、4.2.0-RC1公告的发布日期均为10月23日。M1里最容易被一句话带过的限制M1引入有序Message Parts但公告明确区分原生支持的适配器与后续计划还单列持久化仓库的限制。由此能得出的结论是要按实际适配器和仓库检查消息往返。不能把“框架有这个类型”扩写成“所有模型、流式链路、数据库仓库都已经保真”。例如模型返回“文本—工具请求—工具结果—文本”时只把文本拼成一列保存之后重建会话就失去了调用关系。即使下一轮仍能生成中文也不能说明历史被完整保存。排查时先比较输入输出结构再看回答质量。图中每一格都是待取得的证据封面核对框同样是检查事项不表示项目已经完成这些测试。一份不依赖项目附件的本地核对方法在项目根目录执行下面命令输出写到本地文件即可。它不访问生产系统也不需要模型凭证。mvn -o dependency:tree -Dincludesorg.springframework.ai:* java -version-o是离线模式依赖或插件未缓存时失败含义是本机还不能完成该项核对不能改称“版本不兼容”。依赖树还要配合实际生效的Profile查看不能只读POM里某个未启用分支。随后挑一个最小任务验证四条路径普通文本、带工具调用的响应、流式结束、消息持久化后重载。每项保存依赖身份、输入、原始输出和失败类别。涉及外部接口的部分在测试环境执行并单独确认预算与权限本文没有发起真实模型调用。怎样作升级决定如果目标只是修复现有服务先在原版本线评估补丁。如果目标依赖M1的新能力把它放进隔离验证分支接受API仍可能变化的事实。没有目标环境证据时可以讨论设计不能签“生产兼容”。当前本机Java运行时为12.0.1未启动Spring Boot 4.x或Spring AI集成项目。因此本文完成的是一手资料与版本边界核对没有给出框架运行成功、吞吐提升或多供应商兼容的实测结论。