Java 转 Agent 开发之路（十）：框架选型的分层判断——Spring AI / LangChain4j / SAA /

第八篇拆解了 SAA Graph 的工程代价，第九篇拆解了 LangGraph4j 的状态机语义。两篇都指向同一个结论：这些框架不在同一层，放在一张表里比“谁更强”，方法论本身就是错的。一个框架的“优势”在另一层可能是纯粹的开销，一个框架的“缺失”在另一层可能根本不该由它来补。

这一篇是系列的缓冲篇，不引入新的模块，不做代码堆砌，只做一件事：给出一条可操作的选型判断路径。核心判断先放在前面：Java AI 框架已经形成了三层台阶——模型接入层、编排规划层、运行时底座。选型的第一步不是问“哪个框架最好”，而是问“我的需求落在哪一层”。而无论选哪一层，留痕、成本、评测这三件事，框架都不会替你做完。

一、三层台阶：先确认你的问题在哪一层

把 Java AI 框架按“解决的问题”而不是“功能清单”来分类，分层是清晰的。

第一层：模型接入层。 解决的问题是“调用不同 LLM 提供商而不重写代码”。这一层最成熟，Spring AI 支持 20+ 提供商并通过 auto-configuration 简化配置，LangChain4j 提供 20+ 模型和 30+ 向量库的统一 API。如果你只需要从 Java 调用模型、做一些简单的工具调用和 RAG，这一层就够了。

第二层：编排规划层。 解决的问题是“协调多步骤、多智能体的工作流”——规划、工具使用、反馈循环、状态管理。Spring AI Alibaba 的 Graph Core 和 Agent Framework、LangGraph4j 的状态机、Embabel 的确定性规划，都在这一层。当单 Agent 的上下文和工具集开始互相干扰，或者任务需要断点恢复、条件分支、人机循环时，需求才真正跨到了这一层。

第三层：运行时底座。 解决的问题是“Agent 工作流在生产环境中的耐久性”——崩溃恢复、审计追踪、事件溯源状态、分布式部署。这一层目前最不成熟。AgentScope Java 定位为“企业级分布式 Agent”，是这一层的候选，但它的抽象程度和生态成熟度都还在演进中。

一个务实的判断是：绝大多数 Java 团队的需求落在第一层到第二层之间，真正需要第三层的场景远少于“多 Agent”这个词带来的焦虑。 一个客服系统加订单查询和工具调用，第一层足够；一个退款流程需要多步骤编排和人工审批，第二层才有意义；只有当你需要跨进程的 Agent 注册、独立扩缩容、崩溃后精确恢复执行位置时，第三层才进入视野。

二、第一层的两个选项：Spring AI 和 LangChain4j 不是替代关系

Spring AI 和 LangChain4j 经常被放在一起比较，但它们的设计重心不同，选择取决于你更看重什么。

Spring AI 的核心优势是“集成效率”和 Spring Boot 原生体验。 ChatClient、Advisor 链、@Tool 注解、自动配置——如果你已经在 Spring 技术栈上，Spring AI 的接入成本是最低的。第六篇讨论的 Advisor 顺序、递归循环、UsageAccumulator，都是 Spring AI 在这一层的具体能力。MCP 支持方面，Spring AI 2.0 的 @McpTool 注解可以用几十行代码暴露一组工具，是当前 Java 侧最顺手的 MCP Server 实现方式之一。

LangChain4j 的核心优势是“场景覆盖广度”。 30+ 模型开箱即用，向量库覆盖最广，AiService 的声明式接口把模型调用、工具编排和记忆管理绑定到接口方法上，开发体验非常干净。它的定位是“框架中立”——可以集成 Spring Boot，也可以集成 Quarkus、Helidon、Micronaut。如果你的团队不是纯 Spring 栈，或者需要对接大量不同供应商的模型和向量库，LangChain4j 的覆盖面是更稳妥的选择。

但两者的边界需要说清楚：Spring AI 和 LangChain4j 在“模型接入 + 基础工具调用 + 基础 RAG”这个层面的能力高度重叠。差异不在“能不能做”，在“以什么方式做”。Spring AI 更像“Spring 生态里的 AI 抽象层”，LangChain4j 更像“JVM 上的 AI 工具箱”。如果你的团队已经在 Spring 上，Spring AI 是自然的默认选择；如果你需要跨框架、跨供应商的最大灵活性，LangChain4j 更合适。 不存在“Spring AI 比 LangChain4j 更强”或反过来，只有“你的技术栈和场景更贴近哪一边”。

三、第二层的分化：SAA、LangGraph4j、Embabel 解决的不是同一个问题

第二层的框架经常被统称为“编排框架”，但它们在控制流语义上有本质差异。

Spring AI Alibaba 是把 Agent 装配线分了层，不是“一个更全的 SDK”。 它的定位是“企业级多智能体与工作流”，核心价值在于 Graph Core 的状态管理、ReactAgent/SupervisorAgent 的多 Agent 协作模式、以及 Agent Skills 的渐进式加载。它的代价也是分层本身：每引入一层，就多一个需要理解的配置面和版本对齐点。当你只需要单轮问答时，这套分层是纯粹的开销；只有当你需要长运行状态、可中断、多 Agent 协作时，它才开始回本。

LangGraph4j 的定位更窄：它只管“图和状态”，不绑定模型接入，不提供工具调用循环，不管理记忆。 它同时支持 Spring AI 和 LangChain4j，核心能力集中在有状态的流程编排上。第九篇讨论的 interruptBefore、InterruptableAction、子图中断和检查点恢复，是它的核心价值。如果你已经有了一个单 Agent 运行时，需要把多个 Agent 按有状态的流程组织起来，LangGraph4j 是比在 ChatClient 外面手写 while 循环更干净的承载层。

Embabel 走的是另一条路：确定性规划。 它采用 GOAP（Goal-Oriented Action Planning），强调“可解释可审计”——规划逻辑不是由 LLM 自由生成的，而是在框架层面有明确的搜索和选择机制。这适合那些对“为什么走了这条路径”有强审计要求的场景，但代价是灵活性下降：不是所有任务都适合被表达成 GOAP 的目标-动作模型。

这一层的选型判断可以收束为一句话：如果你需要“多 Agent 协作 + 可视化 + 中文生态”，SAA 是完整度最高的选项；如果你需要“框架无关的状态机 + HITL + 断点恢复”，LangGraph4j 更纯粹；如果你需要“确定性规划 + 可审计路径”，Embabel 值得评估。三者不是互斥的——SAA 的 Graph 和 LangGraph4j 在抽象层上重叠，选一个即可，不要在同一套系统里同时启用两套图编排。

四、一个被低估的工程维度：同步阻塞调用与虚拟线程

框架选型中最容易被忽略、但对生产环境影响最大的一个维度，是并发模型。

Agent 的每一次工具调用、每一次模型请求、每一次 MCP 远程调用，本质上都是 I/O 密集型操作。一个 AI Agent 99% 的时间在等待：等待模型决定调哪个工具、等待网络、等待 MCP Server 返回数据。如果用传统的平台线程池来处理这种阻塞调用，几千个并发 Agent 会话就会在模型生成第一个 token 之前耗尽服务器内存。

Java 21 的虚拟线程正是为这种场景设计的。Spring Boot 3.2+ 可以通过一行配置启用：

spring.threads.virtual.enabled=true

启用后，Tomcat 的线程池会被替换为虚拟线程，每一次阻塞的 HTTP 或 gRPC 调用发生时，JVM 会卸载虚拟线程并释放底层平台线程，让平台线程继续服务其他请求。你仍然可以写直截了当的顺序代码，不需要为了异步而引入复杂的响应式管道。

这对框架选型的含义是：同步阻塞的 API 设计不再是一个必须被“优化掉”的缺陷。Spring AI 的 ChatClient.call()、LangChain4j 的同步 AiService、SAA 的同步 ReactAgent.call()，在虚拟线程的承载下都可以支撑高并发。第八篇提到的 AgentTool 同步阻塞问题，在虚拟线程的上下文中，其严重性从“架构级缺陷”降级为“需要确保虚拟线程启用”。选型时不需要因为“某个框架的 API 是同步的”而直接排除它，但必须确认你的运行时环境（Java 版本、Spring Boot 版本、线程池配置）已经正确启用了虚拟线程。

五、选型路径：四步判断，从技术栈到留痕

把上面的分层和维度收束成一个可操作的选型路径。

第一步，确认技术栈。 纯 Spring Boot 团队，Spring AI 是默认起点；非 Spring 的 JVM 团队（Quarkus、Helidon、纯 Java），LangChain4j 的框架中立性是更自然的选择。如果团队已经在 LangChain4j 或 AgentScope 上有沉淀，硬切到 Spring AI 只是“换了个壳”，收益有限。

第二步，按“需求台阶”定档。 单次问答 + 基础工具调用 → 第一层，Spring AI 或 LangChain4j 足够。多步骤工作流 + 条件分支 + 人工审批 → 第二层，SAA Graph 或 LangGraph4j。需要跨进程分布式 Agent、独立扩缩容、精确崩溃恢复 → 第三层，评估 AgentScope Java 或基于 SAA Graph 自建运行时。

第三步，确认并发模型。 Java 21+ 且启用虚拟线程，则同步 API 可以放心使用；Java 17 且无法升级，则需要评估响应式方案或限制并发规模。这一步不是框架选型的附属品，它决定了你在前两步选出的框架能否在生产环境中撑住。

第四步，也是最容易被跳过的一步：列出框架不提供的东西。 无论选哪一层，以下三件事都需要在框架之上自己补：

• 留痕：谁在什么时间调用了哪个 Agent、路由经过了哪些节点、工具的入参和出参是什么。SAA 的 OverAllState 是状态快照，不是执行轨迹；LangGraph4j 的检查点是恢复位置，不是审计日志。轨迹需要通过 Listener 或自定义埋点来捕获。
• 成本：每一次模型调用、每一次递归循环迭代消耗了多少 Token。框架可能提供 UsageAccumulator（Spring AI）或 Micrometer 指标，但按租户、按 Agent、按工具维度的归因需要自己注入标签。第六篇讨论过的 Token 乘法效应，不会因为换了一个框架就消失。
• 评测：轨迹断言（工具调用序列、路由分支、终止原因）和终答质量评估的分层。框架不提供评测流水线，Mock 的边界需要自己定在 HTTP 层，LLM-as-judge 的弱信号定位需要自己守住。

框架给你的是“能不能跑起来”，你要自己补的是“能不能交代清楚” 。这两件事不在同一层，也没有哪个框架会替你做完第二件。

六、收束：选型的终点，是承认框架的边界

这一篇从三层台阶讲到两层分化，再到虚拟线程和选型路径，核心可以收束为三个判断。

第一，Java AI 框架已经形成了清晰的分层，跨层比较没有意义。 Spring AI 和 LangChain4j 是模型接入层的两种风格，SAA 和 LangGraph4j 是编排规划层的两种路径，AgentScope Java 是运行时底座的早期探索。先确认自己的需求落在哪一层，再比较同层的选项。

第二，“分层是代价”这句话需要被认真对待。 SAA 的 Graph 和 Agent Framework 在多 Agent 协作场景下才回本；LangGraph4j 的状态机语义在你需要 HITL 和断点恢复时才产生价值。如果需求没有跨过那条线，更轻的选项不是“功能更少”，是更少的抽象负担和更短的故障排查路径。

第三，虚拟线程把“同步 API”从选型扣分项变成了需要确认的运行时条件。 Agent 的 I/O 密集本质决定了并发模型是生产落地的硬约束，但它不应该成为排除某个框架的理由，而应该成为部署清单上的一个检查项。