LangChain4j 还是 Spring AI？Java 开发者选型避坑指南
为什么“选哪个框架”比看起来难
我在不同团队里见过至少四种选框架的方式，它们有一个共同点：都是在回答一个错误的问题。
第一种是看 Star 数或热度，“大家都在用”所以我也用。但 Star 反映的是关注度，不回答“它和我现有运维体系兼不兼容”。往往上线后才发现，它要求一个你的运行时没有的东西。
第二种是看 Benchmark 和功能清单。“它支持 30+ 模型，它支持 12 种向量库”。但在 2026 年，两边的能力清单高度重叠，差异项多半用不到。半年后你会发现，那些“用不到的功能”从来没被真正评估过。
第三种是看同事或社区偏好。“我们组有人熟 LangChain4j”。单个人的熟悉度换来的是全团队三年的跟随成本。第一个大版本升级时，那个同事可能已经不在这个项目了。
第四种最危险：“都是 Java 框架，应该差不多”。这是一种直觉，但它们在“对运行时提什么要求”上差别巨大。我见过一个团队的真实决策过程：需求只是“给工单服务加一个智能分派”，实现却是“引入一个 AI 依赖”。三个月后复盘时发现，这件事的真实后果是“整个平台从 Spring Boot 3.5 升到了 Boot 4”——而这个结论从来没有被拿出来讨论过。不是升级不对，而是它是被“顺手带进来”的，没有人为它做过一次决策。
2026 年的关键事实：功能已经不是差异点
到了 2026 年，功能清单已经不是选型依据了。把两边最常被拿来对比的能力列出来，你会看到它们高度重合：聊天抽象、工具调用、结构化输出、RAG、向量库支持、会话记忆、流式输出、MCP 客户端支持以及可观测性。每一格都能填出东西，所以拿它做选型依据，你会得到“两个都行”这个没有用的结论。
真正有区别的，是每一格下面藏着什么约束。比如同样是“流式输出”，LangChain4j 的非阻塞支持是为了在 WebFlux 或 Quarkus 的事件循环上不阻塞线程，而 Spring AI 的做法更贴近 Spring 自己的响应式体系。这两者对“你的服务是什么并发模型”的要求完全不同。
所以我在这篇里坚持一个原则：不比较功能有无，只比较约束与代价。
真正的分野：它对“你已有的运行时”提什么要求
这是本篇最核心的一张图，也是我给所有团队讲选型时用的第一张图。它把两个框架放到“运行时自由度”与“生态整合深度”这两个轴上。注意这两者不是“能力”，而是“承诺”。
Spring AI 的深度整合不是免费的。它换来的是：ChatClient 一行构建、Advisor 可以直接复用你对 Spring 拦截器的直觉、Actuator 天然暴露 LLM 调用链路、配置全部走 Spring 的 @ConfigurationProperties。但这些便利的入场券是 Spring Boot 4 + Framework 7 + Jackson 3 + JDK 21。
LangChain4j 的自由度也不是免费的。它换来的是：在一个 Boot 3.5 的服务里加一个 AI 依赖，不需要动平台版本；或者在一个 Quarkus 项目里用同一套 API。但代价是：那些“Spring 帮你做好的事”（配置绑定、Bean 装配、观测端点）你要自己接一遍。
Spring AI 的“运行时自由度弱”和它的“生态整合强”是同一个决策的两面。选型不是选一个更好的框架，而是选一个你更愿意在接下来三年里为之买单的承诺。
一条被严重低估的成本：版本节奏
上一节讲的是“入场券”，这一节讲“月供”。如果你把框架当成一次性选择，会漏掉成本里最大的一块：跟随它的版本节奏要花多少人力。
Spring AI 的大版本策略是绑定 Spring Boot 大版本，发布节奏与 Boot 同步，大版本间隔以年计。升级动作是大版本升级等于平台级动作，Boot 一起动。主要风险是被“平台升级”的时间表绑架。
LangChain4j 不绑框架，发布节奏是小步快跑，1.12 到 1.20 约 6 个月。它同时维护主版本和多条回溯线（如 1.19.x / 1.11.x / 1.5.x）。升级动作只是改一个依赖版本。主要风险是版本迭代快，集成模块可能带 beta 后缀。
LangChain4j 同时维护多条回溯线，既是优点也是风险。优点是锁在旧版本上的生产系统能持续拿到修复；风险是你必须想清楚“我跟哪条线”，而且大量集成模块仍以 beta 版本号迭代，升级时要留意 API 变化。这不是缺陷，是“小步快跑”这个性格的必然结果——跟踪它需要的是持续的、小额的投入；而跟踪 Spring AI 需要的是间歇的、大额的投资。
如果你有一个稳定的平台团队、能承受“每隔一两年做一次平台大版本升级”，那 Spring AI 的节奏更省心。如果你的团队小而灵活、更接受“每季度花半天跟一下依赖版本”，LangChain4j 的节奏更匹配。
两个框架的设计哲学
Spring AI：把 AI 能力做成“Spring 的一个抽象层”
理解 Spring AI 最快的方式，是把它类比成 Spring Data。两者的定位完全一致：不发明新概念，而是把一类外部能力抽象成 Spring 自己的编程模型，让开发者用已有的 Spring 直觉去使用它。
它的三个设计特征：
第一，一切皆 Advisor。这是 Spring AI 最有辨识度的设计。RAG 检索、会话记忆、工具执行、内容安全过滤，全都实现成 Advisor，串在一条链上。如果你熟悉 Servlet Filter 或 AOP 拦截器，这套模型你会觉得非常自然。代价是顺序变成了语义，而在 2.0 里工具执行也变成了链上的一环，顺序的敏感面进一步扩大。
第二，构建器 + 默认值。默认值集中在构建期，业务代码里只剩 prompt().user(q).call().content()。这个设计的收益是业务代码极干净、能力集集中可审计；代价是配置的“隐式性”较强，出问题时要顺着构建器往回找。
第三，与 Boot 生命周期深度绑定。自动配置、@ConfigurationProperties 绑定、Actuator 端点、条件装配全套齐全。这也是它要求 Boot 4 的原因：这些能力依赖 Boot 与 Framework 的底层机制，跨大版本兼容的代价太高。
顺便说一个 2.0 的取舍，它很能说明这个框架的性格：2.0 对模型提供商做了精简。部分提供商只保留官方 SDK 变体，某些厂商移除了 Vertex 变体。这不是能力倒退，而是“维护可控”优先于“列表好看”。这条取舍对选型的含义是：迁移到 2.0 之前，先确认你要用的提供商在支持列表里。
LangChain4j：一个“地道的 Java 库”，而不是 Python 的移植
关于 LangChain4j 有一个流传很广的误解必须先澄清：它不是 Python LangChain 的 Java 移植，而是从零构建的惯用 Java 库。这个区别不是文字游戏——它的 API 形态是类型安全、POJO、注解、接口、流式 API 那一套 Java 的东西。
它的两个设计特征：
第一，两级抽象，让你自己选深潜程度。低层是原语（ChatModel、EmbeddingStore、EmbeddingModel），自由度拉满；高层是 AiServices 声明式接口——定义一个 Java 接口加注解，框架生成实现，把“调模型”写成像调用本地方法一样。
第二，Agentic 原语走得比较靠前。以 1.19 为例，它引入了 AgenticScope（智能体之间共享状态的载体）、并行 mapper（多步操作并行化）以及工具补偿机制。多个工具连续调用中途失败时自动执行补偿操作，本质是给 AI Agent 补上了 Saga 风格的事务语义。如果你的场景里有“调三个接口完成一个业务动作、中间失败要回滚前两步”这类需求，这一条会成为真实的加分项。
另外它的一个鲜明性格是“MCP 协议跟进速度最快”。它是第一个支持 MCP 2026-07-28 新规范的 Java 框架。如果你在 MCP 生态上押得比较重、需要第一时间用上新协议能力，LangChain4j 的跟进速度是实打实的优势。
同一件需求，两套代码：聊天 + 工具 + RAG
理论说完，直接看代码。这是我认为最诚实的对比方式：不是看文档能做什么，而是看“同样一件事，我的代码会长成什么样”。
需求是一个带会话记忆、能查数据库（工具）、能查文档（RAG）的助手。
Spring AI 的写法形态是构建器 + Advisor 链。记忆、RAG、工具都是“链上的一个环节”，能力集集中在构建期声明。业务代码只剩一行：String answer = assistant.prompt().user(question).call().content();
LangChain4j 的写法形态是接口 + 注解，框架生成实现。记忆、RAG、工具都是“接口上的一个声明”，能力集写在 AiServices 装配处。业务代码像调本地方法：String answer = assistant.chat(question);
两段代码放在一起，差异一眼可见。Spring AI 扩展方式是加一个 Advisor，顺序敏感的显性度高，顺序就在构建器里，一眼可读，但也意味着必须读它。LangChain4j 扩展方式是加一个配置/注解，顺序由框架内部决定，不容易配错，但也难精细干预。
这张表的最后一行是我认为最实在的判断依据。Spring AI 把“顺序”暴露给你了，LangChain4j 把它藏起来了。如果你希望“配错了能一眼看出来”，那 Spring AI 的显性是优点；如果你更希望“框架别让我操这个心”，LangChain4j 的隐藏是优点。但要注意：被隐藏的东西不是消失了，只是不在你眼前。一旦 LangChain4j 内部的默认顺序与你的预期不符，你需要读源码或文档才能调。
术语对照表：避免“同名不同义”的坑
这一节很实用，因为两个框架有大量同名概念但行为不完全一致。从一边迁到另一边的人，最容易踩的坑就是“以为 ChatMemory 是同一个东西”。
对话模型两者都叫 ChatModel，都是低层原语，这点一致。但高层门面差异最大：Spring AI 是 ChatClient（构建器 + Fluent），LangChain4j 是 AiServices（接口 + 注解）。
工具定义注解名接近，但参数注解名不同：Spring AI 用 @ToolParam，LangChain4j 用 @P。两边都能做到“模型不可见”的工具上下文，但写法差别大。
记忆方面，Spring AI 是 ChatMemory + Advisor，是“链上的一环”；LangChain4j 是 ChatMemory 多实现，是“装配时的一项”。这直接影响你排查“上下文丢失”类问题的方式。Spring AI 里第一排查点是“Advisor 有没有挂上、顺序对不对”；LangChain4j 里第一排查点是“AiServices 装配时有没有传”。
向量库方面，Spring AI 叫 VectorStore，LangChain4j 叫 EmbeddingStore。语义一致，但过滤表达式语法不通用。如果你从一边迁到另一边，向量库的过滤逻辑要重写。
环境准备：两套依赖与版本矩阵
版本矩阵：先看那张表，再决定要不要往下读
如果这一篇只看一张表，请看这张。因为它把“选型”直接翻译成了“你能不能接受这个要求”：
Spring AI 路线要求 JDK 21，必须 Spring Boot 4.0/4.1，Spring Framework 7.x，Jackson 3.x。框架耦合强，非 Spring 环境不适用。大版本升级代价是平台级，Boot 一起升。
LangChain4j 路线要求 JDK 17+，Spring Boot 可选（Boot 3.5+/Boot 4 都有 starter，也可不用 Boot）。框架耦合弱，Quarkus/Micronaut/纯 Java 均可。大版本升级代价是依赖级，改版本号即可。
这张表里最关键的一格是“Spring Boot”那一行。它把本文前面所有讨论压缩成了一个二元问题：如果你的服务现在跑在 Boot 3.5 或更低，选 Spring AI 2.0 就意味着“给一个服务加 AI”变成“整个平台升 Boot 4”。而选 LangChain4j，这件事就只是“加一个依赖”。
这不是说 Boot 4 不值得升，关键是这个决定应该在选型会上被明确提出来、被单独评估，而不是作为“引入 AI”的附带结果。
两套依赖
Spring AI（Boot 4 + JDK 21）的依赖管理通过 spring-ai-bom 导入，依赖包括 spring-ai-starter-model-openai 和 spring-ai-starter-vector-store-pgvector 等。你没有写 Boot 的版本，它由 Boot 的父 POM 决定。
LangChain4j（不强制 Boot 4）的依赖包括 langchain4j 核心包、langchain4j-open-ai 适配器以及 langchain4j-spring-boot-starter。所有版本都是显式的，而且要注意 starter 有 Boot 3.5 与 Boot 4 两条线，选错线会出现“能编译、启动失败”的情况。
环境准备阶段就该做的三件事
框架还没选完，有三件事可以先做，它们对两条路线都有价值：
第一件：确认你的 JDK 版本这一项是“决定项”还是“既有事实”。如果团队已经在 JDK 21 上，那么 Spring AI 2.0 的 JDK 要求不构成门槛。如果还在 JDK 17，LangChain4j 的 17+ 门槛就变成一个真实的吸引力。
第二件：把“模型与向量库的支持列表”对着你的技术栈核一遍。两边都支持主流选项，但你可能有非主流需求。一个具体的例子：如果你的需求里有“必须支持某个向量库的 ANN + BM25 混合检索”，那就去查那个库在两边适配器里的成熟度与版本号后缀。
第三件：把版本节奏表，乘以你团队的人力，算成“年成本”。公式保持简单就好：Spring AI 是平台大版本升级，约 1~2 年一次，单次人力高，年成本量级是大额、间歇。LangChain4j 是依赖版本跟随，约每季度一次，单次人力低，年成本量级是小额、持续。这张表的用处不是算出精确数字，而是让你在选型会上能回答一句：“我们更愿意每年花 5 次小力气，还是两年花一次大力气？”
十个维度逐项对比
运行时自由度
Spring AI 不能脱离 Spring，依赖 Boot 自动配置体系，支持的框架仅限 Spring Boot 4.x（1.1.x 支持 Boot 3.5）。给现有服务加 AI 的动作可能触发平台大版本升级，JDK 要求 21。
LangChain4j 可以脱离 Spring，作为普通依赖，支持 Boot 3.5+/Boot 4/Quarkus/Micronaut/纯 Java。给现有服务加 AI 的动作只是加一个依赖，JDK 要求 17+。
这一条什么时候会变成决定项？四种情况，满足任意一种就该把权重拉满：你的项目不是 Spring；你的服务在 Boot 3.5 或更低且短期没有升级窗口；大型多模块单体只想给某一个模块加 AI；平台的升级窗口排不上期，但你有一个业务需求这个季度就要上线。
一个提醒：如果你已经是 Boot 4 + JDK 21，这一维度的权重应该直接归零。
版本节奏与升级代价
LangChain4j 小步快跑，依赖级升级，动作小、频次高，时机由你定。它并行维护回溯线，旧版本仍持续拿修复。
Spring AI 与 Boot 节奏绑定，平台级升级，动作大、频次低，时机受 Boot EOL 时间表牵引。
这一条什么时候会变成决定项？如果你的团队有独立平台团队、能定期做平台大版本升级，Spring AI 的节奏更省心。如果你的团队小而灵活、更接受“每季度花半天跟依赖”，LangChain4j 的节奏更匹配。如果你不能接受“升级时机由别人的 EOL 时间表决定”，这一条会明显偏向 LangChain4j。
一个提醒：大版本绑定的真实风险不是“升级难”，而是“升级的时机不由你定”。当一个平台组件 EOL，它会沿着依赖链把压力传导到你的框架上。
抽象层级与代码形态
Spring AI 高层门面是 ChatClient（构建器 + Fluent），低层原语是 ChatModel/VectorStore/Advisor，扩展机制是加一个 Advisor。业务代码是 prompt().user(q).call().content()。学习曲线需要理解 Advisor 顺序语义。
LangChain4j 高层门面是 AiServices（接口 + 注解），低层原语是 ChatModel/EmbeddingStore/Retriever，扩展机制是加一个装配项/注解。业务代码是 assistant.chat(q)。学习曲线需要理解接口到实现的生成规则。
这一条什么时候会变成决定项？同一个助手被团队里多人、多入口调用，且要求行为一致，LangChain4j 的接口形态优势明显。每个业务场景需要一套不同的能力组合，Spring AI 的构建器更自然。团队里 AI 经验少、Java 常规经验多，接口 + 注解的形态上手更快。
RAG 能力
Spring AI 入库流程是 ETL Pipeline，需自己组合。检索装配是 QuestionAnswerAdvisor 挂到 ChatClient。向量库覆盖主流库完整。
LangChain4j 入库流程是 EmbeddingStoreIngestor 开箱，可插拔 splitter/transformer。检索装配是 ContentRetriever 注入 AiServices。向量库覆盖最广，有专用混合检索 API，自带 ONNX 本地嵌入模型，可完全离线。
这一条什么时候会变成决定项？需求里明确写了某个特定向量库的混合检索，必须去核对该库在两边适配器的成熟度。需要“完全离线/数据不出机房”，LangChain4j 自带的 ONNX 本地嵌入模型让这条路更容易一步到位。已经在 Spring + pgvector 上、需求是标准的向量检索，Spring AI 更顺。
工具调用与 Agentic 编排
Spring AI 工具定义用 @Tool/@ToolParam，模型不可见的上下文用 ToolContext。循环托管在 2.0 上移到 ToolCallingAdvisor，顺序显式可干预。多步编排需引入 graph 模块做图编排，失败补偿需自己实现，多 Agent 共享状态需自行设计。
LangChain4j 工具定义用 @Tool/@P，模型不可见的上下文用参数注入/上下文字段。循环托管在 AiServices 内部。多步编排有 AgentExecutor 原生支持，失败补偿有工具补偿机制（Saga 风格语义），多 Agent 共享状态有 AgenticScope，并行执行有并行 mapper。
这一条什么时候会变成决定项？只是“工具调用 + 单 Agent 一问一答”，两边持平。有多步编排需求，LangChain4j 的原语成熟度是真实的加分项。要做多 Agent 协作，AgenticScope 能省掉不少设计工作。需要精细干预工具循环的每一轮，Spring AI 的 Advisor 位置显式，这件事更清楚。
记忆与会话
Spring AI 抽象是 ChatMemory + Advisor，装配方式是链上的一环，顺序敏感。常用策略是窗口记忆、持久化后端。精细控制方面，Advisor 形态便于横切改造。
LangChain4j 抽象是 ChatMemory 多实现，装配方式是装配时的一项，不易漏。常用策略是窗口记忆、多存储后端。精细控制通过自定义实现替换。
这一条什么时候会变成决定项？只需标准窗口记忆，两边等价。需要对记忆做精细横切干预，Spring AI 的 Advisor 形态更灵活。团队容易“漏挂配置”，LangChain4j 的装配式写法更不容易漏。
流式输出与并发模型
这一节是本文技术含量最高的一节，因为它的差异不是“风格”，而是“能不能用”。
如果你的服务跑在事件循环模型上（Spring WebFlux/Vert.x/Quarkus），这是硬要求，不是偏好。阻塞式的 AI 调用会占住事件循环线程，而 AI 调用恰好是“长耗时 + 多轮”的典型形态，它比普通数据库调用更容易把事件循环堵死。
LangChain4j 在 1.20 起按返回类型选择同步/TokenStream/CompletableFuture/Flow.Publisher，非阻塞覆盖工具/记忆/护栏/检索图。HTTP 请求进入，返回类型决定执行模式，等待期间不占用线程。
Spring AI 的做法更贴近 Spring 自己的响应式体系。如果你的服务是传统 Tomcat + 线程池，阻塞式通常够用，因为线程池本身就是缓冲。
一个提醒：非阻塞的“默认语义与同步不同”，切换时要按迁移处理而不是按开关处理。
可观测性
Spring AI 原生集成 Micrometer/Actuator，Spring 栈内天然可用。Actuator 可暴露 LLM 调用链路、Prompt 渲染结果。工具调用入参/出参有开关。
LangChain4j 原生集成 OpenTelemetry 标准 + Tracer 接口。需自行实现日志埋点。在非 Spring 环境，OTel 标准更通用。
这一条什么时候会变成决定项？你已有 Micrometer/Actuator 体系，且是 Spring 栈，Spring AI 省事明显。你已有 OTel 体系，或者不是 Spring 栈，LangChain4j 的 OTel 路线更标准。
中文生态与信创适配
Spring AI 通义千问接入可通过 OpenAI 兼容端点，另有 Spring AI Alibaba 原生 DashScope 集成。但 Spring AI Alibaba 需与 Spring AI 主线版本对齐。它是官方 Spring 项目，企业采购/合规上更好交代。
LangChain4j 通义千问接入同样可通过 OpenAI 兼容端点，社区有 DashScope 适配。适配模块版本独立，但成熟度需逐个核对。它更容易一步到位实现完全离线（自带 ONNX 本地嵌入）。
这一条什么时候会变成决定项？你需要某个国内平台的“原生独有能力”，必须逐个核对适配模块的实际成熟度。你的合规要求包含“完全离线”，LangChain4j 自带本地嵌入让这条路径更容易闭环。企业采购/合规需要“官方支持方”，Spring AI 的官方属性在这里是实打实的优势。
文档、社区与生态规模
Spring AI 起点是 Spring 官方项目，与 Spring 文档体系一致。集成数量主流覆盖完整。文档风格与 Spring 官方文档同构，有体系。遇到问题时多在 Spring 体系内可找到答案。
LangChain4j 起点是社区驱动，2023 年初起步，更早。模型与向量库集成数量最多。文档教程丰富，但成熟度不齐（部分模块 beta）。遇到问题时更多依赖社区、GitHub issue 与源码。
这一条什么时候会变成决定项？团队需要“出问题能有人问/有体系可查”，Spring AI 的文档体系与官方属性是优势。需要某个小众模型或向量库的现成集成，LangChain4j 的集成广度是优势，但要核对那个具体模块的版本状态。
选型决策树、迁移成本与混合策略
选型决策树
Q1：项目是 Spring Boot 技术栈吗？否（Quarkus/Micronaut/纯 Java）→ LangChain4j。这一条直接决定，无需再看后面。
Q2：现在已在 Boot 4.x + JDK 21 吗？是 → 继续。否：还在 Boot 3.5 或更低 → W1：半年内能完成 Boot 4 升级吗？能，且平台团队有计划 → 继续。不能/不想动平台 → LangChain4j。
Q3：有非主流向量库/混合检索/完全离线嵌入需求吗？有 → 倾向 LangChain4j（先去核对那个具体模块的成熟度）。没有 → 继续。
Q4：有多步编排 + 失败补偿/多 Agent 协作需求吗？有，且愿意用实验性原语 → 倾向 LangChain4j（但其原语成熟度必须逐个确认）。没有，就是工具调用 + 单 Agent → 继续。
Q5：企业的技术评审要求官方支持方吗？要求 → Spring AI。不要求 → 继续。
Q6：团队更接受哪种投入形态？大额间歇（平台级升级）→ Spring AI。小额持续（季度跟依赖）→ LangChain4j。
这张决策树的设计意图很明确：Q1 和 Q2 是“门槛问题”，Q3 之后才是“偏好问题”。
迁移成本：如果选错了，换回来要付多少
双向迁移的成本分解（以中型项目、约 20 个接口、含 RAG 与工具调用为例）：
高成本（工作量大且有隐性坑）：装配与执行链路（Advisor 链 ↔ AiServices 装配，顺序语义要重新确认）、测试体系重建（选择测试/契约测试，断言方式可能全变）、回归与标定（工具选择准确率要重新测，分块与阈值可能要重标）。
中等成本（要重写但要按原逻辑）：工具方法定义（注解换名，ToolContext ↔ 参数注入）、向量库过滤表达式（两边语法不通用）、观测埋点（Micrometer ↔ OTel/Tracer）。
几乎零成本（可整体复用）：提示词与系统约束（系统提示词、工具描述、RAG 提示词模板）、业务逻辑（Service/DAO/SQL、权限模型、幂等设计）。
结论：资产可复用，代码基本重写。量级：中型项目约 3~6 人周，其中约一半花在测试重建与回归标定。
这意味着两件事。第一，如果你已经按本系列的方法做了工程化，那么换框架的代价主要在“装配层”。第二，反过来推，选型的紧迫性可以降低一档：不要因为“怕选错”而迟迟不开始。
混合使用：可行，但不是免费的
“能不能两个都用，各取所长”是评审里必被问到的问题。我的回答是：可以，但要付四份代价，而且不能把它当作“不做决定”的借口。
可行的混合形态：明确边界 + 同一服务 + 同一批人。Spring AI 承载主链路（聊天/工具/RAG/记忆），LangChain4j 的某个模块补特殊能力（如特定向量库的混合检索 API）。
代价一：依赖体积。两套模型客户端 + 两套向量库抽象。
代价二：配置双份。两套 Key/超时/重试策略，且有“两套配置不一致”的风险。
代价三：观测双体系。Micrometer 与 OTel 的指标要各自打通。
代价四：团队心智双份。新人要学两套概念（且同名不同义）。
所以我的建议是：如果一定要混合，就用“主 + 一点”的形态。反过来，“两个都用”如果是因为“评审时决定不了”，那就是把决策成本转嫁成了长期的维护成本。
三年总成本模型
把前面所有维度收成一张能算账的表。注意这里的量级是“相对”的，用来做比较而不是做预算：
初始接入：Spring AI 低（若是 Boot 4 + JDK 21），LangChain4j 中（Spring 侧便利要自己接）。
初始学习：Spring AI 中（Advisor 顺序语义），LangChain4j 中（接口到实现的生成规则）。
平台升级：Spring AI 高（Boot + Framework 一起动），LangChain4j 无此项。
版本跟随：Spring AI 低（大版本间隔以年计），LangChain4j 中高（约季度一次）。
生态适配等待：Spring AI 有（2.0 刚 GA，适配滞后），LangChain4j 低（适配模块独立迭代）。
迁移机会成本：选错后约 3~6 人周，同量级（反向）。
三年主导项：Spring AI 是平台升级（一次大额），LangChain4j 是版本跟随（多次小额）。
这张表的结论是一句话：三年成本的主导项不是“初始接入”，而是“你更愿意付一次大额、还是多次小额”。
适用边界与风险提示
五个必须避开的选型风险
风险一：用 Star 数/集成数量代替架构判断。共同后果：决策看起来有依据，但依据回答的不是真问题。
风险二：把“加 AI”做成“升平台”而不自知。
风险三：低估版本节奏的持续成本，只算初始接入的人天。
风险四：为“万一要用”的宽覆盖买单（支持 30+ 模型，你只用 2 个）。
风险五：项目中期换框架。
缓解方式：把选型依据写成“约束清单”（JDK/Boot/并发模型/向量库/官方支持/升级窗口）而不是“能力清单”。判断标准：如果一份选型文档里全是“支持 XX”而没有“要求 YY”，它就没做完。
什么时候两个框架都不该用
场景一：你只是要“调一次模型”做一次性任务。直接写 HTTP 调用就行，不要引入框架。
场景二：你的需求只是“批量离线文本分类或摘要”。批处理场景没有会话、没有工具、没有流式、并发模型简单。一个 HTTP 客户端 + 一个信号量控制并发就够了。
场景三：需求里没有“会话”这个维度。框架的核心抽象都是围绕会话设计的。如果你的场景是“无状态的一问一答、每次都是独立调用”，那么框架带来的收益会明显下降。
场景四：团队里没有人愿意长期维护这套东西。框架是“需要跟随的资产”，不是“装完就忘的依赖”。
生产建议清单
先写约束清单，再读对比表：JDK/Boot/并发模型/向量库/官方支持/升级窗口，六项写完再看功能。
把“是否触发平台升级”单独评估，不要让它在“引入 AI 依赖”里被顺手带过。
确认你的向量库与模型在目标框架里的适配成熟度（含版本后缀是不是 beta），不要只看“支持”。
如果服务是事件循环模型（WebFlux/Vert.x/Quarkus），把非阻塞支持当硬要求，并按“迁移”对待而非“开关”。
确认候选框架的原语里有多少是实验性标记；核心业务不要压在实验性原语上。
把版本跟随写进团队职责：谁负责跟进、多久看一次、回归跑哪些用例。
选型文档里必须出现“要求”而不只是“支持”。
不要项目中期换框架；真要换，按“改代码 + 重建测试”两笔预算估。
总结
回到开头那个问题
开头我说，“如果这个选择本身就是错的，前面五篇的收益都要打折”。现在可以给出结论了：这个选择不像很多人以为的那样“两个都行”，但它的判据也不是功能清单，而是两条约束。
第一条是硬约束：你的运行时是什么。不是 Spring 栈 → 直接选 LangChain4j。是 Spring 栈但在 Boot 3.5 且半年内不动平台 → Spring AI 2.0 需要 Boot 4 作为入场券，这件事必须被单独决策。
第二条是软约束：你更愿意付哪种代价。Spring AI 用“平台级升级 + 强绑定”换来“深度整合的省心”；LangChain4j 用“集成代码自己接 + 版本迭代更快”换来“运行时的自由”。这两者不是好坏，是两种承诺。
十个维度速查表
运行时自由度：明显偏向 LangChain4j（非 Spring 栈/Boot 3.5 不动/多模块单模块接入）。两边持平（已是 Boot 4 + JDK 21）。
版本节奏：明显偏向 Spring AI（有平台团队、能定期大版本升级）。明显偏向 LangChain4j（不接受升级时机被 EOL 时间表牵引）。
代码形态：明显偏向 Spring AI（每场景一套能力组合）。明显偏向 LangChain4j（同一助手多入口调用、要求行为一致）。
RAG：明显偏向 LangChain4j（特定向量库混合检索/完全离线嵌入）。两边持平（标准向量检索）。
工具与 Agentic：明显偏向 LangChain4j（多步编排 + 失败补偿/多 Agent 共享状态）。两边持平（工具调用 + 单 Agent）。
记忆：明显偏向 Spring AI（需要对记忆做横切改造）。两边持平（标准窗口记忆）。
流式与并发：明显偏向 LangChain4j（事件循环模型）。两边持平（传统 Tomcat 线程池）。
可观测性：明显偏向 Spring AI（已有 Micrometer/Actuator）。明显偏向 LangChain4j（已有 OTel 体系/非 Spring 环境）。
中文与信创：明显偏向 Spring AI（需要官方支持方、企业评审硬项）。明显偏向 LangChain4j（需要完全离线闭环）。
文档与生态：明显偏向 Spring AI（需要成体系的文档与官方支持）。明显偏向 LangChain4j（需要某个小众集成的现成实现）。
用这张表的方法是“数偏向”，而不是“逐格打分”。因为只要有一格落在“硬约束”里，它就直接决定答案，其他格子都不必看。
本系列的选择与下一步
说清我自己的选择，避免这篇文章显得“什么都对”：本系列后续文章继续走 Spring AI。三个理由，按权重排序：一是本系列的读者画像就是 Java/Spring 后端，Spring AI 的 Advisor 语义、@Tool、自动配置这些内容对 Spring 工程师迁移成本最低；二是本系列从第 2 篇起就建立了“Spring AI 2.0.1 + Boot 4.1.x + JDK 21 + OpenAI 兼容端点”这条版本线，中途换框架会让前五篇的代码全部失效；三是 Spring AI 的官方属性，在企业落地与合规评审里更好交代。
但这个选择是有前提的——如果你的项目在 Boot 3.5 且半年内不动平台、或者不是 Spring 栈，请按 5.1 节的决策树选 LangChain4j，前面五篇里除代码外的所有内容依然全部适用。这也是 5.2 节那个结论的实际用法：可迁移的资产比框架本身值钱。
下一篇回到具体落地：用 Spring AI 做文本分类/摘要：落地到后台工作流。那一篇会做一件前六篇都没做的事——把 AI 从“对话式交互”挪到“无人值守的批处理”。场景变了，工程重点也完全变了：没有会话、没有流式、没有实时用户等结果，取而代之的是吞吐量、失败重试、幂等、以及“如何把不确定的输出接进一个要求确定的业务流程”。