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 调用更清楚。二是对模型行为要求极苛刻、要把每一层都捏在自己手里的,框架的默认行为会变成束缚,不如自己搭薄封装。框架解决的是「重复造轮子」,不是「替你思考」。