发刊词：Java 开发者的 AI 转型，为什么首选 Spring AI

本文是专栏《Spring AI 入门与实战》的第 1 篇。这个专栏会用 30 篇的篇幅，带一位普通的 Java/Spring Boot 后端开发者，从零开始把大模型能力接进真实的业务系统：从第一个聊天接口，到 RAG 知识库，到 MCP 工具中枢，最后到能扛住生产流量的智能体应用。这是发刊词，先把路线和理由讲清楚，再上路。

一、为什么是现在：AI 能力正在变成"业务功能"

过去两年，我观察到需求单的变化。2024 年，团队收到的 AI 需求还停留在"做个聊天机器人 demo 给老板看"；到了 2025 年，需求变成了这样：

• 工单系统要接入自动摘要和分类，人工处理时长要降 30%；
• 客服系统要能基于产品手册回答问题，答不上来再转人工；
• 数据平台要支持"自然语言查数"，运营不再想学 SQL；
• 合同审阅、营销文案、代码评审辅助，一个个排队等排期。

注意这些需求的形态：它们没有一个是"独立 AI 产品"，全部是嵌在既有业务系统里的一个功能模块。这意味着落地 AI 的第一责任人不是算法工程师，而是写这些系统的后端工程师——也就是屏幕前的你。

很多 Java 开发者此刻的心态是矛盾的：既觉得大模型是趋势，不想错过；又觉得训练模型、调参、读论文离自己太远，不知道从哪下手。我的观点很明确：应用开发工程师的 AI 转型，转的不是"算法"，而是"工程"。你要学的不是怎么训练模型，而是怎么把别人训练好的模型，以可控的成本、可观测的质量、可接受的延迟，集成进 Spring Boot 应用里。这件事，恰好是 Java 开发者的主场。

二、“Python 税”：割裂带来的隐性成本

聊选型之前，先算一笔账。

多数团队第一次接 AI 功能时走了同一条路：找一个会 Python 的同事（或实习生），用 LangChain 之类搭一个服务，跑通了 demo，然后想办法和主系统对接。这条路能走，但每走一步都在交税，我称之为**“Python 税”**，它至少有四层：

第一层，运维税。 主系统是 Java 单体或 Spring Cloud 微服务，AI 能力却是一个 Python 服务。两套语言意味着两套依赖管理、两套 CI/CD 流水线、两套镜像构建、两套监控告警接入方式。为了一个几百行代码的功能，多养了一整条技术栈。

第二层，安全税。 AI 服务要访问业务数据才能干活，比如客服机器人要读订单。跨语言跨服务的调用链里，鉴权怎么做？Spring Security 的上下文怎么传递过去？数据出了 Java 进程，脱敏、审计、合规边界都要重新设计一遍。最常见的妥协是 Python 服务拿一个"超级权限"的 key 直连数据库——这在安全评审上是要挂红灯的。

第三层，协作税。 Java 团队改不动 Python 服务，Python 服务出了线上问题（超时、幻觉、限流），排查的人两头受气。知识不沉淀在团队里，人就离职了。

第四层，演进税。 AI 应用迭代极快，今天接 DeepSeek，明天要换通义，后天要加 RAG。如果 AI 逻辑在主系统之外，每加一个能力就要跨两个代码库协调一次，业务方的耐心很快就耗光了。

这些税在 demo 阶段全都隐形，一到生产就一笔一笔找上门。Spring AI 存在的意义，就是让 AI 能力以"原生 Spring 组件"的形态长在主业务系统里，把这四层税免掉。

三、Spring AI 的定位：AI 领域的 Spring Data

如果你问我用一句话讲清 Spring AI 是什么，我会说：它在 Spring 生态里之于大模型，就像 Spring Data 之于数据库。

回想 Spring Data 给了我们什么：你写的是 JpaRepository，底下连的是 MySQL 还是 PostgreSQL，基本只差一行配置和方言。它没有发明数据库，它把"访问数据库"这件重复的事变成了统一、可测试、可替换的编程模型。

Spring AI 做的是同一件事，对象换成了大模型：

// 你始终面向 ChatModel / ChatClient 编程
ChatClient chatClient = ChatClient.builder(chatModel)
        .defaultSystem("你是一个简洁的中文技术助手")
        .build();
String answer = chatClient.prompt().user("什么是幂等性？").call().content();

这段代码底下的 chatModel 是 OpenAI、DeepSeek 还是通义千问，只是 application.yml 里几行配置的差别。模型是别人的，编程模型是 Spring 的——这就是它的核心价值主张。

在此基础上，Spring AI 把 AI 应用开发中的高频问题逐一做成了 Spring 风格的抽象：

• ChatClient：类似 RestClient 的流式 API，阻塞、流式调用一把抓；
• PromptTemplate：带占位符的提示词模板，支持参数渲染；
• 结构化输出：.entity(Person.class) 让模型输出直接映射成 Java 对象；
• Advisor 链：AI 应用里的 AOP，会话记忆、日志、安全检查都往这条链上挂；
• RAG 组件族：VectorStore 抽象、文档加载切分、QuestionAnswerAdvisor；
• 工具调用与 MCP：@Tool 注解让模型调用你的 Java 方法，MCP 协议支持让工具跨进程复用。

更重要的是，这些抽象不是孤岛。Spring AI 的自动配置基于 Spring Boot 3 的条件装配，可观测性走 Micrometer（一个开关就能把每次 LLM 调用的 token 数、耗时打进 Micrometer/OTel），流式响应原生支持 Reactor。你花了多年攒下的 Spring 功力——事务、安全、配置管理、健康检查、灰度发布——在这里全部直接复用。

版本方面需要交代一下：Spring AI 1.0 在 2025 年 5 月迎来 GA，结束了漫长的里程碑时代；本专栏基线是 Spring AI 1.1.x GA（2025 年 11 月发布），要求 JDK 17 与 Spring Boot 3.x。API 已经稳定，可以放心把代码写进生产仓库了。早期网上大量 0.8/M 版本的教程代码（比如旧的 FunctionCallback.withFunction 写法）已经失效，这也是我想写这个专栏的原因之一：中文世界里"对得上 1.x GA"的系统性资料太少。

四、和 LangChain 们比：强在哪，弱在哪

绕不开的对比。公平地讲，两边各有胜场，我把判断标准摆出来，你自己选。

生态与迭代速度，LangChain 系赢。 Python 是 AI 研究的一线语言，新模型、新论文、新玩法总是先有 Python 实现。LangChain（以及 LlamaIndex、LangGraph 等）社区大、教程多、尝鲜快。如果你做的是探索性研究、快速验证一个新范式，Python 是合理的。

工程成熟度与可维护性，Spring AI 赢。 这不是贬低，而是两个项目的基因差异：LangChain 的抽象层数出了名地多，API 在快速演进中也以"破坏性变更多"著称，半年不升级就跟不上；Spring AI 背后是 Spring 团队，节奏克制，GA 之后承诺 API 稳定性，发布遵循语义化版本，出了问题有一整套 Spring Boot 的诊断手段（条件装配报告、actuator、Micrometer）兜底。

我的观点是：不要把"用 Python 快速试验"和"把 AI 能力交付到生产"混为一谈。试验可以用任何语言，甚至直接在网页里聊；而交付需要的是依赖可控、观测完备、团队可维护——这三点正好是 Java/Spring 的强项。对一支 1~5 年经验的 Java 团队来说，选 Spring AI 不是技术保守，是把 AI 功能放进自己最有掌控力的地方。

还有一个常见误解要纠正：Spring AI 不是"LangChain 的 Java 复刻"。它没有重复造轮子的野心——鉴权用 Spring Security，监控用 Micrometer，Web 用 Spring MVC/WebFlux，它只补齐 AI 特有的那一层（提示词、模型抽象、向量库、RAG、工具调用）。你在 Spring 里已经拥有的一切，它一分不加地继承。

五、专栏地图：30 篇怎么读

30 篇分四个阶段，难度递进，每个阶段都能独立产出可用的东西：

第一阶段：入门与核心抽象（第 02~09 篇）。 搭环境、跑通第一个对话、理解模型抽象层、学会 PromptTemplate、结构化输出、多模态、会话记忆和 Embedding。这一阶段结束，你能在任何 Spring Boot 项目里加一个"AI 功能"，并且知道怎么切换和配置模型。示例默认用 DeepSeek 和阿里通义千问（都走 OpenAI 兼容端点，成本友好），也会提及 OpenAI、Anthropic 和本地 Ollama。

第二阶段：RAG 与知识库（第 10~14 篇）。 向量库选型（PgVector/Redis/Milvus）、文档处理流水线、从 QuestionAnswerAdvisor 最小实现到查询改写与重排的进阶，最后是企业知识库的避坑指南。这是企业里需求量最大的一块。

第三阶段：工具调用与 Agent（第 15~20 篇）。 @Tool 工具调用、工具设计方法论、MCP 协议（Server 与 Client 的实战）、从工具调用走向 Agent 模式。这一阶段做完，你的 AI 应用就不只是"会聊天"，而是"会干活"。

第四阶段：工程化与实战（第 21~30 篇）。 Advisor 链、可观测性、效果评估、成本与安全治理、测试与 CI/CD，然后是三个完整实战（智能客服、MCP 工具中枢、数据分析智能体），最后是部署上线与学习路线。这一阶段回答那个终极问题：怎么让 demo 活着走进生产。

每篇的结构固定：场景引入、核心讲解（含可运行代码）、生产视角、踩坑记录、小结与练习。代码全部基于 Spring AI 1.1.x，可以直接跑；踩坑记录里的报错都是真实见过的问题，不是编的。

六、适合谁，不适合谁

适合你，如果： 你有 1~5 年 Java/Spring Boot 开发经验，写得出 Controller、配得出数据源、看得懂堆栈；你不需要任何 AI 背景——专栏不要求你懂神经网络，但要求你愿意理解"模型是个不确定的远程服务"这个心智模型。

可能不适合，如果： 你想做模型训练、微调或推理优化——那是另一个领域，本专栏只消费模型不训练模型；你在寻找"零代码接 AI"的方案——Spring AI 是框架不是低代码平台，它需要你写 Java；或者你的团队没有任何 Spring 基础——那先把 Boot 学了再来，性价比更高。

还有一类读者处在中间态：短期只有 Python 同事能做 AI，但又认同"收税"的说法。给你们的建议是两条腿走路——试验留在 Python，交付用 Spring AI 重写，本专栏第四阶段的工程化内容（可观测、评估、成本）对两边的同学都有用。

七、小结

这篇发刊词只讲了一件事：Java 开发者的 AI 转型，重心是工程集成而非算法；而做工程集成，Spring AI 是当前 Java 生态里最顺手的答案。 它用类似 Spring Data 的方式统一了模型访问，让你已有的 Spring 功力直接变现，避免"Python 税"在运维、安全、协作、演进四个维度的持续扣费。

下一篇《环境准备与技术全景图》，我们会把 JDK 17、Spring Boot 3.5、Spring AI 1.1 的骨架工程搭起来，申请好 DeepSeek 与通义千问的 API Key，用十几行代码验证模型连通，并把整个专栏的技术全景图铺开。工具备好，正式开工。