Spring AI 项目初探：Java 生态的 AI 抽象层

Java 也要有自己的 AI 抽象层

2023 年初，Python 侧 LangChain 已经热闹非凡，Java 这边还在各自调 OpenAI 的 HTTP。我们团队想给内部系统接个问答能力，结果每个项目都自己封装一套 OkHttp 调用，模型一换全部重写。Spring 社区开始孵化一个叫 Spring AI 的实验性项目，想给 Java 一套统一的模型抽象。我提前翻了它的早期代码，聊聊形态，也顺手记一笔"现在它还不能用"。

说明：此时 Spring AI 仅是社区孵化的实验性项目，远未 GA，API 随时会变。下文只谈它早期的设计思路，不作为可落地的生产用法，切勿照抄到生产。

ChatClient：模型可替换的抽象

核心理念和 JDBC 之于数据库一样——业务代码面向 ChatClient 编程，底层换模型不改代码：

// 早期草案形态（非最终 API）
ChatClient client = ...;
Prompt prompt = new Prompt("用一句话解释虚拟线程");
ChatResponse r = client.call(prompt);
String text = r.getResult().getOutput().getContent();

把 OpenAI 换成本地模型，只需换一个 AutoConfiguration，业务侧无感。这正是 Java 生态最擅长的"加一层抽象解耦"。当时这段代码还是草稿，包名、方法名都还没定型，我跑起来还改了好几个 import。

与 Python LangChain 的对比

LangChain 在 2023 年初已经能拼链、接记忆、调工具，Spring AI 还停留在"能发个 prompt 收个回复"的阶段。但 Spring AI 胜在和 Spring 的依赖注入、配置体系天然融合，对 Java 团队上手成本低。

设计上的几点观察

翻源码时我注意到几个有意思的点：

• 它把 Prompt 做成对象而非字符串，方便后续加模板、变量，类似 Thymeleaf 的思路；
• ChatResponse 分层（result → output → content），为以后支持多候选、元数据留了扩展位；
• 模型客户端用 SPI 式注册，理论上新增模型只要实现 ApiCall 接口，符合 Spring 一贯的"可替换实现"哲学。

这些设计说明它不是临时拼凑，而是按 Spring 的套路在搭骨架。但骨架归骨架，离"能接 RAG、能管向量"还远。

我的判断

对 Java 团队，等它 GA 后最大的价值是"模型可替换"——今天接 OpenAI，明天换自研，业务逻辑不动。现阶段还只是看个方向，别急着在生产里赌它的 API 稳定。我们内部那个问答需求，暂时还是用 OkHttp 直连，等 Spring AI GA 了再考虑迁，避免早期 API 变动带来的返工。

另外提醒：2023 年初大模型调用有数据合规和数据出境外规的考量，直连境外 API 要评估。Spring AI 这类抽象层未来若支持私有模型接入，对企业反而是关键点。

早期 API 的不稳定证据

光说"实验性"还不够直观，说个具体例子：我拉的快照里，ChatClient 的包名从 org.springframework.ai.client 改到 org.springframework.ai.chat，方法 call 的参数从 ChatRequest 变成 Prompt，前后两周两个 commit 全变了。这种改动频率，意味着你现在写的任何代码，下个里程碑都可能编译不过。所以我们内部明确规定：2023 年不引用 Spring AI 的任何类到业务代码，只做技术预研。

和企业现有架构的契合点

为什么我还花时间看它？因为方向确实对 Java 企业。我们现有系统是 Spring Boot + Spring Data + Spring Security 一整套，如果 AI 调用能像 Spring Data 那样用一套 Repository 风格、一套配置、一套自动装配，那接入成本极低。早期代码里已经能看到它用 @ConfigurationProperties 接配置、用 AutoConfiguration 注册客户端的套路，和 Spring 生态一脉相承。对已经重度 Spring 化的团队，这是它相对 LangChain 的最大吸引力——不用为了接 AI 另起一套技术栈。

我给团队的建议

一是现在别在生产用，把精力放在"业务怎么用大模型"本身，直连 API 封装薄一层即可；二是提前把模型调用抽象成接口，将来 Spring AI GA 了能平滑替换底层，业务逻辑不动；三是关注数据合规，境外 API 的数据出境要走审批，私有模型接入能力才是企业真正需要的，这点 Spring AI 未来若支持本地模型会很关键。

一句话：方向值得跟，时机还没到。把它当技术雷达里"评估中"的项，定期回看，等 GA 再上车，别在预览期赌稳定性。

PromptTemplate 与变量

早期代码里已经能看到 Prompt 支持模板变量的雏形，类似 Spring 的 MessageSource 风格，用占位符拼提示词：

PromptTemplate t = new PromptTemplate(
    "用{lang}解释：{concept}");
Prompt p = t.create(Map.of(
    "lang", "中文", "concept", "虚拟线程"));

这比业务代码里硬编码字符串强太多——提示词可以集中管理、做版本、做 A/B。对 Java 团队，这种"配置化提示词"比 Python 里散落的 f-string 更规整，也是 Spring 系框架的拿手好戏。不过这些都是草稿，API 随时变，别当真。

它未来在企业里的生态位

我的判断：Spring AI 真正值钱的地方不是"能调模型"，而是把 AI 能力接进企业现有的 Spring 体系——和 Spring Data 查库、Spring Security 鉴权、Spring Cloud 治理天然打通。比如"根据用户权限从库里取数据喂给模型"这种企业场景，Spring AI 若提供标准集成，比各自拼装省事。等它 GA，这类"AI + 企业数据"的管道会成它的主战场，而不是和 LangChain 拼链的长度。

现在能做的准备

虽然不能上生产，但可以提前做三件不依赖 Spring AI 的事：一是把模型调用封成内部 interface，将来换底层无痛；二是沉淀企业的提示词模板库；三是建立大模型调用的审计日志（谁、问了什么、用量多少），合规早晚要。这三件做好了，等 Spring AI GA，迁移成本极低。技术可以等等，准备不能停。

它和企业 RAG 的关系

回到我们做的那个内部问答（RAG），它和 Spring AI 的契合点在哪？RAG 链路由"检索 + 拼提示词 + 调模型 + 解析结果"组成，如果每步都用 Spring AI 的统一抽象，那换 embedding 模型、换大模型、换向量库都只改配置。现在我们是自己用 OkHttp + ES 拼的，模型一换就得改代码。等 Spring AI GA 且覆盖 RAG 组件，这套链路能整体迁移到它的抽象上，维护成本降一截。所以关注 Spring AI 不是追新，是为将来 RAG 这类应用的可持续性铺路。

提前识别的风险

即便未来用上，也有风险要提前想：一是模型调用变慢会拖慢整个请求链，得有超时和降级；二是成本，每次问答都调大模型，量起来费用可观，前面说的语义缓存就是用 Spring AI 时也该有的；三是输出不可控，模型可能返回非预期格式，解析层要健壮。这些风险不因为是 Spring 封装就消失，框架只是把"调模型"变简单，业务健壮性还得自己保证。把它当工具而非黑盒。

给技术雷达的一句话

把 Spring AI 放进技术雷达的"评估"象限：方向对、生态未熟、生产勿用。定期回看它的 GA 进度，等 API 稳定、模型适配器齐全，再把它从评估移入"采用"。现在团队要做的，是把模型调用抽象好、提示词管起来、审计日志建起来，这些不依赖 Spring AI 也能做，且为将来迁移铺路。方向跟，时机等。顺便记一笔：2023 年初大模型生态一个月一个样，今天写的判断，半年后可能就过时，所以保持"定期回看"这个动作本身，比某个具体结论更重要。

把 Spring AI 放进技术雷达的"评估"象限：方向对、生态未熟、生产勿用。定期回看它的 GA 进度，等 API 稳定、模型适配器齐全，再把它从评估移入"采用"。现在团队要做的，是把模型调用抽象好、提示词管起来、审计日志建起来，这些不依赖 Spring AI 也能做，且为将来迁移铺路。方向跟，时机等。

先到这

《Spring AI 项目初探：Java 生态的 AI 抽象层》这块我前前后后踩了不止一次。今天先写这些，后面想到新的再补。

参考

• 官方文档：ai-agent
• Baeldung 上的相关实战
• StackOverflow 上的相关讨论