Spring AI 2.1.0-M1 已经可用。版本号中的 M1 表明它是 2.1 系列的第一个里程碑版本，适合提前验证兼容性、观察 API 演进并向项目反馈问题，但不应直接按照正式稳定版的标准投入核心生产流量。
由于当前信息只确认了版本发布，没有提供具体变更清单，本文不推断新增功能，而是聚焦一个更实际的问题：开发团队应该如何以较低风险评估这个版本。
先把 M1 当成兼容性测试目标
里程碑版本的主要价值不是“立即升级”，而是尽早发现升级成本。对已经使用 Spring AI 的项目来说，建议重点检查以下几类边界：
- 现有模型 Starter 和自动配置能否正常加载；
ChatClient调用、结构化输出和流式响应是否保持兼容；- 工具调用、向量存储、记忆或检索增强流程是否出现行为变化；
- Spring Boot、JDK、Reactor 以及模型 SDK 的传递依赖是否发生冲突；
- 超时、重试、指标和日志是否仍然符合生产环境要求。
不要只看项目能否编译。AI 应用经常会在编译通过后暴露运行期问题，例如 Bean 装配失败、模型参数不再被识别、响应映射异常，或者重试策略造成调用量放大。
在隔离分支中升级依赖
可以先创建独立分支，避免里程碑依赖意外进入正式发布链路：
git switch -c experiment/spring-ai-2.1.0-m1
./mvnw -q dependency:tree > dependency-tree-before.txt
在已有且兼容的 Spring Boot 项目中，可以通过 BOM 集中管理 Spring AI 组件版本。下面按 Spring AI 常见的 Maven 坐标给出改造模板；如果正式发布说明调整了模块名称或仓库要求，应以该版本的发布说明为准。
<properties>
<java.version>21</java.version>
<spring-ai.version>2.1.0-M1</spring-ai.version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.ai</groupId>
<artifactId>spring-ai-bom</artifactId>
<version>${spring-ai.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.ai</groupId>
<artifactId>spring-ai-starter-model-openai</artifactId>
</dependency>
</dependencies>
升级后重新生成依赖树并比较差异：
./mvnw -U clean verify
./mvnw -q dependency:tree > dependency-tree-after.txt
diff -u dependency-tree-before.txt dependency-tree-after.txt || true
如果 Maven 无法解析里程碑构件，应先核对官方发布说明中指定的仓库配置，不要随意加入来源不明的 Maven 仓库。
建立一个最小 ChatClient 冒烟测试
下面的控制器适合放进已有 Spring Boot 项目，用来验证自动配置、模型连接和基本对话调用。运行前需要设置模型服务的 API Key。
package com.example.ai;
import java.util.Map;
import org.springframework.ai.chat.client.ChatClient;
import org.springframework.http.HttpStatus;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.server.ResponseStatusException;
@RestController
@RequestMapping("/ai")
public class AiController {
private final ChatClient chatClient;
public AiController(ChatClient.Builder builder) {
this.chatClient = builder.build();
}
@PostMapping
public Map<String, String> ask(@RequestBody Map<String, String> request) {
String prompt = request.get("prompt");
if (prompt == null || prompt.isBlank()) {
throw new ResponseStatusException(
HttpStatus.BAD_REQUEST, "prompt must not be blank");
}
String answer = chatClient.prompt()
.user(prompt)
.call()
.content();
return Map.of("answer", answer == null ? "" : answer);
}
}
对应的 application.yaml 可以保持最小化：
spring:
ai:
openai:
api-key: ${OPENAI_API_KEY}
启动并调用接口：
export OPENAI_API_KEY='replace-with-your-key'
./mvnw spring-boot:run
在另一个终端执行：
curl --fail-with-body \
-X POST http://localhost:8080/ai \
-H 'Content-Type: application/json' \
-d '{"prompt":"用三句话解释什么是向量检索。"}'
这段代码主要验证最短调用链。真实服务还应增加请求大小限制、超时、并发控制、敏感信息过滤以及模型异常映射，避免把供应商返回的原始错误直接暴露给客户端。
不要用自然语言输出做脆弱断言
LLM 的文本输出具有随机性，因此集成测试不应该要求模型返回某个完整句子。更稳妥的方式是验证 HTTP 状态、响应结构和非空字段：
response=$(curl --silent --show-error --fail \
-X POST http://localhost:8080/ai \
-H 'Content-Type: application/json' \
-d '{"prompt":"只回答 OK"}')
echo "$response" | jq -e '.answer | type == "string" and length > 0'
如果项目依赖结构化输出、工具调用或 RAG，应分别建立固定测试集。测试记录至少包含：输入、模型名称、关键参数、响应结构、耗时和失败类型。这样才能区分框架升级问题与模型服务自身波动。
采用前的检查清单
评估 Spring AI 2.1.0-M1 时，可以按照下面的顺序推进：
- 在独立分支或独立示例项目中升级 BOM；
- 保存升级前后的依赖树，检查版本冲突；
- 执行聊天、流式响应、工具调用和向量检索等关键路径测试；
- 对比延迟、错误率、Token 消耗和重试次数；
- 验证监控、日志脱敏及超时配置；
- 保留回退到当前稳定版本的锁定文件或提交；
- 等待后续里程碑或正式版时，再根据变更说明复测。
如果团队的目标是提前适配 2.1 系列，M1 很适合进入实验环境和持续集成矩阵；如果目标是稳定承载业务，则更合理的做法是继续使用经过验证的稳定版本，同时把 2.1.0-M1 当作兼容性预警器，而不是生产升级终点。