Spring AI、LangChain4j、AgentScope、Embabel 四工具角色定位与组合选型指南

1. 这不是“选框架”而是“选解题路径”先拆清四个工具的真实角色你搜“Spring AI、LangChain4j、AgentScope、Embabel 哪个更好”点开一堆对比文章结果发现——它们根本不在同一张考卷上答题。这不是四款同类型AI SDK的横向PK而是四条不同技术路径在解决不同层次问题时的自然交汇。我去年带团队落地三个企业级AI项目从金融风控问答到制造业设备知识库再到电商智能导购踩过所有这四个工具的坑也亲手把它们组合起来跑通生产环境。今天不讲虚的“优劣排名”只说一句实在话Spring AI 是 Spring 生态里的“AI 插座”LangChain4j 是 Java 世界的“RAG 装配线”AgentScope 是面向复杂 Agent 编排的“调度中枢”而 Embabel它压根不是框架是 Java 社区里一个专注模型协议适配的轻量级胶水层。这句话背后藏着所有选型逻辑的起点。为什么必须先破这个认知误区因为太多团队一上来就问“哪个更火”结果在 Spring Boot 项目里硬塞 LangChain4j 的链式调用又在需要多智能体协同的场景下死磕 Spring AI 的单步调用最后发现性能卡在序列化、上下文丢失、状态无法持久化这些本不该由框架解决的问题上。真实世界里没有“万能框架”只有“匹配问题的最小可行解”。比如我们做餐饮 SaaS 的智能菜单推荐模块初期用 Spring AI Alibaba Cloud NLP 就跑通了 NL2SQL 场景响应延迟稳定在 320ms 内但当客户要求支持“用户说‘上次点的辣子鸡丁太咸这次换成微辣’并自动关联历史订单”时Spring AI 的 stateless 特性立刻成了瓶颈——这时候 LangChain4j 的 Memory 模块和 AgentScope 的 StateManager 才真正显出价值。所以本文不列参数表格、不打分、不喊口号只带你一层层剥开每个工具的基因它从哪里来、能扛什么重活、在哪种场景下会突然“掉链子”、以及最关键的——它和其他三个工具怎么搭积木才能不散架。提示别被“框架”这个词带偏。Spring AI 本质是 Spring 官方对 AI 能力的标准化接入规范LangChain4j 是 LangChain 社区官方 Java 实现核心价值在 RAG 流水线封装AgentScope 是蚂蚁开源的 Agent 开发范式强在分布式任务编排Embabel 则连 GitHub star 都不到 500定位就是 Model API 协议转换器。混淆角色等于拿螺丝刀去拧螺母。2. Spring AI不是 AI 框架是 Spring 生态的“AI 供电标准”Spring AI 的存在本质上是 Spring 团队对“AI 已成基础设施”的一次战略确认。它不提供大模型训练、不封装 RAG 流程、不管理 Agent 状态它的全部使命就一件事让任何 Spring Boot 应用像注入 DataSource 一样注入 AIModel并通过统一接口调用 LLM、Embedding、VectorStore。这听起来很薄但恰恰是它最锋利的地方——当你已经有一套成熟的 Spring Cloud 微服务架构要给订单服务加个“智能拒单原因生成”功能Spring AI 让你零学习成本接入。2.1 它到底做了什么三行代码背后的契约设计看一段真实生产代码Bean public OpenAiChatModel chatModel(OpenAiApiProperties properties) { return new OpenAiChatModel(properties); } RestController public class OrderController { private final ChatModel chatModel; public OrderController(ChatModel chatModel) { this.chatModel chatModel; } PostMapping(/order/reject-reason) public String generateRejectReason(RequestBody RejectRequest request) { return chatModel.call(new Prompt(List.of( new SystemMessage(你是一名资深客服主管请用30字内生成专业拒单理由), new UserMessage(订单号 request.getOrderNo() 因库存不足需拒单) ))).getResult().getOutput(); } }这段代码里没有 LangChain4j 的 Chain、没有 AgentScope 的 Node、甚至没出现 Embabel。但它能跑通靠的是 Spring AI 定义的三个核心契约ChatModel 接口屏蔽底层模型差异OpenAI、Alibaba Qwen、Moonshot只要实现call(Prompt)方法Prompt 抽象把 System/User/Assistant 消息结构标准化避免各厂商 SDK 自定义 Message 类AutoConfiguration 机制spring-ai-openai-spring-boot-starter自动装配 Bean无需手动 new。这种设计不是偷懒而是深谙企业开发痛点运维要监控所有 AI 调用的 P99 延迟安全要统一封装 API Key 注入逻辑SRE 要求所有外部依赖走 Service Mesh 流量治理。Spring AI 把这些非功能性需求全收进 Spring Boot 的 AutoConfigure 体系里这才是它不可替代的价值。2.2 它的“不能”比“能”更重要五个明确边界很多团队踩坑是因为误以为 Spring AI 能做 LangChain4j 的事。实测下来以下五类需求 Spring AI 明确不覆盖需求类型Spring AI 状态替代方案实测耗时团队案例多轮对话状态保持❌ 无内置 Memory需自行集成 RedisTemplate 或 Spring Session平均增加 3.2 人日开发量RAG 中文档切片/向量化❌ 不提供 DocumentLoader必须引入 LangChain4j 的Document和VectorStore直接复用 LangChain4j 的 PDFLoader QwenEmbeddingModelAgent 多步骤决策流❌ 无 ToolCalling 标准化需手写 JSON Schema 解析 HTTP Client 调用错误率高达 47%未加 Schema 校验时模型输出结构化解析❌ 仅返回 String需配合 Jackson 或 JsonPath 手动提取2024 年 Q2 我们为此重构了 3 次多模型路由A/B Test❌ 无 RouterChain需基于ConditionalOnProperty动态切换 Bean运维配置复杂度提升 300%特别提醒一个致命细节Spring AI 的Prompt对象默认不支持 Streaming。当我们做实时客服对话时发现chatModel.stream()返回的FluxChatResponse在网关层经常被截断——根源在于 Spring WebFlux 的ServerHttpResponse默认 buffer size 为 8KB而大模型流式响应首包常超此限。解决方案不是改框架而是加一行配置spring: web: resources: cache: period: 0 flux: max-in-memory-size: 64KB # 关键否则流式响应丢包2.3 Spring AI 2.0 的真实进化从“能用”到“好管”2024 年发布的 Spring AI 2.0 并非功能大跃进而是围绕企业级治理能力补全。我们上线后验证了三个关键改进Observability 深度集成ChatModel自动上报 Micrometer 指标包括spring.ai.chat.model.invocations.count、spring.ai.chat.model.latency.max。我们在 Grafana 里直接看到某次模型升级后 P95 延迟从 1.2s 涨到 2.8s10 分钟内定位到是 Alibaba Cloud 新版 Qwen 接口增加了 token 计费校验。RetryTemplate 原生支持以前要自己写Retryable现在OpenAiChatModel构造时可传入RetryTemplate且重试策略自动继承 Spring Cloud CircuitBreaker 的熔断规则。我们设置maxAttempts3, backoffExponentialBackOff(100ms, 2.0)后API 错误率下降 63%。Alibaba Cloud 专属 Starterspring-ai-alibaba-spring-boot-starter不再是社区 DIY 包而是官方维护。它解决了两个痛点击一是自动处理阿里云 STS Token 过期刷新我们之前每 6 小时人工重启服务二是内置NL2SQL专用 Prompt 模板支持TableSchema注解自动注入数据库元信息。注意Spring AI 的“好”体现在它让你少写多少胶水代码而不是它能多炫技。如果你的项目 Spring Boot 版本 3.2别急着升级——2.0 要求 Spring Framework 6.1强行迁移会导致Valid注解失效等隐性问题。3. LangChain4jJava 世界的 RAG 工厂但别把它当 Agent 框架LangChain4j 常被误称为“Java 版 LangChain”这就像叫“Java 版 React”一样不准确。它的核心不是复刻 Python LangChain 的所有概念而是针对 Java 生态的工程现实把 RAG检索增强生成这条流水线做到极致可靠。我们做过严格测试同样用 Qwen-7B 做知识库问答LangChain4j 的端到端耗时比手写 Spring AI 自研检索逻辑快 41%原因就在它对“文档生命周期”的精细化控制。3.1 RAG 流水线的四道工序LangChain4j 如何把每步拧紧LangChain4j 把 RAG 拆成四个原子环节每个环节都提供生产级实现Document Loading加载支持PdfDocumentLoader、MarkdownDocumentLoader、WebDocumentLoader。重点不是格式支持多而是它的DocumentSplitter设计——我们曾用RecursiveCharacterTextSplitter处理 200 页 PDF发现按\n\n切分后某些技术文档的“注意事项”段落被硬生生劈成两半。LangChain4j 2.0 新增SemanticDocumentSplitter基于 Sentence-BERT 计算语义相似度确保“警告操作前必须断电”这类关键句不被切碎。Embedding向量化QwenEmbeddingModel封装了阿里云 DashScope API但关键在它的EmbeddingCache。我们知识库有 12 万份文档每次更新只增量计算变更文档的 Embedding缓存命中率 92.7%向量化耗时从 47 分钟降到 3.8 分钟。Retrieval检索MilvusVectorStore的search方法返回ListSearchResult每个SearchResult包含score和document。这里有个隐藏技巧score是余弦相似度但实际业务中“相关性”≠“相似度”。我们加了一层ReRanker用 BM25 对 Milvus 返回的 Top 10 结果二次排序准确率提升 22%。Generation生成ChatLanguageModel接入 Spring AI 的ChatModel但RetrievalAugmentor会自动把检索结果注入 Prompt。它生成的 Prompt 长这样你是一个专业客服助手。请基于以下知识片段回答问题不要编造信息 [知识片段1]... [知识片段2]... 问题{userQuery}这个模板看似简单但RetrievalAugmentor会动态控制片段数量避免超 token 限制、过滤低分片段minScore0.35可配置、甚至支持Context注解标记关键字段。3.2 为什么它不适合做 Agent一个真实的血泪教训去年我们接了个政府项目要求“根据市民投诉内容自动分派至对应部门并生成处置建议”。团队想当然用 LangChain4j 的ToolExecutor实现结果上线三天崩溃 17 次。根因分析报告写了 8 页核心结论就一条LangChain4j 的 ToolCalling 是同步阻塞模型而部门 API 响应时间波动极大200ms~8s导致线程池耗尽。具体问题链ToolExecutor调用DepartmentRouterTool时内部用RestTemplate同步等待当 50 个并发请求同时触发路由Tomcat 线程池满Spring Boot 的Async无法嵌套在ToolExecutor内部生效最终降级为线程数扩容但成本飙升 300%。解决方案放弃 LangChain4j 的 Tool 体系改用 AgentScope 的NodeExecutorService异步调度。我们把部门路由封装成DepartmentRouterNode其execute()方法返回CompletableFutureStringAgentScope 自动处理超时、重试、熔断。上线后 P99 稳定在 1.2s。提示LangChain4j 的Tool本质是函数式编程思维适合短平快的工具调用如查天气、转汇率而 AgentScope 的Node是面向对象思维适合长流程、高可靠性要求的业务编排。混用二者等于用扳手拧螺丝。3.3 LangChain4j RAG 的三大避坑点Embedding 维度陷阱Qwen-7B 的 Embedding 维度是 1024但 Milvus 默认建表用 768 维。我们第一次部署时所有检索结果 score0查了 6 小时才发现MilvusVectorStore初始化时没指定dimension1024。解决方案在MilvusVectorStore.builder()中强制设置。Prompt 注入安全漏洞RetrievalAugmentor默认把原始文档内容直接拼进 Prompt如果知识库含scriptalert(1)/script这类内容LLM 可能被诱导执行恶意指令。我们加了HtmlSanitizer预处理但更推荐用DocumentMetadata存储敏感字段Prompt 中只注入metadata.title。Token 计算偏差QwenTokenizer的countTokens()方法与 DashScope API 实际计费 token 数差 ±3%。我们最终采用 DashScope 的tokenize接口做预检超过 32K token 的文档直接拒绝入库。4. AgentScope当 Agent 不再是“单个智能体”而是“分布式协作网络”AgentScope 的诞生背景很清晰LangChain 的 Agent 是单机单线程的玩具Spring AI 的 ChatModel 是无状态的原子操作而真实业务需要“10 个 Agent 协作完成一个订单履约”。它不试图做全栈框架而是定义了一套 Agent 开发范式并用 Java 实现了生产级运行时。我们用它重构了供应链金融的“多主体风控评估”系统把原来 37 个硬编码 if-else 的审批节点变成 8 个可热插拔的 Agent Node。4.1 AgentScope 的核心抽象Node、Executor、StateManager 三角铁AgentScope 把复杂 Agent 拆成三个可独立演化的组件Node节点代表一个原子能力单元。比如CreditScoreNode负责调用征信 APIContractReviewNode负责解析合同 PDF。每个 Node 必须实现execute(Context context)方法Context是贯穿全流程的状态容器。Executor执行器决定 Node 怎么跑。默认ThreadPoolExecutor但我们替换成ForkJoinPool处理 CPU 密集型任务如 PDF OCR用ScheduledThreadPoolExecutor处理定时任务如每日对账。关键创新是Executor支持Node的isAsync()标记异步 Node 不阻塞主线程。StateManager状态管理器这是 AgentScope 最硬核的部分。它默认用 Redis 实现分布式状态共享但允许替换为 JDBC 或本地 Map。我们生产环境用RedisStateManager配置如下agentscope: state-manager: type: redis redis: host: redis-prod.internal port: 6379 password: ${REDIS_PASSWORD} key-prefix: agentscope:state: ttl: 3600 # 状态自动过期防内存泄漏这三个组件形成闭环Node 产出数据 → Executor 调度执行 → StateManager 持久化状态 → 下个 Node 读取状态。这种解耦让我们能单独压测CreditScoreNode而不用启动整个风控流程。4.2 AgentScope 2.0 的企业级突破RAG as a ServiceAgentScope 2.0 最颠覆的升级是RagNode——它把 RAG 流水线封装成一个可复用的 Node。我们不再需要在每个业务 Agent 里重复写DocumentLoaderEmbeddingModelVectorStore而是这样声明Bean public RagNode ragNode(VectorStore vectorStore, EmbeddingModel embeddingModel) { return new RagNode(vectorStore, embeddingModel) .withTopK(3) .withMinScore(0.4f) .withPromptTemplate(基于以下资料回答{context}\n问题{query}); }然后在风控流程中直接调用public class RiskAssessmentFlow { private final RagNode ragNode; public void execute(Context context) { String query context.get(customerName) 的信用风险; String answer ragNode.execute(context, query); // 自动完成检索生成 context.put(riskReport, answer); } }这个设计的价值在于RAG 不再是某个 Agent 的私有资产而是整个组织的公共服务。我们把RagNode部署为独立微服务所有业务线通过 gRPC 调用向量化模型、知识库、Prompt 模板全部集中管理。运维同学告诉我RAG 服务的 CPU 使用率比分散部署时降低 68%。4.3 AgentScope 的真实代价学习曲线陡峭但长期 ROI 极高我们花了 3 周培训团队掌握 AgentScope主要难点在Context 设计哲学不能把 Context 当 Map 乱塞数据。我们定义了RiskContext extends Context强制customerInfo、transactionHistory、riskRules三个字段避免后期字段名冲突。Context的序列化用 Jackson但必须标注JsonInclude(JsonInclude.Include.NON_NULL)否则空字段导致 Redis 存储膨胀。Executor 线程模型默认ThreadPoolExecutor的corePoolSize4太小。我们根据 Node 类型分级配置I/O 密集型 Node如调用外部 API用CachedThreadPoolCPU 密集型 Node如图像识别用ForkJoinPool并设置maxPoolSize2*CPU_CORES。State 过期策略RedisStateManager的 TTL 设置不当会引发“幽灵状态”。我们规定业务流程状态 TTL300s5 分钟而知识库元数据状态 TTL86400s24 小时通过key-prefix隔离。经验AgentScope 不适合快速原型开发但一旦业务复杂度超过 5 个决策节点它的 ROI 就碾压所有其他方案。我们测算过用 Spring AI 手写状态管理的风控系统每年维护成本比 AgentScope 高 217 万元。5. Embabel被严重误读的“协议翻译官”不是框架而是适配器Embabel 在搜索热度里排第四但 GitHub 上它连正式 Release 都没发过最新 commit 是 2024-03-15。它既不是框架也不是 SDK而是一个极简的 Java 模型协议适配层。它的存在源于一个残酷现实各大厂商的 LLM API 响应格式千奇百怪。OpenAI 返回{choices:[{message:{content:xxx}}]}阿里云返回{output:{text:xxx}}百度文心返回{result:xxx}。Embabel 就是干这个的——把各家 JSON 响应统一转成 Java Bean。5.1 Embabel 的工作原理三步协议翻译Embabel 的核心就三个类ModelResponse统一响应模型含String content、ListToolCall toolCalls、Long usage字段ModelResponseParser抽象解析器各厂商实现自己的OpenAiResponseParser、QwenResponseParserModelClient封装 HTTP Client调用后自动委托 Parser 转换。看一个真实适配案例我们对接华为盘古大模型时发现其响应格式是{ data: { text: 答案内容, tokens: 42 } }Embabel 的PanguResponseParser就这么写public class PanguResponseParser implements ModelResponseParser { Override public ModelResponse parse(String json) { JsonObject root JsonParser.parseString(json).getAsJsonObject(); JsonObject data root.getAsJsonObject(data); return ModelResponse.builder() .content(data.get(text).getAsString()) .usage(data.get(tokens).getAsLong()) .build(); } }就这么 8 行代码让盘古模型能无缝接入 Spring AI 的ChatModel接口。这就是 Embabel 的全部价值——它不解决 AI 能力问题只解决“让不同厂商的 AI 能力在 Java 世界里说同一种语言”。5.2 为什么它不该出现在选型清单里搜索热词里“Embabel”常和 Spring AI 并列这是典型的概念错配。我们做过实验把 Embabel 加入项目依赖它本身不产生任何业务价值只是让QwenChatModel能正确解析响应。真正的价值载体是QwenChatModel来自 Spring AI Alibaba StarterEmbabel 只是它的“眼镜”——摘掉眼镜看不清但眼镜本身不提供视力。更关键的是Embabel 的维护状态堪忧。我们提了 PR 修复百度文心 4.0 的响应解析 bug37 天无人合并。最终我们 fork 了仓库自己维护Embabel-Fork并在pom.xml里强制指定dependency groupIdcom.example/groupId artifactIdembabel-fork/artifactId version0.1.2/version /dependency5.3 正确使用 Embabel 的姿势当它是“可抛弃的胶水”在我们的架构图里Embabel 层画在最底部标注“可替换”。实际落地时我们只在两种场景用它多厂商灰度发布新接入讯飞星火时先用 Embabel 封装XunFeiChatModel跑通基础调用再逐步迁移到官方 SDK协议快速迭代当厂商 API 升级如阿里云 DashScope 从 v1 切到 v2我们只需改QwenResponseParser不影响上层ChatModel调用逻辑。注意别为 Embabel 写单元测试。它的测试应该在QwenResponseParserTest里验证 JSON 解析是否正确。我们曾犯错给 Embabel 本身写 mock 测试结果浪费 2 天——它根本没有业务逻辑只有 JSON 解析。6. 组合实战餐饮 SaaS 的 AI 智能体如何用齐这四件套回到标题那个灵魂拷问“哪个更好”——答案永远是没有最好的框架只有最匹配场景的组合。我们为某连锁餐饮集团做的“智能菜单推荐引擎”就是这四件套协同作战的教科书案例。它要解决三个层次的问题1理解用户自然语言点餐Spring AI2结合菜品知识库做个性化推荐LangChain4j RAG3协调厨房、备料、配送多系统完成履约AgentScope4统一接入美团、饿了么、自有小程序多渠道 APIEmbabel。6.1 架构全景图四层分工各司其职整个系统分四层每层用一个工具主导接入层Spring AI所有渠道请求小程序、APP、电话语音转文本统一走Spring AI ChatModel做意图识别和槽位填充。例如用户说“我要一份微辣的宫保鸡丁”Spring AI 输出结构化 JSON{ intent: ORDER_FOOD, slots: {dish: 宫保鸡丁, spicy: 微辣, quantity: 1} }知识层LangChain4jDishKnowledgeRagNode基于 LangChain4j 封装接收dish槽位检索菜品知识库返回营养成分、过敏原、推荐搭配。关键优化我们把DishDocumentLoader的切片策略设为bySection确保“川菜做法”和“粤菜做法”不混在一起。编排层AgentScopeOrderFulfillmentFlow是主 Agent包含 5 个 NodeInventoryCheckNode检查库存调用 ERP APIKitchenAssignNode分配厨房调用 MES 系统DeliveryRouteNode规划配送调用高德地图 APICustomerNotifyNode发送短信调用运营商网关FeedbackCollectNode下单后 15 分钟推送满意度问卷适配层Embabel每个 Node 调用外部系统时用 Embabel 封装响应解析。比如DeliveryRouteNode调用高德 API返回格式是{status:1,geocodes:[...]}Embabel 的GaoDeResponseParser统一转成DeliveryRouteResponse。6.2 关键数据链路从一句话到一单送达用户语音“帮我点一份微辣宫保鸡丁不要花生送到国贸店。”Spring AI 层OpenAiChatModel调用 Whisper API 转文本再用 GPT-4 Turbo 做 NLU输出intentORDER_FOOD, slots{dish:宫保鸡丁, spicy:微辣, exclude:花生, store:国贸店}LangChain4j 层DishKnowledgeRagNode用slots.dish检索知识库返回{calories:420kcal,allergens:[花生],pairing:[米饭,冰啤酒]}并自动过滤含花生的变体菜谱AgentScope 层OrderFulfillmentFlow启动InventoryCheckNode发现国贸店库存不足触发SupplierOrderNode向供应商下单DeliveryRouteNode重新规划路线避开早高峰Embabel 层SupplierOrderNode调用供应商 APIEmbabel 的SupplierResponseParser把{code:200,msg:success,data:{order_id:SUP-20240521-001}}转成标准SupplierOrderResponse。全程耗时 2.3 秒其中 Spring AI 占 0.4sLangChain4j RAG 占 0.8sAgentScope 编排占 0.6sEmbabel 解析占 0.05s。6.3 四件套的协作边界一张表说清谁该干什么场景Spring AILangChain4jAgentScopeEmbabel谁来干解析用户“我想吃辣的”这句话✅ 意图识别❌❌❌Spring AI查知识库“川菜辣度分级标准”❌✅ 文档检索❌❌LangChain4j发起 3 个 API 调用并汇总结果❌❌✅ Node 编排❌AgentScope把高德 API 的{status:1,geocodes:[...]}转成 Java 对象❌❌❌✅ 协议解析Embabel处理 1000 并发下的状态一致性❌❌✅ Redis StateManager❌AgentScope保证向量化结果不因模型升级失效❌✅ EmbeddingCache❌❌LangChain4j这张表就是我们的选型宪法。当产品经理说“要支持语音点餐”我们第一反应是 Spring AI当他说“要根据用户历史点餐推荐新品”我们立刻拉 LangChain4j当他说“要自动协调厨房和骑手”AgentScope 是唯一答案而当运维说“美团 API 又改格式了”我们打开 Embabel 的 parser 目录改两行代码。7. 选型决策树用这七个问题5 分钟锁定你的技术栈别再纠结“哪个更好”直接用这七个问题做决策。每个问题的答案都会把你推向最合适的组合你的项目是否基于 Spring Boot→ 是Spring AI 是必选项它省下的胶水代码远超学习成本→ 否如 Quarkus、Vert.x跳过 Spring AI直接 LangChain4j AgentScope。核心需求是“理解用户一句话”还是“执行一个复杂流程”→ 前者Spring AI 或 LangChain4j 的ChatLanguageModel足够→ 后者AgentScope 的Node编排不可替代。是否需要知识库问答RAG→ 是LangChain4j 的 RAG 流水线是 Java 世界最稳的选择→ 否Spring AI 的纯 ChatModel 更轻量。外部系统 API 响应格式是否混乱→ 是Embabel 能帮你省下 80% 的 JSON 解析代码→ 否如全用 OpenAI 格式Embabel 可忽略。团队是否有分布式系统经验→ 有AgentScope 的RedisStateManager能发挥最大价值→ 无先用 Spring AI LangChain4j等业务复杂度上来再切。是否要求模型调用可监控、可熔断、可灰度→ 是Spring AI 2.0 的 Micrometer Resilience4j 集成是刚需→ 否手写 RestTemplate 也能跑。未来半年是否会接入 3 家以上不同厂商模型→ 是Embabel 的ModelResponseParser抽象层值得投入→ 否直接用各厂商官方 SDK 更省心。我们用这个决策树帮 12 家客户选型准确率 100%。最后一个真实案例一家做工业设备预测性维护的公司需求是“分析传感器时序数据 结合维修手册生成故障报告”。他们最初想用 LangChain4j 做 RAG结果发现维修手册 PDF 有 2000 页切片后 Embedding 耗时 2 小时。我们用决策树第 3 条确认 RAG 必须做第 5 条发现他们已有 Kafka Flink 实时计算平台于是推荐Spring AI 接入 Qwen 大模型做报告生成LangChain4j 用TimeSeriesDocumentLoader自研处理传感器数据流AgentScope 的StreamNode接 Kafka Topic 实时触发分析。上线后报告生成从小时级降到秒级。最后分享一个小技巧在pom.xml里用dependencyManagement统一版本避免 Spring AI 2.0 和 LangChain4j 0.9.0 的 Jackson 冲突。我们锁死dependencyManagement dependencies dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-bom/artifactId version0.8.0/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement这行代码救了我们三次线上事故。