给Java AI应用装上“Spring式”的脊梁：Spring AI的抽象哲学与工程化全景剖析
——深度剖析Spring AI的Provider-Agnostic抽象层、模块化架构与从1.0到2.0的Agentic演进
一句话概括：Spring AI不是LangChain的Java翻译版，而是一套以“Provider-Agnostic抽象”为哲学骨架、以“七层模块化架构”为工程血脉、以“ChatClient+Advisor+Options”三位一体为编程范式、以“从模型抽象到Agentic工作流”为演进主线的企业级AI集成框架——让Java开发者用一套接口调用所有主流AI模型，并在2026年2.0版本中完成了从“模型调用工具”到“工具调用成为一等公民”的深刻范式切换。
2023年，当Python开发者用LangChain在几行代码内搭建AI应用时，Java开发者还在为每个AI模型供应商写不同的HTTP客户端、解析不同的JSON响应格式、处理不同的错误码。
“你让Java团队用Python写AI应用？我们的核心业务系统全是Spring Boot。”
“那你们怎么调用大模型？”
“自己封装HTTP客户端，每个模型写一套。”
看起来简单，对吧？调用几个API，解析几个JSON。
但是——当你的业务需要同时支持OpenAI、通义千问、DeepSeek，当模型供应商的API频繁升级，当你需要在对话、嵌入、图像生成之间自由切换时，每一套“自己封装的HTTP客户端”都变成了技术债务。
Spring AI正是在这个背景下诞生的。它的使命朴素到近乎直接：把Spring操作数据库（JDBC）、消息（JMS）、缓存时的那套抽象哲学，原封不动地搬到AI领域。
2025年5月20日，Spring AI 1.0 GA正式发布。仅仅半年后的2025年11月，1.1 GA发布。进入2026年，1.1.3和1.1.4相继推出，2.0.0 GA于6月12日正式发布。Spring AI已成为Java开发者构建企业级AI应用的首选框架。
本文将从抽象哲学、模块架构、核心抽象、源码解析、2.0演进和工程实践六个维度，深度剖析Spring AI的技术全貌——它不是一个“LangChain的Java版”，而是Spring生态在AI时代的自然延伸。
一、抽象哲学：让AI供应商成为“可插拔的基础设施”
1.1 为什么需要抽象？
在Spring AI出现之前，Java开发者调用AI模型的方式是“点对点”的：
// ❌ 紧耦合——每个模型供应商一套APIOpenAiChatClientopenAi=newOpenAiChatClient(apiKey);AnthropicClientanthropic=newAnthropicClient(apiKey);每接入一个新模型，就要学习一套新API、处理一种新格式。切换模型意味着重写业务代码——这违反了软件工程最基本的原则：面向接口编程，而非面向实现编程。
Spring AI的核心洞察是：AI供应商应该是可插拔的基础设施，而非架构决策。正如你切换数据库时不需要重写业务逻辑（因为用了JDBC），切换AI模型时也不应该重写业务逻辑。
1.2 抽象层的三个层次
Spring AI的抽象体系分为三个层次：
| 层次 | 抽象 | 作用 |
|---|---|---|
| 模型抽象层 | ChatModel、EmbeddingModel、ImageModel | 统一不同AI模型的调用接口 |
| 客户端抽象层 | ChatClient | 提供流式DSL风格的高级API |
| 数据抽象层 | Prompt、Message、ChatResponse | 将提示词和响应提升为一等公民 |
1.3 抽象的价值：业务逻辑与AI技术解耦
这套抽象体系的核心价值在于：业务逻辑保持稳定，AI技术快速演进。
// ✅ 面向接口编程——切换模型只需改配置publicinterfaceChatService{ChatResponsechat(Promptprompt);}// 实现类通过Spring的依赖注入获取ChatModel// 切换模型：改application.yml，不改Java代码你的提示词工程、响应处理、错误处理逻辑，在从OpenAI切换到Anthropic再到Mistral的过程中，一行都不需要改。
设计模式解读：这里体现的是桥接模式（Bridge Pattern）——将抽象（业务逻辑中的“对话”概念）与实现（具体AI供应商的API调用）分离，两者可以独立变化。
二、模块架构：从“大而全”到“小而专”
2.1 模块拆分：一次手术式的重构
在Spring AI早期版本中，spring-ai-core包含了所有核心接口，导致每个应用无论用到什么功能，都要拉入整个core模块。
2025年4月4日，Spring团队对模块结构进行了手术式重构，将spring-ai-core拆分成了七个专门的领域模块。
旧架构：spring-ai-core（包含所有接口）→ 依赖臃肿 新架构：七层模块 → 按需引入，依赖精准2.2 七层模块详解
| 模块 | 职责 | 关键内容 |
|---|---|---|
| spring-ai-commons | 基础模块，无其他Spring AI依赖 | Document、TextSplitter、JSON工具、结构化日志 |
| spring-ai-model | AI能力抽象层 | ChatModel、EmbeddingModel、ImageModel接口、Message类型、Prompt模板、ToolDefinition |
| spring-ai-vector-store | 向量数据库统一抽象 | VectorStore接口、相似性搜索、SQL风格过滤、SimpleVectorStore |
| spring-ai-client-chat | 对话式AI高级API | ChatClient接口、ChatMemory、OutputConverter、Advisor拦截 |
| spring-ai-advisors-vector-store | RAG桥接模块 | QuestionAnswerAdvisor、VectorStoreChatMemoryAdvisor |
| spring-ai-rag | RAG完整框架 | 模块化RAG管道、RetrievalAugmentationAdvisor |
| spring-ai-model-chat-memory-* | 对话记忆持久化 | CassandraChatMemory、Neo4jChatMemory |
依赖层次：
spring-ai-commons（地基） ↓ spring-ai-model（依赖commons） ↓ spring-ai-vector-store + spring-ai-client-chat（都依赖model） ↓ spring-ai-advisors-vector-store + spring-ai-rag（依赖client-chat和vector-store）如果你只需要调用ChatGPT的对话API，只需要引入spring-ai-model和对应的模型starter，无需引入向量存储或RAG模块。
设计模式解读：这里体现的是模块化模式（Modularity Pattern）——将功能按领域拆分为独立模块，每个模块有清晰的边界和职责，应用可以按需组合。这与Spring Boot的“起步依赖”（Starter）哲学一脉相承。
设计权衡（模块拆分）：
该设计的收益在于：①按需引入——应用只引入真正用到的模块，避免依赖臃肿；②独立演进——各模块可独立升级，不影响不相关的功能；③降低冲突风险——减少不必要的传递依赖。
该设计的代价在于：①迁移成本——从1.0之前的版本升级需要调整依赖；②学习曲线——开发者需要理解各模块的职责边界。
三、核心抽象：ChatClient、Prompt与Advisor
3.1 ChatClient：对话的“瑞士军刀”
ChatClient是Spring AI面向开发者最核心、最常用的入口。
// 文件路径：spring-ai-client-chat（概念示意）ChatClientchatClient=ChatClient.builder(chatModel).defaultAdvisors(newSimpleLoggerAdvisor()).defaultOptions(ChatOptions.builder().temperature(0.7).model("gpt-4").build()).build();// 流式DSL风格调用ChatResponseresponse=chatClient.prompt().system("你是一个资深的Java技术专家").user("请解释Spring AI的核心设计理念").advisors(newQuestionAnswerAdvisor(vectorStore)).options(ChatOptions.builder().temperature(0.5).build()).call().chatResponse();逐行解读：
ChatClient.builder()：通过构建器模式创建客户端实例，支持设置默认Advisor和默认Optionsprompt()：开始构建一次对话请求，返回PromptSpec（流式DSL的起点）system()/user()：添加系统消息和用户消息，构建Prompt对象advisors()：为本次请求添加拦截器（如RAG检索）options()：覆盖本次请求的模型参数（temperature等）call().chatResponse()：执行同步调用，返回结构化的ChatResponse
设计模式解读：这里体现的是**构建器模式（Builder Pattern）与流式接口模式（Fluent Interface Pattern）**的结合——通过链式方法调用构建复杂的请求对象，代码可读性极高。
3.2 Prompt：从“字符串”到“领域对象”
传统方式将提示词当作字符串处理。Spring AI将Prompt提升为一等公民（First-Class Citizen）——一个结构化的领域对象。
// 文件路径：spring-ai-model（概念示意）publicclassPrompt{privateList<Message>instructions;// 消息列表privateChatOptionschatOptions;// 执行偏好}// Message的三种类型各有语义publicinterfaceMessage{// SystemMessage：系统指令// UserMessage：用户输入// AssistantMessage：模型输出}为什么Prompt是领域对象？因为：
- 可组合性：消息可以组合、模板化、复用
- 类型安全：System、User、Assistant各有不同的语义
- 元数据保留：上下文、选项和历史随Prompt一起传递
- 可测试性：Prompt成为可测试的制品
Prompt → Message → ChatOptions构成了一个语义三元组，将意图、内容和执行偏好封装在单一、不可变的结构中。
3.3 ChatResponse：包裹“不确定性”
AI的响应天然具有不确定性——同一个Prompt可能产生多个候选输出，每个输出有不同的置信度。
// 文件路径：spring-ai-model（概念示意）publicclassChatResponse{privateList<Generation>results;// 多个候选生成结果privateChatResponseMetadatametadata;// 元数据（token用量等）}publicclassGeneration{privateAssistantMessageoutput;// 实际输出内容privateChatGenerationMetadatagenerationMetadata;// 置信度等}ChatResponse → Generation → AssistantMessage的层次结构，镜像了AI生成中固有的不确定性——多个可能的输出、置信度水平和生成元数据。
设计模式解读：这里体现的是响应信封模式（Response Envelope Pattern）——AI响应不仅仅是“内容”，而是带有元数据、候选集和溯源信息的“计算制品”。这种设计保留了响应的丰富性，同时允许简单的访问模式。
3.4 Advisor：AI版的Spring AOP
如果你熟悉Spring AOP（面向切面编程），那么Advisor对你来说会非常自然。
Advisor本质上是一个拦截器，在用户发送问题之后、调用大模型之前，对请求进行一系列增强。
// 文件路径：spring-ai-client-chat（概念示意）publicinterfaceCallAdvisor{AdvisedResponsearoundCall(AdvisedRequestrequest,CallAdvisorChainchain);}// 自定义Advisor：在调用模型前记录日志publicclassLoggingAdvisorimplementsCallAdvisor{@OverridepublicAdvisedResponsearoundCall(AdvisedRequestrequest,CallAdvisorChainchain){log.info("Request: {}",request.prompt());AdvisedResponseresponse=chain.next(request);// 调用下一个Advisor或模型log.info("Response: {}",response.response());returnresponse;}}Spring AI提供了多个开箱即用的Advisor：
- SimpleLoggerAdvisor：记录请求和响应的日志
- QuestionAnswerAdvisor：从向量数据库检索相关文档，注入Prompt（RAG的核心）
- VectorStoreChatMemoryAdvisor：存储/检索对话历史
- ToolCallingAdvisor：工具调用的递归循环（2.0核心特性）
设计模式解读：这里体现的是责任链模式（Chain of Responsibility Pattern）——多个Advisor按顺序组成一条链，每个Advisor决定是否处理请求、是否传递给下一个。这与Spring MVC的拦截器、Servlet的Filter是同一套思想。
你可能会问：Advisor和Spring AOP的切面有什么区别？
Advisor是专门为AI对话场景设计的“切面”——它不仅能拦截方法调用，还能修改Prompt的内容（如注入RAG上下文）、控制对话记忆、处理工具调用的递归循环。这是通用AOP无法优雅实现的。
四、核心源码剖析：从Prompt到Response的完整链路
4.1 请求-响应生命周期
一次完整的AI对话请求，在Spring AI中经历了七个步骤：
业务逻辑 → Prompt构建 → Message组装 → Options应用 → 供应商抽象 → HTTP序列化 → AI供应商API ↓ AI供应商API → 响应反序列化 → ChatResponse信封 → Generation提取 → 业务逻辑为什么这个流程重要？
- 关注点分离：每一步都有单一职责
- 可拦截性：任何一步都可以被拦截（日志、缓存、修改）
- 可测试性：每一层都可以独立测试
- 可观测性：丰富的元数据贯穿整个管道
4.2 工具调用链路：从Tool注解到ToolCallback
工具调用（Tool Calling / Function Calling）是AI智能体的核心能力。Spring AI 1.x中，工具调用的完整链路如下：
ChatClient.prompt().tools(toolNames) ↓ 【ToolCallingManager】解析工具定义（resolveToolDefinitions） ↓ 【模型响应】模型决定调用工具 → 返回tool_calls ↓ 【ToolCallingManager】执行工具调用（executeToolCalls） ├── MethodToolCallback.call()：从方法上提取@Tool注解 │ └── 将模型提取的JSON参数转为Java对象 → 反射调用方法 → 返回结果 └── FunctionToolCallback.call()：函数式工具回调 └── 将模型提取的JSON参数转为Request类型 → 调用Function → 返回结果 ↓ 【工具结果转换】DefaultToolCallResultConverter → 转为JSON字符串 ↓ 【第二轮模型调用】将工具结果发回模型 → 生成最终响应核心类职责：
| 类 | 职责 |
|---|---|
@Tool | 标注一个方法为可被AI调用的工具 |
ToolDefinition | 工具的名称、描述、输入模式（JSON Schema） |
ToolCallback | 工具的执行逻辑 |
MethodToolCallback | 基于@Tool注解方法的回调实现 |
FunctionToolCallback | 基于Function接口的回调实现 |
ToolCallingManager | 解析工具定义、执行工具调用、管理工具上下文 |
ToolCallbackProvider | 集中管理和提供工具回调 |
设计模式解读：这里体现的是**策略模式（Strategy Pattern）与回调模式（Callback Pattern）**的结合——ToolCallback定义了工具执行的统一契约，MethodToolCallback和FunctionToolCallback是两种不同的实现策略。
设计权衡（工具调用）：
该设计的收益在于：①统一抽象——无论使用@Tool注解还是Function接口，调用方使用相同的ToolCallback接口；②类型安全——模型提取的JSON参数被转换为类型安全的Java对象；③可扩展——开发者可以自由添加新工具，只需标注@Tool或实现Function。
该设计的代价在于：①JSON Schema生成——需要从Java方法签名生成JSON Schema，复杂类型可能存在问题；②多轮调用开销——每次工具调用都需要额外的网络往返。
五、RAG与向量存储：让大模型“开卷考试”
5.1 VectorStore抽象：统一向量数据库访问
Spring AI通过VectorStore接口提供了与向量数据库交互的统一抽象：
// 文件路径：spring-ai-vector-store（概念示意）publicinterfaceVectorStore{voidadd(List<Document>documents);List<Document>similaritySearch(SearchRequestrequest);}// 使用示例@AutowiredprivateVectorStorevectorStore;publicvoidsearch(Stringquery){List<Document>results=vectorStore.similaritySearch(SearchRequest.query(query).withTopK(5).withSimilarityThreshold(0.7));}VectorStore支持多种后端实现：PGVector、Milvus、Redis、Chroma、Azure Cognitive Search等。
5.2 QuestionAnswerAdvisor：开箱即用的RAG
Spring AI的RAG能力通过QuestionAnswerAdvisor实现，它作为一个Advisor插入到ChatClient的调用链中：
// 文件路径：spring-ai-advisors-vector-store（概念示意）ChatClientchatClient=ChatClient.builder(chatModel).defaultAdvisors(newQuestionAnswerAdvisor(vectorStore)).build();// 每次对话，QuestionAnswerAdvisor自动：// 1. 从用户问题中提取查询// 2. 从向量数据库检索相关文档// 3. 将文档注入Prompt的上下文// 4. 调用模型生成答案ChatResponseresponse=chatClient.prompt().user("请解释Spring AI的RAG实现原理").call().chatResponse();你可能会问：如果检索到的文档不相关怎么办？
QuestionAnswerAdvisor支持配置相似度阈值，只有超过阈值的文档才会被注入Prompt。你还可以自定义检索策略和文档过滤逻辑。
Spring AI 1.1.3还新增了VectorStoreChatMemoryAdvisor，用于将对话历史存储在向量数据库中，实现跨会话的长期记忆。
六、MCP集成：让Spring AI接入MCP生态
6.1 MCP在Spring AI中的定位
MCP（Model Context Protocol）是Spring AI 1.1版本最重要的功能集改进。Spring AI提供了Spring Boot自动配置和全面的基于注解的编程模型，用于MCP集成。
MCP让Spring AI应用能够：
- 作为MCP客户端，连接外部MCP服务器，获取工具、资源和提示词
- 作为MCP服务器，向外部AI应用暴露自己的工具和能力
6.2 基于注解的MCP编程模型
// 文件路径：Spring AI MCP示例（概念示意）@McpTool(name="get_weather",description="获取指定城市的天气")publicStringgetWeather(@McpToolParam(description="城市名称")Stringcity){// 调用天气APIreturnweatherService.getWeather(city);}只需在方法上添加@McpTool注解，Spring AI就会自动将其注册为MCP工具，对外暴露。
Spring AI 1.1开发周期中，MCP Java SDK从v0.10.0升级到v0.15.0。到Spring AI 2.0，MCP集成进一步深化，实现了协议规范的全面对齐。
七、Spring AI 2.0：从“模型调用工具”到“工具调用成为一等公民”
2026年6月12日，Spring AI 2.0.0 GA正式发布。这次升级被业界称为**“Java AI开发的分水岭”** 。
7.1 最大的架构变化：ChatClient成为主角
在2.0中，ChatClient从“一个方便的高级API”变成了最常用、最推荐的用户面向API，而ChatModel则降级为底层的构建块。
“最大的架构变化：ChatClient才是主角”。
7.2 工具调用进入Advisor链
这是2.0最核心的架构变革。在1.x中，工具调用循环被“隐藏”在ChatModel内部。2.0将其提升到Advisor链中，作为一等公民。
1.x：工具调用循环在ChatModel内部 → 难以观测、难以扩展 2.0：工具调用循环在ToolCallingAdvisor中 → 可观测、可组合、可拦截这意味着：
- 工具调用的每一步都可以被其他Advisor拦截（日志、监控、权限检查）
- 开发者可以自由组合工具调用循环与其他能力（记忆、RAG、结构化输出）
- 工具调用循环本身也变成了可配置、可替换的组件
ToolCallAdvisor在2.0中已重命名为ToolCallingAdvisor。
7.3 按需工具发现（Tool Search）
2.0引入了ToolSearchToolCallingAdvisor，支持LLM按需发现和调用工具，而不是一次性加载所有工具定义。这在拥有大量工具的场景下，可以显著减少token消耗。
7.4 基础设施升级
| 升级项 | 1.x | 2.0 |
|---|---|---|
| Spring Boot | 3.x | 4.0/4.1 |
| Spring Framework | 6.x | 7.0 |
| JSON序列化 | Jackson 2 | Jackson 3 |
| 空安全 | 部分 | JSpecify全量注解 |
| Options配置 | 分散在model/properties | 统一在options层 |
7.5 模型供应商收敛
2.0将核心支持的模型供应商收敛为四个：OpenAI、Anthropic、Amazon Bedrock、Google GenAI。其他供应商可通过兼容API接入。这体现了Spring AI 2.0“少而精”的策略。
设计权衡（模型收敛）：
该设计的收益在于：①降低维护成本——核心团队可聚焦于少数供应商的深度集成；②提高质量——每个集成的测试覆盖率和稳定性更高；③简化文档——用户更容易找到准确的配置指南。
该设计的代价在于：①生态覆盖减少——部分小众模型需要自行适配；②兼容API可能有限——通过OpenAI兼容API接入的模型，可能无法使用全部特性。
八、工程化实践：从安装到生产
8.1 快速开始
Maven依赖（以OpenAI为例）：
<dependency><groupId>org.springframework.ai</groupId><artifactId>spring-ai-openai-spring-boot-starter</artifactId></dependency>配置：
spring:ai:openai:api-key:${OPENAI_API_KEY}chat:options:model:gpt-4temperature:0.7使用：
@RestControllerpublicclassChatController{privatefinalChatClientchatClient;publicChatController(ChatClient.BuilderchatClientBuilder){this.chatClient=chatClientBuilder.build();}@PostMapping("/chat")publicStringchat(@RequestBodyStringmessage){returnchatClient.prompt().user(message).call().content();}}8.2 Spring AI vs LangChain4j：选型建议
| 对比维度 | Spring AI | LangChain4j |
|---|---|---|
| 生态集成 | 深度集成Spring Boot，自动配置完善 | 支持Spring、Quarkus、Java原生 |
| 学习曲线 | 低——熟悉Spring即可上手 | 中等——需学习新API |
| 复杂工作流 | 有限 | 更强——支持复杂推理和自定义工作流 |
| 稳定性 | 官方维护，稳定性更好 | 社区驱动 |
| 适用场景 | 企业级Spring应用快速集成AI | 学术研究、复杂Agent场景 |
选型建议：
- 已有Spring技术栈、追求快速集成→Spring AI
- 需要复杂推理、自定义工作流→LangChain4j
8.3 常见工程陷阱与解决方案
陷阱1：默认LoggerAdvisor使用Debug级别
SimpleLoggerAdvisor默认使用Debug级别输出日志，生产环境可能看不到日志。
解决方案：在application.yml中配置日志级别，或自定义Advisor使用Info级别。
陷阱2：工具调用循环可能导致无限递归
如果工具调用返回的结果再次触发工具调用，可能形成无限循环。
解决方案：使用ToolCallingAdvisor的内置递归限制机制，设置最大迭代次数。
陷阱3：迁移到2.0时工具调用方式变化
2.0移除了toolNames()和toolBeanDefinitionNamesAPI，工具必须通过ToolCallback显式注册。
解决方案：将工具Bean定义为ToolCallback，通过.tools()方法传递。
陷阱4：Options配置迁移
2.0中默认值统一在options层定义，而非model或配置属性。
解决方案：检查所有Options配置，确保迁移到新的配置结构。
九、总结与展望
9.1 关键里程碑
| 时间 | 事件 | 意义 |
|---|---|---|
| 2025年5月20日 | 1.0 GA发布 | Spring生态全面拥抱AI的标志 |
| 2025年11月 | 1.1 GA发布 | 850+改进，MCP集成 |
| 2026年3月 | 1.1.3发布 | 19项新特性，Spring Boot 3.5.11 |
| 2026年6月12日 | 2.0 GA发布 | 最大版本升级，工具调用成为一等公民 |
9.2 核心设计哲学提炼
Spring AI的演进可以用三句话概括：
“Provider-Agnostic是灵魂，不是选项”——Spring AI把操作数据库（JDBC）、消息（JMS）时的抽象哲学原封不动地搬到了AI领域。切换AI模型就像切换数据库驱动一样简单
“从模型调用工具，到工具调用成为一等公民”——1.x时代，工具调用是“模型的一个附加功能”；2.0时代，工具调用循环被提升到Advisor链中，成为可观测、可组合、可拦截的一等公民
“ChatClient是门面，Advisor是灵魂”——
ChatClient提供了优雅的流式DSL，而Advisor机制让AI对话的每一个环节都可被拦截、增强和观测
9.3 核心架构亮点速览
| 亮点 | 说明 | 效果 |
|---|---|---|
| Provider-Agnostic抽象 | ChatModel/EmbeddingModel统一接口 | 切换AI模型不改业务代码 |
| 七层模块化架构 | commons→model→vector-store/client-chat→rag | 按需引入，依赖精准 |
| Prompt领域对象 | Prompt→Message→ChatOptions语义三元组 | 可组合、类型安全、可测试 |
| Advisor责任链 | 对话拦截器，类似Spring AOP | 日志、RAG、记忆、工具调用统一装配 |
| ToolCallingAdvisor | 工具调用循环进入Advisor链（2.0） | 可观测、可组合、可拦截 |
| VectorStore抽象 | 统一向量数据库访问 | 支持PGVector/Milvus/Redis等 |
| MCP原生集成 | 基于注解的编程模型 | 接入MCP生态 |
9.4 对开发者的启示
Spring AI的故事告诉我们：Java生态拥抱AI的方式，不是“抛弃Spring去学Python”，而是“把AI能力变成Spring的另一个抽象层”。
2025年5月之前，Java开发者调用AI模型需要自己封装HTTP客户端。2026年6月之后，Spring AI 2.0已经成为Java企业级AI应用的标准基础设施。
对于开发者，这意味着：
- 如果你在用Spring Boot→ Spring AI是接入AI能力最自然的选择，没有之一
- 如果你需要快速集成AI→ 使用
ChatClient+ Spring Boot自动配置，几行代码即可上线 - 如果你需要RAG→ 使用
QuestionAnswerAdvisor+VectorStore，开箱即用 - 如果你需要工具调用→ Spring AI 2.0的
ToolCallingAdvisor提供了可观测、可组合的解决方案 - 如果你关注MCP生态→ Spring AI 1.1+提供了完整的MCP客户端/服务器支持
- 如果你在从1.x迁移到2.0→ 重点检查工具调用和Options配置的变化
最后，Spring AI的故事还远未结束。从1.0 GA到2.0 GA仅用了一年零一个月——这个速度本身就说明了Spring生态对AI的重视程度。而2.0只是开始，Agentic工作流、更深度的MCP集成、更丰富的向量存储支持，都在路线图上。每一次迭代都在回答同一个问题：如何让Java开发者用最少的代码、最低的学习成本，构建最强大的AI应用？
而答案，正写在每一行Spring AI的源码里。
本文数据来源：Spring AI官方文档（spring.io/projects/spring-ai）、Spring AI GitHub仓库、Spring官方博客、各技术社区及行业报告。所有版本号、发布日期及功能特性均基于公开可验证的官方资料。
如您所在的企业正面临Spring Boot应用AI化改造、企业级AI平台建设或Java技术栈AI落地的相关需求，欢迎进一步沟通。我们可提供针对贵企业具体场景的定制化方案和现场调研服务。
