Java AI 框架选型：先分清基础设施层与 Agent 调度层

选型吵起来，多半是没分清层。

三个人争论 Spring AI、LangChain4j、AgentScope 谁更好，其实各自在回答不同的问题。基础设施层关心怎么连上模型、怎么管 Embedding、怎么接向量库；Agent 调度层关心多个智能体怎么协同、链路怎么可控可解释。把两层的框架放进同一张对比表，参数比得再细也是白比。

Rod Johnson 在发布 Embabel 时给过一个类比：底层基础设施相当于 Servlet API，高级应用框架相当于 Spring MVC。这个类比值得记住，它把 Java AI 生态一刀切成了两半。

第一层：基础设施，解决“接得上”

这一层的任务很具体：把 Transformer 推理、向量数据库、Embedding、工具调用这些能力，用 Java 的方式接进现有工程。

Spring AI 2.0：边界终于划清了

Spring AI 2.0.0 GA 在 2026 年 6 月 12 日发布，构建在 Spring Boot 4.1 和 Spring Framework 7.0 之上。

1.x 时代最常见的一种写法是直接 @Autowired ChatModel，然后往里塞工具调用、重试、内存管理。2.0 把这条线划开了：ChatClient 是面向业务的高层 API，自带 Advisor 链，日常开发用它；ChatModel 是底层模型抽象，直接对接厂商 SDK，只有框架开发者才需要碰。

工具调用的重构是另一个关键点。1.x 里每个 ChatModel 实现都内嵌了私有的工具执行循环——OpenAI 一套、Ollama 一套、Anthropic 一套，代码重复，行为还不一致。2.0 把这些循环统一提升到 Advisor 链里处理。

// Spring AI 2.0 的工具调用写法
String response = ChatClient.create(chatModel)
    .prompt("明天是星期几？")
    .tools(new DateTimeTools())
    .call()
    .content();

这个设计最舒服的地方是循环可组合。Advisor 链支持循环重入，工具调用 Advisor 能重新进入下游链。同一套机制还能拿来做结构化输出的重试循环、评估循环。

适用场景很明确：工程是 Spring Boot 4.x，团队熟悉 Spring 生态，想把 AI 能力快速接进现有系统。自动配置、依赖注入、可观测性全是 Spring 那一套。代价是 Java 版本要跟上，2.0 需要 21+。

LangChain4j：模型和向量库覆盖最广

LangChain4j 从 2023 年初起步，是当前 Java 生态里模型支持和向量存储支持最丰富的框架。截至 2026 年 9 月，最新版本是 1.19.0。

它和 Spring AI 的差异可以概括成一句话：Spring AI 追求整合效率，LangChain4j 追求场景能力。

Spring AI 胜在 Spring 体系原生整合，声明式 @AiService、自动配置、Spring Boot Starter 一应俱全。LangChain4j 胜在功能丰富度和灵活度，30+ 模型开箱即用，向量库覆盖最广，Agent 机制更成熟，处理多步逻辑更稳。

// LangChain4j 的声明式 AI 支持
interface Assistant {
    @SystemMessage("你是一个Java技术顾问，请用中文回答")
    String chat(@UserMessage String question);
}

Assistant assistant = AiServices.create(Assistant.class, model);
String answer = assistant.chat("什么是虚拟线程？");

需要最丰富的模型和向量库支持，或者工程不是纯 Spring（比如 Quarkus、Micronaut 或纯 Java），LangChain4j 是最灵活的选择。代价是写法不够简洁，学习和使用成本相对高一些。

1.19 有一个值得注意的变化：MCP 协议进入稳定期。Streamable HTTP 变成无状态的，协议级 session 被删除，2026 年 7 月 28 日 MCP 发布了新标准。这意味着 MCP 的集成方式会更标准化。

Solon AI：全场景、全版本兼容

Solon AI 是 Solon 项目的核心子项目，定位是全场景 Java AI 开发框架。它有两个鲜明特征。

一是兼容 Java 8 到 Java 26。这在 Java AI 框架里很少见——Spring AI 2.0 需要 Java 21+，LangChain4j 需要 Java 17+。

二是能嵌入任意框架。它不绑定 Solon，可以无缝嵌入 Spring Boot、Vert.x、Quarkus、JFinal。

// Solon AI 的构建式 API
ChatModel chatModel = ChatModel.of("")
    .provider("ollama")
    .model("qwen2.5:1.5b")
    .build();

AssistantMessage result = chatModel.prompt("杭州今天天气怎么样？")
    .options(op -> op.toolAdd(new WeatherTools()))
    .call()
    .getMessage();

工程还停在 Java 8，或者需要一个与框架无关的 AI 能力层，Solon AI 是目前唯一的选择。在 Agent 体系上它提供了三级递进式架构：SimpleAgent、ReActAgent、TeamAgent。

第二层：Agent 调度，解决“组织得起来”

这一层要回答的是：AI 需要多步推理、工具调用、多 Agent 协同时，链路怎么保持可控、可解释、可恢复。

Spring AI Alibaba：企业级多智能体与工作流

Spring AI Alibaba 由 Spring 开源社区和 Alibaba 开源社区共同维护，2024 年 9 月开源，目前 GitHub Star 数已超过 10,000。项目构建在 Spring AI 之上，是阿里云通义系列模型及服务在 Java AI 应用开发领域的最佳实践。

它在 Spring AI 基础上做了向上抽象和功能增强。Spring AI 提供 AI 应用的基础抽象——模型接入、函数调用、MCP、对话记忆、RAG、可观测。Spring AI Alibaba 在此基础上补充了 Agent 调度、Graph 工作流引擎、MCP 双端支持和公司级管控。

用一句话区分：Spring AI 解决怎么调用模型，Spring AI Alibaba 解决怎么让多个 Agent 协作完成复杂链路。

架构分三层：Agent Framework 以 ReactAgent 为核心；Graph 是底层工作流和多代理协调引擎，也是 Agent Framework 的运行时基座；Augmented LLM 基于 Spring AI 的原子抽象，提供模型、工具、MCP、向量存储等基础能力。

// Spring AI Alibaba 创建 Agent
DashScopeApi dashScopeApi = DashScopeApi.builder()
    .apiKey(System.getenv("AI_DASHSCOPE_API_KEY"))
    .build();
ChatModel chatModel = DashScopeChatModel.builder()
    .dashScopeApi(dashScopeApi)
    .build();

ReactAgent agent = ReactAgent.builder()
    .name("weather_agent")
    .model(chatModel)
    .instruction("You are a helpful weather forecast assistant.")
    .build();

agent.call("what is the weather in Hangzhou?");

1.1.2.0 版本带来两个关键升级。Agent Skills 让 ReactAgent 支持以“技能”为单位做可复用指令与上下文的渐进式披露，系统提示里先只注入技能列表，模型需要某技能时才加载完整内容，从而降低 Token 消耗、扩展能力体量。多智能体并行执行支持 LlmRouting、Supervisor 等方式，既可路由到单一子智能体，也可一次选择多个子智能体并行执行，适合多领域并行查询与结果汇总。

工程是 Spring Boot，需要搭建企业级多智能体系统或工作流编排——比如智能客服、审批流、数据管道——Spring AI Alibaba 是当前最完整的选择。它同时具备 Spring 体系的集成优势和阿里云基础设施的深度适配。

AgentScope Java 2.0：分布式 Agent 的工程化

AgentScope Java 2.0 在 2026 年 6 月正式发布，是阿里巴巴集团内部采用最广泛的智能体框架（Java & Python），在十余条核心业务线生产环境深度使用。

核心思路是在 ReAct Agent 推理内核之上加一个 Harness 工程化层。工程师既可以继续用轻量的 ReAct 循环，也可以按需启用 Workspace、持久记忆、Session、Sandbox、Skill 和 Subagent 等能力，把同一套 Agent 逻辑部署上线到公司级分布式服务。

// AgentScope Harness Agent
var agent = HarnessAgent.builder()
    .name("coder")
    .model("dashscope:qwen-max")
    .workspace(Paths.get(".agentscope/workspace"))
    .filesystem(new DockerFilesystemSpec())
    .isolationScope(IsolationScope.USER)
    .build();

agent.call(msg, RuntimeContext.builder()
    .sessionId("demo")
    .userId("alice")
    .build()).block();

它最核心的差异化能力是三个词：身份延续、上下文可控、状态可恢复。工作区即 Agent 的人格和长期记忆，每轮自动注入；上下文自动压缩，大工具结果自动落盘，Context Overflow 兜底重试；同 sessionId 可跨进程恢复完整对话，沙箱状态可快照。

要搭建公司级多 Agent 系统，需要长期稳定运行、多租户隔离、工具调用权限管控，AgentScope 是当前 Java 体系里最完整的选择。

Embabel：把规划从 LLM 手里拿回来

Embabel 是 Spring 之父 Rod Johnson 打造的 JVM 原生智能体框架，2026 年 8 月发布 1.0.0 GA。

它引入 GOAP（Goal-Oriented Action Planning）目标导向规划算法——一种老牌的游戏 AI 规划算法。不靠脚本或预先连线的图，而是给智能体一组可用的 Action，每个 Action 带前置条件和效果，规划器搜索满足目标的动作序列。

和别的框架最大的差异在这里：规划不依赖 LLM。大多数 AI Agent 框架让 LLM 决定下一步做什么，但 LLM 有幻觉、不确定。Embabel 把规划交给确定性的 GOAP 算法，它根据 Action 的前置条件和效果计算最优路径，并能解释为什么选这条路径。

Embabel 构建在 Spring AI 之上，直接复用 Spring AI 的模型连接能力，@Tool、ChatClient 那套都能继续用。

场景需要可解释、可审计、确定性的多步流程编排——比如金融合规、医疗决策、供应链编排——Embabel 的 GOAP 规划比 LLM 驱动的规划更可靠。

各框架定位速查

选型决策路径

没有最好的框架，只有最匹配你场景的框架。按下面几条线走一遍，答案基本就出来了。

第一个问题：你的工程是什么技术栈？纯 Spring Boot 走 Spring AI 或 Spring AI Alibaba；非 Spring 栈优先考虑 LangChain4j；还在 Java 8 或 11 上，Solon AI 几乎是唯一解。

第二个问题：你的场景需要什么？只需要接入模型能力，基础设施层就够；需要多 Agent 协同、工作流调度、生产级运行，就得往 Agent 编排层看。

三个关键判断：

Java 版本。还在 Java 8 或 11，Spring AI 2.0 和 LangChain4j 都用不了，Solon AI 是唯一选择。

单体还是分布式。单体应用或简单微服务，Spring AI 或 LangChain4j 足够。要做公司级多 Agent 分布式系统，Spring AI Alibaba 或 AgentScope 的工程化层是刚需。

场景是否需要确定性。金融、医疗、合规这类场景，链路的可解释性和可审计性是硬要求，Embabel 的 GOAP 规划比 LLM 驱动更靠得住。

这里有个容易踩的坑：很多人按 GitHub Star 数或功能列表长度选框架，选完才发现版本对不上、依赖冲突。先把 Java 版本和现有技术栈这两条硬约束卡死，剩下的空间其实不大。

两个容易忽略的工程细节

依赖冲突是 Java AI 项目里最常见的报错来源。Spring AI 2.0 基于 Spring Boot 4.1，如果你的项目还锁在 Spring Boot 3.x，直接引入 starter 会在启动时抛 NoSuchMethodError 或 ClassNotFoundException，根因是 Spring Framework 7.0 的 API 签名变了。解决方式要么整体升到 Boot 4.1，要么留在 Spring AI 1.x 分支。不要试图只升 AI 依赖不升 Boot，实测走不通。

版本矩阵要对齐。LangChain4j 1.19 要求 Java 17+，如果团队还在用 Java 11 编译，Maven 会在编译期就报 release version 不支持，而不是运行期才暴露。选型评审阶段就该把 JDK 版本写进决策记录，别等到集成阶段才发现。

验证框架是否真正接通的判定标准很简单：跑一个最小对话用例，确认模型返回内容非空、日志里能看到请求耗时和 Token 计数。如果日志里只有请求没有响应，多半是网络出口或 API Key 配置问题，不是框架本身的问题。

到这里，选型的逻辑应该清楚了：先定层，再定框架，硬约束优先于功能对比。