Java 生态的 AI 框架选型，这两年从“没什么可选的”迅速变成了“挑花眼”。2023 年那会儿，想在 Spring Boot 项目里接个大模型，基本就是自己拿 HTTP Client 硬怼，或者找个社区封装凑合用。到了 2024 年之后，Spring AI 正式发版、LangChain4j 快速迭代、AgentScope 带着多智能体理念杀进来、Embabel 又抛出了“领域建模驱动 Agent”的新思路，四个框架各有各的拥趸，也各有各的坑。我过去一年多在这四个框架上都做过实际项目，从简单的 RAG 问答到多 Agent 协作流程都跑过一遍，踩的坑不算少。这篇文章不打算给你一个“XX 最好”的结论，而是把四个框架各自的设计哲学、适用边界、实际开发中的真实体验摊开来讲，帮你在选型时少走弯路。如果你正在纠结“现在到底用 Spring AI 还是 LangChain4j”，或者想搞清楚 AgentScope 和 Embabel 到底解决的是什么问题，下面的内容应该能给你一些参考。
1. 四个框架的出身与设计哲学决定了它们的边界
选框架这件事，很多人上来就看功能列表对比，其实第一步应该看的是“这个框架是谁做的、为什么做”。框架的设计哲学决定了它的能力上限和适用场景，功能可以后续补，但底层思路很难改。
1.1 Spring AI：Spring 生态的“亲儿子”，目标是标准化抽象
Spring AI 的定位非常明确——它是 Spring 官方团队主导的项目，核心目标是把 AI 能力以 Spring 开发者熟悉的方式引入到 Spring 生态中。什么叫“Spring 熟悉的方式”？就是依赖注入、自动配置、Starter 依赖、统一的抽象接口这一套。你在 Spring Boot 里怎么用 JdbcTemplate，就怎么用 ChatClient；怎么配置 DataSource，就怎么配置模型连接。
它的核心抽象是ChatClient、EmbeddingClient、VectorStore这几个接口，上层提供统一的 API，底层通过不同的 Starter 适配 OpenAI、Azure OpenAI、Ollama、Anthropic 等模型提供商。这种设计的好处是可移植性强——今天用 OpenAI，明天想换成本地部署的模型，改个配置就行，业务代码基本不动。
但这也意味着 Spring AI 在功能深度上会相对保守。它优先保证的是“稳定、通用、符合 Spring 规范”，而不是“最快支持最新特性”。比如 Function Calling 的支持、多模态的处理，Spring AI 的节奏通常比 LangChain4j 慢半拍。这不是能力问题，是定位问题。
1.2 LangChain4j：社区驱动的“功能先锋”，迭代速度极快
LangChain4j 的灵感来自 Python 的 LangChain，但它是完全独立的 Java 实现，不是简单移植。它的核心目标是提供最全面的 LLM 应用开发能力，包括对话、RAG、Agent、工具调用、记忆管理等。
LangChain4j 的设计风格更“实用主义”——API 设计上没那么讲究抽象层次，有时候一个功能有好几种用法，文档也相对分散。但它的优势在于功能覆盖广、迭代快。比如 RAG 相关的文档加载器、分割器、检索器、重排序，LangChain4j 提供了一整套开箱即用的组件，数量上远超 Spring AI。再比如多模型支持，除了主流云服务，它还支持大量本地推理框架和社区模型。
LangChain4j 的社区非常活跃，GitHub 上的 Issue 响应速度很快，新功能的合并周期短。但这也带来一个问题：版本之间的 API 变动比较频繁，升级时偶尔会遇到 breaking change。我在一个项目里从 0.31 升到 0.35，就有几个类的包路径变了，需要手动调整。
1.3 AgentScope：阿里出品，多智能体协作是核心命题
AgentScope 最初是阿里达摩院推出的多智能体框架，后来开源并持续迭代到 2.0 版本。它的核心命题不是“怎么调模型”，而是“多个 Agent 怎么协作完成复杂任务”。
AgentScope 的设计里，Agent 是一等公民。它提供了Agent基类、Message消息机制、Pipeline编排、Msghub通信等一套完整的多 Agent 协作基础设施。你可以定义多个角色不同的 Agent，让它们通过消息传递来分工合作，比如一个负责规划、一个负责执行、一个负责审核。
AgentScope 2.0 在 RAG as a Service、分布式部署、可观测性方面做了不少增强。它的 Java 版本（AgentScope Java）也在逐步完善，目标是让 Java 开发者也能用上多 Agent 编排能力。但客观说，AgentScope 的 Java 生态还不如 Python 版成熟，文档和示例相对少一些，上手门槛比 Spring AI 和 LangChain4j 要高。
1.4 Embabel：领域建模驱动的 Agent 框架，思路最独特
Embabel 是四个框架里最“另类”的一个。它的核心思路是用领域驱动设计（DDD）的方式来构建 Agent。在 Embabel 里，你不是在写“调用模型的代码”，而是在定义“领域对象”和“它们之间的动作”。
Embabel 的核心理念是：Agent 的行为应该由领域模型来驱动，而不是由流程编排来驱动。你定义一个Goal，定义达成目标所需的Action，框架会自动规划执行路径。这种思路更接近“声明式编程”，和前面三个框架的“命令式编排”有本质区别。
Embabel 目前还比较新，社区规模小，文档和示例有限。但它的设计思路对复杂业务场景很有启发——尤其是那些规则多、状态多、需要动态规划的场景。不过现阶段把它用在生产环境需要谨慎评估，生态成熟度是最大的短板。
| 框架 | 主导方 | 核心定位 | 设计风格 | 生态成熟度 |
|---|---|---|---|---|
| Spring AI | Spring 官方 | Spring 生态的 AI 标准化抽象 | 约定优于配置，抽象统一 | 高 |
| LangChain4j | 社区 | 全功能 LLM 应用开发工具集 | 实用主义，功能优先 | 高 |
| AgentScope | 阿里 | 多智能体协作与编排 | Agent 为中心，消息驱动 | 中 |
| Embabel | 社区 | 领域建模驱动的 Agent | 声明式，DDD 风格 | 低 |
这张表不是给你一个“谁好谁坏”的排名，而是帮你快速定位：如果你要的是稳定、规范、和 Spring 无缝集成，Spring AI 是首选；如果你要的是功能全、迭代快、RAG 组件丰富，LangChain4j 更合适；如果你要做多 Agent 协作，AgentScope 值得研究；如果你对 DDD 驱动的 Agent 感兴趣，Embabel 可以关注但别急着上生产。
2. 从实际代码看四个框架的开发体验差异
光讲设计哲学太虚，咱们直接看代码。同一个需求——“做一个带 RAG 的问答服务”——在四个框架里分别怎么写，写出来的代码量、可读性、灵活度差多少，一比就清楚了。
2.1 Spring AI 的 ChatClient 与 Advisor 机制
Spring AI 的核心开发入口是ChatClient。它的用法非常 Spring 化：
@RestController public class ChatController { private final ChatClient chatClient; public ChatController(ChatClient.Builder builder, VectorStore vectorStore) { this.chatClient = builder .defaultSystem("你是一个专业的技术助手") .defaultAdvisors(new QuestionAnswerAdvisor(vectorStore)) .build(); } @GetMapping("/chat") public String chat(@RequestParam String message) { return chatClient.prompt() .user(message) .call() .content(); } }这段代码里最值得说的是Advisor机制。Advisor 是 Spring AI 的拦截器抽象，你可以在请求前后插入逻辑。QuestionAnswerAdvisor就是官方提供的 RAG Advisor，它会自动把用户问题向量化、检索相关文档、拼接到 Prompt 里。整个过程对业务代码透明，你只需要在构建 ChatClient 时挂上这个 Advisor 就行。
这种设计的优点是干净、可组合。你可以挂多个 Advisor，比如一个做 RAG、一个做日志、一个做敏感词过滤，它们按顺序执行，互不干扰。缺点是灵活性受限——如果你想在检索后做复杂的重排序、或者根据检索结果动态调整 Prompt 策略，Advisor 的抽象就不太够用了，得自己写自定义 Advisor。
Spring AI 的 RAG 流程里，VectorStore是核心接口，支持多种实现：SimpleVectorStore（内存）、PgVectorStore、RedisVectorStore、MilvusVectorStore 等。文档加载和分割用的是DocumentReader和TextSplitter，组件数量比 LangChain4j 少，但常用的都有。
2.2 LangChain4j 的 AiServices 与 RAG 组件链
LangChain4j 的开发入口是AiServices，它用动态代理的方式把接口转成实现：
interface Assistant { @SystemMessage("你是一个专业的技术助手") String chat(@UserMessage String message); } Assistant assistant = AiServices.builder(Assistant.class) .chatLanguageModel(model) .contentRetriever(contentRetriever) .build(); String answer = assistant.chat("Spring AI 的 Advisor 是什么？");AiServices的好处是声明式、类型安全。你定义一个接口，用注解标注系统消息、用户消息、记忆策略，框架自动生成实现。这种方式写起来很舒服，尤其是当你有多个不同角色的助手时，每个助手一个接口，清晰明了。
RAG 方面，LangChain4j 的组件链更完整：
EmbeddingStore<TextSegment> embeddingStore = new InMemoryEmbeddingStore<>(); EmbeddingStoreIngestor ingestor = EmbeddingStoreIngestor.builder() .documentSplitter(DocumentSplitters.recursive(500, 50)) .embeddingModel(embeddingModel) .embeddingStore(embeddingStore) .build(); ingestor.ingest(document); ContentRetriever retriever = EmbeddingStoreContentRetriever.builder() .embeddingStore(embeddingStore) .embeddingModel(embeddingModel) .maxResults(5) .minScore(0.7) .build();DocumentSplitter支持递归分割、按段落分割、按句子分割等多种策略；ContentRetriever支持向量检索、全文检索、混合检索；还有ReRankingContentAggregator做重排序。这套组件链的丰富度是 Spring AI 目前比不了的。
但 LangChain4j 的 API 风格不太统一。有的地方用 Builder，有的地方用工厂方法，有的地方直接 new。文档虽然全，但组织得比较散，新手容易迷路。我的经验是：先看官方 examples 仓库，再回头看文档，比直接啃文档效率高得多。
2.3 AgentScope 的多 Agent 消息编排
AgentScope 的开发模式和前面两个完全不同。它的核心不是“调模型”，而是“定义 Agent 和它们之间的消息流”：
// 定义一个 Agent ReActAgent agent = ReActAgent.builder() .name("assistant") .model(model) .tools(tools) .build(); // 定义消息 Msg msg = Msg.builder() .name("user") .content("帮我分析这份销售数据") .build(); // 执行 Msg response = agent.reply(msg);这是单 Agent 的用法，看起来和 LangChain4j 差不多。但 AgentScope 的真正威力在多 Agent 编排：
// 定义多个 Agent ReActAgent planner = ReActAgent.builder().name("planner").model(model).build(); ReActAgent executor = ReActAgent.builder().name("executor").model(model).tools(tools).build(); ReActAgent reviewer = ReActAgent.builder().name("reviewer").model(model).build(); // 用 Pipeline 编排 SequentialPipeline pipeline = SequentialPipeline.builder() .addAgent(planner) .addAgent(executor) .addAgent(reviewer) .build(); Msg result = pipeline.run(inputMsg);这种编排方式适合任务可以明确分阶段的场景，比如“规划-执行-审核”三段式。AgentScope 还支持Msghub做更灵活的广播式通信，以及Msg的元数据传递，让 Agent 之间可以共享上下文。
AgentScope 的 Java 版目前还在完善中，部分高级特性（如分布式部署、可视化调试）的 Java 支持不如 Python 版。但基础的 Agent 定义、Pipeline 编排、工具调用已经可用。如果你的团队是 Java 为主但想做多 Agent，AgentScope Java 是目前少有的选择。
2.4 Embabel 的领域建模与 Goal-Action 规划
Embabel 的代码风格在四个框架里最特别。它不是让你写“调用链”，而是让你定义“领域对象”和“动作”：
@Domain public class SalesAnalysis { @Action public SalesReport analyze(SalesData data) { // 分析逻辑 return report; } @Goal public String generateInsight(SalesReport report) { // 生成洞察 return insight; } }Embabel 的框架会根据@Goal和@Action的依赖关系，自动规划执行路径。你不需要写“先调 A 再调 B”，框架自己会算。这种声明式的方式在复杂业务场景下能大幅减少编排代码，但前提是你的领域模型设计得足够清晰。
Embabel 目前还处于早期阶段，API 可能还会变，文档和示例都比较少。我在一个内部项目里试过，思路确实有意思，但遇到问题基本只能看源码。现阶段不建议在生产环境使用，但值得关注它的演进。
3. RAG 能力深度对比：组件丰富度与检索质量
RAG 是当前 Java AI 应用最主流的落地场景，四个框架在这块的能力差异直接决定了它们在实际项目中的适用性。我从文档处理、检索策略、重排序、评估四个维度来拆。
3.1 文档加载与分割：LangChain4j 组件最全
文档加载这块，LangChain4j 提供的DocumentLoader实现最多：文件系统、URL、PDF、Word、Excel、HTML、Markdown 都有对应实现。分割器方面，DocumentSplitter支持递归分割、按字符数分割、按段落分割、按句子分割，还可以自定义分割逻辑。
Spring AI 的DocumentReader实现相对少一些，PDF 和 Markdown 是常用的，其他格式需要自己扩展。TextSplitter提供了基于 Token 的分割和基于字符的分割，够用但不算丰富。
AgentScope 和 Embabel 在文档处理这块不是重点，它们更关注 Agent 编排和领域建模，RAG 能力需要依赖外部组件或自己实现。
我的实际经验是：如果你的 RAG 场景涉及多种文档格式，LangChain4j 能省不少事。如果只是处理 Markdown 或纯文本，Spring AI 完全够用。
3.2 检索策略：向量检索之外的选项
向量检索是 RAG 的基础，但实际项目中往往需要更复杂的检索策略。
Spring AI 的VectorStore接口支持相似度检索和 MMR（最大边际相关性）检索。MMR 的作用是增加结果的多样性，避免返回一堆高度相似的文档。这个在 Spring AI 里是内置支持的。
LangChain4j 的ContentRetriever除了向量检索，还支持全文检索（基于 Lucene）、混合检索（向量+全文）、以及 Web 搜索。EmbeddingStoreContentRetriever可以配置maxResults、minScore、动态过滤条件等参数。
AgentScope 2.0 提出了 “RAG as a Service” 的概念，把 RAG 能力封装成独立的服务，Agent 通过调用服务来获取知识。这种架构在多 Agent 场景下更清晰，但需要额外的服务部署。
提示：检索策略的选择不是越复杂越好。我见过不少项目一上来就上混合检索+重排序，结果效果还不如简单的向量检索。建议先用最基础的向量检索跑通，再根据实际 bad case 逐步优化。
3.3 重排序与检索质量优化
重排序（Re-ranking）是提升 RAG 质量的关键手段。基本思路是：先用向量检索召回一批候选文档（比如 20 条），再用重排序模型精排，取 Top 5 送给大模型。
LangChain4j 提供了ReRankingContentAggregator，可以接入 Cohere Rerank、BGE Rerank 等重排序模型。Spring AI 目前没有内置重排序组件，需要自己实现 Advisor 或后置处理。
除了重排序，检索质量优化还有几个常用手段：
- 查询改写：把用户的口语化问题改写成更适合检索的形式
- 多查询检索：生成多个相关查询，分别检索后合并结果
- 父子文档检索：用小块检索，返回大块上下文
- 元数据过滤：根据文档的元数据（如时间、来源、类型）缩小检索范围
这些手段在 LangChain4j 里大多有对应组件或示例，Spring AI 需要更多自己动手。但自己动手不一定是坏事——自己实现的逻辑更可控，出问题也更容易排查。
3.4 RAG 评估：怎么知道你的 RAG 好不好
RAG 评估是很多项目忽略的环节。你调了半天参数，怎么知道效果真的变好了？靠感觉是不行的。
目前 Java 生态里 RAG 评估工具比较少，DeepEval 主要是 Python 的。Java 项目做评估，通常有几个选择：
- 自己构建评估集：准备一批问题和标准答案，用脚本跑检索和生成，计算命中率、准确率等指标
- 用 LLM 做评估：让大模型给生成结果打分，虽然不完全可靠，但比人工快
- 接入 Python 评估工具：通过 HTTP 接口调用 DeepEval 等工具
我的做法是：项目初期就建立一个小规模的评估集（50-100 条），每次调整检索策略或 Prompt 后跑一遍，看指标变化。这个习惯能帮你避免“改了半天反而变差了”的情况。
| 能力维度 | Spring AI | LangChain4j | AgentScope | Embabel |
|---|---|---|---|---|
| 文档加载器数量 | 中 | 多 | 少 | 少 |
| 分割策略 | 基础 | 丰富 | 基础 | 基础 |
| 向量存储支持 | 多 | 多 | 依赖外部 | 依赖外部 |
| 混合检索 | 不支持 | 支持 | 服务化 | 不支持 |
| 重排序 | 需自实现 | 内置支持 | 服务化 | 不支持 |
| 评估工具 | 无 | 无 | 无 | 无 |
这张表反映了一个现实：Java 生态的 RAG 工具链整体还不如 Python 成熟，四个框架各有短板。选型时要根据你的具体场景来权衡，没有全能选手。
4. Agent 能力对比：从单 Agent 到多 Agent 协作
Agent 是 2024 年以来最热的方向，四个框架在 Agent 能力上的差异比 RAG 更大。有的框架把 Agent 当核心，有的只是附带功能。
4.1 单 Agent 的工具调用与 ReAct 模式
单 Agent 的核心能力是工具调用和推理-行动循环（ReAct）。
Spring AI 的工具调用通过@Tool注解或FunctionCallback实现：
public class WeatherService { @Tool(description = "查询指定城市的天气") public String getWeather(String city) { // 调用天气 API return "晴，25度"; } } ChatClient chatClient = builder .defaultTools(new WeatherService()) .build();Spring AI 会自动把@Tool标注的方法转成模型可调用的函数。ReAct 循环需要自己实现，或者用 Advisor 来编排。
LangChain4j 的工具调用类似，用@Tool注解：
interface Assistant { @SystemMessage("你可以查询天气") String chat(@UserMessage String message); } Assistant assistant = AiServices.builder(Assistant.class) .chatLanguageModel(model) .tools(new WeatherService()) .build();LangChain4j 内置了 ReAct 模式的实现，AiServices会自动处理“模型请求调用工具 -> 执行工具 -> 把结果返回给模型”的循环。
AgentScope 的 Agent 本身就是 ReAct 模式，ReActAgent内置了推理-行动循环，你只需要注册工具：
ReActAgent agent = ReActAgent.builder() .name("assistant") .model(model) .tools(tools) .maxIterations(10) .build();Embabel 的工具调用是通过@Action方法实现的，框架根据 Goal 自动规划调用哪些 Action。
从开发体验看，AgentScope 的 ReAct 支持最完整，参数配置也最丰富（最大迭代次数、超时、错误处理等）。Spring AI 和 LangChain4j 的工具调用够用，但 ReAct 循环的控制粒度不如 AgentScope。
4.2 多 Agent 协作：AgentScope 的主场
多 Agent 协作是 AgentScope 的核心竞争力。它提供了几种编排模式：
SequentialPipeline：顺序执行，前一个 Agent 的输出作为后一个的输入。适合“规划-执行-审核”这类线性流程。
FanoutPipeline：并行执行多个 Agent，然后合并结果。适合“多个专家同时分析，最后汇总”的场景。
Msghub：消息中心模式，Agent 之间通过消息广播通信。适合需要动态协商、角色不固定的场景。
Msghub msghub = Msghub.builder() .participants(List.of(agent1, agent2, agent3)) .build(); msghub.broadcast(Msg.builder().content("开始讨论").build());Spring AI 和 LangChain4j 没有内置的多 Agent 编排能力，需要自己用代码组织。比如你可以用 Spring 的@Async做并行调用，用CompletableFuture做结果合并，但这些都是通用编程能力，不是框架提供的 Agent 编排抽象。
Embabel 的多 Agent 能力体现在它的 Goal-Action 规划上——多个 Action 可以由不同的 Agent 执行，框架自动协调。但这种协调是隐式的，不如 AgentScope 的 Pipeline 直观。
4.3 记忆管理与上下文控制
Agent 的记忆管理直接影响多轮对话的质量。四个框架都提供了对话记忆的支持，但实现方式不同。
Spring AI 的ChatMemory接口支持内存、JDBC、Redis 等实现。你可以配置记忆窗口大小（保留最近 N 轮对话），也可以自定义记忆策略。
LangChain4j 的ChatMemory类似，支持MessageWindowChatMemory（按消息数）、TokenWindowChatMemory（按 Token 数）等策略。
AgentScope 的记忆管理更细粒度，每个 Agent 可以有自己的记忆，也可以共享记忆。Msg对象里可以携带元数据，方便 Agent 之间传递上下文。
Embabel 的记忆管理依托于领域模型，状态保存在领域对象里，框架根据 Goal 的依赖关系自动管理上下文。
注意：记忆窗口不是越大越好。我见过把窗口设成 50 轮对话的，结果 Token 消耗巨大，而且模型容易被早期无关信息干扰。一般 10-20 轮足够，具体看场景。
4.4 可观测性与调试：生产环境的关键
Agent 应用上生产，可观测性是绕不开的。你需要知道：每次请求调了哪些工具、花了多少 Token、耗时多少、哪一步出了问题。
Spring AI 通过 Micrometer 提供指标采集，可以接入 Prometheus、Grafana。Advisor 机制也方便插入日志。
LangChain4j 提供了ChatModelListener接口，可以监听请求和响应，记录日志和指标。
AgentScope 2.0 在可观测性上做了增强，支持 OpenTelemetry 标准，可以追踪 Agent 之间的消息流和执行链路。
Embabel 目前可观测性支持较弱，基本靠自己打日志。
这块我的经验是：不管用哪个框架，都要在项目初期就把日志和指标埋好。Agent 应用的调试比普通应用复杂得多，出了问题没有日志基本没法排查。
5. 选型决策：不同场景下我的真实选择
讲了这么多对比，最后落到实际选型上。我按几个典型场景来说说我的选择逻辑，以及为什么。
5.1 传统 Spring Boot 项目接入 AI 能力
如果你的项目是标准的 Spring Boot 应用，团队熟悉 Spring 生态，需求是“加个 AI 问答”或“做个 RAG 知识库”，Spring AI 是首选。
理由很简单：集成成本最低。加个 Starter 依赖，配几个参数，注入ChatClient就能用。Advisor 机制让 RAG 的接入非常干净，不需要改业务代码结构。团队不需要学新东西，Spring 的那套东西直接复用。
但要注意：Spring AI 的版本迭代也比较快，从 0.x 到 1.0 有不少 API 变动。建议锁定版本，升级前先看 Release Notes。
5.2 需要丰富 RAG 组件的项目
如果你的 RAG 场景比较复杂——多种文档格式、需要混合检索、需要重排序、需要查询改写——LangChain4j 更合适。
它的组件链更完整，很多功能开箱即用。AiServices的声明式接口写起来也舒服。代价是 API 风格不太统一，文档需要花时间梳理。
我的建议是：用 LangChain4j 做 RAG 核心链路，用 Spring Boot 做应用框架。两者不冲突，LangChain4j 可以作为一个库引入 Spring Boot 项目。
5.3 多 Agent 协作场景
如果你要做的是多 Agent 协作——比如“规划 Agent + 执行 Agent + 审核 Agent”的流程，或者需要多个角色动态协商——AgentScope 是目前 Java 生态里最合适的选择。
它的 Pipeline 编排、Msghub 通信、Agent 生命周期管理都是为多 Agent 场景设计的。虽然 Java 版还不如 Python 版成熟，但基础能力已经可用。
如果团队以 Python 为主，那直接用 AgentScope Python 版更省事。Java 版适合那些“必须用 Java”的场景。
5.4 复杂业务规则的 Agent 场景
如果你的业务规则特别多、状态特别复杂，传统的流程编排写起来很痛苦，Embabel 的领域建模思路值得研究。
它的 Goal-Action 自动规划能减少大量编排代码，领域模型也让业务逻辑更清晰。但现阶段生态太早期，不建议上生产。可以拿它做原型验证，或者关注它的演进，等成熟了再考虑。
5.5 混合使用的可能性
实际项目中，四个框架不是非此即彼的关系。我做过的一个项目就是：Spring Boot 做应用框架 + LangChain4j 做 RAG + AgentScope 做多 Agent 编排。三者通过接口解耦，各司其职。
这种混合方案的好处是取长补短，坏处是增加了依赖复杂度和维护成本。是否值得，取决于你的项目规模和团队能力。小项目建议选一个主框架，大项目可以考虑混合。
| 场景 | 推荐框架 | 核心理由 |
|---|---|---|
| Spring Boot 快速接入 | Spring AI | 集成成本最低，生态最顺 |
| 复杂 RAG 链路 | LangChain4j | 组件丰富，检索策略灵活 |
| 多 Agent 协作 | AgentScope | 编排能力强，消息机制完善 |
| DDD 驱动 Agent | Embabel | 思路独特，但生态早期 |
| 混合方案 | 按需组合 | 取长补短，但复杂度高 |
6. 迁移与升级：换框架的代价有多大
选型时还有一个容易被忽略的问题：如果以后想换框架，代价有多大？这个问题在项目初期不重要，但项目做大了就是大事。
6.1 抽象层设计：让业务代码与框架解耦
不管你选哪个框架，我都强烈建议在业务代码和框架之间加一层自己的抽象。比如定义一个AiService接口，Spring AI 和 LangChain4j 各写一个实现。这样换框架时只需要换实现，业务代码不动。
public interface AiService { String chat(String message); String ragChat(String question, String knowledgeBaseId); } // Spring AI 实现 @Service public class SpringAiService implements AiService { private final ChatClient chatClient; // ... } // LangChain4j 实现 @Service public class LangChain4jService implements AiService { private final Assistant assistant; // ... }这层抽象会增加一些代码量，但换来的是框架无关性。我在一个项目里从 Spring AI 换到 LangChain4j，因为有这层抽象，业务代码一行没改，只换了实现类。
6.2 数据迁移：向量库和记忆的坑
换框架时，向量库里的数据通常可以复用（因为向量库是独立的），但记忆数据（对话历史）的格式可能不同，需要转换。
Spring AI 的ChatMemory和 LangChain4j 的ChatMemory存储格式不一样，迁移时需要写转换逻辑。如果记忆存在数据库里，还要考虑表结构的变化。
我的建议是：记忆数据尽量用通用的格式存储（比如 JSON），这样换框架时转换成本最低。
6.3 Prompt 模板的兼容性
不同框架的 Prompt 模板语法可能不同。Spring AI 用的是PromptTemplate，LangChain4j 用的是@SystemMessage注解或PromptTemplate。简单的模板可以通用，复杂的模板（带条件、循环）需要重写。
这块没有太好的办法，只能尽量把 Prompt 逻辑集中管理，换框架时统一调整。
7. 一些踩坑经验和实用建议
最后分享一些我在实际项目中踩过的坑和总结的经验，这些在官方文档里通常看不到。
7.1 模型调用的超时和重试
不管用哪个框架，模型调用都要配超时和重试。大模型 API 偶尔会慢或者失败，没有超时控制会拖垮整个服务。
Spring AI 可以在ChatClient构建时配置超时，LangChain4j 在模型配置里设置。重试建议用 Spring Retry 或 Resilience4j，不要自己写循环。
提示：重试次数不要太多，2-3 次足够。重试太多次会放大延迟，用户体验更差。
7.2 Token 消耗的监控
Token 消耗直接关系到成本，必须监控。Spring AI 和 LangChain4j 都提供了 Token 使用量的获取接口，建议在每次调用后记录到日志或指标系统。
我见过一个项目因为没监控 Token，一个月账单超预算好几倍。后来加了监控和告警，才发现是某个 Prompt 模板写得太啰嗦，每次调用都消耗大量 Token。
7.3 流式输出的处理
流式输出（Streaming）能显著提升用户体验，但处理起来比同步调用复杂。Spring AI 的stream()方法返回Flux<String>，LangChain4j 返回TokenStream。两者都需要处理背压、错误、取消等情况。
我的经验是：流式输出适合聊天场景，不适合需要完整结果的场景（比如生成结构化数据）。用之前先想清楚是否真的需要。
7.4 本地模型 vs 云服务
四个框架都支持本地模型（通过 Ollama 等）和云服务。本地模型的优势是数据不出内网、成本可控，劣势是效果通常不如云服务的大模型。
我的建议是：开发测试用本地模型，生产环境根据数据敏感性和效果要求选择。如果数据敏感，本地模型是必须的；如果追求效果，云服务更合适。
7.5 版本锁定与升级策略
四个框架都在快速迭代，版本升级是常态。我的策略是：
- 生产项目锁定版本，不轻易升级
- 升级前先在测试环境验证，跑一遍核心用例
- 关注 Release Notes 的 breaking change，提前评估影响
- 小版本可以跟，大版本谨慎
LangChain4j 的 breaking change 相对多一些，Spring AI 在 1.0 之后稳定了不少。AgentScope 和 Embabel 还在早期，API 变动更频繁。
7.6 团队能力匹配
最后一点，也是最重要的：选框架要考虑团队能力。Spring AI 对 Spring 团队最友好，LangChain4j 需要花时间熟悉它的 API 风格，AgentScope 需要理解多 Agent 的概念，Embabel 需要 DDD 基础。
选一个团队能驾驭的框架，比选一个“理论上最好”的框架更重要。我见过团队硬上 AgentScope 结果多 Agent 编排写不明白，最后退回单 Agent 方案的案例。
我个人在实际项目中的体会是：没有最好的框架，只有最适合当前场景和团队的框架。Spring AI 和 LangChain4j 是目前 Java 生态里最稳妥的选择，AgentScope 在多 Agent 场景有独特价值，Embabel 值得关注但别急着上生产。选型时多想想“我的场景是什么、团队会什么、以后怎么维护”，比看功能对比表有用得多。
