Spring AI 2.0 vs LangChain4j 1.19：MCP 新规范竞速，Spring AI 慢在哪

Lambert2812026-08-28 15:13

本文事实核查自 LangChain4j 1.19.0 Release Notes、LangChain4j MCP 官方文档、langchain4j-mcp 模块源码（POM 依赖）、Spring AI 2.0.1 发布公告、MCP Java SDK Releases 与 java-sdk issue #1089，核查时间 2026-08-28。上一篇：Agent 的 App Store 来了：写一个 SKILL.md，Java Agent 立刻多一项新技能。该领域迭代极快，请以官方文档为准。

开篇：一场结果反直觉的竞速

2026 年 7 月 28 日，MCP 发布了史上最大规模的协议升级：握手移除、会话消失、协议全面无状态化（规范细节我在上一篇拆过，此处不重复）。规范一发布，Java 生态两家头部框架的竞速就开始了。

结果是：LangChain4j 1.19.0（8 月 14 日）成为第一个支持 2026-07-28 规范的 Java 框架------虽然只是客户端；而 Spring AI 2.0.x 至今停在 2025-11-25 规范，官方口径的跟进时间表还不存在。

单看这个结果，你可能会得出"Spring 团队效率不行"的结论。但这场比赛有一个反直觉的细节：MCP Java SDK------就是那个还没跟上新规范的 SDK------恰恰是 Spring 团队在维护的。也就是说，维护着官方 SDK 的一方，反而输掉了框架层面的竞速。

所以"慢在哪"就不是个效率问题，而是个结构问题。这篇文章把这场竞速复盘清楚：先看两家的哲学底色和 API 风格（这是快慢的体质），再拆 Spring AI 慢下来的三层结构性原因，最后给出我的选型判断。 Agent 框架层（SAA / AgentScope / ADK）不在本文射程内，五框架全景与分层地图见这篇。

一、版本基准与对比维度

Spring AI LangChain4j
当前版本 2.0.1（2026-08-21，修 7 个 CVE + 新增工具调用上限） 1.19.0（2026-08-14，另有 1.11.x / 1.5.x 两条补丁线）
基线要求 Java 17 + Spring Boot 4.0/4.1 + Framework 7 + Jackson 3 Java 17，框架无关（Spring Boot / Quarkus / Helidon / Micronaut 均可）
MCP 实现 基于 MCP Java SDK 2.0.x（2025-11-25 规范） langchain4j-mcp 模块自研 （2026-07-28 规范，客户端）
一句话定位 Spring 生态的 AI 原生运行时（"JDBC for AI"） 框架无关的全功能 LLM 应用工具箱

对比维度声明：本文聚焦两家的哲学、API 风格、MCP 竞速、Agent 能力、版本节奏五个维度。评测跑分、模型集成数量这类"功能清单对比"网上已经很多，不赘述。

二、哲学差异：一个想当地基，一个想当工具箱

理解快慢，得先理解两家的自我定位------生态位决定了策略，策略决定了速度。

**Spring AI 想做 AI 世界的基础设施。**官方给它的类比是"JDBC for AI"：统一抽象、可组合、与 Spring Security / Micrometer / Observation 天然打通。2.0 的三个动作都是这个思路的延续：ChatClient 成为唯一推荐入口（收敛 API 面）、工具调用循环 Advisor 化（横切能力组件化）、MCP 收编进官方体系（@McpTool 一个注解暴露 Spring 服务）。做基础设施的人有一个职业本能：接口要稳，变更要慎------没人能接受 JDBC 每三个月换一次用法。

LangChain4j 想做顺手的全功能工具箱。从低级原语（ChatModel、EmbeddingStore）到高级声明式 API（AiServices）再到 Agentic 原语，聊天、RAG、Agent 全覆盖，20+ 模型提供商、30+ 向量存储，集成面是全 Java 生态最广的。工具箱的生存法则是快：新协议、新模型、新范式，谁先支持谁就被写进下一个 demo。它甚至不是 Python LangChain 的 Java 移植------是从零写的 Java 库，没有历史包袱，也没有"必须服务好企业存量"的包袱。

一个是航空公司换机型的节奏，一个是消费级 App 更新的节奏。同一场竞速，两家选手根本不在同一个赛制里。

三、API 风格：同一需求的两种写法

空谈哲学无益，看代码。同一个需求------带记忆、带工具的对话助手------两家的写法：

Spring AI 2.0：ChatClient + Advisor 链（编程式，一切显式）

java 复制代码 
ChatClient chatClient = ChatClient.builder(chatModel)
    .defaultSystem("你是天气助手")
    .defaultTools(new WeatherTools())
    .defaultAdvisors(
        MessageChatMemoryAdvisor.builder(chatMemory).build(),  // 记忆：一个 Advisor
        new SimpleLoggerAdvisor())                              // 日志：也是一个 Advisor
    .build();

String answer = chatClient.prompt()
    .user("北京今天适合穿什么？")
    .call()
    .content();

LangChain4j：AiServices（声明式，接口即应用）

java 复制代码 
interface Assistant {
    @SystemMessage("你是天气助手")
    String chat(@MemoryId String userId, @UserMessage String question);
}

Assistant assistant = AiServices.builder(Assistant.class)
    .chatModel(chatModel)
    .chatMemoryProvider(userId -> MessageWindowChatMemory.withMaxMessages(20))
    .tools(new WeatherTools())
    .build();

String answer = assistant.chat("user-42", "北京今天适合穿什么？");

两段代码背后是两种世界观：

Spring AI LangChain4j
心智模型 "组装一条处理链"------像配 Filter 链 "描述一个服务"------像写 MyBatis Mapper
记忆 Advisor（可插拔、可排序、可自定义） 注解 + MemoryProvider
工具循环 2.0 起从 ChatModel 抽出，统一由 ToolCallingAdvisor 承载 AiServices 内置执行循环，上手零配置
深度定制 天然顺手：Advisor 就是拦截器，Java 后端最熟的东西 要下探到低级 API（ChatModel + 手动转发 ToolExecutionRequest）
适合谁 习惯 Spring 编程模型的团队 想用最少代码跑通、或非 Spring 技术栈的团队

值得说一句公道话：两家的 API 都很好，难分高下，差异只在审美取向。Spring AI 的 Advisor 链在需要深度定制时（审计、重试、工具循环接管）优势明显；LangChain4j 的声明式接口在"快速搭一个带记忆带工具的助手"场景里代码量减半。真正的分水岭在下一节。

四、MCP 竞速复盘：Spring AI 慢在哪

回到这场比赛。先把时间线摆全（全部核对自 GitHub Releases 与官方公告）：

时间 事件
2026-05-21 2026-07-28 规范 RC 锁定，进入十周验证窗口
2026-06-11 MCP Java SDK 2.0.0 GA（对应 2025-11-25 规范）
2026-06-12 Spring AI 2.0.0 GA（MCP 基于上述 SDK）
2026-07-28 新规范正式发布
2026-08-13 java-sdk 设计 issue #1089 开启，无时间表
2026-08-14 LangChain4j 1.19.0 发布，客户端支持新规范（#5881）
2026-08-19 MCP Java SDK 2.0.1 发布------11 项变更全是修复，无新规范支持
2026-08-21 Spring AI 2.0.1 发布------7 个 CVE 修复 + 工具调用上限，MCP 无变化

规范发布后 17 天，LangChain4j 冲线；Spring AI 这边，连它脚下的 SDK 都还没起跑。慢在哪？我拆出三层原因，一层比一层深。

第一层：供应链传导链------一步到位 vs 等两跳

这是最直接的技术原因，也是最值得画出来的一张图：

打开 langchain4j-mcp 模块的 POM 会看到一个关键事实：它不依赖 MCP Java SDK 。编译依赖只有 jackson-databind 和 LangChain4j 自家的 http-client 抽象------协议的 JSON-RPC 编解码、传输（STDIO / Streamable HTTP / WebSocket / Docker）、版本探测，全部自研。所以新规范发布后，LangChain4j 团队直接在自己的代码库里实现即可：规范 → 框架，一步到位。

Spring AI 走的是另一条路：它的 MCP 客户端与服务端构建在 MCP Java SDK 之上。新规范要落地，得先等 SDK 实现，再等 Spring AI 跟随 SDK 升级：规范 → SDK → 框架，两跳传导。每一跳都有排期、有协调成本、有自己的发布节奏------传导链上任何一环慢，整条链都慢。

第二层：治理结构------SDK 的包袱，Spring 团队的两头跑

更微妙的问题在于：SDK 这一跳为什么慢？

**MCP Java SDK 服务的不只是 Spring AI。**它是 modelcontextprotocol 组织的官方 Java 实现，要对整个 Java 生态的兼容性负责：Quarkus、Helidon、云厂商、无数自研接入......对官方 SDK 来说，"快"反而是危险的------一个没吃透规范细节就发布的实现，会把兼容性债务扩散给所有下游。所以它的节奏审慎：issue #1089（2026-08-13 开启）在设计阶段，没有承诺时间表。这不是懈怠，是官方 SDK 的职业操守。

**Spring 团队在两头跑。**MCP Java SDK 由 Spring 团队（与社区）维护，Spring AI 本体也是 Spring 团队在做------同一批人，一边要给 SDK 设计新规范支持（从零实现无状态传输、server/discover、subscriptions/listen），一边要赶 Spring AI 2.0.1 的 CVE 修复（8 月 21 日那 7 个 CVE 不等人）。人力资源就那么多，竞速优先级必然让位于安全修复。

而 LangChain4j 自研客户端只需对自己负责：不用等任何人，不用照顾全生态，规范看懂了就写，写完就发 1.19.0。自研的敏捷，本质上是"没有下游"的敏捷。

第三层：生态位的自觉------基础设施不追热点

最深的一层：Spring AI 可能就没打算赢这场竞速。

回看 Spring AI 2.0 的版本叙事，它的重心从来不在"追协议"，而在"收内核"：ChatClient 收敛入口、Advisor 承载工具循环、模型提供商精简 （OpenAI/Anthropic 只留官方 SDK 变体、Google 砍掉 Vertex）------注意这个方向：它连功能都在做减法。一个把自己定位成"JDBC for AI"的项目，在协议规范发布三周后就跟进，反而是不称职的------基础设施的纪律是等尘埃落定再上实现，因为它的每个决定都会被下游锁死好几年。

MCP 新规范自己也留了余地：官方建立了功能生命周期与弃用政策（最少 12 个月弃用窗口），旧协议的存量服务器在未来相当长时间内仍是合法公民。今天用 2025-11-25 规范部署的 Spring AI MCP Server，不是"错误答案"，只是"上一代答案"。

反转视角：慢的红利

但如果把"慢"一律当贬义词，这篇文章就白写了。Spring AI 走官方 SDK 路线，换来的是：

  1. 官方背书的互操作性 ------MCP Java SDK 与规范同源（modelcontextprotocol 组织），协议语义的裁判权和实现权在一处，出问题有官方 issue 追踪（比如 java-sdk #1072 的 server/discover 500 错误，P1 修复）；
  2. 一处升级、全家受益------SDK 升级后，Spring AI、以及所有直接用 SDK 的项目同步获得新规范支持，避免生态碎片化；
  3. 服务端能力的完整度 ------Spring AI 的 MCP 服务端（@McpTool + Streamable HTTP + STATELESS 部署模式）是 Java 生态目前最完整的官方路线实现，LangChain4j 的 MCP 重心在客户端，服务端尚在 community 模块。

而 LangChain4j 自研的代价也得摊开说：从此规范追新全靠自己 。WebSocket 传输这种规范之外的扩展（为兼容 Quarkus MCP Server 而做）也得自己维护；每次规范变更都要重读 changelog 重排实现------1.19 的自动探测默认 30 秒超时就是自研协议栈要自己处理兼容性细节的例证（连接已知服务器记得显式设 protocolVersion，详见上一篇坑 3）。

对你的实际影响：一张矩阵

竞速的宏观叙事之外，落到你的项目里，现状其实是这样的：

你的场景 受竞速结果影响吗
用 Spring AI 暴露 MCP Server（@McpTool） 基本无感------新规范客户端对 legacy 服务器向后兼容，你的服务照常可被调用
用 Spring AI 做 MCP 客户端连新规范服务器 受影响------连不上 2026-07-28 形态的服务器，需等 SDK 升级
用 LangChain4j 1.19 连任意 MCP 服务器 无感，反而受益（自动探测两代协议）
关心多副本水平扩展 无感------Spring AI 的 STATELESS 模式（2025-11-25 变体）已够用，注意它≠新规范
依赖协议新特性（subscriptions/listen、x-mcp-header、MRTR） 只有 LangChain4j 客户端可用

五、Agent 能力：Advisor 体系 vs Agentic 原语

MCP 之外，两家的 Agent 能力是第二个分水岭，而且路线分歧比 MCP 更彻底。

**Spring AI 的路线：把 Agent 能力沉到基础设施层，一切皆 Advisor。**2.0 把工具循环从 ChatModel 抽出后，Agent 语义变成了 Advisor 链上的可组合组件：

  • ToolCallingAdvisor------工具调用循环本身（2.0.1 起支持 maxToolCalls 上限，防 Agent 无限循环）；
  • ToolSearchToolCallingAdvisor------渐进式工具披露：工具太多时按需检索而不是全量塞给模型；
  • StructuredOutputValidationAdvisor------结构化输出的校验与重试。

这套设计的潜台词是："Agent"不是一个功能，而是一组可自由组装的横切关注点。你想要什么行为，就往链上挂什么 Advisor------和 Spring 全家桶里其他所有东西的心智完全一致。

**LangChain4j 的路线：在框架层长出 Agent 语义原语。**1.19 的 Agentic 包提供了面向"多 Agent 协作"的一等公民抽象：

  • AgenticScope------智能体间共享状态的会话域，Agent 写入的中间结果对下游 Agent 可见；
  • parallel mapper------并行映射模式，一个 Agent 的输出扇出到多个 Agent 并行处理后聚合；
  • 工具补偿机制 （#5823）------多个工具连续调用中途失败时，自动执行补偿操作，本质是给 AI Agent 加上了 Saga 风格的事务语义（API 细节本系列后续单独拆解）。

两条路线的差异可以这么概括：Spring AI 给你乐高积木（自己拼），LangChain4j 给你预制家具（直接用）。前者上限高、一致性费心思；后者上手快、深定制要下探。判断你的团队适合哪条，先问一个问题：你们有没有能力（和意愿）维护一条自己的 Advisor 链？有，Spring AI 的自由度是真金白银；没有，LangChain4j 的原语开箱是真省心。

六、版本节奏：单一主线 vs 三条维护线

最后一维：版本节奏。这可能是最容易被忽视、但长期影响最大的维度。

**Spring AI：单一主线，企业节奏。**2.0.0 GA（6 月 12 日）之后只有一个 2.0.1（8 月 21 日），内容是 7 个 CVE 修复 + 一个保守的新特性（工具调用上限）。语义清晰：主线只有一条，升级路径唯一，但大版本之间的间隔以月计。配套约束是基线大跳版------Boot 4.0/4.1 + Framework 7 + Jackson 3，从 1.x 升上来要过 9 处破坏性变更（升级实录在这篇）。

**LangChain4j：三条并行维护线，社区节奏。**主线 1.19（8 月 14 日）之外，还并行维护 1.11.x（最新 1.11.11，8 月 11 日）和 1.5.x（最新 1.5.3，7 月 29 日）------锁旧版本的生产系统也能持续拿到修复。代价是心智负担：跟哪条线？另外大量集成模块以 beta 版本号迭代（如 1.19.0-beta29），升级时得留意 API 变化。再加上 JDK 17 基线无 Java 8 版本线的既定事实，存量系统的引入成本要提前算清。

Spring AI LangChain4j
维护线 单一主线 1.19 / 1.11.x / 1.5.x 三条并行
发布节奏 月级，稳 周级，快
升级路径 唯一但陡（Boot 4 基线） 平缓但多头（beta 双轨版本号）
协议跟进 等传导链，慢而稳 一步到位，快而勤

七、结论：竞速给选型的三点启示

复盘完这场竞速，我的结论浓缩成三点：

**第一，快慢是生态位差异，不是优劣。**LangChain4j 的快，来自自研协议栈的供应链短、无下游包袱、工具箱的生存法则；Spring AI 的慢，来自官方 SDK 的传导链、治理审慎与基础设施的自觉。拿"谁先支持新规范"给两家排优劣，就像拿百米成绩评价载重卡车。

**第二，选型跟着供应链走，不跟着功能表走。**功能表半年一翻篇，供应链结构几年不变。选 Spring AI，意味着你的 MCP 协议演进绑定 MCP Java SDK 的节奏（官方、稳、慢）；选 LangChain4j，意味着绑定它自研协议栈的节奏（社区、快、勤）------但注意它只有客户端先行，服务端新规范支持同样在路上。这个结构比任何 feature list 都更值得写进你的技术决策记录。

**第三，两种"等"都要会等。**等 Spring AI 跟进新规范时盯两个信号：MCP Java SDK 的版本号（支持 2026-07-28 的版本大概率是 2.1/3.0 级别）和 issue #1089 的进展；等 LangChain4j 的 Agent 原语成熟时，留意 beta 版本号转正的节奏。

落到具体的"什么团队选什么"：

你的情况 建议
Spring 技术栈，应用形态以对话 + 工具 + RAG 为主 Spring AI 2.0------摩擦最小，MCP 竞速的差距对你无感（见第四节矩阵）
非 Spring 技术栈（Quarkus/Micronaut/纯 Java） LangChain4j------唯一顺手的选项，协议跟进还快
重度依赖 MCP 新规范特性（subscriptions/listen、MRTR、x-mcp-header） LangChain4j 1.19 客户端------当前唯一可用路径
需要暴露企业级 MCP Server Spring AI------Java 生态最完整的官方路线服务端
多 Agent 协作是核心诉求 两家都别硬上------看 AgentScope Java 或等 SAA 跟进 2.0（五框架全景里有决策树）

半年后回看，这篇文章大概率会过时一半：MCP Java SDK 的新规范版本、LangChain4j 的服务端跟进、SAA 跟上 Boot 4------每个变量都在路上。但"看供应链结构选基座"这个方法论不会过时：框架的功能你三个月就能追平，框架的出身你要追三年。

参考资料

相关推荐
晚安code24 分钟前
LangChain4j AiService 实战：会话记忆与结构化输出
java·langchain
Sword9927 分钟前
近 90 天用了 14 亿 Token，我拿 AI 干了些什么
ai编程
晚安code30 分钟前
LangChain4j 实战：RAG、工具调用、护轨与 SSE 流式输出
java·langchain
、如果44 分钟前
推文评论数据怎么拿？X(Twitter)评论分析 Skill 的工程拆解与实测
爬虫·ai编程·twitter
郑州光合科技余经理1 小时前
本地生活平台搭建：统一订单表与多后台切换怎么拆
java·开发语言·前端·系统架构·uni-app·php·ai编程
让你三行代码QAQ1 小时前
SpringAI-Advisors
spring·ai编程
JavaDog程序狗2 小时前
【AI工具实测】豆包也干了！字节发布企业级 AI Agent「豆包工作」
ai编程·豆包marscode
JavaDog程序狗2 小时前
【AI工具】你敢看自己一个月烧了多少 Token 吗？Juejin Usage来了
ai编程·掘金社区
淼澄研学3 小时前
基于Llama3与LangChain构建长尾搜题系统实操指南
langchain
热门推荐
01国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）02GitHub 镜像站点032026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？04历年考研数学一、数学二、数学三真题试卷及答案PDF05微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新06AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路07Agnes AI 免费 API 接入指南：文本、生图、生视频，一套接口全免费08VSCode+CodeX扩展，无法启动09如何新建文件夹？ 电脑新建文件夹的4种方法10蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接