★ FEATURED ARTICLE 最近一个月我在技术交流群里被问得最多的问题就是Spring AI、LangChain4j、AgentScope、Embabel这四个AI框架到底选哪个尤其是手里捏着Spring Boot项目、想快速给系统接入AI能力的同学2025年这个时间节点想做技术选型一搜发现能打的框架实在不少光Java生态就有这么多个。我这段时间正好把四个框架都从零跑了一遍从PDF文档的RAG问答到多Agent协作从本地Ollama模型到云上大模型API做了完整的对比实验。这篇文章我把每个框架的真实定位、核心API、实际落地步骤和踩过的坑都摆出来给出一个可以直接抄作业的选型结论不整虚的。先说一句最重要的这四个框架根本不是“谁比谁强”的问题而是“它们压根不是一类东西、各自想解决不同问题”。Spring AI是Spring官方押注的AI全家桶入口LangChain4j是LangChain思路的Java移植版AgentScope是自带可视化运维的多Agent编排平台Embabel则是个相对小众、偏轻量化的实验性框架。你拿它们比性能、比上下文长度方向就错了。正确的姿势是先搞清楚自己的场景属于哪种再决定用哪个。下面我按真实调研和动手实验的顺序把四个框架挨个拆开说。1. 四个框架的真实定位先别纠结谁更强先搞清楚它们是谁1.1 Spring AISpring官方的“AI全家桶”入口Spring AI是Spring生态在AI领域的官方答案。它的核心野心不是重新做一个LangChain而是把大模型、向量数据库、RAG这些能力以Spring Boot的习惯封装进生态里。你用过spring-boot-starter-data-redis、spring-boot-starter-security之后再上手spring-ai-starter套路基本都是熟的依赖一个starter声明Bean然后用ApplicationContext自动装配拿到底层对象。我实测下来Spring AI 2.0这个版本变化非常大尤其是Maven坐标和Package名的重构让老教程基本都失效了。以前一些教程里用的org.springframework.experimental.ai包已经变成了org.springframework.ai类也从AiClient演进成了ChatClient。现在是直接用ChatClient.builder(chatModel).build()构建一个声明式的客户端然后像写SQL一样链式调用String answer chatClient.prompt() .user(用一句话解释什么是延迟绑定?) .call() .content();这种设计的好处是上手门槛确实低坏处也明显它把很多细节用“魔法”藏起来了。你想调温度、调top_p需要去翻ChatOptions的源码想自定义RAG的检索策略要理解QueryAugmenter和DocumentRetriever这套抽象。说白了Spring AI的价值是把90%的常用场景做成模板但如果你要做非标准的东西就得自己往框架的抽象层里钻。1.2 LangChain4jJava界的LangChain但比LangChain更克制LangChain4j这个名字一听就是对着LangChain做的。它诞生于LangChain最火的时候一群Java开发者觉得“这么好用的Agent思路怎么Java没有”于是有了这个项目。但LangChain4j没有跟着LangChain的步子乱跑它做了两个非常Java化的设计一个是把LLM调用变成Java接口方法一个是把Prompt模板和JSON解析放进编译器可验证的类型系统里。具体来说AiServices是它的核心你把一个Java接口丢进去框架自动生成实现interface Assistant { SystemMessage(你是一个乐于助人的助手回答尽量简洁。) UserMessage({{userMsg}}) String chat(V(userMsg) String userMsg); } Assistant assistant AiServices.builder(Assistant.class) .chatLanguageModel(ollamaChatModel) .build(); String response assistant.chat(你好帮我介绍一下你自己);这在Java里简直是降维打击IDE补全、编译期检查、单元测试都变得非常顺滑。如果你有Django和Python的经验对比一下LangChain原版那套冗长的RunnableSequence和回调地狱LangChain4j这个“把Prompts映射成接口”的思路清爽太多了。它是我个人认为这四个框架里唯一一个把“LLM编程”做得像“Java CRUD”的东西。1.3 AgentScope自带Web UI和全链路观测的多Agent平台AgentScope和前面两个完全不是一路。它最早是阿里巴巴的研发面向的是多Agent编排和分布式部署场景。不是“给某个方法加个AI能力”而是“让一堆角色化Agent跑工作流、互相协作、并统一做可视化监控”。AgentScope 2.0出来后Java版本也补上了定位是企业级实战尤其是“RAG as a Service”这个口号把检索增强做成独立服务供多个Agent或外部系统调用。我用AgentScope最直观的感受是它自带服务端控制台和运行时日志系统相当于把LangChain生态里需要一堆开源组件拼起来的观测能力开箱就能用了。你可以看到每个Agent的输入输出、调用了什么模型、执行了多久、在哪一步抛了异常。这种体验在Spring AI或LangChain4j里需要自己接Micrometer和OpenTelemetry才有AgentScope直接内置了。它的Java写法大概是这个风格AgentConfiguration? agentConfig AgentConfiguration.create( assistant, AssistantAgent.class );但说实话AgentScope的Java版本文档丰富度比Python版差一截中文资料的密度现在反而上来了很多社区文章都是“AgentScope Java 2.0企业级实战”这个路数。适合的团队是那种已经有运维体系、需要长时间运行多个Agent服务、对可观测性有硬指标的人。1.4 Embabel小众、轻量、实验性强谨慎使用Embabel这个名字在社区里搜到的教程确实少得可怜官网、GitHub、Gitee能挖到的信息分散给人一种“个人项目刚起步”的感觉。我把它试跑了一圈之后整体的判断是它更像一个实验性质的轻量级框架核心思想是把Agent拆成可插拔的JVM组件通过极简的配置做模型接入和对话流转。对想象力是好的但生产环境的坑实在太多。我不是说它代码烂而是说作为选型对象它的社区规模、文档完备度、Issue响应速度都与前面几个不在一个量级。如果你是因为好奇想做技术研究完全可以花一天时间玩一玩看它如何组织对话状态、如何封装模型调用如果是公司项目要上线我建议直接排除它。选型不是选最炫的是选“出了问题有人接盘”的。Embabel目前的“接盘侠”太少了。2. 核心能力横评用四个维度把框架打出原形2.1 模型接入能力谁接Ollama、通义、ChatGPT最方便模型接入是所有AI框架的第一个门槛。我以本地Ollama部署的Qwen2.5作为统一测试模型因为四个框架都能连Ollama方便直接对比。Spring AI在2.0里的模型接入抽象是ChatModel接口你只需要在application.yml里配置模型名称和地址ChatClient自动就能用。做过Spring Boot的同学对这个体验应该不陌生配置驱动、注解注入、约定优于配置非常“Spring”。它除了OpenAI、Anthropic、Ollama还支持国内很多模型比如Moonshot、DeepSeek这些通过通义千问的适配器也能接阿里系的模型所以中文场景下用Spring Alibaba那套spring-ai-alibaba分支也很顺。LangChain4j的模型接入同样很宽OpenAiChatModel、OllamaChatModel、QwenChatModel都有独立类每个类上的builder方法参数非常显式。比如说OllamaChatModel model OllamaChatModel.builder() .baseUrl(http://localhost:11434) .modelName(qwen2.5:7b) .temperature(0.3) .build();它没有隐藏配置所有参数都能在Java代码里看到对调试非常友好但你得自己管理配置对象的生命周期。如果你想做动态切换模型、灰度路由这种高级玩法LangChain4j的扩展点依然藏在SPI里得自己写。AgentScope的模型配置更多是围绕Runtime和Agent参数做的模型信息通常在Agent配置里声明支持多种模型服务。Java版因为起步晚示例大多围绕Ollama和DashScope阿里灵积展开。Embabel我试的时候发现模型接入是有的但协议适配层比较薄一些特殊参数传不进去需要改源码这也是我对它生产可用性存疑的原因之一。2.2 Agent编排单Agent回调和多Agent协作的差异如果你只是想“给用户一个问题让AI回答”Agent这个词纯属散步用什么都行。真正用到编排能力的是复杂任务先让一个Agent拆分问题再让另一个Agent做检索最后第三个Agent整理答案。Spring AI的Agent编排目前还是依赖Advisor链类似过滤器链你可以在调用前后插入各种逻辑。比如“先读历史、再检索、再调用模型”这种流程用ChatClient加ChatMemoryAdvisor加QuestionAnswerAdvisor可以组合出来。但它是围绕单个Chat会话做的偏“一条流水线”不是多角色协作的感觉。LangChain4j则保留了LangChain式的graph演进方向而且社区讨论度很高的LangGraph4j就是在这个生态里长出来的。如果你想做有状态、有分支、可回退的复杂流程LangChain4j加LangGraph4j的组合拳会更顺手。不过说句实话绝大多数业务场景根本用不到分支图一条简单的工具调用链就够了。AgentScope天生就是多Agent架构AgentGroup可以直接为一组Agent创建群聊式的协作会话任务轮流发言多Agent之间的消息路由是做在框架级别的。这一点在Java生态里确实独一份别人是在框架上搭积木它直接给了积木盒子。2.3 RAG落地从PDF到可问答知识库的完整链路RAG是现在企业接入AI最刚需的能力。四个框架我都跑了“上传一份PDF基于文档做问答”的完整链路差别主要在封装程度上。Spring AI 2.0的RAG走的是VectorStore、DocumentReader、QueryAugmenter这套标准抽象官方有非常清晰的文档。Pdf、Txt、Markdown的Reader都有现成实现向量库支持PGVector、Redis、Milvus、Chroma等。你拼起来大概是这样读文件→切块→向量化→存库→查询时召回→拼接上下文→给模型。Spring AI的问题在于版本更新太快有时候前天看的文档写法今天就不推荐了我中间升级小版本就踩过一次断档坑。LangChain4j的RAG组件非常细DocumentSplitters、EmbeddingStoreIngestor、ContentRetriever、RAG高级API都给你备好了。它的设计理念更贴近原始LangChain对检索链路的控制颗粒度更细。比如你可以自定义DocumentTransformer在入库前对文本做清洗、去重、打标签再决定怎么切分怎么存。对RAG有精细化调优需求的LangChain4j是我最推荐的一个。AgentScope 2.0主打“RAG as a Service”意思是把检索服务独立部署对外提供APIAgent只是消费方。这个模式在企业里很实用知识库可以单独维护、单独扩容、单独鉴权不用跟着Agent应用一起发版本。但对应的复杂度也高你需要单独部署和管理这个检索服务。Embabel的RAG能力非常初级官方示例里只有简单的向量Store演示离能用的知识库差得远这点也不用多讲。2.4 可观测性和工程化上生产之前必须看的一环写Demo的时候没人关心日志上生产之后没有日志你就抓瞎。Spring AI在可观测性上做了Observation支持接Micrometer之后可以把token消耗、响应耗时、调用次数都推到Prometheus里。但它只是提供指标Web UI是没有的你得自己接Grafana自己画Dashboard。LangChain4j也支持Micrometer和OpenTelemetry的SPI但默认情况下日志还是普通的slf4j想要完整的链路追踪得自己实现或者引入扩展模块。它的强项是测试因为接口方法是Java类型你可以Mock一个ChatLanguageModel用单元测试把整个Agent流程跑通这一点在工程化上非常加分。AgentScope在可观测性上是绝对的顶配自带的ServiceCenter可以查看所有Agent的会话记录、调用链、执行耗时、异常快照部署运维人员可以零成本上手不需要额外搭一套可观测体系。当然代价是AgentScope本身更像一个大平台学习和运维的成本都更高。Embabel嘛日志能打出来但没有链路ID没有追踪线上排查问题会很痛苦。3. 同一个需求用四个框架各写一遍以“文档问答Agent”为例3.1 需求描述与实验环境为了公平对比我设计了一个非常典型的场景给一个HR系统接“员工手册问答Agent”用户上传或者指定一份员工手册PDF系统读取内容用户可以用自然语言问“年假怎么算”“报销流程是什么”这类问题。要求是先本地跑通再考虑改云上模型。我的测试环境很简单一台装了Docker的机器用Docker起了Ollama和Qwen2.5:7b作为本地模型向量库统一用PGVector开发工具IntelliJ IDEAJava 17Spring Boot 3.3。四个框架各自建一个独立工程不共用一个数据库避免污染数据。这个场景足够典型它有文档加载、文档切分、向量化入库、检索召回、上下文拼接、对话输出六个环节每个框架的差别在这六个环节里都暴露得很清楚。我下面按实践顺序写方便想复现的朋友直接对照。3.2 Spring AI实现最快跑通但版本坑要小心Spring AI的代码量确实最少。Maven依赖加spring-ai-starter-ollama和spring-ai-starter-vector-store-pgvector。配置类示意图如下Configuration class RagConfig { Bean VectorStore vectorStore(EmbeddingModel embeddingModel) { return new PgVectorStore(embeddingModel, new PgVectorStoreConfig()); } }做RAG时核心代码大致是DocumentReader reader new PagePdfDocumentReader(classpath:handbook.pdf); ListDocument docs reader.get(); docs.forEach(d - vectorStore.add(new TextSegment(d.getContent()))); ChatClient chatClient ChatClient.builder(chatModel).build(); String answer chatClient.prompt() .advisors(QuestionAnswerAdvisor.builder(vectorStore).build()) .user(年假天数怎么算?) .call() .content();流程很短对吧这就是Spring AI的套路框架接住了大部分逻辑你只需要填空。而且QuestionAnswerAdvisor已经把“召回文档→拼接Prompt→调用模型→输出引用”这事封装完了极大降低了RAG的上手门槛。但是我在这套实现上卡了整整一个晚上。原因是我一开始用的Spring AI 1.0时代的老依赖然后升级到2.0时PgVectorStore和QuestionAnswerAdvisor的构造方式全变了旧配置直接编译不过。后来我按官方2.0的示例重建了一遍才通。如果你想用Spring AI一定先确认自己看的文档版本和你引入的依赖版本一致不要拿旧教程干新版本。3.3 LangChain4j实现接口化设计的优雅与调试的烦琐LangChain4j的工程结构更清晰。先建一个嵌入模型的EmbeddingModel再构造EmbeddingStore然后写一个Retriever。它的文档切分API是独立的你可以完全控制切块大小和重叠DocumentSplitter splitter DocumentSplitters.recursive(600, 100); ListTextSegment segments splitter.split(document); EmbeddingStoreIngestor ingestor EmbeddingStoreIngestor.builder() .embeddingModel(embeddingModel) .embeddingStore(embeddingStore) .build(); ingestor.ingest(document);检索和问答的模块我单独定义了一个接口interface RAGAssistant { UserMessage( 你是一个基于资料的助手。只根据以下资料回答问题 {{context}} 用户问题: {{userMsg}} ) String answer(V(context) String context, V(userMsg) String userMsg); }然后手动完成“召回”→组装参数→调用接口的步骤ListEmbeddingMatchTextSegment matches embeddingStore.findRelevant(query, 5); String context matches.stream().map(m - m.embedded().text()).collect(Collectors.joining(\n)); RAGAssistant assistant AiServices.builder(RAGAssistant.class) .chatLanguageModel(chatModel) .build(); String answer assistant.answer(context, query);这个东西的好处是每个环节都可测试。我可以单独测试切分粒度、单独测试召回质量、单独测试上下文拼接后的Prompt效果这在调优阶段太重要了。缺点是如果完全靠手动拼上下文你要对自己的Prompt工程能力有信心不像Spring AI那样有现成的Advisor兜底。我还踩过一个关于EmbeddingStore的坑直接用内存InMemoryEmbeddingStore跑测试很方便但重启项目之后知识库全没了。换成PGVector之后注意EmbeddingStoreIngestor的初始化时机不然容易重复入库同一文档被索引多遍检索时召回结果里全是重复内容。3.4 AgentScope实现更像搭一个服务而不是写一个方法AgentScope Java的建模方式确实不一样。你需要先定义Agent再把Agent装进群聊或者编排里去。它把“RAG as a Service”做成了一个独立检索服务Agent通过服务调用拿上下文这个架构让我眼前一亮。我按官方2.0示例写了差不多这样的结构// 定义检索服务 RAGService ragService RAGService.builder() .vectorStore(vectorStore) .embeddingModel(embeddingModel) .topK(5) .build(); // 定义Agent AgentConfiguration? assistantConf AgentConfiguration.create(assistant, ChatAgent.class) .withArgs(Collections.singletonMap( formatter, ChatAgent.formatter.withRag(ragService)));实际跑起来AgentScope的链路会自己在控制台里展开每一步怎么走、消息怎么流转、服务端怎么响应的都看得一清二楚。这种体验对喜欢“一切尽在掌握”的技术人员来说很舒服。但AgentScope Java的版本迭代也很频繁API变动不打招呼。我按官网复制的配置本地因为JDK版本问题直接启动失败后来看Issue才知道需要JDK 17以上的特定小版本配合某些依赖才行。还有Agent群里消息老是早于服务端就绪就发出去了我一度以为是时序问题排查了半天发现是配置里agent_services和model的顺序不对被AgentScope解析器当成“先定义后执行”的依赖了。这类问题在框架文档里不会写得特别细全靠跑报错、看日志、去GitHub Issue里面翻。3.5 Embabel实操记录思路有点意思但工程化差距明显Embabel的代码风格很精简设计上有点“万物皆组件”的味道。我试着用它的组件方式做同样的文档问答发现它提供的接口非常少我甚至需要手写向量化的逻辑把召回结果拼进Prompt的代码也得自己搞。我并不是说这样不对但框架的意义应该是把重复劳动变成配置和抽象而不是让每个使用者都重新发明一次检索流程。Embabel适合的场景我觉得是教学和源码研究——看一个开源项目如何用最少的类实现Agent的基本交互对理解大模型应用的底层结构很有帮助。生产项目里我劝你慎重。还有一个现象值得注意Embabel的文档和Demo更新速度明显跟不上大模型发展节奏。比如它对Qwen2.5的新能力支持、对多模态输入的支持都还停留在很初级的状态这在快速演进的AI领域是个致命弱点。选一个不更新的框架等于今天上了船明天船就停在岸上不走了。4. 项目落地中的常见问题与排查经验4.1 版本升级灾难老教程全废API大改是常态四个框架里版本变动最剧烈的是Spring AI和AgentScope。Spring AI从1.0到2.0的包名重构还有ChatClient从AiClient的迁移算是框架正常的大版本演进但如果你拿旧笔记配置新项目编译报错能报到你怀疑人生。我的建议是只看官方对应版本的Reference文档和当前版本的源码注释不要看一年前的博客包括我写的这篇——因为AI框架更新太快我写这篇时是2.0下个月可能就出2.1把API又改了。LangChain4j相对稳定一些它的接口设计从一开始就偏Java化核心抽象比如ChatLanguageModel、EmbeddingStore、AiServices一直在延续变化更多是增加新模块。排查版本问题的时候记得看langchain4j和langchain4j-ollama这些子模块的版本对齐光是主POM对齐不够子依赖版本不齐一样会冒出NoSuchMethodError。我总结了一套排查“NoSuchMethodError / ClassNotFoundException”的固定流程先mvn dependency:tree看冲突再确认所有langchain4j-*都是同一版本再查EmbeddingModel和EmbeddingStore是在langchain4j-core还是langchain4j-easy-rag模块里整个过程大概十分钟能定位。4.2 RAG链路调优召回质量差问题可能不在模型很多新手做文档问答回答得不行就以为是模型不好其实80%的情况是RAG链路的问题。我在LangChain4j实验里就遇到过切块600个字符、重叠50个字符时问“年假和病假有什么区别”召回的文档块只能覆盖其中一篇另一半内容被切到别的块里了模型看到的信息不完整自然回答不到位。解决办法是把切块大小从固定字符数改成按语义边界切分或者在召回后做一次重新排序。Spring AI的QuestionAnswerAdvisor里默认的TopK是4太机械了我通常会改成按相关性阈值过滤低于0.2的直接不召回。另外一定把QueryAugmenter用上让“用户原始问题”和“检索问题”解耦比如用户说“那它呢”你可能需要先做指代消解再检索。AgentScope的RAG Service默认带了召回分数和上下文组装但我在Java版里没找到特别精细的调优参数面板主要还是走API配置。想要做混合检索、重排序、多路召回这些高级玩法AgentScope更适合你有独立检索服务团队的情况自己一个人调有点重。4.3 本地模型和云端模型切换的稳定性问题我在实验里遇到过最无语的事本地Ollama服务一切正常切到云端模型比如OpenAI或者通义之后Prompt格式甚至模型名里带个连字符都会报400。这其实是框架层面对不同模型的适配差异。Spring AI对模型的适配做得比较“自动”它在ChatOptions里封装了各家模型的差异但如果你直接改了请求体里的字段Spring AI可能用自己的默认值覆盖掉你给的值。经验是先用框架自带的ChatClient跑通再考虑自定义请求体不要一上来就在Prompt之外动手脚。LangChain4j则要求你对不同模型类区别对待每个模型的配置参数差异很大比如Ollama的流式输出和OpenAI的流式输出在处理模式上完全不一样切换时如果只换模型对象不换流式解析逻辑前端输出就会乱。AgentScope因为把模型封装进Runtime切换相对统一但配置项比较复杂云端模型要格外注意服务地址的白名单和鉴权方式。Embabel在这块基本没有建树切换云端模型需要对源码做修改让我彻底放下了用它做生产的念头。4.4 常见问题速查表框架典型问题排查思路Spring AI升级2.0后旧代码编译失败确认Maven依赖版本和参考文档一致优先看官方2.0示例Spring AIRAG回答找不到资料检查VectorStore是否为空、TopK设置、Embedding模型是否统一LangChain4j子模块NoSuchMethodError用dependency:tree查版本冲突所有子模块对齐到同一版本LangChain4j知识库重复入库检查EmbeddingStoreIngestor初始化时机入库前先按文档ID去重AgentScopeAgent启动顺序出错检查AgentConfiguration和model配置声明顺序按依赖先定义模型AgentScope控制台看不到日志确认ServiceCenter服务地址和Agent应用地址一致确认端口放通Embabel生产环境基本不可用建议POC阶段就判断是否弃用不为情怀买单5. 选型决策表按场景直接对号入座这四个框架我建议用一套“团队技术栈 场景复杂度 运维能力”的打分体系来选。我给自己团队做了个权重表你们可以按实际情况调整。如果你的项目是标准Spring Boot单体应用日常就是CRUD加少量AI功能团队没有专门做AI组件的经验那我直接推荐Spring AI。它的学习成本最低官方文档和社区资料最多出问题最容易搜到答案。哪怕你是一个没做过大模型开发的Java开发跟着官方RAG教程跑一遍一个下午就能搭出第一个能用的问答机器人。如果你的项目要深度调优RAG、要做复杂的Agent流程、做多步工具调用而且团队有比较强的工程基因、喜欢把每一步都捏在手里LangChain4j会更合适。它给你的是“组件库”而不是“全家桶”当成积木自己拼出适合业务的形状。尤其是AI Service接口这个设计对Java团队实在太友好了测试写起来跟Mock Service一样丝滑。如果你的项目是平台型的比如多个业务线都要接AI能力、需要多Agent跨部门协作、需要统一的任务调度和监控面板那直接上AgentScope。它的定位就是企业级多Agent平台“RAG as a Service”这个模式也很适合大团队运维。当然你要接受它比前两者复杂得多的事实可能需要专门小组维护这套平台。至于Embabel你可以把它放进技术雷达的“评估”区隔几个月再回头看一眼它有没有长起来。在它社区活跃度、文档完备度、发布频率没有一个达到及格线之前不用认真考虑。场景推荐框架理由Spring Boot单体项目快速接AISpring AI全家桶一步到位成本最低需要深度定制RAG管线LangChain4j组件粒度细控制力强,可测试性好多Agent协作可视化运维AgentScope平台级别支持开箱即用Java团队做复杂Agent流程LangChain4j LangGraph4j接口化加流程编排扩展性强技术研究/框架源码学习Embabel代码量小适合研究不适合生产最后再分享一个真实心得我见过太多团队在框架选型上耗掉两个星期的例会时间最后选了一个最热门的但连自己的核心需求都没理清。选型之前先回答一个问题——你到底是想要一个“快速接API的边角料工具”还是“能支撑整个知识库体系的平台”这两个答案对应的框架是截然不同的。我自己在实际项目中大概率会用Spring AI起步把业务跑通然后根据RAG调优需求把核心链路换成LangChain4j等Agent数量真多到需要统一运维时再考虑引入AgentScope那套平台能力。先跑起来再去打磨这个顺序永远比“一步到位选个完美的框架”更靠谱。
阅读完成 · 觉得有帮助？
