Spring AI 注册 ToolCallbacks 报 generateSchema NoSuchMethodError，先查混进来的旧版本

应用还没向模型发请求，注册工具时就失败，堆栈指向 SchemaGenerator.generateSchema，异常类型是 java.lang.NoSuchMethodError。遇到这种情况，先检查运行时依赖，不必急着改工具参数。

这个案例最后查到了什么

Spring AI 的 #5668 报告于 2026 年 3 月 25 日，目标版本是 2.0.0-M3。作者最初认为发布包使用了错误的 jsonschema-generator 版本，并发现降级该依赖后可以运行。

但后续排查推翻了最初判断：项目的 classpath 中残留了 Spring AI 2.0.0-M2 artifact。作者更正

因此，这个案例适合用来检查“依赖声明看似一致，最终运行包却混用了旧模块”，不宜据此认定 M3 发布本身有编译错误。

怎样定位实际加载的版本

Maven 项目先看依赖树：

./mvnw dependency:tree

重点查 org.springframework.ai 下的模块，以及 com.github.victools 下的 schema 相关依赖。留意直接依赖、上游组件传递引入的版本和 dependencyManagement 中的覆盖。

Gradle 项目可以针对运行配置查询：

./gradlew dependencyInsight --dependency spring-ai --configuration runtimeClasspath
./gradlew dependencyInsight --dependency jsonschema-generator --configuration runtimeClasspath

多模块项目应对实际启动模块执行命令。接着检查打包产物里的依赖，避免本地源码已经更新，部署的 JAR 仍然来自旧构建。

修复时，把 Spring AI 模块统一到项目选定的兼容版本，优先让同一套 BOM 管理它们。移除遗留的单模块版本覆盖，重新构建并部署整个产物。不要只在开发环境里强制降级一个 victools 包，然后把“能启动”当作依赖已经配平。

修完以后看两个结果

先独立执行应用原有的 ToolCallbacks.from(...) 注册路径，确认能生成工具定义及输入 schema。这一步不需要调用付费模型。

再启动最终打包产物，走一遍相同的工具注册。若开发环境正常而 JAR 仍失败，就继续查部署文件、实际类路径和旧缓存。依赖树消除了 M2/M3 混用，且最终产物也能注册，才算覆盖了这个案例的故障边界。

如果项目没有混用版本，不要强套此结论。完整异常中的方法签名可以继续帮助定位是哪组编译期与运行期 API 不一致。