1. 项目概述这不是“又一个Spring Boot Demo”而是一次对AI集成范式的重新校准“Spring AI 初体验配好 yml 就能聊ChatClient 四步链式调用”——这个标题乍看像极了某次内部技术分享的PPT副标题但背后藏着一个被多数人低估的事实Spring生态正在把大模型能力从“需要写一堆胶水代码的基础设施层”拉回到“开箱即用的应用逻辑层”。我第一次在本地跑通这个流程时没有写一行HTTP客户端封装没碰一次JSON序列化甚至没打开OpenAI官网查API Key格式只改了3个yml字段、写了4行Java代码就让一个空荡荡的Spring Boot应用开口说话了。这背后不是魔法而是Spring AI 0.8.x之后确立的一套全新抽象契约它不试图替代LangChain也不硬刚Llama.cpp而是专注做一件事——让Java工程师用他们最熟悉的配置驱动和链式编程习惯去消费任何合规的LLM服务。核心关键词“yml配置”“ChatClient”“四步调用”绝非营销话术而是三个精准锚点yml是Spring Boot的呼吸节奏ChatClient是统一的语义入口四步则是从请求构造到结果解析的最小完备路径。它适合谁不是算法研究员也不是全栈架构师而是每天和Controller、Service、Repository打交道、想快速验证某个业务场景是否值得上RAG或Agent但又不想被向量库选型拖住手脚的后端开发也适合带学生做课程设计的某高校导师能在两节课内让学生从“Hello World”跨越到“调用大模型生成实验报告摘要”。它解决的不是“能不能用大模型”的问题而是“要不要为一次简单问答搭一套微服务、写十页文档、配五个环境变量”的决策成本问题。这种轻量级集成恰恰是当前企业级AI落地中最稀缺的“最小可行性触点”。2. 核心设计思路拆解为什么是“yml ChatClient”而不是“AutoConfiguration Template”2.1 拒绝“重抽象”拥抱“配置即契约”很多团队在引入AI能力时第一反应是封装一个AIService里面塞满generateText()、embed()、stream()等方法再搞个工厂模式根据模型类型返回不同实现。Spring AI没走这条路。它的核心设计哲学是模型调用的本质是参数化请求与结构化响应的映射而Spring Boot最擅长的正是将YAML/Properties中的键值对精准注入到类型安全的对象中。所以你看spring.ai.*这一整套命名空间它不叫spring.ai.openai.client而叫spring.ai.openai.chat.options.temperature——这个.options.层级的存在就是在明确告诉你“温度值”不是OpenAI专属参数而是所有支持聊天能力的模型Anthropic、Azure、Ollama都必须遵循的语义契约。我试过把同一份yml里的openai前缀换成anthropic只改了3个字段整个应用就无缝切到了Claude连Java代码都不用动。这种设计规避了传统方案里“每个模型写一套Adapter”的泥潭。它背后的工程权衡很务实与其花三个月设计一个能兼容未来十年新模型的万能接口不如先用配置约定好当前主流模型共有的12个关键参数temperature、topP、maxTokens、stopSequences等剩下的交给具体实现去扩展。这就像Spring Data JPA的Query注解——你不用关心Hibernate怎么生成SQL但必须理解?1代表第一个参数。Spring AI的yml就是你的“AI Query DSL”。2.2 ChatClient不是客户端而是“对话意图”的声明式表达ChatClient这个名字极具迷惑性。如果你按字面意思去理解会以为它是个类似RestTemplate的网络调用工具。实际上它是Spring AI里最精妙的抽象层——一个承载“对话上下文、系统提示、用户消息、输出解析规则”四重语义的不可变构建器。它的链式调用.withSystemPrompt()→.withUserMessage()→.stream()根本不是在拼接HTTP请求而是在声明“我要发起一次具备系统角色设定、携带历史消息、并以流式方式接收Token的对话”。我曾对比过直接用WebClient调用OpenAI API的代码要手动构造ChatCompletionRequest对象处理messages数组的嵌套结构还要写回调函数解析ChatCompletionChunk。而ChatClient把这一切编译期就固化了.withSystemPrompt(你是一个严谨的学术助手)会自动把这段文本塞进messages[0]且标记为system.withUserMessage(请总结这篇论文)则生成messages[1]并标记为user。更关键的是.stream()方法返回的不是FluxChatResponse而是FluxString——它已经帮你完成了从delta.content到纯文本的提取。这种设计让开发者从“协议细节搬运工”回归到“业务意图定义者”。它不阻止你深入底层ChatClient底层确实封装了WebClient但它坚决要求你先用高层语义把意图说清楚再决定是否需要降级操作。2.3 “四步链式调用”的底层逻辑为什么必须是这四步标题里强调的“四步”指的是ChatClient最常用的调用链.withSystemPrompt()→.withUserMessage()→.call()→.content()。这绝非随意排列而是严格对应LLM交互的四个不可跳过的阶段系统提示System Prompt这是模型的“人格设定”决定了它回答问题的风格、知识边界和伦理约束。Spring AI强制要求显式声明杜绝了“默认系统提示可能泄露敏感信息”的风险。我在线上环境吃过亏某次忘记设系统提示模型在回复中无意间复述了前一个用户的手机号因上下文残留后来强制要求所有ChatClient调用必须前置.withSystemPrompt(你是一个无状态的助手不记忆任何用户信息)才解决。用户消息User Message这是真正的业务输入。Spring AI在这里做了个关键优化——它支持String、Message对象、甚至ListMessage三种传参形式。当你传入ListMessage时它会自动合并成符合OpenAI规范的messages数组且自动处理role字段user/assistant/system。这意味着你可以轻松实现多轮对话把上一轮的response.getOutput().getChoices().get(0).getMessage()存下来下一轮作为withUserMessage()的参数传入完全不用手撕JSON。执行调用call()这是真正的网络触发点。但注意call()返回的不是原始响应体而是ChatResponse对象。这个对象里封装了output结构化结果、metadatatoken用量、模型ID、usage详细计费信息三大块。我特别喜欢metadata.getModel()这个字段——它能让你在日志里清晰看到“本次请求实际调用的是gpt-4-turbo还是gpt-3.5-turbo”这对成本审计至关重要。内容提取content()最后一步.content()看似简单实则暗藏玄机。它不是简单取response.getOutput().getChoices().get(0).getMessage().getContent()而是做了容错处理当模型返回空内容、或choices为空列表时它会抛出RuntimeException而非返回null强制你在业务层处理异常分支。这种“宁可失败也不静默”的设计比那些返回空字符串还假装成功的SDK靠谱得多。这四步构成一个闭环从设定边界system到输入问题user到触发执行call到安全取值content。少任何一步都会导致语义缺失或运行时错误。它不是为了炫技而是把LLM调用中90%的共性错误如忘记设system prompt导致回答不专业、忽略choices为空导致NPE、不检查token用量导致账单爆炸提前扼杀在编译期和调用链设计里。3. 实操细节与配置要点yml里那17个字段哪些必须填哪些可以赌一把3.1 最小可行yml配置从“能跑”到“跑得稳”的三阶演进很多教程一上来就贴出30行yml新手直接懵圈。其实Spring AI的启动依赖极简我们分三步走第一阶段仅保证启动不报错3行spring: ai: openai: api-key: ${OPENAI_API_KEY:sk-xxx} # 必填否则启动失败此时应用能启动但任何ChatClient调用都会抛IllegalStateException因为缺少基础连接配置。第二阶段实现基础对话再加5行spring: ai: openai: api-key: ${OPENAI_API_KEY:sk-xxx} base-url: https://api.openai.com/v1/ # 必填指定API入口 chat: options: model: gpt-3.5-turbo # 必填告诉客户端用哪个模型 temperature: 0.7 # 推荐填控制创造性 max-tokens: 512 # 强烈建议填防止单次请求耗尽配额此时ChatClient能正常工作但每次调用都是“裸奔”——没有系统提示、没有历史上下文、没有错误重试。第三阶段生产可用配置终极17字段清单spring: ai: openai: api-key: ${OPENAI_API_KEY:sk-xxx} base-url: https://api.openai.com/v1/ # 连接池与超时关键 client: connect-timeout: 10s read-timeout: 60s max-connections: 100 chat: options: model: gpt-4-turbo temperature: 0.3 # 业务问答推荐0.1~0.5 top-p: 0.9 max-tokens: 1024 stop-sequences: [\n\n] # 防止模型胡说八道 frequency-penalty: 0.2 presence-penalty: 0.2 # 响应格式高级用法 response-format: type: json_object # 要求模型返回JSON需配合system prompt # 全局重试策略救命稻草 retry: max-attempts: 3 backoff: multiplier: 2 max-delay: 10000ms这17个字段里标“必填”的只有api-key、base-url、model三个。但实战中connect-timeout和read-timeout不设等于裸奔——OpenAI偶尔有10秒级延迟没超时设置会导致线程池被占满max-tokens不设等于给黑客送漏洞——恶意用户发10万字prompt你的账单瞬间爆炸retry不配等于放弃SLA——网络抖动时请求失败率飙升。我在线上环境实测过加了retry后因网络波动导致的5xx错误下降了73%。3.2 四步调用的Java代码从“Hello World”到“生产就绪”的5个版本光有yml不够Java代码才是灵魂。下面展示从最简到最稳的演进版本1教科书式Hello World2行Autowired private ChatClient chatClient; String result chatClient .withUserMessage(你好) .call() .content();能跑但毫无健壮性。call()可能抛HttpClientErrorException4xx、ResourceAccessException网络异常、RuntimeException模型返回空全都没捕获。版本2基础异常处理5行try { String result chatClient.withUserMessage(你好).call().content(); log.info(AI回复: {}, result); } catch (HttpClientErrorException e) { log.error(客户端错误: {}, e.getStatusCode(), e); } catch (ResourceAccessException e) { log.error(网络错误: {}, e.getMessage(), e); } catch (RuntimeException e) { log.error(AI服务异常: {}, e.getMessage(), e); }覆盖了主要异常但content()仍可能为null虽然概率低且没做任何降级逻辑。版本3带降级的防御式编程8行String result Optional.ofNullable( chatClient.withUserMessage(你好).call().content()) .filter(StringUtils::isNotBlank) .orElseGet(() - { log.warn(AI返回空内容启用降级文案); return 抱歉当前AI服务繁忙请稍后再试; });用Optional和filter确保不返回空字符串降级文案写死在代码里——适合内部系统。版本4配置化降级推荐Value(${ai.fallback.response:AI服务暂时不可用}) private String fallbackResponse; // 在调用处 String result Optional.ofNullable(chatClient.withUserMessage(你好).call().content()) .filter(StringUtils::isNotBlank) .orElse(fallbackResponse);把降级文案提到yml里运维可随时热更新无需发版。版本5全链路可观测线上必备long start System.currentTimeMillis(); try { ChatResponse response chatClient .withSystemPrompt(你是一个客服助手用中文回答不超过50字) .withUserMessage(userInput) .call(); String content response.content(); long cost System.currentTimeMillis() - start; // 上报监控指标 meterRegistry.counter(ai.call.success, model, response.getMetadata().getModel(), costMs, String.valueOf(cost)) .increment(); log.info(AI调用成功 | 模型:{} | 耗时:{}ms | Token用量:{}, response.getMetadata().getModel(), cost, response.getUsage().getTotalTokens()); return content; } catch (Exception e) { long cost System.currentTimeMillis() - start; meterRegistry.counter(ai.call.error, exception, e.getClass().getSimpleName()).increment(); log.error(AI调用失败 | 耗时:{}ms | 异常:{}, cost, e.getMessage(), e); throw e; // 或返回fallback }这才是生产环境该有的样子记录模型名、耗时、Token用量上报Prometheus指标日志带关键维度。我所在某公司就靠这套监控在一次OpenAI API限流事件中10分钟内定位到gpt-4-turbo调用量激增300%及时切到gpt-3.5-turbo保住了核心业务。3.3 多模型切换实战如何用同一套代码同时对接OpenAI、Ollama、AzureSpring AI最被低估的能力是它的“模型无关性”。下面是我压测过的三模型共存方案第一步yml里定义多个配置段spring: ai: openai: api-key: ${OPENAI_API_KEY} base-url: https://api.openai.com/v1/ chat: options: model: gpt-4-turbo ollama: base-url: http://localhost:11434 chat: options: model: llama3:8b azure-openai: api-key: ${AZURE_API_KEY} endpoint: https://your-resource.openai.azure.com/ deployment-name: gpt-4-turbo api-version: 2024-02-15-preview第二步Java中通过Qualifier注入特定ClientAutowired Qualifier(openAiChatClient) private ChatClient openAiClient; Autowired Qualifier(ollamaChatClient) private ChatClient ollamaClient; Autowired Qualifier(azureOpenAiChatClient) private ChatClient azureClient;第三步业务层动态路由关键public String callModel(String modelName, String userInput) { return switch (modelName.toLowerCase()) { case openai - openAiClient.withUserMessage(userInput).call().content(); case ollama - ollamaClient.withUserMessage(userInput).call().content(); case azure - azureClient.withUserMessage(userInput).call().content(); default - throw new IllegalArgumentException(不支持的模型: modelName); }; }第四步灰度发布控制高阶技巧Value(${ai.model.strategy:openai}) // 默认走OpenAI private String defaultModel; // 在Controller里 GetMapping(/chat) public String chat(RequestParam String query) { // 5%流量切到Ollama做AB测试 String modelToUse Math.random() 0.05 ? ollama : defaultModel; return callModel(modelToUse, query); }这套方案让我在某次技术评审中说服了CTO我们不需要为每个模型建一套微服务只需在yml里增删几行就能完成模型供应商的快速切换。当OpenAI突然涨价时我们用3小时就把70%的非核心问答流量切到了自建Ollama集群成本直降65%。4. 实操过程详解从零搭建一个“会议纪要生成器”的完整链路4.1 需求还原为什么选这个场景它暴露了哪些真实痛点某高校导师找到我希望做一个工具上传一段会议录音转写的文字约5000字自动生成三点式纪要结论/待办/风险并支持导出Word。表面看是NLP任务但深挖发现三个痛点输入质量差录音转写文本充满“呃”、“啊”、“这个那个”等填充词还有大量重复语句输出格式刚性必须严格按“【结论】xxx【待办】xxx【风险】xxx”格式不能多一个字、少一个标点成本敏感每月约200次调用但gpt-4-turbo单次成本是gpt-3.5-turbo的8倍必须精准控制Token用量。这恰好是Spring AI的黄金场景用yml配置预处理规则用ChatClient链式调用保证输出格式用response-format: json_object强制结构化。4.2 Step-by-Step搭建过程每一步都附带避坑说明Step 1创建Spring Boot项目3分钟Spring Initializr选Spring Web、Spring AI OpenAI或Spring AI Ollama、Lombok避坑提示务必选Spring Boot 3.2Spring AI 0.8.x要求Jakarta EE 9若用2.7.x会报ClassNotFoundException: jakarta.annotation.PostConstruct。Step 2yml配置12行含关键注释spring: ai: openai: api-key: ${OPENAI_API_KEY} base-url: https://api.openai.com/v1/ chat: options: model: gpt-3.5-turbo-0125 # 选最新廉价模型 temperature: 0.1 # 低温度保准确性 max-tokens: 1024 # 精确计算5000字输入≈7000Token输出1024足够 response-format: type: json_object # 强制返回JSON避免格式错乱 # 关键预处理过滤填充词 client: connect-timeout: 15s read-timeout: 90s # 长文本处理需更长超时Step 3定义结构化响应DTO4行POJOData public class MeetingSummary { private String conclusion; // 【结论】 private String todo; // 【待办】 private String risk; // 【风险】 }提示Spring AI会自动将JSON响应反序列化为这个对象前提是response-format: json_object已启用且system prompt明确要求返回此结构。Step 4编写核心Service18行含容错Service public class MeetingSummaryService { Autowired private ChatClient chatClient; public MeetingSummary generateSummary(String rawTranscript) { // 预处理移除填充词业务强相关放这里比放yml灵活 String cleanText rawTranscript .replaceAll(呃|啊|嗯|这个|那个|然后|就是, ) .replaceAll(\\s, ) .trim(); // 构建结构化提示 String systemPrompt 你是一个专业的会议纪要助手。 请严格按以下JSON格式输出不要任何额外字符 {conclusion: 【结论】..., todo: 【待办】..., risk: 【风险】...} 输入文本可能包含口语化表达请提炼核心信息。 ; try { // 四步调用系统提示 用户消息 执行 反序列化 return chatClient .withSystemPrompt(systemPrompt) .withUserMessage(cleanText) .call() .contentAs(MeetingSummary.class); // 关键自动JSON转对象 } catch (Exception e) { log.error(纪要生成失败, e); // 降级返回空对象前端判空显示友好提示 return new MeetingSummary(); } } }注意contentAs(MeetingSummary.class)是Spring AI 0.8.1新增方法它会调用Jackson将JSON字符串反序列化为指定类型比手动new ObjectMapper().readValue()安全得多——自动处理null、类型转换异常等。Step 5Controller暴露API8行RestController RequestMapping(/api/summary) public class SummaryController { Autowired private MeetingSummaryService service; PostMapping public ResponseEntityMeetingSummary generate( RequestBody String transcript) { MeetingSummary summary service.generateSummary(transcript); // 若summary为空返回400而非500语义更准确 return summary.getConclusion() null || summary.getConclusion().isEmpty() ? ResponseEntity.badRequest().build() : ResponseEntity.ok(summary); } }Step 6前端调用示例JavaScript// 前端只需发一个POST请求 fetch(/api/summary, { method: POST, headers: {Content-Type: text/plain}, body: document.getElementById(transcript).value }) .then(r r.json()) .then(data { document.getElementById(conclusion).innerText data.conclusion; document.getElementById(todo).innerText data.todo; document.getElementById(risk).innerText data.risk; });实测效果5000字转写文本平均响应时间2.3秒Token用量稳定在980±20成本0.0012美元/次。相比之前用Python脚本Flask方案需维护Docker、Nginx、SSL部署复杂度下降80%。4.3 性能压测与调优单机QPS从12到217的实录用JMeter对上述服务做压测初始结果惨不忍睹10并发下QPS仅12错误率37%。排查发现三个瓶颈瓶颈1HTTP连接池耗尽现象java.net.SocketException: No buffer space available根因默认max-connections: 1010并发直接打满解决yml中设max-connections: 200max-connections-per-route: 50瓶颈2线程阻塞在call()现象Thread State: WAITING占比超60%根因call()是同步阻塞调用每个请求独占一个Tomcat线程解决改用stream()Flux异步处理需WebFlux依赖public FluxString streamSummary(String transcript) { return chatClient .withSystemPrompt(...) .withUserMessage(transcript) .stream() // 返回FluxString .doOnNext(chunk - log.debug(收到chunk: {}, chunk)); }瓶颈3JSON反序列化GC压力大现象Young GC频率达5秒/次停顿200ms根因contentAs()每次新建ObjectMapper实例解决全局复用ObjectMapperSpring AI 0.8.2已修复但旧版需手动Bean Primary public ObjectMapper objectMapper() { return JsonMapper.builder() .addModule(new JavaTimeModule()) .configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false) .build(); }最终压测结果并发数QPS错误率平均延迟50870%320ms1001560%410ms2002170.2%580ms实操心得Spring AI的性能天花板不在框架本身而在你对WebClient连接池、JVM GC、以及同步/异步模型的理解。别迷信“自动配置”生产环境必须亲手调每一个螺丝。5. 常见问题与排查技巧实录那些官方文档不会写的血泪教训5.1 经典问题速查表按发生频率排序问题现象根本原因解决方案我的实操记录启动报错No qualifying bean of type ChatClientspring-ai-openai-spring-boot-starter未正确引入或Spring Boot版本不匹配检查Maven依赖树mvn dependency:tree | grep ai确认Spring Boot 3.2若用Gradle确认implementation org.springframework.ai:spring-ai-openai-spring-boot-starter某次升级Spring Boot到3.3.0-M1因Spring AI尚未适配降级回3.2.4解决调用返回空字符串日志无报错content()方法在choices为空时抛RuntimeException但被全局异常处理器吞掉在ControllerAdvice中单独捕获RuntimeException并打印response.toString()我在ChatResponse对象上打了断点发现response.getOutput().getChoices()是空集合原因是OpenAI返回了{error:{message:Rate limit reached...}}但Spring AI没解析这个错误体中文乱码返回“”符号WebClient默认编码为ISO-8859-1而OpenAI返回UTF-8在application.yml中添加spring.web.charset.force-responsetrue或自定义WebClientBean这个坑我踩了两次第二次直接在WebClientCustomizer里强制设codecs { it.defaultCodecs().maxInMemorySize(10 * 1024 * 1024) }max-tokens不生效模型仍返回超长文本max-tokens是请求参数但模型可能忽略它尤其开源模型改用stop-sequences设终止符如[\n\n, 。, ]或在content()后手动截断对Ollama的llama3模型max-tokens基本无效必须配stop-sequencesresponse-format: json_object返回普通字符串system prompt未明确要求JSON格式或模型不支持该参数如gpt-3.5-turbo-0613不支持升级到gpt-3.5-turbo-0125或gpt-4-turbosystem prompt首句写“请严格按JSON格式输出不要任何额外说明”我用curl手动调OpenAI API验证发现gpt-3.5-turbo-0613返回{error: invalid_request_error}换模型后解决5.2 高级调试技巧如何像侦探一样追踪一次失败的AI调用当ChatClient调用失败别急着改代码。按这个顺序排查第一步开启DEBUG日志最有效logging: level: org.springframework.ai: DEBUG org.springframework.web.reactive.function.client: DEBUG启动后你会看到类似日志DEBUG o.s.a.o.c.OpenAiChatClient - Sending request: POST https://api.openai.com/v1/chat/completions DEBUG o.s.w.r.f.c.ExchangeFunctions - [7a8b9c] Response 200 OK DEBUG o.s.a.o.c.OpenAiChatClient - Received response: {id:chat...,choices:[{message:{content:{\conclusion\:\...\}}}]}这比任何断点都快——直接看到原始请求体和响应体。我靠这招发现过三次问题一次是API Key权限不足返回401但Spring AI吞掉了错误信息一次是base-url末尾少了/v1返回404一次是system prompt里用了中文引号导致JSON解析失败。第二步用WebClient拦截器抓包终极手段Bean public WebClient.Builder webClientBuilder() { return WebClient.builder() .exchangeStrategies(ExchangeStrategies.builder() .codecs(configurer - configurer.defaultCodecs() .maxInMemorySize(10 * 1024 * 1024)) .build()) .filter((request, next) - { log.info(REQUEST: {} {}, request.method(), request.url()); log.info(HEADERS: {}, request.headers()); return next.exchange(request); }) .filter((response, next) - { log.info(RESPONSE STATUS: {}, response.statusCode()); return next; }); }这个拦截器会打印每一次HTTP调用的完整头信息包括Authorization、Content-Type甚至能帮你确认API Key是否被正确注入。第三步绕过Spring AI直连API验证隔离故障写一个临时ControllerGetMapping(/debug/openai) public String debugOpenAI() throws Exception { String url https://api.openai.com/v1/chat/completions; String json {model:gpt-3.5-turbo,messages:[{role:user,content:test}]} ; HttpClient httpClient HttpClient.newHttpClient(); HttpRequest request HttpRequest.newBuilder() .uri(URI.create(url)) .header(Authorization, Bearer System.getenv(OPENAI_API_KEY)) .header(Content-Type, application/json) .POST(HttpRequest.BodyPublishers.ofString(json)) .build(); HttpResponseString response httpClient.send(request, HttpResponse.BodyHandlers.ofString()); return response.body(); }如果这个能通说明网络和Key没问题问题一定在Spring AI配置如果这个不通说明是环境问题代理、DNS、防火墙。5.3 生产环境必须做的5件事血的教训总结永远不要在yml里硬编码API Key错误api-key: sk-xxx正确api-key: ${OPENAI_API_KEY:sk-xxx}并用K8s Secret或AWS Parameter Store管理教训某次Git提交误传ymlKey泄露3小时内账单超$2000。为每个ChatClient调用设置唯一Trace IDMDC.put(ai_trace_id, UUID.randomUUID().toString()); String result chatClient.withUserMessage(input).call().content(); MDC.clear();不然日志里全是ChatClient无法关联到具体业务请求。监控total_tokens设置告警阈值在ChatResponse.getUsage().getTotalTokens()上埋点当单次5000时告警——这通常是Prompt注入攻击的标志。定期轮换API KeyOpenAI控制台可设Key有效期我设为30天自动过期并用CI/CD自动更新Secret。准备离线Fallback方案当所有AI服务不可用时至少要有基于规则的关键词匹配引擎如用Apache Lucene实现简易FAQ而不是返回“服务不可用”。我在某次OpenAI全球中断事件中靠这个Fallback撑过了47分钟。6. 后续演进方向从“能聊”到“会思考”的三步跃迁Spring AI的“yml配置四步调用”只是起点。基于当前项目我规划了三条清晰的演进路径6.1 第一步接入RAG检索增强生成让AI“有据可查”当前会议纪要生成器依赖模型自身知识但实际会议常涉及公司内部文档。下一步是接入RAG技术选型用Spring AI内置的VectorStore抽象底层对接Milvus高性能向量库yml配置新增spring.ai.vector-store.type: milvus自动注入VectorStoreBean代码改造ChatClient升级为ChatClientRetrievalAugmentor四步调用变为五步.withSystemPrompt()→.withUserMessage()→.withRetrieval()→.call()→.content()关键收益会议中提到的“