最近在尝试将AI能力集成到自己的Spring Boot应用中发现市面上模型众多接口各异直接对接不仅代码冗余后期切换和维护更是头疼。好在Spring社区推出了Spring AI项目它就像给各种大模型OpenAI、Azure、Claude、Ollama等提供了一个统一的“插座”我们只需要用一套标准的接口就能和它们对话大大简化了集成工作。为了更直观地展示这种效率提升我动手搭建了一个演示项目核心就是展示如何用同一套代码轻松在多个AI模型间切换。这个项目的目标很明确构建一个后端服务它对外提供一个统一的聊天接口。用户访问这个接口时可以通过一个简单的参数比如modelopenai或modelollama来指定本次对话使用哪个AI模型。服务内部则会根据这个参数自动加载对应的配置API密钥、基础URL等并使用Spring AI提供的统一ChatClient去调用相应的模型最后将结果返回给用户。整个过程业务逻辑代码完全不用关心底层到底是哪个模型在响应。项目骨架与依赖搭建。首先我使用Spring Initializr创建了一个标准的Spring Boot项目核心依赖包括spring-boot-starter-web用于提供REST接口、spring-ai-openai-spring-boot-starter和spring-ai-ollama-spring-boot-starter这是Spring AI为OpenAI和Ollama提供的官方集成。此外为了监控服务状态还加入了spring-boot-starter-actuator为了编写测试引入了spring-boot-starter-test以及Mockito相关依赖。这一步的关键在于通过Maven或Gradle引入这些starter后Spring AI的核心组件ChatClient就会被自动配置到Spring上下文中我们直接注入使用即可。多环境配置管理。为了实现动态切换配置是重中之重。我没有把所有模型的配置都堆在application.properties里而是利用了Spring Boot的Profile特性。我创建了三个配置文件application-openai.properties用于配置OpenAI需要设置spring.ai.openai.api-key和spring.ai.openai.chat.options.model比如gpt-3.5-turboapplication-ollama.properties用于配置本地Ollama需要设置spring.ai.ollama.base-url为本地服务地址如http://localhost:11434以及spring.ai.ollama.chat.options.model比如llama3。还有一个基础的application.properties里面可以放一些公共配置比如服务端口、Actuator端点暴露设置management.endpoints.web.exposure.includehealth,info等。这样通过启动时激活不同的profile例如--spring.profiles.activeopenai就能让应用加载对应模型的连接配置。核心服务层设计。接下来是业务逻辑的核心——服务类。我创建了一个AiChatService它的职责就是根据前端传入的模型标识调用正确的AI模型进行对话。这里有一个设计考量如何根据运行时参数动态选择ChatClientSpring AI的ChatClient本身是一个接口其具体实现连接OpenAI或Ollama由当前激活的Profile决定。但在一个请求中切换Profile是行不通的。因此更优雅的做法是利用Spring的Qualifier注解。我为OpenAI和Ollama的ChatClientBean分别定义了特定的名称比如openaiChatClient和ollamaChatClient然后在服务中根据模型参数通过一个Map或者条件判断来注入并使用对应的那个ChatClient。服务类中的一个核心方法chat(String message, String modelType)就包含了这个选择逻辑并最终调用chatClient.call()方法发送消息获取AI回复。对外暴露REST接口。有了服务层控制器Controller的编写就非常直观了。我创建了一个AiChatController里面定义一个POST /api/chat接口。这个接口接收两个参数message用户输入和model模型类型如“openai”。控制器的方法体非常简单校验参数然后调用上面提到的AiChatService.chat()方法并将结果包装成统一的JSON格式返回。这样前端或任何HTTP客户端就能通过一个接口自由地在不同的AI模型间进行切换和测试了。健康检查与单元测试。为了确保服务可靠性我集成了Spring Boot Actuator。Actuator的/actuator/health端点默认会检查应用状态而Spring AI的starter通常会为ChatClient提供健康指示器Health Indicator。这意味着访问健康端点时它能反馈当前配置的AI模型连接是否正常例如OpenAI的API密钥是否有效Ollama服务是否可达这对于运维监控非常有用。最后为了保证代码质量我为AiChatService编写了单元测试。使用Mockito框架我可以轻松模拟ChatClient的行为分别测试当传入“openai”或“ollama”参数时服务是否正确地调用了对应的模拟客户端并验证了返回结果的处理逻辑。这种测试不依赖真实的AI API运行快速且稳定。通过这个项目我深刻体会到Spring AI带来的效率飞跃。过去每接入一个新模型我都要仔细阅读其独特的SDK文档编写不同的HTTP调用逻辑和响应解析代码。现在绝大部分的样板代码——包括HTTP客户端配置、请求/响应体的序列化与反序列化、错误处理等——都被Spring AI的ChatClient接口和各个starter封装掉了。开发者只需要关注配置和业务逻辑。当需要从OpenAI切换到Azure OpenAI或者增加对Anthropic Claude的支持时理论上只需要引入新的starter、添加对应的配置Profile并在服务层的选择逻辑中增加一个分支即可核心的对话调用代码一行都不用改。这种“一次编写多处运行”的能力在快速迭代和对比不同模型效果的场景下尤其有用。比如产品经理想同时对比GPT-4和本地部署的Llama 3对同一个问题的回答质量利用我这个项目写个简单的脚本循环调用两次接口改个参数就行了无需启动两个不同的服务。整个项目从构思到跑通编码工作量比预想中少了很多。这让我想起最近在体验的InsCode(快马)平台它的理念和Spring AI有异曲同工之妙都是通过抽象和封装来降低复杂度、提升效率。在InsCode上你甚至不需要在本地安装任何开发环境打开网站就能直接创建、编辑和运行像这样的Spring Boot项目。它内置了代码编辑器和智能辅助对于想快速验证Spring AI这类新框架效果的开发者来说特别友好。更让我觉得省心的是它的部署功能。像这个Spring AI演示项目它是一个标准的Web服务启动后会持续监听端口等待HTTP请求。在InsCode上完成代码后基本上点一下“部署”按钮平台就会自动处理编译、打包、环境配置和发布上线这一系列繁琐流程生成一个可公开访问的URL。这意味着我不仅能自己测试还可以直接把链接分享给同事或朋友让他们实时体验不同AI模型的对话效果收集反馈整个过程非常流畅。技术工具的进化无论是像Spring AI这样的开发框架还是InsCode这样的云开发平台本质都是在帮开发者扫清障碍让我们能把更多精力集中在创造性的业务逻辑上而不是重复的环境配置和底层细节上。这个Spring AI多模型切换的Demo就是一个很好的效率提升实践。如果你也对统一AI接口感兴趣不妨按照这个思路试试相信你也能很快感受到这种开发模式带来的便捷。