上一篇我们没有使用任何 Agent Framework而是手写了一个最小 Agent最终把 Agent 的核心压缩成一句话Model → Action → Observation → Model。那段代码并不复杂但只要继续往真实项目推进很快就会遇到新的问题Messages 越来越长怎么办Tool 越来越多怎么管理任务中断如何恢复RAG 放在哪里如何做流式输出、人工审批、重试和 Trace多个 Agent 又该怎样协作这也是 Agent Framework 出现的原因。因此这一篇不准备逐个介绍框架 API而是从上一篇的最小 Agent 出发看看Spring AI、LangChain4j、LangGraph以及 Qwen-Agent、AgentScope 等框架究竟替我们封装了什么。一、框架没有改变 Agent Loop只是在它周围增加了工程能力上一篇的最小 Agent 大致只有Messages、Tool Map、LLM Client、Agent Loop、try / catch。进入真实项目以后它会逐渐演进成Messages➜Context / Memory / StateTool Map-➜Tool RegistryLLM Client➜Model Adapter / Model Gatewaywhile Loop➜Agent Runtime / Graphtry / catch ➜Retry / Recovery日志 ➜Trace / Observability。再继续增加RAG、Checkpoint、Human-in-the-Loop、Streaming、Permission、MCP、Multi-Agent。最终才成为我们今天看到的各种 Agent Framework。所以判断一个框架不应该只问“能不能创建 Agent”而应该继续问它在 Agent Loop 的哪个层次替我做了什么二、先看 Spring AI更像 Spring 应用里的 AI 基础设施对于 Java / Spring Boot 开发者Spring AI 通常是比较自然的入口。它并不是简单提供一个agent.run(...)。然后隐藏所有细节而是把模型、Tool、RAG、Structured Output、Vector Store 等能力按照 Spring 的方式组织起来。例如上一篇手写的调用模型➜发现 Tool Call ➜找到 Tool➜执行 Tool➜Tool Result 写回 Messages➜再次调用模型。在 Spring AI 当前实现中可以由ToolCallingAdvisor管理。官方文档描述的流程正是将 Tool Definition 一起发送给模型模型返回 Tool CallToolCallingManager查找并执行对应 ToolTool Result 追加到对话历史再次请求模型直到模型不再产生 Tool Call。也就是说上一篇我们手写的 Agent Loop框架已经封装掉了。程序更多只需要定义Tool public Weather getWeather(String city) { return weatherService.query(city); }然后chatClient.prompt() .user(userInput) .tools(weatherService) .call() .content();这里最重要的不是 API 少了几行而是Tool Schema 生成、Tool Call 匹配、执行结果回填和循环请求都可以由框架统一管理。Spring AI 同时已经提供 Model、Vector Store、Structured Output、Tool Calling 等统一抽象因此它非常适合已有 Spring Boot 业务系统逐步增加 AI 能力。三、Spring AI 更适合什么场景如果一个项目本身就是Java 21Spring BootRedisPostgreSQL企业业务 API。那么 Spring AI 最大的优势并不是“Agent 能力最复杂”而是AI 能力可以自然进入现有 Spring 应用。例如OrderService DocumentService KnowledgeService ↓ Tool ↓ Spring AI ↓ LLM已有业务 Service 很容易变成 Agent 可以使用的 Tool。RAG 也可以通过Document➜Embedding➜Vector Store➜Retriever➜ChatClient。进入现有系统。因此 Spring AI 更像Spring 应用里的 AI Application Framework。它特别适合Java 企业应用已有 Spring Boot 系统增加 AITool CallingRAGStructured OutputWorkflow Agent 混合应用。如果要开发复杂的长任务状态机则还需要继续组合状态管理和编排能力。四、LangChain4j把 AI 能力进一步封装成 Java ServiceLangChain4j 的思路与 Spring AI 又有些不同。它同时提供低层 APIChatModel、ChatMessage、EmbeddingStore、Tool。和更高层的AI Services。官方文档明确说明低层组件虽然灵活但开发者需要自己处理大量组合逻辑AI Services 的目标则是把模型、Prompt、Memory、Tool、RAG 等能力隐藏在一个类似普通 Java Service 的接口后面。例如interface Assistant { String chat(String message); }然后Assistant assistant AiServices.builder(Assistant.class) .chatModel(model) .tools(new BusinessTools()) .build();调用时assistant.chat( 查询上海天气并计算出差费用 );看起来已经非常接近普通 Java 方法。但内部实际上仍然是User Message➜ChatModel➜Tool Call➜执行 Java Method➜Tool Result➜ChatModel➜Final Answer。LangChain4j 的AI Services会自动执行通过Tool暴露的方法再把结果交回模型继续生成。五、LangChain4j 最大的特点是“Java 类型化”如果说 Spring AI 更强调Spring 生态整合。那么 LangChain4j 一个很明显的特点是尽量把 AI 开发变成普通 Java 开发。例如interface RequirementAgent { RequirementResult analyze( String requirement ); }开发者关注的是输入类型、输出类型、Tool、Memory、RAG。而不是每一次模型请求具体怎样拼 JSON。AI Services 还能组合Chat Memory、Tools、RAG、Output Parsing。这些正是上一篇最小 Agent 继续扩展以后必然会遇到的能力。因此对于希望保持 Java 编程模型、减少 AI SDK 胶水代码的项目LangChain4j 非常有吸引力。六、Spring AI 和 LangChain4j 怎么选两者在 Java 生态中存在明显重叠因此经常被放在一起比较。可以先做一个非常粗略的区分维度Spring AILangChain4j核心定位Spring AI 应用基础设施Java LLM / Agent 开发框架与 Spring Boot非常自然支持 Spring Boot编程风格ChatClient / Advisor / BeanAI Services / Java InterfaceTool强强RAG强强Structured Output强强Memory可组合原生抽象较清晰Java 类型化体验强很突出适合Spring 企业应用Java AI 应用因此并不存在简单的Spring AI 好还是 LangChain4j 好更实际的问题应该是你的应用更需要 Spring 生态的一致性还是希望以 AI Service 为中心组织 Agent 能力七、为什么有了这些框架还需要 LangGraph假设现在用户提出分析一份需求文档如果信息不足先提问信息完整后生成需求条目再做质量检查低于 80 分重新修改高于 80 分提交人工确认。这里开始出现状态、节点、条件分支、循环、中断和恢复。这就是 LangGraph 更擅长的领域。八、LangGraph 的核心不是“再封装一次 Agent”而是状态图LangGraph 官方目前将自己定义为用于构建长任务、状态化 Agent 的低层编排框架和 Runtime。它重点解决的是Durable ExecutionStatePersistenceStreamingHuman-in-the-Loop长任务恢复。官方甚至明确说明如果只是需要简单 Agent可以优先使用更高层的 LangChain AgentLangGraph 更适合需要深度定制 Agent 编排的场景。它的核心思路可以理解为这里 Agent Loop 已经不再只是一个简单的while(...)。而是被明确建模成State Graph。九、从上一章的 while Loop 到 LangGraph上一篇while 任务未完成: model() tool()优点是简单。但复杂以后if else retry pause resume human approval全部写进一个 Loop很快会失控。LangGraph 相当于把while / if / else升级成StateNodeEdgeCheckpoint。因此可以这样理解简单 Agent 的核心是 Loop复杂 Agent 的核心往往变成 State Loop。这也是为什么本系列下一篇还会专门介绍使用状态机开发一个可控 Agent。这一篇只需要先建立这个认识。十、三个框架其实处于不同抽象层级把 Spring AI、LangChain4j 和 LangGraph 放在同一张图里就更容易理解。十一、国内开源 Agent 框架也在快速演进除了这些国际上使用较多的框架国内开源 Agent 生态这两年也发展得非常快。其中比较典型的是DeepSeek Harness、Qwen-Agent等。其中Qwen-Agent 是通义千问团队开源的 Agent Framework目前已经支持Tool Calling、Planning、Memory、RAG、Code Interpreter、MCP。官方项目还提供 Browser Assistant、Code Interpreter 等示例并且 Qwen-Agent 已作为 Qwen Chat 的后端运行。其 Agent 抽象同样把MessagesLLMToolsAgent Loop。组合到更高层的Assistant中。例如bot Assistant( llmllm_cfg, function_listtools )然后bot.run(messagesmessages)Qwen-Agent 内部已经封装了 Tool Calling 模板、Tool Calling Parser 等逻辑因此使用 Qwen 系列模型开发工具型 Agent 时代码量会明显下降。十二、AgentScope从 Agent 开发继续走向多 Agent 和 Runtime另一个值得关注的国内开源项目是AgentScope。AgentScope 2.0 在 2026 年已经进一步扩展到ReAct AgentToolsSkillsMemoryPlanningHuman-in-the-LoopRAGAgent TeamMCPA2AObservability。官方将其定位为面向生产场景的 Agent Framework并提供多 Agent 编排、工具、记忆、RAG、评估和部署等能力。这实际上又比我们上一篇的最小 Agent 向前走了一大步Minimal Agent➜Tool Agent➜Stateful Agent➜Agent Team➜Agent Runtime。因此国内 Agent 项目也正在经历类似的演进从“调用模型”逐渐走向“管理 Agent 的完整生命周期”。十三、那么今天开发 Agent应该选哪个框架没有一个框架适合所有项目。如果用最简单的方式分类可以这样选择。Java / Spring 企业应用优先考虑Spring AI特别适合已有 Spring Boot业务 Service数据库企业 APIAI 能力Java 为主希望 AI 编程模型更加类型化可以重点考虑LangChain4j尤其适合Java InterfaceToolMemoryRAG结构化结果Python 复杂 Agent 工作流可以重点考虑LangGraph特别是涉及State、Checkpoint、循环、条件分支、人工审批、长任务、恢复的系统。多 Agent 与生产 Runtime可以继续关注AgentScope特别适合希望进一步探索Agent Team、Memory、Tool、MCP / A2A、Evaluation、Observability、Deployment的场景。十四、真正重要的不是学多少框架而是理解它们封装了哪一层如果没有上一篇手写 Agent 的基础第一次看到assistant.chat(...)或者agent.invoke(...)。很容易产生一种错觉Agent 是框架创建出来的。但现在我们已经知道它内部仍然在处理Messages➜Model➜Tool Call➜Tool Execute➜Tool Result➜Context➜Model。框架只是继续增加Memory、RAG、State、Workflow、Retry、Streaming、Checkpoint、Tracing、Approval、Multi-Agent。因此学习一个 Agent Framework 时可以固定问几个问题Model 在哪里Messages / State 存在哪里Tool 如何注册谁负责 Agent LoopTool Result 怎样进入下一轮任务如何结束任务失败怎样恢复执行轨迹怎样记录只要这些问题能够回答清楚就基本理解了这个框架真正的设计。十五、框架不是越重越好还有一个需要特别强调的问题。一个任务如果只是用户➜Model➜Tool➜Model。完全没有必要为了“Agent 化”就引入State GraphMulti-AgentCheckpointDistributed Runtime。反过来如果任务包含几十个步骤、人工确认、长时间运行、复杂状态、失败恢复、多角色协作。继续坚持几十行while Loop也会逐渐变成维护灾难。因此选择框架真正应该依据任务复杂度而不是框架热度。这仍然符合本系列前面一直强调的原则能用简单方案解决的问题不应该为了使用 Agent 而过度设计。十六、小结上一篇我们亲手写出了Model➜Action➜Observation➜Model。这一篇进一步看到主流 Agent Framework 并没有改变这个核心闭环。它们真正做的是把闭环外面的工程问题逐步封装起来。可以简单概括为Spring AI→ 把 AI 能力融入 Spring 应用LangChain4j→ 把 AI 能力封装成 Java ServiceLangGraph→ 把复杂 Agent 建模成可持久运行的 State GraphQwen-Agent→ 封装 Qwen 的 Tool / RAG / MCP 等 Agent 能力AgentScope→ 向多 Agent、Runtime、评估和生产部署扩展因此Framework 决定我们怎样开发 Agent但 Agent Loop 才决定 Agent 怎样运行。理解这一点以后就不会把框架 API 当成 Agent 本身。我们真正需要掌握的仍然是Model、Context、Tool、State、Loop以及它们之间的关系。上一篇回顾【第三部分第一个 Agent 应用】10. 不使用框架手写一个最小 Agent-CSDN博客下一篇将继续向前一步使用状态机开发一个可控 Agent因为当任务从Model → Tool → Model逐渐变成判断 → 分支 → 循环 → 暂停 → 人工审批 → 恢复简单的 Agent Loop 就开始显得不够用了。这时真正需要解决的问题不再只是Agent 下一步做什么而是怎样让 Agent 的每一步都处于一个明确、可恢复、可控制的状态中这也将是从简单 Agent 继续走向生产级 Agent 的下一道门槛。