今年早些时候,我需要为我维护的一个 Spring Boot 应用添加 AI 助手。没什么特别的——只是一个聊天界面,能回答关于系统文档的问题。我有两个显而易见的选择:Spring AI 或 LangChain4j。

我原以为这会是一个快速决定。两个框架都很成熟。都支持主要的 LLM 提供商。都有 Spring Boot 集成。它们能有多大区别?

六周和两个原型之后,我发现差异远比特性矩阵所显示的重要得多。

我是来自孟加拉国达卡的一名高级软件工程师。我每天都在使用 Spring Boot。我还运行 Hermes Agent 作为我的个人 AI 基础设施。所以我同时涉足企业级 Java 世界和 AI 代理世界。以下是我在对比这两个框架时发现的情况。


两个竞争者

Spring AI 是来自 Broadcom(前 VMware)Spring 团队的官方 AI 集成框架。它在 2026 年与 Spring Boot 4 一起达到了 2.0.0 版本。它涵盖了全部范围:聊天、嵌入、图像生成、音频转录、文本转语音、审核,以及——2.0 版本的头条功能——一流的 MCP(Model Context Protocol)支持。你可以在 start.spring.io 上找到它,与其他所有 Spring 启动器并列。

LangChain4j 于 2023 年初启动,作为对 Python 主导的 AI 格局的回应。尽管名字如此,但它并不是 LangChain 的 Java 移植版。维护者强调:它是为 Java 构建的,而不是移植到 Java。LangChain4j 支持 20 多个 LLM 提供商和 30 多个向量存储,并与 Spring Boot、Quarkus、Helidon 和 Micronaut 集成。

两个框架都允许你调用 LLM、构建 RAG 管道、调用工具和创建代理。但它们从根本上不同的角度处理这些任务。


架构哲学

这是两者之间最大的单一差异,也是驱动所有其他决策的因素。

Spring AI 是为 Spring 生态系统构建的。 如果你已经在使用 Spring Boot,Spring AI 就像任何其他 Spring 启动器一样滑入。你会获得自动配置、属性驱动的设置、熟悉的依赖注入模型,以及与 Spring 可观测性堆栈(Micrometer、Actuator)的紧密集成。API 感觉就像是由给你带来 RestTemplate 和 WebClient 的同一批人设计的——因为确实如此。

以下是如何将 Spring AI 添加到 Spring Boot 4 项目中:

<dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-openai-spring-boot-starter</artifactId>
</dependency>

进入全屏模式 退出全屏模式

然后在 application.yaml 中:

spring:
  ai:
    openai:
      api-key: ${OPENAI_API_KEY}
      chat:
        options:
          model: gpt-4.1

进入全屏模式 退出全屏模式

在代码中:

@RestController
class ChatController {
    private final ChatClient chatClient;

    ChatController(ChatClient.Builder builder) {
        this.chatClient = builder.build();
    }

    @PostMapping("/chat")
    String chat(@RequestBody String message) {
        return chatClient.prompt()
            .user(message)
            .call()
            .content();
    }
}

进入全屏模式 退出全屏模式

就是这样。一个依赖项、一个配置属性、一个构造函数注入,你就可以调用 LLM 了。

LangChain4j 是框架无关的。 你可以将其与 Spring Boot、Quarkus、Helidon、Micronaut 或纯 Java 一起使用。它不假设你在 Spring 上下文中。这使其更具可移植性,但也意味着当你将其与 Spring Boot 一起使用时,你需要自己处理更多的连线。

以下是使用 LangChain4j 在 Spring Boot 中的相同聊天端点:

@Configuration
class LangChain4jConfig {
    @Bean
    ChatLanguageModel chatModel() {
        return OpenAiChatModel.builder()
            .apiKey(System.getenv("OPENAI_API_KEY"))
            .modelName("gpt-4.1")
            .build();
    }
}

@RestController
class ChatController {
    private final ChatLanguageModel model;

    ChatController(ChatLanguageModel model) {
        this.model = model;
    }

    @PostMapping("/chat")
    String chat(@RequestBody String message) {
        return model.generate(message);
    }
}

进入全屏模式 退出全屏模式

代码并没有显著变长,但更明确。你自己构建模型实例,而不是依赖自动配置。


LLM 提供商支持

两个框架都涵盖了主要提供商。实际差异在于不常见的提供商。

Spring AI 2.0 支持:OpenAI、Anthropic、Google Gemini、Amazon Bedrock、DeepSeek、Mistral AI、Ollama、Groq、Perplexity AI、NVIDIA、MiniMax、OCI Generative AI、Azure OpenAI 和 Docker Model Runner。完整列表可在 Spring AI 参考文档 中找到。

LangChain4j 支持:OpenAI、Anthropic、Google Gemini、Azure OpenAI、Amazon Bedrock、Ollama、Mistral AI、DeepSeek、Groq、Perplexity AI、HuggingFace、LocalAI,以及大约 10 个更多。完整列表可在他们的 集成页面 上找到。

差异不在于大品牌——两者都有这些。差异在于长尾。LangChain4j 有更多社区贡献的集成,因为其插件式架构使得添加新提供商更容易。Spring AI 更少,但每个都由 Spring 团队维护并遵循一致的 API 模式。

获胜者: 主流提供商平手。LangChain4j 在小众提供商方面胜出。


ChatClient 与 AI Services 的差异

Spring AI 2.0 引入了其流畅的 ChatClient API,它有意模仿 WebClient 和 RestClient。你可以链式调用 .prompt().user().system().call().entity()。它冗长但富有表现力——你可以一目了然地看到请求的每个部分。

LangChain4j 则推向一个名为 AI Services 的声明式模式。你定义一个接口,为其添加注解,LangChain4j 会在运行时生成实现:

interface Assistant {
    String chat(@UserMessage String message);
}

// 用法
Assistant assistant = AiServices.create(Assistant.class, model);
String response = assistant.chat("Hello!");

进入全屏模式 退出全屏模式

这更接近 Spring Data JPA 的存储库模式。你描述你想要什么,框架会生成实现。

两种方法都有效。我发现 ChatClient API 更容易调试,因为流程是明确的。AI Services 模式对于简单用例更简洁,但在出现问题时可能更难追踪。


RAG:检索增强生成

两个框架都支持 RAG,但方法不同。

Spring AI 捆绑了用于文档摄取的 ETL 框架。你可以使用管道读取文档、拆分文档、嵌入文档并将它们存储在向量数据库中:

var pipeline = DocumentReadConfig
    .from("classpath:docs/")
    .toVectorStore(pgvectorStore)
    .splitter(TokenTextSplitter.builder().build())
    .build();

pipeline.run();

进入全屏模式 退出全屏模式

然后在查询时,你可以使用 Advisors API 注入相关上下文:

chatClient.prompt()
    .user(question)
    .advisors(assistant.createContextRetrievalAdvisor(pgvectorStore))
    .call()
    .content();

进入全屏模式 退出全屏模式

LangChain4j 使用 ContentRetriever 抽象。你配置一个嵌入存储和一个检索器,然后将其附加到你的 AI Service:

var embeddingStore = new PgVectorEmbeddingStore(...);
var contentRetriever = new EmbeddingStoreContentRetriever(embeddingStore);

var assistant = AiServices.builder(Assistant.class)
    .chatLanguageModel(model)
    .contentRetriever(contentRetriever)
    .build();

进入全屏模式 退出全屏模式

两个框架都支持主要的向量存储:带有 pgvector 的 PostgreSQL、Pinecone、Qdrant、Milvus、Chroma、Redis、Weaviate、MongoDB Atlas、Cassandra、Elasticsearch 等。

差异在于 ETL 管道。Spring AI 的 DocumentReadConfig 管道更具主观性和结构性。LangChain4j 为你提供对每个步骤的更多控制,但需要更多手动设置。


MCP:模型上下文协议

这是两个框架在 2026 年显著分歧的地方。

Spring AI 2.0 具有一流的 MCP 支持,带有专用的 Boot 启动器。你可以使用 STDIO、SSE 或 Streamable-HTTP 传输运行 MCP 服务器和客户端。甚至还有一个 MCP 注解系统,用于将 Spring Beans 暴露为 MCP 工具:

@McpServer
@Component
public class MathTools {

    @McpTool(description = "Add two numbers")
    public int add(@McpParam int a, @McpParam int b) {
        return a + b;
    }
}

进入全屏模式 退出全屏模式

Spring AI 2.0 将 MCP 视为一流的集成点,而不是事后考虑。你在 application.yaml 中配置 MCP 服务器,它们会自动加载。

LangChain4j 也通过其工具调用和函数调用机制支持 MCP。但它没有相同级别的自动配置或注解驱动的服务器模型。你可以连接到 MCP 服务器,但你需要手动连接它们。

如果 MCP 是你架构的核心,Spring AI 2.0 目前有明显的优势。


何时选择 Spring AI

在以下情况下选择 Spring AI:

  • 你已经在使用 Spring Boot 4。 自动配置、属性驱动的设置,以及与 Spring 生态系统其余部分的一致性,可以节省真正的开发时间。
  • 你需要可观测性。 Spring AI 开箱即用地与 Micrometer 和 Spring Boot Actuator 集成。你无需额外检测即可获得关于令牌使用、延迟和错误率的指标。
  • MCP 是你的主要集成模式。 MCP 注解和自动配置目前领先于 Java 生态系统中的任何东西。
  • 你想要 Spring 团队的支持。 Broadcom 已承诺为 Spring AI 提供长期资源。发布周期与 Spring Boot 绑定。

Spring AI 文档非常优秀。参考指南 涵盖了每个功能,并带有可运行的示例。

何时选择 LangChain4j

在以下情况下选择 LangChain4j:

  • 你不在 Spring Boot 上。 如果你使用 Quarkus、Helidon、Micronaut 或纯 Java,LangChain4j 是自然的选择。
  • 你需要更广泛的提供商和向量存储生态系统。 社区维护了更多的集成,并且发布周期独立于任何框架。
  • 你更喜欢 AI Services 声明式模式。 如果存储库式代理对你来说感觉自然,LangChain4j 比 Spring AI 更干净地提供它。
  • 你想要框架独立性。 如果你可能从 Spring Boot 切换到 Quarkus(反之亦然),LangChain4j 可以降低迁移成本。

LangChain4j 的入门指南位于 docs.langchain4j.dev


我实际做了什么

在构建了两个原型之后,我为我的文档助手选择了 Spring AI。原因是无聊但实用的:我的项目已经在 Spring Boot 4 上,自动配置带来的开发速度是显而易见的。Advisors API 使 RAG 的实现变得微不足道。MCP 注解意味着我可以将现有的 Spring Beans 暴露为工具,而无需编写适配器。

但是,如果我在 Quarkus 上启动一个全新的项目,或者构建一个需要跨多个 Java 框架工作的库,我会毫不犹豫地选择 LangChain4j。

两个框架都能生成优秀的应用程序。错误的选择不是在它们之间做出选择——而是试图在同一个项目中使用两者并重复抽象。


快速决策矩阵

你的框架 —— Spring Boot 4?选择 Spring AI。任何其他 JVM 框架?选择 LangChain4j。

提供商覆盖 —— 主流提供商都得到了良好的支持。小众或社区维护的提供商倾向于 LangChain4j。

MCP 集成 —— Spring AI 2.0 具有一流的、注解驱动的 MCP 支持和自动配置。LangChain4j 需要手动连接。

可观测性 —— Spring AI 内置了 Micrometer 和 Actuator 集成。LangChain4j 期望你自己连接监控。

学习曲线 —— 如果你了解 Spring Boot,Spring AI 感觉很自然。如果你了解没有 Spring 的 Java,LangChain4j 更容易上手。

项目可移植性 —— LangChain4j 是框架无关的(可与 Quarkus、Helidon、Micronaut、纯 Java 一起工作)。Spring AI 将你绑定到 Spring 生态系统。

RAG 的 ETL —— Spring AI 提供了一个结构化的文档管道。LangChain4j 为你提供对每个步骤更灵活的手动控制。


我每周都撰写关于 Java、Spring Boot 和 AI 的文章。订阅——它是免费的。没有通讯平台,没有废话。只有我在达卡构建真实软件时学到的东西。

你是否在生产环境中使用过 Spring AI 或 LangChain4j?是什么驱使你做出选择?我很想在评论中听到你的经验。

要点:不要通过比较功能列表来选择框架。选择与你的项目理念相匹配的那个。Spring AI 通过速度和一致性奖励 Spring Boot 团队。LangChain4j 通过灵活性和可移植性奖励任何 JVM 团队。两者都已准备好用于生产。你的上下文决定一切。