上一篇，我们没有使用任何 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 / State；
Tool Map-➜Tool Registry；
LLM Client➜Model Adapter / Model Gateway；
while Loop➜Agent Runtime / Graph；
try / 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 Call；
ToolCallingManager查找并执行对应 Tool；- Tool 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 21+Spring Boot+Redis+PostgreSQL+企业业务 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 系统增加 AI；
- Tool Calling；
- RAG；
- Structured Output；
- Workflow + Agent 混合应用。
如果要开发复杂的长任务状态机，则还需要继续组合状态管理和编排能力。
四、LangChain4j：把 AI 能力进一步封装成 Java Service
LangChain4j 的思路与 Spring AI 又有些不同。它同时提供低层 API：ChatModel、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 AI | LangChain4j |
| 核心定位 | Spring AI 应用基础设施 | Java LLM / Agent 开发框架 |
| 与 Spring Boot | 非常自然 | 支持 Spring Boot |
| 编程风格 | ChatClient / Advisor / Bean | AI Services / Java Interface |
| Tool | 强 | 强 |
| 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 Execution；
- State；
- Persistence；
- Streaming；
- Human-in-the-Loop；
- 长任务恢复。
官方甚至明确说明，如果只是需要简单 Agent，可以优先使用更高层的 LangChain Agent；LangGraph 更适合需要深度定制 Agent 编排的场景。它的核心思路可以理解为：
编辑
这里 Agent Loop 已经不再只是一个简单的：while(...)。而是被明确建模成：State Graph。
九、从上一章的 while Loop 到 LangGraph
上一篇：
while 任务未完成: model() tool()
优点是简单。但复杂以后：
if else retry pause resume human approval
全部写进一个 Loop，很快会失控。LangGraph 相当于把：while / if / else 升级成：State+Node+
Edge+Checkpoint。因此可以这样理解：简单 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 抽象同样把：Messages+LLM+Tools+Agent Loop。组合到更高层的 Assistant 中。例如：
bot = Assistant( llm=llm_cfg, function_list=tools )
然后：
bot.run(messages=messages)
Qwen-Agent 内部已经封装了 Tool Calling 模板、Tool Calling Parser 等逻辑，因此使用 Qwen 系列模型开发工具型 Agent 时，代码量会明显下降。
十二、AgentScope：从 Agent 开发继续走向多 Agent 和 Runtime
另一个值得关注的国内开源项目是 AgentScope。AgentScope 2.0 在 2026 年已经进一步扩展到：
- ReAct Agent；
- Tools；
- Skills；
- Memory；
- Planning；
- Human-in-the-Loop；
- RAG；
- Agent Team；
- MCP；
- A2A；
- Observability。
官方将其定位为面向生产场景的 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+数据库+企业 API+AI 能力
Java 为主，希望 AI 编程模型更加类型化
可以重点考虑：LangChain4j
尤其适合：Java Interface+Tool+Memory+RAG+结构化结果
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 Loop？Tool Result 怎样进入下一轮？任务如何结束？任务失败怎样恢复？执行轨迹怎样记录？只要这些问题能够回答清楚，就基本理解了这个框架真正的设计。
十五、框架不是越重越好
还有一个需要特别强调的问题。一个任务如果只是：用户➜Model➜Tool➜Model。完全没有必要为了“Agent 化”就引入：State Graph+Multi-Agent+Checkpoint+Distributed Runtime。反过来，如果任务包含：几十个步骤、人工确认、长时间运行、复杂状态、失败恢复、多角色协作。继续坚持几十行 while Loop，也会逐渐变成维护灾难。因此选择框架真正应该依据：任务复杂度，而不是框架热度。这仍然符合本系列前面一直强调的原则：能用简单方案解决的问题，不应该为了使用 Agent 而过度设计。
十六、小结
上一篇我们亲手写出了：Model➜Action➜Observation➜Model。这一篇进一步看到：主流 Agent Framework 并没有改变这个核心闭环。它们真正做的是把闭环外面的工程问题逐步封装起来。可以简单概括为：
- Spring AI→ 把 AI 能力融入 Spring 应用
- LangChain4j→ 把 AI 能力封装成 Java Service
- LangGraph→ 把复杂 Agent 建模成可持久运行的 State Graph
- Qwen-Agent→ 封装 Qwen 的 Tool / RAG / MCP 等 Agent 能力
- AgentScope→ 向多 Agent、Runtime、评估和生产部署扩展
因此：Framework 决定我们怎样开发 Agent，但 Agent Loop 才决定 Agent 怎样运行。理解这一点以后，就不会把框架 API 当成 Agent 本身。我们真正需要掌握的仍然是：Model、Context、Tool、State、Loop以及它们之间的关系。
上一篇回顾：
https://developer.aliyun.com/article/1757224?spm=a2c6h.13148508.setting.16.49264f0eBcBIGq
下一篇将继续向前一步：使用状态机开发一个可控 Agent
因为当任务从：Model → Tool → Model 逐渐变成：
判断 → 分支 → 循环 → 暂停 → 人工审批 → 恢复
简单的 Agent Loop 就开始显得不够用了。这时真正需要解决的问题，不再只是：Agent 下一步做什么？而是：怎样让 Agent 的每一步都处于一个明确、可恢复、可控制的状态中？这也将是从简单 Agent 继续走向生产级 Agent 的下一道门槛。
