Spring AI 與 LangChain4j：2026 年你該選擇哪個 Java AI 框架？

今年稍早，我需要在我維護的 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 一起使用時，你需要處理更多的連接工作。

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

@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);
}

// Usage
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 團隊。兩者都已準備好投入生產。你的情境決定一切。