引子·HR联手面试官，用Spring AI搞我

会议室的门“咔哒”一声关上，他坐下的那一刻其实是挺自信的。
八年 Java 后端，大厂出身，Spring 全家桶玩得飞起，微服务、分布式、限流熔断一套套讲，他都能切换到“自动回答模式”。

对面技术面试官是个戴金属框眼镜的中年男人，从头到尾脸像写了个 final，几乎不变。旁边的女 HR 翘着腿，红唇、职业装，一边敲笔记本一边不时抬眼打量他，像在看一件“还没决定要不要买”的商品。

前半场发挥完美，技术面试官合上简历：“那后端这块差不多了。聊点新的。你了解 Spring AI 吗？”他心里“咯噔”一下。

Spring 他太熟，AI 这两年也天天刷屏，但“Spring AI”三个字拼在一起，他大脑里只有一张模糊的公众号封面。他硬着头皮笑了笑：“略微了解一点，大概是用来在 Spring 体系里接大模型的框架……”

女 HR 终于抬头，嘴角一勾：“我们现在 AI 项目是标配 Spring AI 的哦。你说‘略微了解’，具体是指？比如，它相比直接用 OpenAI SDK，或者 LangChain4j，有什么优势？”

技术面试官顺势补刀：“对，同样是接大模型，你为什么会更推荐 Spring AI？工程化、落地层面，说几个点。再具体点：让你设计企业知识库问答，你会怎么用 Spring AI 搭？”

他能感觉到手心在出汗~~~~~，ChatClient？RAG？工具调用？这些词像弹幕一样从脑子里飘过，但没有一个能落地成句子。女 HR 又轻轻补一刀：“你简历上写‘关注大模型在后端的落地’，那我们会默认你对 Spring AI 至少有自己观点的。”

“我觉得……它在工程化上，更适合……”话说到一半，他突然发现自己根本接不下去，只剩一个念头在脑子里回响：完了，这题真不会。就在他准备硬着头皮胡扯一套“生态”“可维护”时，耳边突然响起一阵刺耳的“滴滴滴——”。

面试官的脸开始模糊，女 HR 的红唇变成一团颜色，会议室的白墙像 PPT 一样一页页往后翻——
他猛地睁眼，从床上坐起来。

闹钟在床头拼命震动，手机屏幕写着：08:30，他愣了两秒，才反应过来：刚才那一切，只是一场梦，可心跳还在加速~~~。

他拿起手机，看着日程提醒上那行字——“10:00 某某公司后端面试（加分项：了解 Spring AI / LangChain 等 AI 框架）”，沉默了几秒，打开浏览器，在搜索框里认真敲下：【Spring AI 扫盲】

以上内容纯属虚构，如有雷同纯属巧合。面试本身就是双向选择，我们不要放低姿态也不要故作姿态，只要拿出正确的态度就好。不卑不亢你的人生才有方向，哟...哟...哟...(punchline...)

好了让我们进入正题吧！！！

一、Spring AI 到底是个什么玩意？

1.1 它不是模型，而是 Spring 世界里的 AI 应用框架

如果只是在朋友圈刷到过“Spring AI 正式发布”，你大概率会把它归类成“Spring 也整了个 AI 新玩具”。但真到了面试或者项目立项会上，你会发现这个模糊印象完全不够用：你得先搞清楚，Spring AI 不是一个“模型”，也不是随便包一层 HTTP 的“小工具包”，而是 Spring 官方打算认真经营的一块“AI 基础设施”。

先把最容易误解的点说死：根据官方定位，Spring AI 是一个“AI 应用框架（application framework for AI engineering）”，目标是把 Spring 生态那套可移植、模块化、基于 POJO 的设计哲学搬到 AI 领域来。 它自己不训练模型、不托管模型，更不是“Spring 版 ChatGPT”。它做的是另一件事：在你的 Spring 应用和各种 AI 服务、向量数据库之间，提供一层统一的抽象，让你用 Spring 的方式写 AI，而不是被每家厂商的 SDK 牵着走。

1.2 它在 Spring 体系里的位置：上接业务，下接模型和向量库

如果把系统粗暴地画成三层，上层是 Controller / Service / 领域服务这种“你已经写了很多年的业务代码”，底层是一堆花里胡哨的东西：OpenAI、Anthropic、各路国产大模型、Ollama、本地 LLM，还有 PGVector、Mongo、ES、Qdrant、Redis 之类带向量能力的存储。中间那一层，本来靠你自己一堆工具类、SDK 封装、HttpClient 去糊，现在 Spring AI 站出来说：这些“胶水活我来干，你只管对着 ChatClient、EmbeddingClient、VectorStore、Tools、Advisors 这些抽象编程就行”。

换成人话就是：

WebClient 帮你优雅地调 HTTP，
JdbcTemplate / Spring Data 帮你优雅地查数据库，
Spring AI 帮你优雅地调大模型、搞 Embedding、连向量库、做工具调用。

业务仍然写在你熟悉的 Spring 世界里，只是多了几块新的“砖”。

---

二、Spring AI 有哪些能力？一张「功能清单」说完

这一节就没必要写成论文了，直接给一张能力表，让你一眼知道 Spring AI 手里有什么牌，后面哪一块想深挖，再单开一篇“源码 / 实战篇”去拆。

整体可以粗暴概括成一句话：

Spring AI 能力 = 模型调用 + Embedding/向量库 + RAG 套路 + Tools 工具调用 + Prompt/Advisors + 工程化观测

2.1 ChatClient：统一的「调模型」入口

• 干嘛的：用一套 Fluent API 和各种聊天/补全模型对话（OpenAI、Ollama、Anthropic、Google、Amazon 等）。

• 长啥样：chatClient.prompt().system(...).user(...).call()，风格和 WebClient / JdbcClient 很像。

• 意义：你关注“怎么组织 Prompt、要什么结果”，而不是“HTTP 怎么拼、JSON 字段叫啥”。

2.2 EmbeddingClient + VectorStore：Embedding 和向量库打包

• EmbeddingClient：把文本/文档变成向量。

• VectorStore：一套统一接口操作各种向量库（PostgreSQL/PGVector、MongoDB Atlas、Cassandra、Pinecone、Qdrant、Redis、Weaviate、Milvus 等）。

• 用途：给后面的 RAG 做“底层记忆”，文档怎么入库、向量怎么查有固定套路。

2.3 RAG 支持：问问题前，先帮你「查一圈资料」

• 典型场景：企业知识库问答、文档助手、FAQ 机器人。

• 框架提供：把“问题 → Embedding → 向量检索 → 拼上下文 → 再问模型”这一条流水线组合起来的组件（Advisor 等）。

• 效果：模型不是凭想象瞎编，而是“先查你们文档，再回答”。

2.4 Tools / Function 调用：让模型去「跑你的接口」

• 你：写正常的 Java 方法，标注/注册成“工具”。

• 模型：在对话中提出“我要调用某个工具，参数是 xxx”。

• Spring AI：解析参数 → 调用你方法 → 把执行结果丢回模型继续推理。

• 意义：回答里用的是你系统里的真实数据，而不是模型脑补出来的数字。

2.5 PromptTemplate + Advisors：提示词和「一圈增强逻辑」

• PromptTemplate：把 Prompt 模板化，有变量、有占位符，不用在 Controller 里堆几百行字符串。

• Advisors：一圈围绕 ChatClient 转的“拦截器”，可以做聊天记忆、RAG 问答、日志、重试等通用能力。

• 好处：通用套路（对话记忆、知识库检索、输出结构化…）变成可复用组件，而不是散落在各个类里的 if/else。

2.6 工程化能力：真的能「上生产」

• 自动配置：Spring Boot Starter 一加，Model/VectorStore/ChatClient 直接注入用。

• 观测：接入 Spring 的 Observability 栈，对 AI 调用打指标、打 trace。

• 模型类型：支持聊天、Embedding、文本转图像、语音转文字、文字转语音、内容审核等，接口尽量保持一致。

---

三、Spring AI 适合什么场景？顺便踩一脚 LangChain

3.1 给现有 Spring 系统「加一点聪明劲儿」

聊完“是什么”和“能干啥”，接下来是最现实的问题：什么场景值得上 Spring AI？ 如果站在一个典型 Java 团队的角度，我觉得可以抓几类最常见的画面。

第一类，是“给现有 Spring 系统加一点聪明劲儿”。你的工单系统、客服系统、运营后台、管理控制台本来就跑得好好的，现在只是想多加几块：工单自动分类、客服问题智能建议、运营活动自动总结、接口文档自然语言搜索。这些需求的共性是：系统核心仍然是 Spring，只是多了几条“问模型一下”的支路。这种场景上 Spring AI，好处不是“模型更强”，而是改造成本可控——多几个 Bean、多几个配置、多一条链路，CI/CD、监控、权限、网关都不用重搭一份。

3.2 企业知识库 / 内网文档问答

第二类，是“企业知识库 / 内网文档问答”。无论是新员工培训、售前售后 FAQ，还是内部技术文档、规范手册，本质上都是“有一堆文档，希望按自然语言问答能查到东西”。RAG 是标配，向量库是必选项。而你肯定不希望这个服务完全脱离现有体系单飞——权限、审计、脱敏、限流，最终都要挂回你们现有的那套 Spring 世界观。Spring AI 这时候的优势，是它和 Spring Security、Spring Cloud Gateway、各种数据源天然贴得比较紧。你写的不是“某某 Python 服务 + 半天网关对接”，而是一个地地道道的 Spring Boot 应用，只不过里面有 ChatClient + VectorStore 这种新玩意。

3.3 内部工具型 Agent / 助手

第三类，是“内部工具型 Agent / 助手”：比如运营同学希望来一句“帮我分析一下最近一周新增用户变化”，然后系统懂得去查报表、调几个内部接口，给出一段分析；研发希望有个“代码知识助手”，能看项目文档、Issue、部分代码，再帮忙回答一些问题。这背后的共性是：模型不仅要聊天，还要查你们系统里的真实数据，甚至执行一些动作（比如拉取报表、触发一个模拟任务）。这个时候 Tools/Function 调用就很关键，而 Tools 的世界观恰好就是一个个 Java 方法。Spring AI 把这一层做成基础设施，对 Java 团队来说，会比“绕一个 Python LangChain 服务，在那里搞一套自己的 RPC 协议”更自然。

3.4 顺带聊聊：为什么我愿意吹它比 LangChain 更香

至于和 LangChain 的对比，我自己的态度比较简单粗暴：LangChain 很强，但天生是 Python 那一边的“主角”；Spring AI 则是 Java / Spring 这边的“本地亲儿子”。

从思维模式上看，LangChain 更像“给你一个 AI 积木盒子，链、Agent、内存、工具随便拼”，适合从 0 到 1 做实验、做原型；Spring AI 更像“在你熟悉的 Spring 世界里，多了一套 AI 组件”，适合给现有系统加能力。从工程一体化上看，LangChain 要接入 Java 体系，常见做法是旁边起个 Python 服务 → 再用 HTTP/RPC 连过去 → 再把日志、监控、限流、安全接回来；Spring AI 本身就是 Spring 项目的一部分，直接享受 Spring Boot 配置、Actuator 观测、Security 鉴权、Cloud Config / Gateway 等生态。

从团队成本上看，让一整个 Java 团队学 Python + LangChain，不现实；让大家多学一套 Spring 风格的 API，相当于“在本地王国里多修几条路”。所以如果在面试里有人问我“你怎么评价 Spring AI 和 LangChain？”，我大概会这样回：

LangChain 更适合在 Python 世界玩出花，Spring AI 更适合在 Java / Spring 体系里长期落地。
一个偏研究，一个偏工程。
如果我手里已经有一堆 Spring Boot 服务、打算认真搞 AI，那我会优先选 Spring AI 做底座。

---

四、初学者怎么学 Spring AI？别概念都没搞懂就上来敲代码

4.1 先把几个名词在脑子里「对上号」

最后这一段，说白了就是给“梦里的自己”开个学习路线，不是“十分钟跑个 Demo 就完事”的那种，而是真能撑得住面试和落地。

我自己的经验是，Spring AI 这种东西，如果你概念没吃透就上来抄 Demo，非常容易写成屎山。尤其是现在各种博客、视频、短教程，最爱那种“10 行代码搞定 AI 问答”，跟着抄一遍确实能跑，但你问它一句“这行 API 在整个框架里处于什么位置”“为什么要用 Advisor 而不是自己写一堆工具类”，马上原形毕露。

比较靠谱的节奏，第一步是先把几个核心名词在脑子里“对上号”，别急着敲代码。

ChatClient 是什么概念（大模型客户端，类比 WebClient）；

Prompt 在 Spring AI 里的结构是什么（system / user / assistant 消息，各自干嘛）；

Embedding / VectorStore / RAG 分别管哪一段（从文档到向量、从向量到检索、从检索到拼上下文）；

Tools/Function 调用大致走的是什么流程（模型发意图 → 框架调方法 → 结果回流到模型）；Advisors 在调用链里是站什么位置的（像一圈可复用的“AI 中间件”）。

这些东西官方文档、社区文章都有比较清晰的图和示例，花半天扫一遍，后面写代码会轻松很多。

4.2 再按「从简单到复杂」写 Demo，别一上来造宇宙级 Agent

第二步，再按“从简单到复杂”的顺序写 Demo，而不是一上来搞什么“多 Agent 超级助手”。一个比较稳的路线可以是：

1. 只用 ChatClient，在一个 Spring Boot 项目里写出一个简单问答接口，顺手试一下流式输出。

2. 把 Prompt 抽成 PromptTemplate，加一点点 Advisor，让系统提示、格式约束这些东西不要散落在 Controller 里。

3. 接一个向量库（哪怕是本地 in-memory 也行），做一版“小范围文档问答”，体验一下 RAG 的链路。

4. 写一两个 Tools，比如“查订单、查用户”，让模型第一次真正动到你系统里的真实数据。

5. 给这些调用打上一点指标、日志、trace，让 AI 调用出现在你原来就盯着的监控大盘里。

走完这一圈，你再回头看 Spring AI，就不会只停留在“我跟着抄过一个例子”这个层面，而是至少能算得上“知道它在我系统里的位置”。

---

结语：把 Spring AI 记成一句话、三件事

最后用一个比较“干货向”的总结，把前面的东西压一压，方便你以后回想。

第一，它是什么。Spring AI 不是模型，而是 Spring 生态里的 AI 应用框架和适配层，站在 OpenAI、Ollama、国产大模型、各种向量库的上面，站在你的 Controller / Service 的下面，负责用 Spring 的方式帮你调模型、做 Embedding、连向量库、走工具调用。

第二，它手里有什么牌。可以粗暴记成一句：

ChatClient 调模型，Embedding + VectorStore 管向量和 RAG，
Tools 让模型跑你的接口，PromptTemplate + Advisors 管套路，
再加一整套能进生产的配置、监控和观测能力。

也就是说，从“模型会说话”，到“模型能看你们文档”，再到“模型能查你们系统里的真实数据”，以及“这些东西能被监控和治理”，Spring AI 都给了一套相对统一的编程模型。

第三，它适合用在什么地方。
最典型的三类：给现有 Spring 系统一点「大模型加持」，做企业知识库 / 内网文档问答，做内部工具型 Agent / 助手。共同特点是：系统本身就是 Spring、工程体系已经成熟，而 Spring AI 负责把 AI 这一块顺滑地接进来，而不是另起一条 Python 技术栈单飞。如果只留一句最短的记忆点给自己，我会写成这样：

Spring AI = Java / Spring 阵营里，真正打算“长期运维”的大模型落地框架。

以后别人问你：“你会不会 Spring AI？”你至少可以抬头说一句：“会一点，不只跑过 Demo，我们可以聊聊怎么落地。”

写在最后·说书人摊手一礼

诸位看官老爷们，今日这篇若有一言半句让您拍案叫好，还请 👍 点赞、📌 收藏、👁关注；要是看完觉得“这讲的是个啥”，或者“作者是不是昨晚没睡醒”，也欢迎 💬 留言开喷！什么都能说，什么都能问，吐槽不扣钱，发问不掉头发sker~~~~~

说书人摊手作揖：码客江湖，热血未凉，风不息，云未散，山河还在，诸位请慢走，咱们江湖再会～