看了几个 Agent 框架，很容易产生一个疑问：
AgentScope 能接模型，也有记忆、工具和 MCP。Spring AI、LangChain4j 好像也都有，那为什么还要分这么多框架？
这些能力确实有大量重叠。只列一张"是否支持模型、RAG、MCP"的勾选表，很难看出差异。
选型时更值得问的是：从收到任务到交付结果，框架已经替你管到了哪一步？剩下的执行机制，要由谁来补？
我们用同一个任务，对比 AgentScope Java、Spring AI、LangChain4j、Google ADK Java 和 LangGraph4j。
版本说明：本文按 2026-10-16 查阅的官方文档与源码整理，涉及 AgentScope Java 2.x、Spring AI 2.0.1，以及其他项目的当前文档或 main 分支。仓库中的能力不一定已经进入你正在使用的发行版。文中的诊断助手是设计示例，本文没有对五个框架做性能实测。
1. 先让五个框架做同一件事
假设我们要开发一个诊断助手。用户输入：
帮我分析这次订单导出为什么失败，查一下操作文档和相关日志，必要时运行获准的诊断脚本，最后给我一份带证据的报告。
这项任务可能经历下面的过程：
- 读取当前问题、会话历史和可用资料，整理上下文。
- 调用模型，让它判断还缺什么证据。
- 根据模型提出的请求，检索文档或调用日志工具。
- 把真实工具结果加入上下文，再次调用模型。
- 证据足够时输出报告；遇到权限、预算或执行限制时暂停或结束。
模型返回"查询日志"的工具调用请求时，日志还没有被查出来。框架和应用需要校验请求、执行工具，再把结果交回模型。
Harness 也需要调用模型。 模型接入、工具循环和运行管理可以在一套框架中提供，也可以由不同组件组合完成，不能把它们理解成互相排斥的层次。
图中的 RAG、MCP 则需要分开理解：RAG 是检索并利用知识的方法；MCP 是工具和资源的接入协议。一个检索工具可以通过 MCP 提供，二者也不必同时出现。RAG 既可以由 Agent 按需调用，也可以在第一次请求模型前执行。
2. 同样写着"支持"，交付范围可能不同
以"记忆"为例，这个词可能指向几种不同的实现：
| 保存的是什么 | 在诊断助手中有什么用 |
|---|---|
| 最近几轮对话 | 知道用户刚刚说的是哪次导出 |
| 长期保存的偏好或经验 | 记住报告格式、已确认的操作约定 |
| 外部知识库 | 检索导出功能的操作文档和故障说明 |
| 任务检查点 | 记录已经查过哪些证据、下一步从哪里继续 |
聊天记录可以保存到数据库，但程序重启后，未完成的诊断任务仍可能不知道该从哪里继续。
同理，有工具调用接口，不代表已经配置了执行权限；有容器执行器，也要继续检查隔离模式和资源限制。
因此，下面的图把能力分为三类：已有组件、官方扩展或适配、应用需要接入或补齐。 "需要补齐"也可以是接入成熟服务，不代表全部从零实现。
图中几个版本边界尤其需要留意：① AgentScope Java 旧 RAG API 正在迁移；② LangGraph4j 的现成审批来自相应集成模块；③ ADK Java 容器执行器的严格沙箱需要显式开启；④ LangChain4j 的 agentic 恢复能力属于实验模块。下面逐项展开。
3. 五个框架，各自把什么放在中心？
AgentScope Java：围绕任务执行组织 Harness
AgentScope Java 的 ReActAgent 提供推理和工具循环；HarnessAgent 进一步组合工作区、上下文管理、长期记忆、子 Agent 和沙箱接入。会话日志与检查点承担相应的状态保存和恢复职责。具体模型供应商通过扩展接入。官方 Harness 架构
放到诊断助手里，这条路线比较适合继续扩展"管理任务工作区、保留诊断材料、执行工具、延续会话"等能力。
但有一个容易踩坑的版本问题：Java 2.x 的旧 Knowledge、GenericRAGHook 等 RAG API 已弃用并计划移除，新接口仍在重构。旧实现为兼容保留，新代码应按当前迁移建议接入检索能力，不能照搬旧教程。官方迁移说明
知识如何入库、哪些资料允许当前用户读取、沙箱后端怎样部署，仍然需要应用配置。
Spring AI：把 AI 能力装进 Spring 应用
Spring AI 的使用重心是 ChatClient、模型接口和 Advisor 链，适合沿用现有 Spring 应用的配置与服务组织方式。
它也能驱动工具循环。在 2.x 中，ChatClient 的 ToolCallingAdvisor 会处理模型响应、执行工具，并继续请求模型，直到不再有工具调用。把 Spring AI 理解成"只能发一次模型请求的 SDK"并不准确。官方工具循环说明
对诊断助手来说，可以先把文档检索、日志查询封装成已有服务或工具，再装配记忆和 RAG。相应组件可见官方的 ChatMemory、RAG 和 MCP 文档。
如果目标扩展成"后台运行很久、等待人工确认、重启后继续"的任务平台，还需要明确任务调度、持久恢复和执行环境由哪部分系统负责。
LangChain4j：把 AI 能力表达成 Java 服务接口
LangChain4j 的 AI Services 把模型、工具、记忆和检索增强组织成较高层的 Java 服务。对习惯接口、方法参数和返回类型的开发者，这种入口比较直观。官方 AI Services 文档
例如，可以围绕诊断请求定义一个 AI 服务，把日志查询与知识检索作为它能使用的工具。
它也在向复杂任务编排扩展：langchain4j-agentic 已提供步骤检查点和恢复机制，需要配置 AgenticScopeStore，并使用稳定的 MemoryId 识别执行状态。整个 agentic 模块仍被官方标为实验性。 这些条件不能省略，也不能把该模块的恢复能力直接算成普通 AI Services 的默认行为。官方 agentic 文档
因此，既要看到它已有的编排能力，也要评估实验 API 的变化成本，以及持久存储、工具权限和隔离环境的接入工作。
Google ADK Java：围绕 Agent、Runner 和服务组织运行
Google ADK Java 以 LlmAgent、Runner 及相应会话服务组织执行。Java SDK 已有 MCP 工具集，也有面向 Vertex AI RAG 的检索工具；具体集成需要核对 Java 实现，不能直接把 Python 文档中的能力搬过来。ADK Java 仓库、Java RAG 工具源码
如果诊断助手使用 Vertex AI RAG，可以评估这项现成集成。使用其他知识服务时，则要确认对应的检索接法。
Java 侧也已有 ContainerCodeExecutor。本文查阅的 main 分支中，严格沙箱仍需通过 setStrictSandbox(true) 显式开启，默认模式为 unrestricted。它控制的是交给该执行器的代码，不能据此认为所有业务工具都已经被隔离。Java 容器执行器源码
持久化后端、运行环境与业务授权策略，仍要逐项装配和验证。
LangGraph4j：把步骤、分支和恢复点表达成状态图
LangGraph4j 的核心抽象是状态图。对"先检索文档，再查日志；证据不足则补查；需要执行脚本则等待批准"的任务，可以把步骤、分支和状态变化明确表达出来。项目提供检查点和相应保存机制。LangGraph4j 官方仓库
模型和工具能力可以通过 Spring AI、LangChain4j 等适配取得。官方 spring-ai-agent 还提供现成的 ReAct 执行器和工具审批能力，因此也不能简单写成"只有图，没有 Agent 循环"。官方 Spring AI 集成说明
这里要补的工作，主要是具体 AI 组件、持久化后端、检索节点和执行环境的装配。
状态图提供的检查点，也不自动保证外部写入不重复。恢复后是否重新执行某个动作，需要结合工具的幂等性和执行记录处理。
4. 用一次中断，把差别测出来
假设诊断助手已经查完文档和日志，正准备执行获准脚本，进程却退出了。
重新启动后，真正需要回答的是：
- 上一次查到的证据还在不在？
- 系统知道任务停在哪一步吗？
- 已有批准是否仍适用于当前脚本和参数？
- 脚本到底没执行、执行了一半，还是执行完但结果没保存？
这时，单看"支持 Memory"已经不够。我们需要检查会话保存、任务检查点、审批记录和工具结果之间怎样关联。
这也是做 Harness 选型时，恢复和执行治理值得单独比较的原因。一次顺利完成的演示，通常看不出这些差别。
5. 怎么选？先确定你要交付哪一种应用
基于上述交付边界，我会按下面的顺序缩小候选范围。这是功能匹配建议，不是性能排名。
| 主要目标 | 可以优先评估 |
|---|---|
| 给现有 Spring Boot 服务增加问答、RAG 和工具调用 | Spring AI |
| 用 Java 接口组织 AI 服务，按需接工具和检索 | LangChain4j |
| 构建带工作区、上下文管理和执行能力的任务型 Harness | AgentScope Java 的 Harness 路线 |
| 围绕 ADK 的 Agent / Runner 组织应用，使用相应生态集成 | Google ADK Java |
| 显式控制步骤、分支、暂停与恢复 | LangGraph4j，配合所需 AI 适配 |
一个应用通常不需要把五个框架全部装进去。
例如，Spring AI 配合 LangGraph4j，可以让前者提供模型与工具集成，后者管理状态图。选择 AgentScope Harness，也可以直接围绕它已有的执行机制扩展。
如果两套组件都在管理同一次工具循环、同一份会话历史，接入前就要明确由谁负责。组件越多，责任重复的可能性也越大。
最后，拿同一个小任务做验证：
- 先跑通调用链。 确认所选 Qwen 或 DeepSeek 版本、服务端点和框架适配能正确完成工具请求与结果回填；"兼容某 API"本身还不够。
- 主动中断一次。 在明确步骤后结束进程，检查能保存什么、恢复到哪里、会重做哪些动作。
- 制造一次拒绝。 让任务申请超出授权范围的工具，确认执行层真的拦截，而不只是提示词里写了限制。
- 留下执行记录。 记录实际模型调用、工具结果、耗时和失败原因，再比较需要补多少代码。
到这一步，框架差异就会变成具体的工程工作：谁已经提供循环，谁负责恢复，谁需要额外接入执行环境。
选 Agent 框架，最终是在决定：哪些机制交给框架，哪些能力由自己的应用负责。