Spring AI 还是 LangChain4j:Java 写 Agent 的分水岭不在功能列表里 | 框架选型

10 月 28 日晚上，LangChain4j 刚发了 1.23.0；隔两天，10 月 30 日的 GitHub tags 里又冒出 1.19.4 和 1.11.12 两个维护版。同一时间，技术群里有人问：新起一个 Java Agent 项目，Spring AI 还是 LangChain4j？底下很快有人回：Spring 项目就用 Spring AI，这还用问。

这话只对了一半。另一半里的坑，我两个框架都在项目里踩过——Spring AI 从 1.0 用到现在，LangChain4j 从 1.7 开始跟。这篇不堆功能列表，只讲四个真正影响决策的维度，看完你大概率不用再翻第二篇选型文章。

先说结论：这不是好坏之争，是两种工程哲学

一个求稳，一个求快。说白了，Spring AI 像精装房，LangChain4j 像宜家。

精装房的水电、软装、收纳都给你配好了，拎包入住，代价是你得接受它的户型。Spring AI 就是这个思路：starter 自动装配、Advisors（可以理解成 Spring MVC 拦截器的 AI 版，请求前后都能插逻辑）责任链、观测埋点，全按 Spring 的路数铺好。条件也写在售楼处门口：Java 21 起步，深度绑定 Spring Boot 的生命周期。

宜家给的是零件和说明书，拼在哪、怎么拼自己定，代价是说明书翻新快，螺丝得自己拧。LangChain4j 纯 Java 就能跑，Spring、Quarkus 各有官方 starter，想塞进什么工程随你——但它的抽象层翻新也快，你需要自己盯。

维度一：同一个需求，两套写法

空谈哲学没意思。拿一个最小需求做对比：给 Agent 一个查订单状态的工具，问一句「订单 A1001 到哪了」，它自己决定调不调工具。

Spring AI 1.1.x：装配感

<!-- 版本由 spring-ai-bom 统一管理（1.1.x），需 Spring Boot 3.4+、Java 21 --> <dependency>     <groupId>org.springframework.ai</groupId>     <artifactId>spring-ai-starter-model-openai</artifactId> </dependency>

@Component public class OrderTools {      // @Tool：Spring AI 的工具注解，description 是给模型看的说明书     @Tool(description = "按订单号查询订单当前状态")     public String getOrderStatus(String orderId) {         return "订单 " + orderId + " 已发货，预计明天送达";     } }  @RestController public class OrderAgentController {      private final ChatClient chatClient;      public OrderAgentController(ChatClient.Builder builder, OrderTools orderTools) {         // ChatClient 由 starter 自动装配进来，工具在这里挂载         this.chatClient = builder                 .defaultTools(orderTools)                 .build();     }      @GetMapping("/ask")     public String ask(@RequestParam String q) {         return chatClient.prompt().user(q).call().content();     } }

你在写 Spring。工具是 Bean，装配走构造器，配置进 application.yml，出了问题查日志、接 Micrometer，全是熟悉的动线。

LangChain4j 1.23.0：接口即服务

<dependency>     <groupId>dev.langchain4j</groupId>     <artifactId>langchain4j</artifactId>     <version>1.23.0</version> </dependency> <dependency>     <groupId>dev.langchain4j</groupId>     <artifactId>langchain4j-open-ai</artifactId>     <version>1.23.0</version> </dependency>

public class Demo {      // 声明一个接口就行，框架用动态代理帮你实现     interface OrderAssistant {         String chat(String userMessage);     }      static class OrderTools {         @Tool("按订单号查询订单当前状态")  // LangChain4j 的 @Tool 直接收描述         public String getOrderStatus(String orderId) {             return "订单 " + orderId + " 已发货，预计明天送达";         }     }      public static void main(String[] args) {         OrderAssistant assistant = AiServices.builder(OrderAssistant.class)                 .chatModel(OpenAiChatModel.builder()                         .apiKey(System.getenv("OPENAI_API_KEY"))                         .modelName("gpt-4o-mini")                         .build())                 .tools(new OrderTools())   // 工具交给框架反射发现                 .build();          String answer = assistant.chat("帮我查一下订单 A1001 到哪了");         System.out.println(answer);     } }

这就是 AiServices（声明式接口代理：方法进、回答出）的路子。没有 Controller，没有上下文，一个 main 方法跑通。适合验证期、脚本化、嵌进非 Spring 工程。

维度二：发版节奏，藏在暗处的隐形变量

这一条很少被写进对比文，但真实影响维护成本。

看两组公开数据：LangChain4j 从 8 月 15 日的 1.19.0 到 10 月 28 日的 1.23.0，两个半月发了五个 minor 版本，差不多十天一个（来源：GitHub tags 页与 Maven Central）。Spring AI 这边，5 月 8 日一口气发布了三条线——1.0.7（LTS 维护）、1.1.6（功能版）、2.0.0-M6（里程碑），并修复了 CVE-2026-40966 至 40980 一批安全漏洞（来源：官方发布记录），之后功能线明显进入收敛期。

迭代快意味着什么？新模型特性跟得紧，1.20 之后非阻塞返回类型、并发工具调用这些能力很快就位。但快也有代价：细节藏雷的概率高——我上个月写过 LangChain4j 1.20 非阻塞模式下工具异常语义反转的事，同步和异步的行为正好相反，改一行返回类型就触发，编译器不吭声。这类坑，在发版慢的框架里出现概率小一些，因为每次变更都会被更多生产项目先替你踩过。

你想想你们团队的情况：有人专门盯 release notes 吗？没有的话，收敛型的节奏其实更省心。

维度三：Agent 能力走到了哪一步

Spring AI 1.1 GA 带来了两样值得单独看的东西：Agents 框架（官方封装了几种 Agent 编排模式，不用自己从 ChatClient 手搓循环）和 Spring AI Bench 评估套件（测 Agent 完成任务的成色，不止测聊天）。MCP（Model Context Protocol，模型连工具的开放协议）在 1.1 里做成了注解化集成，接 MCP Server 的胶水代码少了很多。

LangChain4j 的 Agent 能力长在 AiServices 和工具调用循环上，胜在灵活和快。1.20 起同步、异步、流式返回类型都齐了，配合 toolExecutionErrorHandler 这类显式配置，能做出相当精细的容错。它没有官方评估套件，这在做严肃 Agent 项目时是个空位，通常得自己接。

选型建议：三条决策规则

• 项目已在 Spring Boot 上、团队五人以上、要维护两年以上
  ——选 Spring AI。治理、观测、升级节奏、CVE 响应都在 Spring 的成熟管线里，接手的人也好招。
• 非 Spring 工程，或者验证期项目要快速试模型新特性
  ——选 LangChain4j。一个 main 方法跑通的能力，在原型期价值巨大。
• Spring 项目但需要 LangChain4j 的某个特有能力
  ——它有官方 spring boot starter，可以只把它当一个库引入，别把整套架构都搬过去。混用不丢人，重复造轮子才丢人。

边界：别把选型当终身契约

两个框架都还在 1.x，抽象层都还会动。今天的功能差异，半年后大概率被互相借鉴抹平——两边都在快速吸收对方验证过的设计。所以比功能列表意义不大，真正该比的是工程节奏和你团队的匹配度。

我的做法是在业务代码和框架之间留一层薄接口：工具定义、会话编排走自己的抽象，框架沉在最底下。这样哪天要换方向，改的是适配层，不是全项目的业务代码。这层接口大概多花你两三天，能省下未来不可知的一段时间。

说了这么多，轮到你了：你现在手上在写的 Agent 项目，押的是 Spring AI 还是 LangChain4j？评论区报个栈，我看看两边的比例悬不悬。