引子：一个后端团队的框架选型困局你所在的Java后端团队接到一个需求：给现有的Spring Boot微服务集群加一个“智能运维助手”——它能查询服务健康状态、分析异常日志、执行简单的运维操作（重启服务、扩容、回滚部署），并且需要支持多步骤的运维工作流，比如“检测到服务异常→拉取日志→分析根因→如果确定是内存泄漏则重启→否则通知值班工程师”。你打开技术选型文档，发现Java生态中至少有九个AI框架、三个协议标准在2026年同时活跃。Spring AI、LangChain4j、LangGraph4j——名字看起来都差不多，但团队里没人说得清楚它们的区别。一个成员说：“Spring AI是Spring官方的，肯定选它。”另一个成员反驳：“LangChain4j生态更全，支持30+模型。”第三个成员问：“那LangGraph4j是什么？它跟前面两个是竞争关系吗？”这场争论的核心问题，在本文里会有一个清晰的答案。Java AI Agent生态的混乱，根源在于把不同层次的框架放在了同一个选择维度上。一旦你理解了它们各自占据的“栈层”位置，选型就不再是“选哪个”，而是“怎么组合”。一、三层栈：Java AI Agent框架的定位地图当前Java AI Agent框架的混乱，可以用一个三层栈来澄清。JamJet团队在一篇系统性分析中指出，大多数关于JVM AI框架的困惑来自“混淆了三个不同的层”。第一层：模型抽象层——解决“怎么调用大模型”这一层解决的问题最基础：让你的业务代码不绑定任何一家模型供应商。你写一段代码调用ChatClient，底层可以是OpenAI、Anthropic、通义千问、DeepSeek，切换模型只需要改配置。这一层是JVM生态最成熟的层。Spring AI和LangChain4j都支持20+模型供应商的统一API。如果你只需要从Java调用Claude、GPT-4或Gemini并处理响应，Spring AI或LangChain4j可以让你在几分钟内跑通。Java视角：这一层本质上是一个适配器模式——和JDBC屏蔽不同数据库差异、SLF4J屏蔽不同日志框架差异的设计思路完全一致。第二层：Agent编排层——解决“怎么协调多步骤、多Agent的工作流”这一层解决的问题比模型抽象复杂得多：规划、工具使用、反馈循环、状态管理、持久化检查点。LangGraph4j在这一层的地位最关键。它引入了循环图（cyclical graphs）和持久化检查点——这两个能力是Agent工作流区别于普通链式调用的核心。没有循环，Agent无法“执行→观察→修正”；没有检查点，长任务中断后无法恢复。LangChain4j的langchain4j-agentic模块也提供Agent编排能力，通过@Agent注解和Supervisor-Worker模式支持多Agent协作。但LangGraph4j在这一层做得更深——它把Agent工作流建模为状态图，节点是计算单元，边是路由逻辑，状态是贯穿全图的共享内存。Java视角：这一层本质上是一个工作流引擎——和Camunda/Activiti的建模思路同构。节点≈Service Task，边≈Sequence Flow，状态≈Process Variable。区别在于，路由决策是模型实时做出的，而非预定义规则。第三层：生产运行时层——解决“怎么让Agent在生产环境可靠运行”这一层解决的问题最容易被忽视：崩溃恢复、审计追踪、事件溯源状态、可观测性。JamJet团队指出，JVM AI生态目前最大的缺口正是在这一层。已有的框架在模型抽象和Agent编排上做得不错，但“让它跑起来”和“让它可靠地跑起来”之间有巨大的鸿沟。这一层的典型需求包括：Agent在执行第30步时崩溃，重启后能否从第29步的检查点恢复？Agent修改了生产环境的配置，有没有完整的审计日志？Agent的Token消耗和延迟，有没有可观测的指标？Spring AI 1.1在这一层开始布局。它通过Micrometer提供了可观测性集成，通过ChatMemory的持久化存储支持状态恢复。LangChain4j 1.10新增了Agentic observability and monitoring支持。但整体而言，这一层仍是JVM生态最薄弱的部分——大多数框架的“生产就绪”还停留在文档层面。二、三个框架的定位差异：一张表看清本质理解了三层栈之后，三个框架的定位就非常清晰了：维度Spring AILangChain4jLangGraph4j核心定位Spring生态的AI工程框架JVM上的LLM应用开发工具箱有状态多Agent编排引擎优化方向Spring生态集成、自动配置广度与灵活性状态图、循环、检查点核心优势20+模型供应商、MCP原生支持庞大的供应商生态、RAG、工具调用循环图、反馈回路、持久化检查点权衡复杂Agent工作流支持较弱比Spring多样板代码较新，受Python LangGraph启发当前版本1.1.0 GA（2025年11月）1.11.0（2026年2月）1.8.1Spring AI的定位是“Spring生态里的AI工程框架”——它不是要发明新奇的AI玩法，而是把AI能力“Spring化”，让习惯了Spring Boot的开发者以最低学习成本把大模型接进现有微服务。它的核心优势是自动配置、依赖注入和MCP原生集成。Spring AI 1.1被称为“MCP集成是Spring AI 1.1最重要的功能集改进”，提供了完整的Spring Boot自动配置和基于注解的编程模型（@McpTool、@McpResource、@McpPrompt）。LangChain4j的定位是“JVM上的LLM应用开发工具箱”。它提供AiServices、ChatModel、EmbeddingStore、ContentRetriever、Memory、Tool等能力，开发者可以较快组合出RAG、智能体、工具调用和对话应用。它的核心优势是集成广度——支持30+模型供应商、覆盖最广的向量库。通过@Tool注解，任何Java方法可以被自动转换为工具供LLM调用。LangGraph4j的定位是“有状态多Agent编排引擎”。它框架无关——可以与LangChain4j或Spring AI任意搭配使用，专注于“图”本身的编排能力。它的核心抽象是StateGraph：用户定义State对象，添加节点和边，编译后执行。LangGraph4j的核心价值在于循环和检查点——这两个能力让它能够表达“执行→观察→修正→再执行”的Agent循环，以及“中断后从检查点恢复”的长任务能力。Java视角：三个框架的关系不是竞争，而是分层协作。Spring AI和LangChain4j解决“怎么调用模型”（第一层），LangGraph4j解决“怎么编排Agent”（第二层）。你可以在Spring Boot应用中用Spring AI的ChatClient调用模型，用LangChain4j的@Tool定义工具，用LangGraph4j的StateGraph编排多Agent工作流。这不是“选一个”的问题，而是“各司其职”的问题。三、实战：一个多Agent招聘工作流理论讲完了，用一个真实的项目案例来展示三个框架如何协作。这个案例来自DEV Community上的一篇实战文章，作者用Spring Boot + LangChain4j + LangGraph4j构建了一个多Agent招聘工作流。工作流设计招聘场景的需求很明确：一份候选人简历进来，需要从技能匹配、经验匹配、文化契合度、风险信号四个维度独立评分，然后汇总评分做出路由决策（自动通过、自动拒绝、或转人工审核）。这个工作流需要的三样东西，普通的链式LLM调用给不了：并行运行的独立Agent、等待人类介入并在之后恢复的中断点、每一步的持久化记录。这正是作者选择LangGraph4j的StateGraph而非简单串联LangChain4j调用的原因。图的拓扑结构parseResumeNode从原始简历文本中提取结构化数据。如果解析失败，直接短路到人工审核——不需要对四个评分Agent空转。否则，图扇出（fan out）到四个独立的Agent，每个Agent从不同维度评估候选人。aggregateScoresNode用加权公式汇总四个评分，任何不是“干净地自动通过或自动拒绝”的结果都落入humanReview中断。人工可以批准、拒绝或要求定向重新分析，重新分析会循环回到审核阶段，直到做出最终决定。LangChain4j的AiServices：每个Agent就是一个Java接口这个案例中最优雅的部分是Agent的定义。每个评分Agent就是一个纯Java接口——没有客户端样板代码，没有手动JSON解析。publicinterfaceSkillsAgent{@UserMessage(""" Candidate ID: {{candidateId}} Job Requisition ID: {{requisitionId}} Use the available tools to fetch the job requisition and the candidate. Assess how well the candidate's skills match the requisition's required skills. Score 0-100. Flag any required skill that's missing. Recommend ADVANCE, CAP, or REJECT. """)AgentScoreResultanalyzeSkills(@V("candidateId")longcandidateId,@V("requisitionId")longrequisitionId);}AgentScoreResult是一个普通的Java record——包含score、flags、recommendation三个字段。LangChain4j自动处理了“让模型填充这个record并解析回Java对象”的所有细节。工具的接入同样低摩擦：AiServices.builder(SkillsAgent.class).chatModel(...).tools(jobRequisitionTool, ...)。Java视角：LangChain4j的AiServices本质上是一个动态代理——你定义一个接口，框架在运行时生成实现类，把方法调用转换为LLM请求，把响应解析回Java对象。这和MyBatis的Mapper接口设计思路完全一致：你定义接口，框架处理SQL和对象映射的细节。LangGraph4j的StateGraph：把工作流画成图LangGraph4j的核心抽象是StateGraph。构建图的过程分三步：定义状态、添加节点和边、编译。// 1. 定义状态publicclassHiringStateextendsAgentState{publicstaticfinalStringMESSAGES_KEY="messages";// ... 其他字段}// 2. 构建图vargraph=newStateGraph<>(HiringState.SCHEMA,HiringState::new).addNode("parseResume",parseResumeNode).addNode("skillsAgent",skillsAgentNode).addNode("experienceAgent",experienceAgentNode)// ... 其他节点.addEdge("parseResume","skillsAgent")// 扇出到四个并行Agent.addEdge("parseResume","experienceAgent").addConditionalEdges("aggregateScores",routingFunction)// ....compile();这个案例使用了Postgres checkpointer来持久化状态。这意味着如果工作流在人工审核阶段中断（等待审批），服务重启后可以从检查点恢复，不需要重新执行前面的Agent。Java视角：LangGraph4j的StateGraph和Java的**CompletableFuture编排**有结构上的相似性。addEdge相当于thenApply/thenCompose，addConditionalEdges相当于thenCompose中的条件分支，checkpointer相当于把中间状态持久化到数据库。区别在于，LangGraph4j的图是可序列化和可恢复的，而CompletableFuture的编排状态在JVM内存中。四、选型决策：你该从哪个框架开始理解了三个框架的定位和协作方式之后，选型决策可以归结为三个问题：✅ 是❌ 否🔁 需要➖ 不需要📗 低📕 高① 项目是 Spring Boot？② 是否需要循环、中断恢复长任务？③ 团队可接受的学习成本？🌱 起点：Spring AI🧠 起点：LangChain4j🔗 引入 LangGraph4j编排层🧩 只用单层模型抽象框架无需 LangGraph4j✅ 优先 Spring AI+ 简单 Advisor 链🚀 Spring AI + LangChain4j+ LangGraph4j 完整组合问题一：你的项目是不是Spring Boot？是→ Spring AI是你的自然起点。它的自动配置、依赖注入和MCP原生支持，让你可以用最少的代码把AI能力融入现有Spring应用。Spring AI 1.1的MCP集成让“把Spring Boot服务暴露为Agent可调用的工具”变得几乎零成本。不是→ LangChain4j是更轻量的选择。它没有Spring的框架绑定，可以在任何Java应用中使用。如果你在做Quarkus、Vert.x或纯Java SE项目，LangChain4j的AiServices和@Tool注解提供了同样流畅的开发体验。问题二：你的Agent工作流需要循环和中断恢复吗？需要→ LangGraph4j是当前Java生态中唯一提供完整循环图+持久化检查点的框架。如果你的工作流包含“执行→验证→修正”的循环，或者需要在人工审核处中断并在之后恢复，LangGraph4j的StateGraph是必要的。不需要→ 如果工作流是线性的（A→B→C→D），Spring AI的Advisor链或LangChain4j的AiServices串联就足够了。不需要引入LangGraph4j的额外复杂度。问题三：你的团队愿意接受多少新概念？少→ Spring AI的学习曲线最平缓。ChatClient.prompt().user(...).call().content()的API风格和RestTemplate或JdbcTemplate一脉相承。多→ LangGraph4j需要你理解“状态图”“节点”“边”“检查点”等新概念。但如果你的团队有工作流引擎（Camunda/Activiti）的使用经验，这些概念可以几乎无摩擦地映射。推荐组合对于大多数Java后端团队，推荐的起点是：Spring AI + LangGraph4j。用Spring AI的ChatClient处理模型调用和工具定义（@McpTool），用LangGraph4j的StateGraph编排多步骤Agent工作流。两者可以无缝协作——LangGraph4j的节点实现中可以注入Spring AI的ChatClient。如果需要更丰富的RAG和工具调用能力，可以在Spring AI的基础上叠加LangChain4j。LangChain4j的@Tool注解和EmbeddingStore抽象可以与Spring AI的ChatClient共存于同一个Spring Boot应用中。五、Java AI Agent的运行时缺口在结束本文之前，有必要坦诚地指出当前Java生态的一个关键缺口。JamJet团队的分析一针见血：JVM AI生态已经有了框架，但还缺少“Spring时刻”——就像Spring在2003年不仅给Java开发者提供了框架，还给他们提供了一种构建“能在生产环境中真正工作”的企业应用的方式。当前的缺口具体体现在三个方面。崩溃恢复：Agent执行到第30步时JVM崩溃，重启后能从检查点恢复吗？LangGraph4j提供了检查点机制，但需要开发者手动配置持久化存储（如Postgres checkpointer），框架层没有提供开箱即用的运行时恢复。审计追踪：Agent修改了生产环境的配置，有没有完整的操作日志？当前大多数框架的日志停留在“LLM请求/响应”级别，缺少“Agent决策链”级别的审计。事件溯源状态：Agent的状态变更是否可以像事件溯源一样被完整记录和重放？这对于合规和调试场景至关重要。Java视角：这个缺口正是Java工程师的机会所在。你在分布式系统中积累的可观测性、熔断降级、事务补偿、审计日志的经验，在Agent运行时层几乎可以一一映射。Agent的Token消耗监控≈JVM的GC监控，Agent的检查点恢复≈数据库的事务回滚，Agent的决策链审计≈分布式追踪的Span记录。Java工程师不是AI领域的“后来者”——在生产可靠性这个维度上，他们比Python生态更有经验。小结：Java AI Agent生态的三个关键判断第一，三个框架不是竞争关系，而是分层协作。Spring AI和LangChain4j占据模型抽象层（第一层），LangGraph4j占据Agent编排层（第二层），生产运行时层（第三层）仍是整个JVM生态的共同缺口。选型的正确问法不是“选哪个”，而是“我需要哪几层的组合”。第二，LangGraph4j的“循环+检查点”是Java Agent从Demo走向生产的关键能力。没有循环，Agent无法自我纠错；没有检查点，长任务中断后无法恢复。这两个能力让LangGraph4j成为多Agent工作流的必要组件，而非可选项。第三，Java工程师在Agent运行时层的优势被低估了。当前AI Agent的热度集中在模型能力和编排范式上，但生产级Agent的瓶颈不是模型智力，而是工程可靠性。织灵Coda Loom在智能制造和能源领域的落地数据（研发效率提升75%、缺陷率降低50%、交付周期缩短60%）验证了这个判断。Java工程师在分布式系统、可观测性、事务管理方面积累的经验，是Agent运行时层建设中最稀缺的能力。下一篇进入2.2 Java程序员的Agent工程进阶路线，从TRAE辅助编码到LangGraph4j自定义工作流，给出一个分阶段的、可操作的学习路径，以及每个阶段应该掌握的具体技能和实战项目。🍃 系列专栏导航🔖 专栏导航 大模型学习其他专栏衔接🔖 《若依框架全攻略：从入门到项目实战》🔖 《深入浅出Mybatis》🔖 全面掌握MySQL工具🔖 《深入浅出Maven》🔖 《深入浅出Kafka》🔖 《全面掌握Swagger：从入门到实战》🔖 《Lombok：高效Java开发的秘密武器（完全解读）》🍃 博客概览：《程序员技术成长导航，专栏汇总》建议按系列顺序阅读，从基础到进阶逐步掌握核心能力，避免遗漏关键知识点～全景导航博文系列🔖《一口气学完fastJson》🔖《一文搞懂PageHelper》🔖《一文搞懂MyBatis》
引子：一个后端团队的框架选型困局你所在的Java后端团队接到一个需求：给现有的Spring Boot微服务集群加一个“智能运维助手”——它能查询服务健康状态、分析异常日志、执行简单的运维操作（重启服务、扩容、回滚部署），并且需要支持多步骤的运维工作流，比如“检测到服务异常→拉取日志→分析根因→如果确定是内存泄漏则重启→否则通知值班工程师”。你打开技术选型文档，发现Java生态中至少有九个AI框架、三个协议标准在2026年同时活跃。Spring AI、LangChain4j、LangGraph4j——名字看起来都差不多，但团队里没人说得清楚它们的区别。一个成员说：“Spring AI是Spring官方的，肯定选它。”另一个成员反驳：“LangChain4j生态更全，支持30+模型。”第三个成员问：“那LangGraph4j是什么？它跟前面两个是竞争关系吗？”这场争论的核心问题，在本文里会有一个清晰的答案。Java AI Agent生态的混乱，根源在于把不同层次的框架放在了同一个选择维度上。一旦你理解了它们各自占据的“栈层”位置，选型就不再是“选哪个”，而是“怎么组合”。一、三层栈：Java AI Agent框架的定位地图当前Java AI Agent框架的混乱，可以用一个三层栈来澄清。JamJet团队在一篇系统性分析中指出，大多数关于JVM AI框架的困惑来自“混淆了三个不同的层”。第一层：模型抽象层——解决“怎么调用大模型”这一层解决的问题最基础：让你的业务代码不绑定任何一家模型供应商。你写一段代码调用ChatClient，底层可以是OpenAI、Anthropic、通义千问、DeepSeek，切换模型只需要改配置。这一层是JVM生态最成熟的层。Spring AI和LangChain4j都支持20+模型供应商的统一API。如果你只需要从Java调用Claude、GPT-4或Gemini并处理响应，Spring AI或LangChain4j可以让你在几分钟内跑通。Java视角：这一层本质上是一个适配器模式——和JDBC屏蔽不同数据库差异、SLF4J屏蔽不同日志框架差异的设计思路完全一致。第二层：Agent编排层——解决“怎么协调多步骤、多Agent的工作流”这一层解决的问题比模型抽象复杂得多：规划、工具使用、反馈循环、状态管理、持久化检查点。LangGraph4j在这一层的地位最关键。它引入了循环图（cyclical graphs）和持久化检查点——这两个能力是Agent工作流区别于普通链式调用的核心。没有循环，Agent无法“执行→观察→修正”；没有检查点，长任务中断后无法恢复。LangChain4j的langchain4j-agentic模块也提供Agent编排能力，通过@Agent注解和Supervisor-Worker模式支持多Agent协作。但LangGraph4j在这一层做得更深——它把Agent工作流建模为状态图，节点是计算单元，边是路由逻辑，状态是贯穿全图的共享内存。Java视角：这一层本质上是一个工作流引擎——和Camunda/Activiti的建模思路同构。节点≈Service Task，边≈Sequence Flow，状态≈Process Variable。区别在于，路由决策是模型实时做出的，而非预定义规则。第三层：生产运行时层——解决“怎么让Agent在生产环境可靠运行”这一层解决的问题最容易被忽视：崩溃恢复、审计追踪、事件溯源状态、可观测性。JamJet团队指出，JVM AI生态目前最大的缺口正是在这一层。已有的框架在模型抽象和Agent编排上做得不错，但“让它跑起来”和“让它可靠地跑起来”之间有巨大的鸿沟。这一层的典型需求包括：Agent在执行第30步时崩溃，重启后能否从第29步的检查点恢复？Agent修改了生产环境的配置，有没有完整的审计日志？Agent的Token消耗和延迟，有没有可观测的指标？Spring AI 1.1在这一层开始布局。它通过Micrometer提供了可观测性集成，通过ChatMemory的持久化存储支持状态恢复。LangChain4j 1.10新增了Agentic observability and monitoring支持。但整体而言，这一层仍是JVM生态最薄弱的部分——大多数框架的“生产就绪”还停留在文档层面。二、三个框架的定位差异：一张表看清本质理解了三层栈之后，三个框架的定位就非常清晰了：维度Spring AILangChain4jLangGraph4j核心定位Spring生态的AI工程框架JVM上的LLM应用开发工具箱有状态多Agent编排引擎优化方向Spring生态集成、自动配置广度与灵活性状态图、循环、检查点核心优势20+模型供应商、MCP原生支持庞大的供应商生态、RAG、工具调用循环图、反馈回路、持久化检查点权衡复杂Agent工作流支持较弱比Spring多样板代码较新，受Python LangGraph启发当前版本1.1.0 GA（2025年11月）1.11.0（2026年2月）1.8.1Spring AI的定位是“Spring生态里的AI工程框架”——它不是要发明新奇的AI玩法，而是把AI能力“Spring化”，让习惯了Spring Boot的开发者以最低学习成本把大模型接进现有微服务。它的核心优势是自动配置、依赖注入和MCP原生集成。Spring AI 1.1被称为“MCP集成是Spring AI 1.1最重要的功能集改进”，提供了完整的Spring Boot自动配置和基于注解的编程模型（@McpTool、@McpResource、@McpPrompt）。LangChain4j的定位是“JVM上的LLM应用开发工具箱”。它提供AiServices、ChatModel、EmbeddingStore、ContentRetriever、Memory、Tool等能力，开发者可以较快组合出RAG、智能体、工具调用和对话应用。它的核心优势是集成广度——支持30+模型供应商、覆盖最广的向量库。通过@Tool注解，任何Java方法可以被自动转换为工具供LLM调用。LangGraph4j的定位是“有状态多Agent编排引擎”。它框架无关——可以与LangChain4j或Spring AI任意搭配使用，专注于“图”本身的编排能力。它的核心抽象是StateGraph：用户定义State对象，添加节点和边，编译后执行。LangGraph4j的核心价值在于循环和检查点——这两个能力让它能够表达“执行→观察→修正→再执行”的Agent循环，以及“中断后从检查点恢复”的长任务能力。Java视角：三个框架的关系不是竞争，而是分层协作。Spring AI和LangChain4j解决“怎么调用模型”（第一层），LangGraph4j解决“怎么编排Agent”（第二层）。你可以在Spring Boot应用中用Spring AI的ChatClient调用模型，用LangChain4j的@Tool定义工具，用LangGraph4j的StateGraph编排多Agent工作流。这不是“选一个”的问题，而是“各司其职”的问题。三、实战：一个多Agent招聘工作流理论讲完了，用一个真实的项目案例来展示三个框架如何协作。这个案例来自DEV Community上的一篇实战文章，作者用Spring Boot + LangChain4j + LangGraph4j构建了一个多Agent招聘工作流。工作流设计招聘场景的需求很明确：一份候选人简历进来，需要从技能匹配、经验匹配、文化契合度、风险信号四个维度独立评分，然后汇总评分做出路由决策（自动通过、自动拒绝、或转人工审核）。这个工作流需要的三样东西，普通的链式LLM调用给不了：并行运行的独立Agent、等待人类介入并在之后恢复的中断点、每一步的持久化记录。这正是作者选择LangGraph4j的StateGraph而非简单串联LangChain4j调用的原因。图的拓扑结构parseResumeNode从原始简历文本中提取结构化数据。如果解析失败，直接短路到人工审核——不需要对四个评分Agent空转。否则，图扇出（fan out）到四个独立的Agent，每个Agent从不同维度评估候选人。aggregateScoresNode用加权公式汇总四个评分，任何不是“干净地自动通过或自动拒绝”的结果都落入humanReview中断。人工可以批准、拒绝或要求定向重新分析，重新分析会循环回到审核阶段，直到做出最终决定。LangChain4j的AiServices：每个Agent就是一个Java接口这个案例中最优雅的部分是Agent的定义。每个评分Agent就是一个纯Java接口——没有客户端样板代码，没有手动JSON解析。publicinterfaceSkillsAgent{@UserMessage(""" Candidate ID: {{candidateId}} Job Requisition ID: {{requisitionId}} Use the available tools to fetch the job requisition and the candidate. Assess how well the candidate's skills match the requisition's required skills. Score 0-100. Flag any required skill that's missing. Recommend ADVANCE, CAP, or REJECT. """)AgentScoreResultanalyzeSkills(@V("candidateId")longcandidateId,@V("requisitionId")longrequisitionId);}AgentScoreResult是一个普通的Java record——包含score、flags、recommendation三个字段。LangChain4j自动处理了“让模型填充这个record并解析回Java对象”的所有细节。工具的接入同样低摩擦：AiServices.builder(SkillsAgent.class).chatModel(...).tools(jobRequisitionTool, ...)。Java视角：LangChain4j的AiServices本质上是一个动态代理——你定义一个接口，框架在运行时生成实现类，把方法调用转换为LLM请求，把响应解析回Java对象。这和MyBatis的Mapper接口设计思路完全一致：你定义接口，框架处理SQL和对象映射的细节。LangGraph4j的StateGraph：把工作流画成图LangGraph4j的核心抽象是StateGraph。构建图的过程分三步：定义状态、添加节点和边、编译。// 1. 定义状态publicclassHiringStateextendsAgentState{publicstaticfinalStringMESSAGES_KEY="messages";// ... 其他字段}// 2. 构建图vargraph=newStateGraph<>(HiringState.SCHEMA,HiringState::new).addNode("parseResume",parseResumeNode).addNode("skillsAgent",skillsAgentNode).addNode("experienceAgent",experienceAgentNode)// ... 其他节点.addEdge("parseResume","skillsAgent")// 扇出到四个并行Agent.addEdge("parseResume","experienceAgent").addConditionalEdges("aggregateScores",routingFunction)// ....compile();这个案例使用了Postgres checkpointer来持久化状态。这意味着如果工作流在人工审核阶段中断（等待审批），服务重启后可以从检查点恢复，不需要重新执行前面的Agent。Java视角：LangGraph4j的StateGraph和Java的**CompletableFuture编排**有结构上的相似性。addEdge相当于thenApply/thenCompose，addConditionalEdges相当于thenCompose中的条件分支，checkpointer相当于把中间状态持久化到数据库。区别在于，LangGraph4j的图是可序列化和可恢复的，而CompletableFuture的编排状态在JVM内存中。四、选型决策：你该从哪个框架开始理解了三个框架的定位和协作方式之后，选型决策可以归结为三个问题：✅ 是❌ 否🔁 需要➖ 不需要📗 低📕 高① 项目是 Spring Boot？② 是否需要循环、中断恢复长任务？③ 团队可接受的学习成本？🌱 起点：Spring AI🧠 起点：LangChain4j🔗 引入 LangGraph4j编排层🧩 只用单层模型抽象框架无需 LangGraph4j✅ 优先 Spring AI+ 简单 Advisor 链🚀 Spring AI + LangChain4j+ LangGraph4j 完整组合问题一：你的项目是不是Spring Boot？是→ Spring AI是你的自然起点。它的自动配置、依赖注入和MCP原生支持，让你可以用最少的代码把AI能力融入现有Spring应用。Spring AI 1.1的MCP集成让“把Spring Boot服务暴露为Agent可调用的工具”变得几乎零成本。不是→ LangChain4j是更轻量的选择。它没有Spring的框架绑定，可以在任何Java应用中使用。如果你在做Quarkus、Vert.x或纯Java SE项目，LangChain4j的AiServices和@Tool注解提供了同样流畅的开发体验。问题二：你的Agent工作流需要循环和中断恢复吗？需要→ LangGraph4j是当前Java生态中唯一提供完整循环图+持久化检查点的框架。如果你的工作流包含“执行→验证→修正”的循环，或者需要在人工审核处中断并在之后恢复，LangGraph4j的StateGraph是必要的。不需要→ 如果工作流是线性的（A→B→C→D），Spring AI的Advisor链或LangChain4j的AiServices串联就足够了。不需要引入LangGraph4j的额外复杂度。问题三：你的团队愿意接受多少新概念？少→ Spring AI的学习曲线最平缓。ChatClient.prompt().user(...).call().content()的API风格和RestTemplate或JdbcTemplate一脉相承。多→ LangGraph4j需要你理解“状态图”“节点”“边”“检查点”等新概念。但如果你的团队有工作流引擎（Camunda/Activiti）的使用经验，这些概念可以几乎无摩擦地映射。推荐组合对于大多数Java后端团队，推荐的起点是：Spring AI + LangGraph4j。用Spring AI的ChatClient处理模型调用和工具定义（@McpTool），用LangGraph4j的StateGraph编排多步骤Agent工作流。两者可以无缝协作——LangGraph4j的节点实现中可以注入Spring AI的ChatClient。如果需要更丰富的RAG和工具调用能力，可以在Spring AI的基础上叠加LangChain4j。LangChain4j的@Tool注解和EmbeddingStore抽象可以与Spring AI的ChatClient共存于同一个Spring Boot应用中。五、Java AI Agent的运行时缺口在结束本文之前，有必要坦诚地指出当前Java生态的一个关键缺口。JamJet团队的分析一针见血：JVM AI生态已经有了框架，但还缺少“Spring时刻”——就像Spring在2003年不仅给Java开发者提供了框架，还给他们提供了一种构建“能在生产环境中真正工作”的企业应用的方式。当前的缺口具体体现在三个方面。崩溃恢复：Agent执行到第30步时JVM崩溃，重启后能从检查点恢复吗？LangGraph4j提供了检查点机制，但需要开发者手动配置持久化存储（如Postgres checkpointer），框架层没有提供开箱即用的运行时恢复。审计追踪：Agent修改了生产环境的配置，有没有完整的操作日志？当前大多数框架的日志停留在“LLM请求/响应”级别，缺少“Agent决策链”级别的审计。事件溯源状态：Agent的状态变更是否可以像事件溯源一样被完整记录和重放？这对于合规和调试场景至关重要。Java视角：这个缺口正是Java工程师的机会所在。你在分布式系统中积累的可观测性、熔断降级、事务补偿、审计日志的经验，在Agent运行时层几乎可以一一映射。Agent的Token消耗监控≈JVM的GC监控，Agent的检查点恢复≈数据库的事务回滚，Agent的决策链审计≈分布式追踪的Span记录。Java工程师不是AI领域的“后来者”——在生产可靠性这个维度上，他们比Python生态更有经验。小结：Java AI Agent生态的三个关键判断第一，三个框架不是竞争关系，而是分层协作。Spring AI和LangChain4j占据模型抽象层（第一层），LangGraph4j占据Agent编排层（第二层），生产运行时层（第三层）仍是整个JVM生态的共同缺口。选型的正确问法不是“选哪个”，而是“我需要哪几层的组合”。第二，LangGraph4j的“循环+检查点”是Java Agent从Demo走向生产的关键能力。没有循环，Agent无法自我纠错；没有检查点，长任务中断后无法恢复。这两个能力让LangGraph4j成为多Agent工作流的必要组件，而非可选项。第三，Java工程师在Agent运行时层的优势被低估了。当前AI Agent的热度集中在模型能力和编排范式上，但生产级Agent的瓶颈不是模型智力，而是工程可靠性。织灵Coda Loom在智能制造和能源领域的落地数据（研发效率提升75%、缺陷率降低50%、交付周期缩短60%）验证了这个判断。Java工程师在分布式系统、可观测性、事务管理方面积累的经验，是Agent运行时层建设中最稀缺的能力。下一篇进入2.2 Java程序员的Agent工程进阶路线，从TRAE辅助编码到LangGraph4j自定义工作流，给出一个分阶段的、可操作的学习路径，以及每个阶段应该掌握的具体技能和实战项目。🍃 系列专栏导航🔖 专栏导航 大模型学习其他专栏衔接🔖 《若依框架全攻略：从入门到项目实战》🔖 《深入浅出Mybatis》🔖 全面掌握MySQL工具🔖 《深入浅出Maven》🔖 《深入浅出Kafka》🔖 《全面掌握Swagger：从入门到实战》🔖 《Lombok：高效Java开发的秘密武器（完全解读）》🍃 博客概览：《程序员技术成长导航，专栏汇总》建议按系列顺序阅读，从基础到进阶逐步掌握核心能力，避免遗漏关键知识点～全景导航博文系列🔖《一口气学完fastJson》🔖《一文搞懂PageHelper》🔖《一文搞懂MyBatis》