目录SpringAI Alibaba上一节第2章Ollama本地部署大模型Qwen3本节第3章快速入门SpringAI Alibaba下一节待更新第3章快速入门 Spring AI Alibaba前两章我们已经分别完成了两件很重要的事情先在云端把大模型调用链路跑通再在本地把 Qwen3 跑起来到了这一步一个更贴近 Java 开发者的问题自然就出现了如果我要在 Spring Boot 项目里真正接入大模型到底该怎么做很多人第一反应会想到Spring AI。但当你真正开始接国内模型、接阿里云百炼、接本地 Ollama 时很快就会发现光知道Spring AI还不够真正更顺手的往往是Spring AI Alibaba。这一章我们就用一个最小可跑通的例子快速上手Spring AI Alibaba把云端模型、本地模型、同步对话、日志记录和流式输出这几件事串起来。Spring AI 和 Spring AI Alibaba 到底有什么区别先说结论Spring AI更像是一套通用的大模型接入标准而Spring AI Alibaba则是在这个基础上针对阿里云百炼和国内模型生态做了更贴近实战的增强。官方网站https://java2ai.com如果只用一句话来理解两者的关系可以这样看Spring AI标准能力框架Spring AI Alibaba更适合国内模型接入场景的落地方案对很多国内开发者来说真正的痛点并不是“不会写 Java 代码”而是“接模型的时候总有各种兼容细节”。比如模型配置方式、平台适配、调用体验、生态整合等这些问题一旦叠加就会让一个本来很简单的 Demo 变得不再简单。而Spring AI Alibaba的价值恰恰就在于它把这些接入成本往下压了一层。你可以把它的优势理解为三点兼容Spring AI的整体标准对阿里云百炼的支持更自然同时也方便接入本地模型能力例如Ollama这意味着我们既可以保留 Spring 体系里的开发习惯又能更顺畅地把国内云模型和本地模型接进同一个项目里。图1Spring AI Alibaba 官网首页第一步完成项目初始化和依赖准备真正开始写代码之前先把基础环境搭好。这一部分的目标很明确让 Spring Boot 项目同时具备三类能力接入阿里云百炼模型接入本地 Ollama 模型具备后续扩展记忆、RAG 等能力的基础依赖下面是示例依赖配置propertiesjava.version21/java.versionspring-ai.version1.0.0/spring-ai.versionspring-ai-alibaba.version1.0.0.2/spring-ai-alibaba.versionspring-boot.version3.4.5/spring-boot.version/propertiesdependencyManagementdependenciesdependencygroupIdcom.alibaba.cloud.ai/groupIdartifactIdspring-ai-alibaba-bom/artifactIdversion${spring-ai-alibaba.version}/versiontypepom/typescopeimport/scope/dependencydependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-dependencies/artifactIdversion${spring-boot.version}/versiontypepom/typescopeimport/scope/dependencydependencygroupIdorg.springframework.ai/groupIdartifactIdspring-ai-bom/artifactIdversion${spring-ai.version}/versiontypepom/typescopeimport/scope/dependency/dependencies/dependencyManagementdependenciesdependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-web/artifactId/dependencydependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-test/artifactIdscopetest/scope/dependencydependencygroupIdcom.alibaba.cloud.ai/groupIdartifactIdspring-ai-alibaba-starter-dashscope/artifactId/dependencydependencygroupIdorg.projectlombok/groupIdartifactIdlombok/artifactIdoptionaltrue/optional/dependencydependencygroupIdorg.springframework.ai/groupIdartifactIdspring-ai-starter-model-ollama/artifactId/dependencydependencygroupIdcom.alibaba.cloud.ai/groupIdartifactIdspring-ai-alibaba-starter-memory-redis/artifactId/dependencydependencygroupIdredis.clients/groupIdartifactIdjedis/artifactIdversion5.2.0/version/dependency/dependenciesbuildpluginsplugingroupIdorg.springframework.boot/groupIdartifactIdspring-boot-maven-plugin/artifactId/plugin/plugins/build如果你第一次看这段依赖不需要一上来就把每个包都研究透。先抓住最关键的几项就够了spring-ai-alibaba-starter-dashscope用于接入阿里云百炼spring-ai-starter-model-ollama用于接入本地 Ollamaspring-ai-alibaba-starter-memory-redis为后续记忆能力预留扩展空间也就是说这个工程从一开始就不是只为“跑一个聊天接口”准备的而是已经具备继续往更复杂 AI 应用演进的基础。第二步完成基础配置依赖准备好之后下一步就是配置模型连接信息。这里建议使用application.yml而不是把模型相关参数散落在代码里。这样后续切换模型、切换环境、切换云端或本地服务时都会轻松很多。示例配置如下spring:application:name:SpringAIAlibaba-RAG-Milvusai:dashscope:api-key:${DASHSCOPE_API_KEY}chat:model:qwen-plusoptions:temperature:0.7ollama:enabled:truebase-url:http://localhost:11434chat:model:qwen3:1.7boptions:temperature:0.7server:port:8080这里有一个对外发布时必须注意的点不要在文章或代码仓库里直接暴露真实 API Key。所以在正式分享时更推荐像上面这样写成环境变量形式api-key:${DASHSCOPE_API_KEY}这样既保留了配置结构也避免把敏感信息直接暴露出去。如果你从理解配置的角度来读这段内容可以重点关注三件事云端模型这里使用的是qwen-plus本地模型这里接的是qwen3:1.7b两套模型都被纳入了同一个 Spring Boot 配置体系中这一步做完其实就意味着你的项目已经同时具备了调用“云模型”和“本地模型”的基础能力。第三步创建 ChatClient 配置有了依赖和配置之后接下来要做的就是把模型真正封装成项目里可直接使用的ChatClient。这一步的意义在于后面的控制器、服务层、工作流逻辑都不需要直接关心底层模型初始化细节而是直接面向ChatClient编程。示例配置类如下ConfigurationpublicclassChatConfig{BeanpublicChatClientdashscopeChatClient(Qualifier(dashscopeChatModel)ChatModeldashscopeChatModel){returnChatClient.builder(dashscopeChatModel).build();}BeanpublicChatClientollamaChatClient(Qualifier(ollamaChatModel)ChatModelollamaChatModel){returnChatClient.builder(ollamaChatModel).build();}}如果你把它翻译成人话其实就是给云端 DashScope 模型创建一个ChatClient给本地 Ollama 模型创建一个ChatClient这样后面我们就可以像调用普通组件一样分别去调用云端模型和本地模型而不需要在业务代码里重复写初始化逻辑。第四步先写出第一个同步对话接口环境和配置都准备好之后最自然的下一步就是先把最基础的聊天接口跑起来。下面是一个最小示例RestControllerRequestMapping(/api/ai)publicclassSimpleAiController{AutowiredprivateChatClientdashscopeChatClient;AutowiredprivateChatClientollamaChatClient;/** * 云端模型聊天接口 */GetMapping(/chat/alibaba)publicStringchat(RequestParam(question)Stringquestion){returndashscopeChatClient.prompt(question).call().content();}/** * 本地模型聊天接口 */GetMapping(/chat/ollama)publicStringollamaChat(RequestParam(question)Stringquestion){returnollamaChatClient.prompt(question).call().content();}}这段代码虽然简单但它已经完成了一件非常有价值的事情同一个 Spring Boot 项目同时暴露了云端模型和本地模型的调用入口。从工程视角看这一步能帮助我们快速回答两个问题云端模型能不能正常调用本地模型能不能在同一套项目结构里正常接入很多时候真正的开发节奏不是一开始就追求复杂能力而是先把最短调用链路跑通。只要这一步通了后面的上下文管理、日志记录、流式输出和 RAG 才有继续往上叠加的基础。第五步用 Advisor 给 AI 对话加日志当最基础的聊天接口跑通之后接下来非常值得做的一件事就是把日志接进来。因为在 AI 应用开发里很多问题都不是“接口有没有返回”而是请求到底发了什么模型到底怎么回的参数是否符合预期Token 消耗是否合理这时候Advisor就很有用了。你可以把它理解成 AI 对话流程里的“拦截增强器”。在请求发送前后它可以自动插入额外逻辑例如日志记录、审查、监控等。一句话理解Advisor 可以看作 AI 调用链路中的拦截器用来在请求前后自动附加额外逻辑。示例配置如下ConfigurationpublicclassAIClientConfig{/** * 配置本地 Ollama 的 ChatClient带日志记录 */Bean(nameollamaChatClient)publicChatClientollamaChatClient(OllamaChatModelollamaChatModel){returnChatClient.builder(ollamaChatModel).defaultAdvisors(newSimpleLoggerAdvisor()).build();}/** * 配置云端 DashScope 的 ChatClient带日志记录 */Bean(namedashscopeChatClient)PrimarypublicChatClientdashscopeChatClient(DashScopeChatModeldashscopeChatModel){returnChatClient.builder(dashscopeChatModel).defaultAdvisors(newSimpleLoggerAdvisor()).build();}}这一步做完之后最大的价值不是“代码更炫了”而是你的 AI 调试能力会明显提升。因为从这一刻开始你不再只是看到一个最终回复而是能看到请求消息内容模型参数返回结果结构Token 使用情况这些信息对于后续做提示词优化、问题排查、性能分析都会非常有帮助。第六步日志结果到底该怎么看当SimpleLoggerAdvisor生效之后你会在日志里看到完整的请求和响应信息。下面是一段典型的返回示例2026-05-02T08:34:36.38408:00DEBUG...request:ChatClientRequest[promptPrompt{messages[UserMessage{content你是什么模型,...}],modelOptionsDashScopeChatOptions:{model:qwen-plus,temperature:0.7,...}},context{}]2026-05-02T08:34:38.23508:00DEBUG...response:{metadata:{usage:{promptTokens:12,completionTokens:67,totalTokens:79}},results:[{output:{text:我是通义千问Qwen由通义实验室研发的超大规模语言模型。...}}]}对外写文章时其实没必要把整段完整日志一股脑贴出来。更适合读者的方式是告诉他们应该重点看什么请求里真正发给模型的内容是什么本次调用使用的是哪个模型usage里记录了多少 Token 消耗返回文本是否符合预期换句话说日志最重要的价值不是“展示信息很多”而是帮我们快速定位调用过程中的关键信号。这也是为什么在 AI 工程实践里日志常常不是可选项而是基础能力。第七步再补一个流式接口同步对话跑通之后下一步通常就是流式输出。因为很多真实场景里我们并不希望模型把整段内容生成完再一次性返回而是更希望它像聊天产品一样边生成边输出。这样用户的体感会更自然交互也会更流畅。示例代码如下/** * 流式聊天接口 */GetMapping(value/stream/chat/ollama,producestext/html;charsetutf-8)publicFluxStringstreamChat(RequestParam(question)Stringquestion,HttpServletResponseresponse){returnollamaChatClient.prompt(question).stream().content();}这段代码的核心并不复杂关键点只有一个call()适合同步结果stream()适合流式返回。也就是说当你从.call().content()切换到.stream().content()你的接口能力就从“一次性返回结果”变成了“持续输出生成内容”。对于后面做聊天界面、流式问答、长文本生成来说这一步会非常关键。写在最后如果说前两章解决的是“模型能不能用”那么这一章解决的就是如何把模型真正接进一个 Spring Boot 工程。通过Spring AI Alibaba我们不仅能更自然地接入阿里云百炼也能把本地Ollama模型一起纳入同一个项目体系中。再往上叠加Advisor日志和流式接口之后一个最基础但已经很有实战味道的 AI 应用骨架其实就已经搭起来了。更重要的是当你亲手把这些代码跑通后你对 AI Java 开发的理解就会从“知道概念”进入“会搭工程”的阶段。