LangChain4j：JVM 上以 Java 慣例重寫的 LLM 整合層
LangChain4j is an idiomatic, open-source Java library for building LLM-powered applications on the JVM. It offers a unified API over popular LLM providers and vector stores, and makes implementing tool calling (including MCP support), agents and RAG easy. It integrates seamlessly with enterprise Java frameworks like Quarkus and Spring Boot.
秒懂
- 它是什麼？
- LangChain4j 不是 LangChain 的 Java 移植，而是一套圍繞型別安全、POJO、註解與依賴注入重新設計的 Java 函式庫。它的價值在於用一層統一 API 隔開 20 多個 LLM 供應商與 30 多個向量儲存，代價是抽象層本身也成為你必須維護的依賴。
- 適合誰用？
- 如果你已經在 JVM 上，且需要在多個 LLM 供應商或向量儲存之間切換，LangChain4j 的統一 API 與 Quarkus、Spring Boot 整合能省下大量樣板程式碼，值得採用。若你只固定用一家供應商的 SDK、且不打算做 RAG 或工具呼叫，直接使用官方 SDK 會少一層抽象與升級負擔。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 Java（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是 Java 生態裡缺對應函式庫的問題
專案 README 對動機講得很直白：LangChain4j 始於 2023 年初，作者群注意到 Python 與 JavaScript 有大量 LLM 函式庫與框架，Java 卻沒有對應物。目標受眾因此不是「想學 LLM 的人」，而是已經有一批 Java 服務、不想為了接一個模型而引入第二套語言執行環境的團隊。
問題的形狀是這樣：OpenAI、Google Vertex AI 這類供應商各有專屬 API，Pinecone、Milvus 這類向量儲存也各有專屬 API。要在同一個應用裡換模型，通常得改動呼叫端程式碼。LangChain4j 提供一層統一 API，讓切換供應商不需要重寫程式。README 列出目前支援 20 多個 LLM 供應商與 30 多個向量儲存。
這裡要說清楚一個常見誤解。README 用粗體寫明：儘管名字如此，LangChain4j 不是 LangChain（Python）的 Java 移植，它是為 Java 而建，不是被移植到 Java。它的 API、內部實作與發布週期都獨立於 Python 專案。所以不要拿 Python 版的類別名稱去推測 Java 版的結構，兩者沒有對應關係。
統一 API 之下的分層：從 prompt 模板到 Agent 與 RAG
README 把工具箱描述成從低階到高階的一整條線：低階有 prompt 模板與聊天記憶管理，中階有 function calling，高階是 Agent 與 RAG 這類模式。對每個抽象，專案提供一個介面加上多個立即可用的實作。
這個分層方式決定了你怎麼用它。如果你只需要把一段文字送進模型拿回答案，用最底層的模型介面就夠，不需要碰 Agent 或 RAG 的抽象。反過來說，如果你要做完整的檢索流程，README 的說法是 LangChain4j 提供從資料匯入到檢索的完整選項。這種「同一套 API 覆蓋多個層級」的設計，好處是不用為了升級做法而換函式庫，壞處是相依套件的表面積會隨你引入的模組增加。
README 也提到工具呼叫包含 MCP 支援。MCP 是模型與外部工具之間的協定，把它放進工具呼叫這一層意味著工具定義可以來自外部服務，而不只是應用內寫死的 Java 方法。實際的註冊與呼叫細節在 README 中沒有展開，需要查 docs.langchain4j.dev 的整合章節。
專案另有一個實驗性的文件聊天機器人，位在 chat.langchain4j.dev。README 自己標註為 experimental，這個定位值得照字面理解。
用 Maven Central 上的 dev.langchain4j 座標開始
README 沒有在正文貼出完整的安裝指令，但徽章指向 Maven Central，座標群組為 dev.langchain4j，主要 artifact 為 langchain4j。取得方式就是一般 Maven 或 Gradle 依賴宣告，版本對照 Maven Central 上的最新版。
真正需要花時間的是選擇供應商模組。因為統一 API 是核心，各供應商與向量儲存是以獨立模組形式提供，你得同時引入核心與你實際要用的整合模組。README 沒有列出模組命名規則，這部分要看 docs.langchain4j.dev 的 integrations 頁面，語言模型與嵌入儲存各有自己的清單頁。
框架整合的路徑 README 講得比較具體。Quarkus 走 quarkus-langchain4j 這個依賴，範例在 quarkiverse/quarkus-langchain4j 的 samples 目錄。Spring Boot 有 spring-boot-example 範例專案。Helidon 走 io.helidon.integrations.langchain4j，Micronaut 走 micronaut-langchain4j。也就是說，四個企業框架的整合並不在同一個 repo 裡，Quarkus 與 Micronaut 的整合由各自的社群專案維護，版本節奏未必與核心同步。這是採用前要納入考量的現實。
版本節奏與那個不該使用的版本
近期發布紀錄顯示 1.20.0 與 1.20.0-beta30 在 2026-09-04 發布，1.19.2 與 1.19.2-beta29 在 2026-09-07 發布，而 1.19.1 的說明直接寫明是誤發布、不要使用。這種情況在任何活躍專案都可能發生，但值得記住的是：不要看到版本號比較新就無條件升級。
更值得注意的是 beta 版本與正式版本並行發布的做法。1.19.2 與 1.19.2-beta29 同日出現，1.20.0 與 1.20.0-beta30 同日出現。這代表專案維持兩條線：穩定線與 beta 線。beta 線通常承載尚未定案的新整合或 API 調整。如果你的服務要上線，選擇穩定線；只有在你需要某個尚未進入穩定線的供應商整合時，才考慮 beta，並且要預期 API 會變。
README 自己也承認「函式庫仍在積極開發中，部分功能還在處理」。這句話放在採用決策裡的意思不是專案不成熟，而是你必須把升級成本算進維護預算。抽象層的好處是隔開供應商，代價是這一層本身會隨版本演進而變動。
抽象層在什麼情況下反而是負擔
統一 API 有一個結構性的限制：它只能覆蓋多數供應商共有的能力。當某家供應商推出獨有功能時，這層抽象通常來不及或不打算暴露它。你如果正好需要那個功能，就得繞過統一介面直接呼叫原生 SDK，於是你同時維護兩套呼叫路徑，抽象帶來的好處在那一處歸零。
第二個限制是整合廣度與整合深度不是同一件事。README 列出 20 多個 LLM 供應商與 30 多個向量儲存，但每個整合的完成度、支援的參數、是否支援串流或工具呼叫，在 README 中看不出來。如果你的檢索流程依賴某個向量儲存的特定索引設定，先確認那個整合模組是否暴露對應設定，再決定要不要採用。
第三，LangChain4j 不負責模型品質，也不負責檢索品質。它提供的是介面與實作，不是調校好的管線。RAG 效果不好時，問題通常在切塊策略或嵌入模型選擇，換函式庫不會改善。把它當成整合層而不是效能層，期待才不會落空。
與直接用供應商官方 SDK 的實際差異
最現實的替代方案就是直接用 OpenAI 或 Anthropic 的官方 Java SDK，或各家向量儲存自己的客戶端。差別在於抽象的位置：官方 SDK 把供應商的概念直接呈現給你，LangChain4j 在中間插入一層自己的介面。
如果你的應用只接一家供應商、短期內不打算換，官方 SDK 的優勢是沒有中間層，供應商新增什麼你就能用什麼，升級路徑也由供應商負責。LangChain4j 的優勢則出現在你有兩個以上供應商或儲存的時候：切換時改的是設定與模組依賴，不是散落在各處的呼叫程式碼。
另一個差異在框架整合。Spring Boot 或 Quarkus 專案裡，LangChain4j 有現成的整合模組與範例，官方 SDK 通常要自己寫設定類別。如果你的服務已經大量使用這些框架的依賴注入與設定機制，整合模組能省下的樣板程式碼是實質的。
至於 Python 的 LangChain，README 已經排除把它當成對照組的可能：兩者沒有移植關係，API 不對應，發布週期也各自獨立。把它們放在一起比較架構沒有意義。
授權與升級成本要一起看
授權為 Apache-2.0，這是寬鬆授權，允許商業使用與修改，通常只需要保留版權聲明與授權條款。這裡不提供法律意見，實際條款以專案 LICENSE 檔案與你組織的政策為準。要注意的是，核心採 Apache-2.0 不代表每個周邊整合模組都相同，尤其 Quarkus 與 Micronaut 的整合位於各自的社群專案，授權需個別確認。
升級成本主要來自兩處。第一是核心 API 的演進，專案同時維護穩定線與 beta 線，跨版本升級需要讀 release notes。第二是整合模組與框架整合模組的版本對齊，核心升了但框架整合還沒跟上時，你可能得暫時停在舊版核心。
降低這個成本的做法很具體：在 pom.xml 或 build.gradle 中把 LangChain4j 相關依賴集中管理版本，不要讓各模組散落不同版本號。這樣升級時只需要改一處，也能一眼看出哪些整合模組還沒跟上。
編輯結論
如果你已經在 JVM 上，且需要在多個 LLM 供應商或向量儲存之間切換，LangChain4j 的統一 API 與 Quarkus、Spring Boot 整合能省下大量樣板程式碼，值得採用。若你只固定用一家供應商的 SDK、且不打算做 RAG 或工具呼叫，直接使用官方 SDK 會少一層抽象與升級負擔。導入前先確認三件事：你要用的模型與向量儲存在文件列出的整合清單中、你預定使用的版本號（README 明確指出 1.19.1 是誤發布、不應使用）、以及該版本對應的 JDK 需求。
社群筆記