Java 后端接 AI Agent,绕不开的第一个问题是用哪个框架。市面上聊 AI Agent 的教程大多是 Python 的,Java 生态的选择少但清晰:主流就 Spring AI 和 LangChain4j 两家,周边工具(MCP、评测、可观测)再各自补。这篇把这几块的能力边界和选型依据摊开。
判断直接放开头:团队已经在 Spring 栈里,用 Spring AI;要更细的控制和更广的模型集成,用 LangChain4j。
Spring AI 与 LangChain4j
Spring AI 是 Spring 官方项目,好处是和你现有的 Spring Boot 融在一起,配置走 application.yml,工具调用用 @Tool 注解,MCP 有专门的 starter。代价是它绑定 Spring 生态,抽象层相对薄,不少能力还处在「能跑起来」的阶段。
LangChain4j 是社区主导,模型集成面比 Spring AI 宽,RAG、记忆、结构化输出这些组件更全,而且不依赖 Spring,纯 Java 也能用。代价是它自己的一套抽象要学,和 Spring 的整合不如 Spring AI 顺。
横向对比
| 维度 | Spring AI | LangChain4j |
|---|---|---|
| 维护方 | Spring 官方 | 社区主导 |
| Spring Boot 集成 | 原生,配置即用 | 有 starter,稍绕 |
| 模型接入面 | 主流几家 | 更广,含本地模型 |
| MCP 支持 | 官方 starter | 支持 |
| RAG / 记忆 | 基础可用 | 组件更全 |
| 上手成本 | 低(熟悉 Spring 的话) | 中 |
这张表能解释大部分选型分歧:不是谁更好,是你在哪个生态、要多少控制力。
周边工具
框架之外,三块周边要单独选。评测方面 RAGAS 是主流,但它是 Python 的,Java 侧要么自己复刻指标,要么走独立评测服务。可观测方面 Langfuse 支持 OTel 接入,Java 项目接起来成本低。MCP 方面,不管是 Spring AI 还是 LangChain4j,都把工具解耦成 MCP server,让工具独立进程发布、客户端动态发现,这一层两个框架殊途同归。
下面是一段 Spring AI 的最小配置加一个 @Tool,示意工具怎么挂进去:
// pom.xml 依赖
//
// org.springframework.ai
// spring-ai-starter-model-openai
//
@RestController
public class AgentController {
private final ChatClient chatClient;
public AgentController(ChatClient.Builder builder) {
this.chatClient = builder.build();
}
@Tool(description = "查订单状态,只读")
public String orderStatus(String orderId) {
return "订单 " + orderId + " 状态:已发货";
}
@GetMapping("/ask")
public String ask(@RequestParam String q) {
return chatClient.prompt().user(q).tools(this).call().content();
}
}
这段代码的骨架是 Spring AI 公开用法:ChatClient 发起对话,@Tool 标注的方法自动暴露给模型,tools(this) 把当前 bean 的工具注册进去。变量名和示例业务(查订单)是我自己定的。
护栏与可观测
框架帮你跑通调用,但「模型会胡说、会超时、会烧 token」这几件事,框架不替你兜,得自己上工程手段。护栏这一层,Java 后端的老手艺全都能复用:工具调用统一走一个网关,熔断、缓存、超时、结构化降级各司其职。下游工具挂了,返回结构化的「查不到」而不是抛异常,模型就不会拿空结果开始编。可观测这一层,把每次调用的 token 用量、工具轨迹、延迟打点接进 OTel 再到 Langfuse,出问题能回放轨迹,而不是对着一个黑盒猜。
这两块和选哪个框架基本无关,是横切的能力。别指望 Spring AI 或 LangChain4j 自带的默认行为能覆盖生产要求,它们给的是「能跑」,护栏和观测得自己补。
选型建议
一句话版本:Spring 栈里做内部工具,直接 Spring AI,省心;要跨框架、要深度定制 RAG 和记忆、或者团队里 Spring 和纯 Java 混着用,LangChain4j 更稳。评测和可观测别指望框架给你包全,RAGAS、Langfuse 这些该单独接就单独接。
不适合谁
两类团队别急着上框架。一是需求就一个「调 API + 写 prompt」的,加个框架徒增抽象层,直接 HTTP 调用更清楚。二是对模型行为要求极苛刻、要把每一层都捏在自己手里的,框架的默认行为会变成束缚,不如自己搭薄封装。框架解决的是「重复造轮子」,不是「替你思考」。