Spring AI 1.0 像是把 Java 开发者带进了大模型世界：终于不用绕到 Python 那边才能写 AI 应用了。Spring AI 2.0 则更像是另一个阶段：不只是能调模型，而是要把 AI 能力塞回企业系统里，接上权限、日志、知识库、工具调用、监控和发布流程。
一、那个熟悉的问题又回来了
前段时间和一个做 Java 后端的朋友聊天，他说他们公司终于决定把内部知识库接上大模型。
一开始大家都挺兴奋。
产品经理想要一个能回答制度问题的助手，客服团队想让它自动查工单，研发团队想让它读接口文档，老板则希望它以后能接审批、报表和数据分析。
听起来很美。
真正开始做的时候，后端团队卡住了。
因为他们的主系统全是 Spring Boot：订单、客户、权限、工单、知识库、日志、监控，全部在 Java 体系里。可是大模型生态那边，示例代码大多是 Python，教程不是 LangChain，就是 FastAPI，再不然就是各种 Python SDK。
于是团队里出现了一个很熟悉的争论：
“要不要单独起一个 Python AI 服务？”
这个问题看起来只是技术选型，实际上是工程体系的分叉口。
如果每做一个 AI 能力都单独起一套 Python 服务，短期确实快。Demo 两天能跑，老板一看也高兴。但过几个月，事情就麻烦了：权限要打通，日志要采集，链路要追踪，部署要进流水线，敏感信息要脱敏，业务接口要治理，事故要有人背锅。
这时候 Java 团队才会意识到：AI 应用不是一个聊天窗口，它迟早要回到企业工程体系里。
Spring AI 1.0 解决的就是第一层焦虑：Java 也能优雅地接入大模型。
Spring AI 2.0 开始回答第二个问题：Java AI 应用能不能像一个真正的企业系统那样长期维护？
这也是为什么 Spring AI 2.0 值得单独聊。它不是简单换了一个版本号，而是把 Spring AI 1.0 里已经有的能力继续往生产化方向推了一大步。
二、Spring AI 1.0 不是玩具，Spring AI 2.0 也不是重写
很多人一听到 2.0，就会下意识以为 1.x 是过渡版，2.0 才是真正能用的版本。
这对 Spring AI 不太公平。
Spring AI 1.0 已经把 Java AI 应用的基础骨架搭出来了。你能用它接 Chat Model，做 Embedding，连 Vector Store，写 RAG，用 ChatClient 调模型，挂 Advisors，做 Tool Calling，拿 Structured Outputs，还能接 Observability 和 ETL Pipeline。
换句话说，Spring AI 1.0 不是“只能跑个 Hello World”。
它真正的问题是：很多能力有了，但还在快速演进期。你能把东西拼起来，可一旦项目开始变大，就会遇到更细的工程问题。
比如同一个项目里，有人直接调模型 SDK，有人用 ChatClient；有人手写 RAG prompt，有人用 Advisor；有人把历史消息全塞进去，有人又单独维护一套 memory 表；工具调用有一套写法，日志采集又是另一套配置。
一开始没什么。
等业务越堆越多，AI 代码就会变成一片“能跑但不敢动”的区域。
Spring AI 2.0 的变化，重点不是“终于有 AI 了”，而是把这些能力继续收拢、清理、规范化。
它做的事情更像一次工程整理：旧的 deprecated API 该删就删，ChatClient 和 Advisors 继续强化，Tool Calling 按新方向调整，Memory 相关模块重新拆分，可观测性行为改造，OpenAI 兼容生态补上扩展参数，MCP 继续往 Agent 生态靠近。
所以如果要用一句话说清楚：
Spring AI 1.0 让 Java 项目能接上大模型；Spring AI 2.0 让这件事更像 Spring 项目里的一等公民。
三、ChatClient 变成了整条 AI 调用链的入口
我第一次看 Spring AI 的 ChatClient，第一反应其实很熟悉。
它有点像 AI 时代的 WebClient。
不是因为它们 API 长得一模一样，而是因为它们都在解决同一种问题：不要让底层调用细节散落在业务代码里。
在 Spring AI 1.0 里，你已经可以这样写：
String answer = chatClient.prompt().user("解释一下 RAG 是什么").call().content();这比直接对接各家模型 SDK 舒服多了。
但到了 Spring AI 2.0，ChatClient 的角色更明确：它不只是“发一个 prompt，拿一个回答”的客户端，而是整个 AI 调用链的组织入口。
你可以在这条链路上挂 system prompt、user prompt、Advisors、Memory、RAG、Tool Calling、Structured Output、流式输出和模型参数。
这个变化对 Demo 来说可能不明显。
Demo 里一共就三五个接口，怎么写都行。可企业项目不一样，一个知识库助手可能今天只回答文档问题，明天要接权限过滤，后天要接工具调用，下周又要加审计日志和 token 统计。
如果每个地方都手写一套模型调用逻辑，后面就会出现很难看的代码：
// 这里调 OpenAI// 那里调私有化模型// 这个接口手动拼 prompt// 那个接口自己查向量库// 另一个地方再手动解析 JSON短期能跑，长期就是债。
Spring AI 2.0 继续强化 ChatClient，本质上是在告诉 Java 开发者：把 AI 调用链收回来，不要让它在业务代码里野蛮生长。
四、Advisors 让 RAG 从手工作坊变成组合机制
很多团队第一次做 RAG，写法都差不多。
先拿用户问题去向量库检索，再把检索结果拼到 prompt 里，然后让模型回答。刚开始这套流程很直观，甚至还有点爽。
问题出在第二个接口、第三个接口、第五个接口。
你会发现大家都在复制同一段逻辑：查向量库、拼上下文、控制 topK、处理空结果、加引用来源、记录日志、再把结果交给模型。
改一次策略，全项目搜一遍。
这就是 Spring AI 里 Advisors 的价值。
你可以把 Advisor 理解成 AI 调用链上的增强器。它可以在请求进入模型前后做事情，比如加入对话记忆、执行 RAG 检索、注入上下文、记录日志、处理工具调用、修改模型参数。
在知识库场景里，QuestionAnswerAdvisor 就是很典型的例子。它把“根据问题检索相关内容，再交给模型回答”这件事封装到了调用链里，而不是让每个 Controller 都手动拼 prompt。
这很 Spring。
Spring 最擅长的从来不是让你少写一行代码，而是把重复模式抽成可组合、可配置、可替换的组件。
Spring AI 2.0 对 Advisors 相关 API 做清理和调整，去掉一些旧的 deprecated 用法，就是在把这套机制往正式工程里推。
RAG 不应该永远停留在“字符串拼接艺术”。
它应该变成一条可以被配置、测试、观测和替换的链路。
五、Tool Calling 是最容易让人兴奋，也最容易出事故的部分
如果说 ChatClient 和 Advisors 解决的是“怎么组织 AI 调用”，那 Tool Calling 解决的就是另一个更刺激的问题：模型能不能真的帮我干活？
不只是回答一句话，而是查订单、查库存、查客户、创建工单、调审批流、查实时数据、触发内部工具。
这也是很多老板最爱听的部分。
“以后是不是让 AI 直接处理工单？”
“是不是能让它自动查数据？”
“是不是能让它自己发起审批？”
技术上，Tool Calling 的确让这些事变得更近了。
但越接近真实业务，风险也越大。
Spring AI 2.0 的升级说明里明确提到，ChatClient 的 tool calling 有 breaking changes。这句话对老项目很重要：如果你的 Spring AI 1.0 项目大量用了工具调用，升级时不能只看编译是否通过。
工具调用最麻烦的地方，是它经常“编译没问题，行为变了”。
模型选择工具的时机、参数结构、上下文传递、历史对话是否参与判断、工具执行结果怎么回传，这些细节都会影响最终效果。
比如一个“查询订单”的工具，原来模型会稳定传 orderId。升级后如果上下文组织方式变了，它可能开始传用户手机号，或者把订单号和工单号混在一起。代码不一定报错，但业务结果已经偏了。
所以 Tool Calling 升级一定要单独测。
更重要的是，工具调用必须有边界。
读操作可以相对自动，写操作要二次确认，删除操作必须人工审批，涉及钱、权限、生产环境的操作必须有硬规则。
Spring AI 2.0 让 Tool Calling 更规范，但它不会替你设计安全边界。
企业系统里，工具调用是生产能力，不是玩具。
六、Memory 不是把聊天记录无限塞回去
做 AI 助手时，很多人都会很早提到“记忆”。
听起来也合理。
用户上次问过什么、偏好是什么、当前任务进行到哪里，如果系统都能记住，体验肯定更好。
但我见过不少项目，所谓 Memory 最后变成了一个很粗暴的实现：把历史对话全查出来，然后继续塞进 prompt。
前几轮还好。
用久了以后，token 越来越多，响应越来越慢，成本越来越高，模型还会被旧上下文带偏。
这不是记忆，这是垃圾袋。
Spring AI 2.0 的 upgrade notes 里有一组 Memory 相关变化：移除了 CassandraChatMemory 实现，简化了 chat memory advisor 层级，移除了 JdbcChatMemory 里的 deprecated API，重构了 chat memory repository artifacts，也调整了相关 auto-configuration 和 starters。
这些变化看起来很碎，但方向很明确：Memory 这块要从“能用”继续往“结构更清晰、更可维护”走。
真正的记忆应该分层。
短期会话记忆是一回事，用户偏好记忆是一回事，业务事实记忆是一回事，可检索知识库又是另一回事，审计日志更不能和上下文记忆混在一起。
如果你从 Spring AI 1.0 升级到 Spring AI 2.0，Memory 相关代码一定要单独测。尤其是 JDBC 存储、Advisor 组合顺序、conversation id 隔离、历史消息裁剪和 starter 自动配置。
Memory 不是越多越好。
能被正确取回、正确裁剪、正确隔离、正确审计，才是好记忆。
七、extraBody 看着小，但对本地模型很关键
Spring AI 2.0.0-M5 的发布说明里，OpenAI 相关模块被提到了不少，比如 spring-ai-openai、spring-ai-openai-sdk、spring.ai.openai，还有一个很值得注意的能力：extraBody。
这个名字看起来不起眼。
但如果你接过本地模型或者国内模型网关，就知道它有多实用。
现在很多模型服务都号称 OpenAI-compatible。比如 vLLM、Ollama、LMDeploy、Xinference、各种国产模型网关，以及企业内部自己封装的模型服务。
它们大体兼容 OpenAI API，但经常又多出一些自己的参数。
比如 reasoning 参数、thinking 开关、repetition_penalty、top_k、chat template 参数、自定义路由字段、特定推理引擎参数。
如果框架只允许你传标准 OpenAI 字段，问题就来了。
你的服务明明兼容 OpenAI 协议，但关键参数传不进去。最后只能绕开框架，自己封一层客户端。绕着绕着，统一抽象就被你绕没了。
extraBody 的价值就在这里：在不破坏统一抽象的前提下，让你给 OpenAI-compatible 服务传额外字段。
这对本地部署 Qwen、DeepSeek、GLM，或者对接企业内部模型网关都很关键。
Spring AI 2.0 在这块增强，实际意义比看起来大。它说明 Java 团队不只是在接 OpenAI 官方 API，也在认真面对现实里的混合模型生态。
八、Structured Output 决定 AI 能不能进入业务流程
聊天窗口喜欢自然语言，业务系统不喜欢。
业务系统喜欢确定的字段。
比如用户说：“帮我查一下 123456 这个订单现在到哪了。”
模型如果回答一段话，人看着当然没问题。但后端系统真正想要的是这种东西：
{"intent": "QUERY_ORDER","orderId": "123456","confidence": 0.92或者 Java 里的 POJO：
public record IntentResult(String intent,String orderId,double confidence这就是 Structured Output 的意义。
AI 应用一旦进入业务流程，输出就不能只是“看起来对”。它要能被程序继续处理，被规则校验，被日志记录，被测试覆盖。
Spring AI 2.0.0-M5 的新特性里提到 StructuredOutputConverter，说明这块还在继续整理和增强。
这很重要。
因为没有结构化输出，你就会被迫写一堆脆弱的字符串解析：从模型回答里截字段、猜意图、用正则找订单号、用 contains 判断分类。
Demo 里能跑，生产里迟早崩。
企业 AI 应用最怕的不是模型不会说话，而是模型说得挺像那么回事，系统却没法可靠处理。
Structured Output 解决的正是这个断点。
九、MCP 让 Java 服务有机会进入 Agent 工具体系
过去我们说 AI 应用，多数时候说的是“应用调用模型”。
但 Agent 时代的结构会复杂得多。
模型不只接收 prompt，它还要连接数据库、文件系统、搜索服务、Git 仓库、内部 API、工单系统、监控系统、知识库，甚至浏览器自动化工具。
如果每个工具都用一套私有协议，生态会很乱。
MCP，也就是 Model Context Protocol，想解决的就是这个问题：让 AI 应用和外部工具、数据源之间有一种更标准的连接方式。
Spring AI 2.0.0-M5 的新特性里提到 spring.ai.mcp.server.expose-mcp-client-tools，说明 MCP 相关能力也在继续增强。
这件事对 Java 团队很有想象空间。
因为企业内部真正有价值的工具，很多都在 Java 系统后面。
查订单、查库存、查日志、查告警、查文档、发起审批、生成报表，这些能力本来就在 Spring Boot 服务里。过去它们只是内部接口，现在有机会被包装成 Agent 可以调用的标准工具。
但这里还是要泼一盆冷水。
MCP 很强，不等于可以把生产操作裸奔暴露给模型。
权限、审计、限流、确认机制、环境隔离，一个都不能少。
Agent 越像员工，就越要按员工的方式管理权限。
十、可观测性不是锦上添花，是救命绳
普通接口出问题，排查路径比较熟。
看请求参数，看 SQL，看异常栈，看日志，看链路追踪。多数时候，只要日志没瞎打，总能顺着线索找到问题。
AI 应用不一样。
它出问题的时候，可能不是代码异常，而是回答跑偏。
用户问制度，模型引用了旧文档；用户查订单，模型没有调用工具；本来应该输出 JSON，结果多说了一句“好的”；RAG 检索到了不相关片段；工具调用参数少了一个字段；上下文太长，关键内容被挤掉了。
这些问题如果没有观测数据，排查起来非常痛苦。
至少你要能看到用户问题、system prompt 版本、检索到的文档片段、模型名称、token 用量、latency、tool call 过程、最终回答和异常信息。
Spring AI 2.0 的 upgrade notes 里提到 Observability 有行为变化：内容观察从 tracing 方式调整为 logging handlers，相关配置属性也做了重命名。
这听起来很细，但升级时一定要看。
因为一旦观测链路变化，你原来的监控面板、日志采集、脱敏策略都可能受影响。
尤其是企业知识库场景，prompt 和检索片段里很可能有敏感内容。生产环境要不要记录内容日志，记录到什么程度，怎么脱敏，谁能看，都要提前定。
别等线上回答错了，才发现升级后关键日志没了。
十一、RAG 的效果经常输在文档切分上
很多人调知识库效果，一上来就盯着模型。
模型不行，换一个；embedding 不行，换一个；向量库不行，也换一个。
但真实项目里，RAG 效果差，经常不是模型的问题，而是文档入库的时候就切坏了。
Spring AI 2.0 的 ETL Pipeline 里，TokenTextSplitter 有一个很实际的变化：在 2.0 中，小文本如果 token 数低于 chunk size，不会再被无意义地按标点切碎。
这个细节很工程。
企业文档不全是长篇论文，更多时候是短 FAQ、接口说明、制度条款、配置说明、故障处理记录。
这些内容本来就短，如果还被继续切碎，语义上下文会丢，检索结果会变得很散，向量库里的 chunk 数量也会膨胀。
最后模型拿到的不是一段完整信息，而是几块断掉的碎片。
小文本不再过度切分，看起来不像大功能，但对知识库质量很有帮助。
这也说明 Spring AI 2.0 不只是在堆新名词，它也在补真实 RAG 场景里的细节。
十二、Vector Store 和自动配置，升级时别只看主流程
Spring AI 1.0 已经支持很多向量库。
到了 Spring AI 2.0，Vector Store 生态依然很丰富，比如 PGVector、Milvus、Qdrant、Redis、Elasticsearch、MongoDB Atlas、OpenSearch、Neo4j、Oracle、Weaviate 等。
但 upgrade notes 里也有一些移除和调整，比如 HanaDB vector store autoconfiguration 的移除。
这类变化平时不起眼，升级时很容易踩坑。
如果你用的是 PGVector、Redis、Qdrant 这类常见方案，影响可能不大。但只要项目里依赖了特定 starter、自动建表、metadata filter、embedding 维度、topK 阈值，就不能只跑一遍主流程。
知识库系统最怕“看起来还能回答”。
因为它可能只是还能回答，但召回质量已经变了。
升级 Spring AI 2.0 时，向量库相关的依赖、配置项、自动建表行为、过滤条件和召回参数，都要单独核对。
十三、从 Spring AI 1.0 升级到 2.0，真正要小心什么
如果是新项目，直接看 Spring AI 2.0 问题不大。
但如果你手里已经有一个 Spring AI 1.0 项目，我不建议你周五下午改个版本号，然后期待一切顺利。
这不是吓人。
Spring AI 2.0 有 breaking changes，而且很多变化影响的是运行行为，不只是编译结果。
比较稳的路线是这样的。
先把项目升到 1.x 最新维护版本，把 deprecated API 清掉。不要把所有警告都留到 2.0 再爆。
然后梳理项目里几条关键链路：ChatClient 怎么用，Advisors 怎么组合，RAG 怎么查，Memory 怎么存，Tool Calling 调了哪些业务能力，可观测性记录了什么。
接着单独准备回归测试。
Tool Calling 要测模型是否能正确选择工具、参数是否能正确生成、执行结果是否能回传、多轮对话里是否稳定、工具失败时能不能兜住、写操作有没有确认机制。
Memory 要测历史消息是否按预期带入，JDBC 存储是否正常，advisor 顺序是否影响结果，conversation id 是否隔离，历史消息会不会造成 token 膨胀。
Observability 要测 prompt 是否还能观测，token 用量是否还能统计，模型调用耗时是否还能看到，tool call 是否有日志，敏感信息是否脱敏。
Vector Store 要测 starter artifact 是否变化，自动建表是否还按预期工作，embedding 维度是否匹配，metadata filter 是否正常，topK 和阈值是否仍然生效。
这些测试听起来麻烦，但比上线后排查“为什么它今天回答不对”便宜多了。
十四、谁适合现在用 Spring AI 2.0
如果你现在才开始做企业知识库、智能客服、内部助手、业务 Copilot，我会更倾向于直接看 Spring AI 2.0。
因为它的 API 更干净，也更贴近后续方向。
如果项目还在 Demo 或试验阶段，也可以尽早切到 Spring AI 2.0。越早切，迁移成本越低。
如果项目已经上线，而且依赖了 Tool Calling、Memory、RAG 和向量库，那就别冲动。
不是不能升，而是要开分支升，准备回归测试，再灰度验证。
尤其是大量依赖工具调用和记忆的项目，要最谨慎。Spring AI 2.0 正好在这些地方做了调整，收益也在这里，风险也在这里。
十五、我真正看重 Spring AI 2.0 的地方
Spring AI 2.0 最值得关注的，不是某一个新 API。
不是 extraBody，不是 MCP，也不是某个新的 converter。
这些都重要，但它们不是核心。
核心是 Spring AI 2.0 在继续把 AI 应用开发变成 Spring 体系里的正常工程能力。
这件事对 Java 团队很关键。
因为 AI 应用最终不会只停留在一个聊天框里。它会变成知识库、智能客服、业务助手、代码助手、数据分析助手、运维助手、内部流程自动化 Agent。
这些东西都要接权限、接数据库、接日志、接监控、接发布流程，也要面对安全、成本、审计和稳定性。
如果每个 AI 能力都游离在主系统之外，后面一定会乱。
Spring AI 2.0 的价值就在于：Java 团队不必为了做 AI 应用放弃已有工程体系。
你仍然可以用 Spring Boot 的配置方式、依赖管理、自动配置、Controller、Service、Repository、Observability，同时接入大模型、向量库、RAG、Tool Calling 和 MCP。
这比写一个漂亮 Demo 有价值得多。
十六、结语：Spring AI 1.0 是上车，Spring AI 2.0 是进站
如果用一个比喻，Spring AI 1.0 像是告诉 Java 开发者：这趟大模型的车，你也能上。
Spring AI 2.0 则更像是在修站台、铺轨道、接调度系统。
它没有推翻 Spring AI 1.0，而是在继续补工程化能力。
ChatClient 更核心，Advisors 更成熟，Tool Calling 更规范，Memory 更清晰，OpenAI 兼容扩展更友好，MCP 更值得期待，可观测性和 ETL 细节也更贴近生产。
但升级时要现实一点。
Spring AI 2.0 有 breaking changes，老项目别无脑改版本。新项目可以大胆看 2.0，老项目最好先清理 1.x 的 deprecated API，再开分支升级，补回归测试，最后灰度上线。
AI 应用正在从 Demo 走向生产。
Spring AI 2.0 其实就是 Java 生态在回答一个问题：
大模型应用不应该只停留在 Python 实验室里，它也应该进入企业级 Java 工程体系。
本文作者：全栈直男。关注我，一起聊 Java、Spring AI 和企业级 AI 应用落地。
热门跟贴