spring-projects/spring-ai

如果你的团队已经在用 Spring 构建服务，并且希望模型调用、检索和工具调用都像普通带类型的服务代码一样，Spring AI 值得一看；不在 Spring 技术栈上的团队则需要更谨慎地评估这层抽象带来的成本。

解决什么问题

一个 Java 团队想在现有服务里加入对话接口、基于内部文档的检索，以及几个工具调用。惯常做法是写一堆很薄的厂商 SDK 封装：OpenAI 一套写法、Bedrock 另一套，流式响应又要单独处理，模型输出还得手工转成领域对象。Spring AI 把这一步改成了 Spring 风格的接口加 Boot 自动配置：控制器调用带类型的客户端，直接拿到映射好的对象。变化发生在集成层——厂商对接的胶水代码变成配置和接口——而业务代码仍然是可读的 Java。

有什么不同

它的核心机制是跨模型厂商和向量库的可移植 API，同时在需要时仍能访问特定模型的选项。结构化输出能把响应映射成 POJO；流畅风格的 ChatClient 和用于封装重复模式的 Advisors 层，让调用点读起来接近其他 Spring 客户端。工具调用、MCP 支持、可插拔存储的对话记忆、RAG、文档注入 ETL 管线以及可观测性钩子，意味着一个 AI 功能常用的部件大多是现成的，而不是自己拼。代价是抽象层本身的负担：你接受了 Spring AI 的术语、生命周期和升级节奏；当需要可移植 API 未暴露的选项时，厂商特性仍可能透出来。收益是跨厂商的一致性和更少的胶水代码，成本是应用与厂商之间多了一层依赖。

谁值得试

适合已经在交付 Java 服务的 Spring Boot 团队：希望 AI 功能沿用系统里其他部分的配置、测试和可观测性惯例，尤其是确实可能切换或混用模型厂商时。想用检索和工具调用、又不想自己设计可移植接口的团队也合适。不合适的是小型脚本或非 Spring 的 JVM 服务，框架约定会成为额外负担；或者团队需要的厂商特性这层没有建模，最后会跟它较劲。先确认版本配对：2.x 对应 Spring Boot 4.x，1.1.x 对应 Spring Boot 3.5.x，现有 Boot 3.5 项目不能默认 main 分支适用。

使用条件与边界

第一个约束是版本矩阵：按你的 Boot 版本选择分支，跨版本迁移前先看升级说明。第二，它是框架而不是托管服务，仍然需要模型厂商账号或 Ollama 这类本地运行时，以及密钥或端点配置，实际入口是入门指南。第三，向量库和对话记忆后端是需要自己准备或运维的集成，RAG 功能会带来代码之外的存储与索引维护。初始配置主要是通过 Boot starter 选依赖，后续维护则是跟着 Spring AI 的发布节奏和其背后的厂商 API 走。

HotRepo 点评

HotRepo 只记录到一次日榜出现：2026-10-27，在新项目榜排第 9，当天 9,588 星、增长 6 星。仅凭这一个带日期的快照，无法判断热度是上升还是消退。真正需要先核对的是上面提到的 Boot 版本配对，确认后再决定是否投入这套 API。