把 Spring AI 和 AgentScope 放在同一张评分卡上很容易让讨论失焦。前者是 Spring 团队（Broadcom）做的 Java 应用框架，2025 年 5 月才打出 1.0 GA[Spring AI 1.0 GA]；后者是阿里通义实验室 SysML 团队做的 Python 多智能体平台，2024 年 2 月就发了 arXiv 论文，2025 年 8 月做了一次推倒重写[AgentScope 1.0 paper]。一个把 LLM 当作"企业系统的新型外部依赖"来对待，关心 starter、autoconfigure、observability；一个把 agent 当作"研究与生产之间的可移植平台"来对待，关心 ReAct 范式、async 通信、可视化追踪。它们解决的不是同一道题。

但这两个项目恰好踩在 2025-2026 年智能体框架最分裂的两条路径上：用企业语言栈把 LLM 拉低成一个新的中间件，与用编程范式实验把 agent 拉高成一种新的应用形态。把它们的差异讲清楚，就把过去一年间 LangChain4j / Semantic Kernel / LangGraph / AutoGen / CrewAI 这些项目各自的位置一并讲清楚了。本文以 Spring AI 和 AgentScope 为主轴，旁通其余五个主流方案。

一、命名先去重：六个常被混为一谈的实体

智能体框架领域名字混乱程度仅次于"Hermes"[本博 2026-04-30 Hermes 横评]。讨论之前先把以下六个实体的所指锁死，否则后面所有判断都会建立在错位的概念上。

名字 是什么 与本文的关系
Spring AI spring-projects/spring-ai，Spring 团队官方仓库，Apache-2.0 本文研究对象之一
Spring AI Alibaba alibaba/spring-ai-alibaba，阿里在 Spring AI 之上叠的 agentic framework Spring AI 生态的下游扩展，不是替代
AgentScope agentscope-ai/agentscope（旧地址 modelscope/agentscope，仍有重定向），阿里通义实验室 SysML 团队 本文研究对象之二
LangChain4j langchain4j/langchain4j，由 Dmytro Liubarskyi 等人主导的 Java LLM 库 README 明确"是为 Java 而生，不是从 Python 翻译来的"——和 LangChain 公司没有从属关系
AutoGen 至少有三个并存实体：microsoft/autogen v0.4（已进入 maintenance 模式）、ag2ai/ag2（Chi Wang 与原班人马的延续）、Microsoft Agent Framework（MAF，2026-04-03 GA，吸收 AutoGen + Semantic Kernel） 本文当作三条线分别处理
MAF（Microsoft Agent Framework） 微软在 2026 年 4 月把 AutoGen 与 Semantic Kernel 合并而成的官方继任者 Semantic Kernel 与 AutoGen 都被它吸纳；旧仓库进维护态

[PATTERN] 处理 agent 框架命名漂移：写作和阅读时凡是涉及"AutoGen"、“AgentScope”、"Spring AI"这类高歧义名词，第一件事是声明本文采用的具体仓库 URL 与版本号。半年前"AutoGen"指 v0.2 的 ConversableAgent，今天可能指 MAF——同一个名字背后是完全不同的代码。

本文用到的版本（2026-05 截至日）：

  • Spring AI 1.1.6（2026-05-08 发布），下一代 2.0.x 在 Milestone 阶段[spring-projects/spring-ai releases]
  • Spring AI Alibaba 1.0.x，GitHub Stars 已反超主仓
  • AgentScope 1.0.20（PyPI 当前版本），v1.0 论文 arXiv 2508.16279
  • LangChain4j 1.14.1（2026-05-07）
  • Microsoft Agent Framework 1.0（2026-04-03 GA），AutoGen v0.4 已停在 python-v0.7.5（2025-09-30）
  • LangGraph 1.2.0（2026-05-12）
  • CrewAI 1.14.4（2026-04-30）
  • AG2 0.13.0（2026-05-13）

二、分析的两个轴：抽象密度与运行模型

讨论框架最容易陷入"逐项打勾"的对比表——支持哪些 provider、有没有 RAG、能不能 streaming——这种比法在 2024 年还有意义，今天所有主流项目在这些维度都打勾，差异只剩两个轴。

第一轴：抽象密度。框架对 agent 行为做了多少预设？

  • 低密度（SDK 路线）：只提供 model client、tool calling、memory、RAG 这些"积木"，不规定 agent 的行为模式。开发者自己拼。Spring AI、LangChain4j 在这一档。
  • 中密度（pattern 路线）：给出几种典型 workflow 模板（Sequential / Parallel / Routing / Orchestrator-Workers），开发者按模板填空。Spring AI Alibaba、CrewAI 的 Crew 模式属于这一档。
  • 高密度（runtime 路线）：直接定义 agent 之间的通信范式与状态机——actor 模型、graph 模型、role-task 模型。AgentScope、AutoGen v0.4 / MAF、LangGraph 都在这一档。

第二轴：运行模型。agent 怎么执行？

  • 同步阻塞 + 显式编排：开发者在主循环里调 chatClient.prompt(...).call()，每一步等返回。Spring AI、LangChain4j 默认是这种。
  • 协程异步 + 消息驱动：所有 agent 是 async def，靠消息传递触发行动。AgentScope v1.x、AutoGen v0.4 是典范。
  • 状态图 + checkpoint 持久化：agent 行为被建模为 graph node，每一步落 checkpoint，可以中断、回溯、time-travel。LangGraph 是这条路上的标杆。

把这两个轴交叉，得到的二维空间能解释为什么 Spring AI 和 AgentScope 表面看起来都在做"智能体框架"，实际上根本不在同一个象限里：

1
2
3
4
5
6
7
8
9
10
11
抽象密度 ↑
高 │  AgentScope v1.x        LangGraph
   │  AutoGen v0.4 / MAF     CrewAI
   │
中 │  Spring AI Alibaba
   │
低 │  Spring AI              LangChain4j     Semantic Kernel*
   └─────────────────────────────────────────→ 运行模型
        同步阻塞              协程异步         状态图

   *Semantic Kernel 1.x 接近低密度 SDK，但 MAF 1.0 已上移到高密度 runtime

[PATTERN] 选择 agent 框架的两个先验问题：在比较任何具体功能之前先回答两件事——（1）你想让框架替你决定 agent 行为模式吗？（2）你的 agent 跑在长程任务还是单次会话里？两个答案合起来基本就唯一确定了你应该选哪一档。

三、Spring AI：把 LLM 当成新一代 JDBC

Spring AI 的官方使命陈述是"connecting your enterprise Data and APIs with the AI Models"[spring-ai README]。这句话看起来平平无奇，但放在 Spring 三十年的语境里读就能听出弦外之音——Spring 一直做的事就是把异构外部系统抽象成可移植的接口：JDBC 抽象数据库、JMS 抽象消息中间件、Spring Cloud 抽象服务注册中心。Spring AI 想做的是把 LLM 抽象成一种新的中间件。

抽象层叠：从 ChatModel 到 ChatClient 到 Advisor

Spring AI 的 chat 层有两个高度：

  • ChatModel 接口位于底层（spring-ai-model），暴露 provider 原生能力
  • ChatClient（spring-ai-client-chat）是一个 fluent API，刻意对齐 WebClient / RestClient 的风格

ChatClient 不立刻发请求，调 .call() 也不发——直到调 .content()、.chatResponse() 或 .entity(Class) 才真正打到 provider。这种"延迟触发"的设计让上层可以串很多 Advisor。Advisor 是 Spring AI 的 interceptor 抽象，对应 Spring 体系里的 HandlerInterceptor / AOP，承担横切关注：RAG 注入、记忆注入、日志、安全、reasoning capture。框架内置的 advisor 包括 MessageChatMemoryAdvisor、QuestionAnswerAdvisor、RetrievalAugmentationAdvisor、SimpleLoggerAdvisor[spring-ai docs/api/chatclient.html]。

Modular RAG：把检索拆成 LEGO

Spring AI 1.0 起把 RAG 改造成 Modular RAG 架构（出处是同名论文 Modular RAG: Transforming RAG Systems into LEGO-like Reconfigurable Frameworks）。四个阶段——Pre-Retrieval / Retrieval / Post-Retrieval / Generation——每一阶段都有可替换的组件接口：QueryTransformer（CompressionQueryTransformer、RewriteQueryTransformer、TranslationQueryTransformer）、MultiQueryExpander、DocumentRetriever（VectorStoreDocumentRetriever，支持 topK、similarityThreshold、动态 Supplier<FilterExpression> 多租户过滤）、DocumentJoiner、DocumentPostProcessor、QueryAugmenter。

这种拆法在 Java 圈是新颖的，在 Python 圈（LlamaIndex 已有 router/transformer/aggregator/postprocessor 多年）则属于追平。

跨 20 种 VectorStore 的 portable filter DSL

VectorStore 接口配上一套 SQL-like 的 filter expression language，跨 PGVector、Pinecone、Qdrant、Milvus、Chroma、Weaviate、Redis、Neo4j、Oracle、MariaDB、MongoDB Atlas、Cassandra、Elasticsearch、OpenSearch、Couchbase、Typesense、Azure Cosmos DB、Azure AI Search、GemFire 等 20 种后端。每个 store 有 native fallback，不能表达的复杂条件下沉到底层。这是把"换 vector DB 等同于换 JDBC driver"的承诺真正落到代码里——业务代码不动，依赖换 starter。

Tool calling 与 MCP 的工程化

Spring AI 1.x 的 tool 体系收敛到 @Tool 注解 + ToolCallback 接口，旧的 FunctionCallback 已经 deprecated。注册方式有三种：.tools(obj)、.toolCallbacks(cb)、.toolNames("beanName")，最后一种允许通过 Spring bean name 动态解析——这一点对企业里"工具实例由 Spring 容器管理"的场景非常顺手。

MCP 是 Spring AI 在 2025-2026 最重投入的方向。Spring AI 把自己的 MCP Java 实现 donate 给 Anthropic，成为官方 MCP Java SDK 的基础——这是它在 agent 协议标准化领域罕见的话语权。@McpTool、@McpResource、@McpPrompt、@McpComplete（server 侧）和 @McpLogging、@McpSampling、@McpElicitation、@McpProgress（client 侧）这些注解从 2.0.0-M3 起进入 core。

一段典型代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
@Bean
ChatClient chatClient(ChatClient.Builder builder, ChatMemory memory, VectorStore vs) {
    return builder
        .defaultSystem("You are an enterprise support assistant.")
        .defaultAdvisors(
            MessageChatMemoryAdvisor.builder(memory).build(),
            RetrievalAugmentationAdvisor.builder()
                .queryTransformers(RewriteQueryTransformer.builder()
                    .chatClientBuilder(builder).build())
                .documentRetriever(VectorStoreDocumentRetriever.builder()
                    .vectorStore(vs).similarityThreshold(0.7).topK(5).build())
                .build())
        .defaultTools(new OrderTools(), new InventoryTools())   // @Tool-annotated POJOs
        .build();
}

OrderSummary answer = chatClient.prompt()
    .user(question)
    .advisors(a -> a.param(ChatMemory.CONVERSATION_ID, sessionId))
    .call()
    .entity(OrderSummary.class);                                  // 强类型 POJO 出参

15 行代码同时呈现了：fluent builder、双 Advisor 链（memory 先于 RAG）、Modular RAG with query rewriting、@Tool POJO 注册、structured output 落 record。Java 工程师读这段代码不需要任何额外解释——它就是普通 Spring 代码。

Spring AI 对 agent 的态度：刻意克制

最关键的差异化判断在这里。Spring AI 1.x 没有独立的 Agent class，只给出五种 workflow pattern 的参考实现（出自 Anthropic Building Effective Agents）：Chain、Parallelization、Routing、Orchestrator-Workers、Evaluator-Optimizer。自治 agent 走 incubating 的 Spring MCP Agent。

这是 Spring AI 与所有"agent runtime"路线最根本的哲学分歧：Spring AI 是 SDK，不是 agent framework。文档里直接采用 Anthropic 的二分法——Workflows（预定义代码路径）vs Agents（LLM 自主调度）——并明确"对 well-scoped enterprise tasks，workflows 更可预测"[Spring AI agentic patterns blog]。

社区抱怨 Spring AI"agent 能力滞后"的人，其实是在抱怨 Spring AI 没把它本来就不打算做的事做了。这是产品定位问题，不是能力问题。需要 multi-agent 编排的人，被 Spring 团队默认转介到下游的 Spring AI Alibaba。

Spring AI Alibaba：在 Spring AI 之上加一层 framework

阿里仓库 alibaba/spring-ai-alibaba 的 Stars 已经反超主仓（约 9.6k vs 8.7k）。它不是 fork，而是叠加：

  • 内置 Workflow Agents：SequentialAgent、ParallelAgent、RoutingAgent、LoopAgent
  • Graph Runtime（spring-ai-alibaba-graph）：持久化 / 工作流编排 / streaming，支持 conditional routing、nested graphs、parallel execution、state management，可导出 PlantUML / Mermaid
  • Admin platform 可视化开发 + Dify DSL 迁移工具
  • A2A（Agent-to-Agent）+ Nacos 做分布式协调
  • DashScope（通义/Qwen）一等公民

[PATTERN] 主仓克制 + 下游叠加：当一个上游框架明确选择"做 SDK 不做 framework"时，社区会自然长出下游 framework。Spring AI / Spring AI Alibaba 与 LangChain / LangGraph 是同一种生态分工：上游守住"原子能力"和"接口稳定"，下游做"行为预设"和"产品化"。

四、AgentScope：从 actor 到 ReAct 的范式翻转

AgentScope 在 2025 年最重要的事件不是新版本发布，是v1.0 推倒重写——这是一次架构哲学的彻底翻转，理解这个翻转才能理解它今天的设计。

v0.x 的卖点：actor-based 多机分布式

最初的 AgentScope（arXiv 2402.14034，2024-02）以 Multi-Agent first 为核心论调。最显眼的差异化贡献是actor-based distributed framework——自研 gRPC 的 RpcAgent、placeholder/future 模式让"本地代码自动转分布式"，多个 agent 可以分布在不同进程或不同机器上协作。原 README 强调：“Native Distribution / Parallelization: Centralized programming for distributed application.”

这条路线在 2024 年的多智能体研究里很有市场——LLM agent 的协作需要并发，actor 模型理论上完美匹配。

v1.x 的转向：删掉自研 actor，全面 async-ReAct

打开 agentscope-ai/agentscope 当前 main 分支的 src/agentscope/__init__.py，顶层导出是这样：

1
2
exception, module, message, model, tool, formatter, memory, agent,
session, embedding, token, evaluate, pipeline, tracing, rag, a2a, realtime

rpc 模块没了，distributed 没了，RpcAgent 类没了。旧仓库 v0.1.6 tag 下的 src/agentscope/agents/rpc_agent.py 在新 main 分支直接 404。

新 README 的开篇第一句也不再是"多 agent 优先"，而是：

We design for increasingly agentic LLMs. Our approach leverages the models’ reasoning and tool use abilities rather than constraining them with strict prompts and opinionated orchestrations.

v1.0 论文（arXiv 2508.16279）摘要写得更直接：

we ground agent behaviors in the ReAct paradigm and offer advanced agent-level infrastructure based on a systematic asynchronous design

这是官方承认的范式转移。新核心是 ReActAgentBase → ReActAgent，全 async。多 agent 协作降级到工作流层（MsgHub + sequential_pipeline + fanout_pipeline），分布式从"自研 actor"换成"标准化协议"——A2AAgent 类继承自 AgentBase，本质是用 httpx 调远端 agent card 的客户端。

[PATTERN] 当一个研究型框架愿意删掉自己最大的差异化卖点：通常是因为这个差异化卖点在生态里失去了独占性。AgentScope 砍掉自研 actor 这件事，对应的外部条件是 A2A 协议的标准化、AutoGen v0.4 把 actor 推上了 runtime 层、MAF 把 actor 内嵌到了 .NET 与 Python 的运行时里——自研 RPC 在 2025 年下半年已经不再是优势。

核心抽象：ReActAgent + MsgHub

AgentScope v1.x 的核心是单 agent 的 ReAct 循环加多 agent 的"群组对话"工作流，而不是状态机或 role-task 模板。一段实际可运行的多 agent 群聊代码：

1
2
3
4
5
6
7
8
9
10
11
12
from agentscope.agent import ReActAgent
from agentscope.pipeline import MsgHub, sequential_pipeline
from agentscope.message import Msg

async with MsgHub(
    participants=[agent1, agent2, agent3],
    announcement=Msg("Host", "Introduce yourselves.", "assistant"),
) as hub:
    await sequential_pipeline([agent1, agent2, agent3])
    hub.add(agent4)
    hub.delete(agent3)
    await hub.broadcast(Msg("Host", "Goodbye!", "assistant"))

这段代码的特点是全 async、显式消息对象 Msg、显式订阅广播、无隐式状态机。和 LangGraph 的 StateGraph、CrewAI 的 Crew(role, goal, task)、AutoGen 的 GroupChatManager 是三种完全不同的多 agent 心智模型。

Memory 的两层设计

工作记忆与长期记忆显式分层：

  • 工作记忆：MemoryBase, InMemoryMemory, RedisMemory, AsyncSQLAlchemyMemory, TablestoreMemory
  • 长期记忆：LongTermMemoryBase, Mem0LongTermMemory, ReMePersonalLongTermMemory, ReMeTaskLongTermMemory, ReMeToolLongTermMemory

这是把"对话短期上下文"和"agent 跨会话经验"两件事彻底拆开。Spring AI 的 ChatMemory 只解决前者，长期记忆要自己拼 VectorStore。AgentScope 内置的 ReMe 系列对接的是阿里自家的长期记忆服务。

Trinity-RFT：内置 Agentic RL

TrinityChatModel + examples/tuner/model_tuning 提供了 6 个调优范例（Math / Frozen Lake / Learn-to-Ask / Email Search / Werewolves / Data Augment），多以 Qwen 2.5/3 系列为底。这是 AgentScope 区别于 LangGraph / AutoGen 的研究路线痕迹——其他框架做"运行时"，AgentScope 试图把"训练"也纳入框架视野。

设计哲学：别和 LLM 顶牛

v1.0 论文里的 developer-centric 加了一层意思：别用强 prompt 和强 orchestration 把模型框死。这是对 AutoGen 的 GroupChatManager、LangGraph 的 StateGraph 那种"框架强加流程"的隐性批评。AgentScope 的多 agent 是 ad-hoc 工作流（MsgHub + sequential_pipeline + fanout_pipeline），不是状态机也不是 role hierarchy。

代价是：AgentScope 几乎没有提供"开箱即用的多 agent 模板"，需要开发者自己组装协作逻辑。这与 CrewAI 给你 role / goal / backstory 三元组就能起项目的体验完全相反。

五、Spring AI vs AgentScope：六维直接对比

维度 Spring AI AgentScope
出身 Spring 团队（Broadcom） 阿里通义实验室 SysML 团队
语言 Java（Kotlin/Groovy 受 Spring 兼容惠及） Python（≥ 3.10）
起跑时间 2025-05-20 GA 2024-02 论文，2025-08 v1.0 重写
抽象密度 低（SDK 路线，刻意不做 agent runtime） 高（runtime 路线，全 async ReAct + MsgHub）
运行模型 同步阻塞 + 显式编排 协程异步 + 消息驱动
默认 provider 倾向 OpenAI / Anthropic / Bedrock 平衡 DashScope/Qwen 优先（中国血统）
长期记忆 不内置（要自己拼 VectorStore） 内置 Mem0 / ReMe 多层
RAG 抽象 Modular RAG（4 阶段拆分） 基础 RAG，依赖外部组件
Tool calling @Tool POJO + ToolCallback Toolkit + 函数式注册
MCP 一等公民，主仓 donate 给 Anthropic 成官方 SDK 一等公民，提供"细粒度 tool 拆分"模式
分布式 不在框架职责内 已删自研 actor，靠 A2A 协议
可视化追踪 走 Micrometer + 任意 OTel 后端 AgentScope Studio + 内置 OTel
Agent 抽象 不提供（推荐 5 种 workflow pattern） ReActAgent + MsgHub 多 agent 工作流
RL 集成 无 内置 Trinity-RFT
部署形态 Spring Boot starter / autoconfigure 普通 Python 包 + Studio 远端 UI
典型用户 Java 企业团队，要把 LLM 接进现有业务系统 Python 研究/产品团队，做多 agent 应用或 agentic RL
直接竞品 LangChain4j（Java）、Semantic Kernel（多语言） AutoGen / AG2、LangGraph、CrewAI
最大缺点 没有原生 multi-agent / graph，需装 Spring AI Alibaba 海外影响力远不如 LangGraph，文档中英割裂

[PATTERN] 互补关系而非竞争关系：Spring AI 和 AgentScope 是两个目标市场不重叠的产品。Java 企业团队选 AgentScope 没有路径——它是 Python 库；Python 研究团队选 Spring AI 没有意义——他们要的是 agent 行为实验空间，不是 starter。把它们放进同一张评分卡比较，主要是为了把"agent 框架的 design space"勾勒出来。

六、其余主流方案：六个值得写的竞品

LangChain4j：Java 圈的 AiServices 路线

langchain4j/langchain4j 与 Spring AI 是 JVM 生态最直接的两个竞品。它最显眼的特征是 AiServices——把"AI 接口"做成 JDK dynamic proxy 的声明式接口：

1
2
3
4
5
6
7
interface Assistant {
    @SystemMessage("You are a helpful assistant. Answer concisely.")
    String chat(@UserMessage String message);
}

Assistant assistant = AiServices.create(Assistant.class, model);
String reply = assistant.chat("Hello");

文档原话：“very similar to Spring Data JPA or Retrofit: you declaratively define an interface with the desired API, and LangChain4j provides an object (proxy) that implements this interface.” 这是把 LLM 行为完全放在类型化 Java 契约背后——AI 服务可以被 mock、可以走 if/switch/for、可以混合大小模型、可以做单元测试。

LangChain4j 与 Spring AI 的差异不在能力上，在风格上：

  • 项目归属：Spring AI 在 Spring portfolio 内部；LangChain4j 是 Open Collective 资助的社区项目
  • 核心抽象：Spring AI 是 ChatClient + Advisor（fluent + interceptor）；LangChain4j 是 AiServices（typed declarative interface）
  • 跨框架覆盖：Spring AI 只做 Spring Boot；LangChain4j 同时一等支持 Spring Boot、Quarkus（注解处理器无反射）、Helidon、Micronaut
  • provider 广度：LangChain4j 显式宣称 20+ chat-model provider 和 30+ embedding store，矩阵更宽
  • Agent 模块：LangChain4j 已经有独立的 langchain4j-agentic / -agentic-patterns / -agentic-a2a / -agentic-mcp，提供 SupervisorAgent、Workflow Agent、AgenticScope 等抽象——agent 路线比 Spring AI 主仓激进

[PATTERN] Java 圈选 Spring AI 还是 LangChain4j：Spring 重度用户（已经在用 Spring Boot 3.x）选 Spring AI 直接，autoconfigure 一键到位；多框架（Quarkus / Micronaut / 纯 Java）或希望"AI 服务像 JPA repository 一样写"的团队选 LangChain4j。两者能力近乎打平，差异在风格。

Microsoft Agent Framework：Semantic Kernel + AutoGen 的合并

讨论 Semantic Kernel 和 AutoGen 必须合在一起讲——它们 2026 年 4 月 3 日合并成了 Microsoft Agent Framework（MAF）。

时间线：

  • 2023：Semantic Kernel 起步，Kernel + Plugin（旧称 Skill）+ Function 模型，C# 优先
  • 2023：AutoGen 由 Microsoft Research（Chi Wang、Qingyun Wu 等）发布，ConversableAgent / AssistantAgent / UserProxyAgent + GroupChat 模式
  • 2024-11-11：Chi Wang 与原班人马离开微软，注册 ag2ai 组织，把项目延续为 AG2，仍由他们任 administrator
  • 2024-11-04：微软发布 Magentic-One（5 个通用 agent：Orchestrator + WebSurfer + FileSurfer + Coder + ComputerTerminal），跑在 AutoGen v0.4 之上
  • 2024 末：微软在 microsoft/autogen 仓库做 v0.4 重写——actor model + 异步消息传递 + 跨语言（Python / .NET）runtime，分 Core / AgentChat / Extensions 三层 API
  • 2026-04-03：Microsoft Agent Framework 1.0 GA，吸收 SK 的中间件管线、多 provider chat client、声明式 YAML agent、OTel；继承 AutoGen 的 graph-based 多 agent 模式（sequential / concurrent / handoff / group collaboration）+ checkpointing / streaming / time-travel / human-in-the-loop。Magentic-One 作为 5 种 orchestration pattern 之一被纳入[microsoft/agent-framework]
  • 同期：microsoft/autogen 进 maintenance 模式（最后版本 python-v0.7.5，2025-09-30）；Semantic Kernel 1.x 承诺 GA 后再维护一年

[PATTERN] 当一个公司同时维护两个有重叠野心的项目：合并是大概率事件。SK 与 AutoGen 在 2025 上半年还在共存，到 2026-04 完成合并。要在微软栈上选项目的人，2026 年起的默认答案是 MAF，不是 SK 或 AutoGen 任何一支。

至于 AG2——Chi Wang 团队的延续——它继承 AutoGen v0.2 的开发者直觉，加了 Apache-2.0、AgentOS 定位、autogen.beta 等新框架。Stars 4.6k，远不如微软主仓的 58k，但代表了另一条不被微软商业化路线绑架的开源路径。

LangGraph：Pregel 启发的状态图 runtime

LangGraph 是 LangChain Inc. 自家的 agent runtime，README 直接点名灵感来源是 Pregel 与 Apache Beam，公开 API 模仿 NetworkX。Stars 32.1k，README 列出的采用方含 Klarna、Replit、Elastic、Uber、LinkedIn、GitLab。

核心抽象是 StateGraph(State)：

  • State 是 TypedDict / dataclass / pydantic.BaseModel，每个 key 可以单独配 reducer（Annotated[list[str], operator.add] 是典型写法）
  • add_node(name, fn) 加节点，add_edge / add_conditional_edges 加边
  • 多条出边自动并行（Pregel 的 super-step 概念）
  • .compile(checkpointer=...) 后得到带 checkpointing 的可执行图

持久化层是 LangGraph 的杀手锏：

  • BaseCheckpointSaver 接口 + 三种实现（InMemorySaver / SqliteSaver / PostgresSaver / CosmosDBSaver）
  • thread_id 唯一标识一个会话的全部状态
  • time-travel：传特定 checkpoint_id 调用，前面的步骤跳过（已持久化），后续节点重跑
  • update_state(...) 写新 checkpoint 而不是原地修改，可指定 as_node 让更新看起来"来自"某个节点
  • interrupt() + HumanInterrupt / HumanResponse 实现 human-in-the-loop

多 agent 拓扑被拆到独立包里：langgraph-supervisor（中心化协调）、langgraph-swarm（去中心化 peer-to-peer handoff）、Deep Agents（长程规划 agent）。

[PATTERN] 状态图 vs 消息驱动：LangGraph 与 AutoGen v0.4 / AgentScope v1.x 的根本差异在心智模型——LangGraph 把 agent 行为建模为"状态在节点间流动"，状态是一等公民；后两者把 agent 行为建模为"agent 之间发消息"，消息是一等公民。前者天然适合需要 audit / replay / time-travel 的场景，后者天然适合开放式协作。

CrewAI：role-task 模板派

CrewAI（crewAIInc/crewAI）的产品定位与上面几个都不一样：它把多 agent 系统类比成人类团队。基本元素是 Agent(role, goal, backstory) + Task(description, expected_output) + Crew(agents, tasks, process)，Process 可选 sequential 或 hierarchical（自动加 manager）。

这是一个有意思的产品决策：用人类团队的隐喻给非工程师降低多 agent 编排的认知门槛。“高级数据研究员 + 报告分析师"这种设定比"actor A 给 actor B 发消息"对产品经理友好得多。代价是"团队隐喻"在某些技术场景下并不自然——比如你想做的是"用 LLM 做异常检测”，而不是"组建一个团队"。

CrewAI 1.x 的 Flows 是它对"团队隐喻 vs 工程化编排"两难局面的回答：@start() / @listen() / @router() / @persist / @human_feedback 装饰器组成一套事件驱动的工作流原语，与 Crew 互相嵌套——Flow 当外层确定性骨架，Crew 当内层自主子任务。Stars 51.5k，星速是这一代 agent 框架里最快的。

License 是 MIT，README 反复强调"completely independent of LangChain or other agent frameworks"——市面流传的"CrewAI 起源于 LangChain 后来独立"说法没有官方证据支持，按 README 的口径它从一开始就独立。

商业化走 CrewAI AMP Suite + Crew Control Plane（app.crewai.com），有可观测性、企业整合、本地/云双部署。

AG2：保持原班 AutoGen 直觉的开源延续

AG2 的位置略尴尬——技术上仍在 v0.13 这种小版本号摸索 v1.0 路径（autogen.beta 框架），star 数 4.6k 远小于微软主仓和 CrewAI；但它是唯一一条不被微软商业化路线绑架的"原 AutoGen"延续。对于在意"项目治理独立性"和"延续 v0.2 编程直觉"的团队仍然有价值——尤其是已有大量 v0.2 代码不想改写到 MAF 的存量项目。

Semantic Kernel 的 Java 端：不要选

microsoft/semantic-kernel-java 仓库存在，license MIT，最新可见版本 java-1.4.4-RC1（2025 年 5 月），距离 .NET / Python 主线落后近一年，没有 Spring Boot starter，没有 Quarkus 集成。Java 用户选 SK 实质上是给自己挖坑——Spring AI 与 LangChain4j 都是更优解。这一点连第三方 2026 年 Java GenAI 框架对比文章都已经形成共识。

七、综合判断：六个选型决策点

把以上七个项目（Spring AI、Spring AI Alibaba、AgentScope、LangChain4j、MAF、LangGraph、CrewAI）按真实工程语境而非功能勾选打分，得到的指引是：

1. 你的代码主体是 Java/Kotlin

  • 已重度依赖 Spring Boot：Spring AI（要 multi-agent 加 Spring AI Alibaba）
  • 跨多框架（Quarkus / Micronaut / 纯 Java）：LangChain4j
  • 不要选 Semantic Kernel Java——它是二等公民

2. 你的代码主体是 Python，要做 agent 应用

  • 状态可审计、需要 checkpoint / time-travel / 人在回路：LangGraph
  • 多 agent 异步协作、研究偏向、要做 RL：AgentScope
  • 团队隐喻友好、产品经理友好、需要 enterprise hosted：CrewAI
  • 已有 v0.2 AutoGen 存量代码：AG2 或 MAF（按是否绑定微软栈选）

3. 你的代码主体是 .NET 或想用微软栈

  • 默认选 MAF（2026-04 GA），不要新写 SK 或 AutoGen 代码

4. 你需要一个跨语言（Java + Python + .NET）共用的 agent 协议

  • A2A + MCP 的组合——这是当前唯一现实的跨语言方案。Spring AI 和 AgentScope 都已是 A2A / MCP 一等公民

5. 你在意"框架的长期演进风险"

  • 风险最低：Spring AI 主仓（克制、迭代慢、向后兼容好）、LangChain4j（社区治理、月度发版稳定）
  • 风险中等：LangGraph（LangChain Inc. 商业捆绑，但开源代码独立）、CrewAI（商业版与开源版分层，开源版被商业版牵动）
  • 风险较高：AgentScope（半年 20 个 patch，2.0 又在路上）、MAF（吸收两个老项目，迁移成本未稳定）、AG2（小社区、v1.0 仍在 beta）

6. 你需要把"训练 agent"和"运行 agent"做在同一套框架里

  • AgentScope（Trinity-RFT）是目前唯一一个把 RL 内嵌进框架视野的主流选择。其余项目都假设训练在外部完成

[PATTERN] 选框架的最终判据是"和你在解什么问题对齐"：Spring AI 解的是"企业 Java 系统怎么把 LLM 接进来"，AgentScope 解的是"研究/产品团队怎么实验和部署多 agent 应用"，LangGraph 解的是"agent 行为怎么变成可审计的状态机"，CrewAI 解的是"非工程师怎么组装 agent 团队"，MAF 解的是"微软栈怎么有一个统一的 agent SDK"。所有"我应该选哪个框架"的问题，本质上是"我在解哪一道题"的问题。

八、与 Hermes 横评一文的分工：框架层不是产品层

本博 2026-04-30 那篇 《谁在记住你：Hermes、OpenClaw、Claude Code 等主流智能体的记忆架构深度横评》 里有一句明确划界的话——“LangGraph、AutoGen、CrewAI、Claude Agent SDK 是另一个层级的东西——它们是搭建智能体的积木，不是智能体本身。记忆机制由框架使用者自己实现，框架只提供插槽。”

本文讨论的恰好是那篇文章显式排除在比较范围外的层。两篇放在一起读才是完整图景：上面一篇讲"agent 产品做什么"，本文讲"agent 产品用什么搭"。把两篇之间的对应关系讲清楚，比单独写好任何一篇都更重要——这一节就专门做这件事。

8.1 三层堆栈：产品、框架、协议

1
2
3
4
5
6
7
8
9
10
11
12
13
产品层（Hermes 那篇）   →  Hermes Agent / OpenClaw / Claude Code / Crush / Devin
                           回答："我要给用户交付一个能用的 agent"
                                    ↑
                                  搭建于
                                    ↑
框架层（本文）           →  Spring AI / AgentScope / LangChain4j / MAF /
                           LangGraph / CrewAI / AG2
                           回答："开发者怎么把 LLM 装配成一个 agent"
                                    ↑
                                  调用
                                    ↑
协议与 SDK 层            →  MCP / A2A / Anthropic SDK / OpenAI SDK / Bedrock SDK …
                           回答："agent 之间、agent 与模型之间怎么通信"

三层之间不是简单的"上层调用下层"——产品也可以跳过框架层直接调模型 SDK，Hermes 就是这种做法（前文 Hermes 横评里 Hermes 的"第 1 层 Agent 核 + transport ABC"是项目自己写的，并没有建立在 Spring AI / AgentScope / LangGraph 之类的公共框架之上）。这种跳层选择本身是一个值得专门解读的工程信号，而不是 Hermes 团队"没用过框架"那么简单——后面 8.3 节会拆开讲。

8.2 框架天花板：把 L0–L4 记忆模型反投影到框架层

Hermes 横评一文给出过一个 L0–L4 记忆成熟度模型——L0 无状态、L1 会话持久化、L2 项目上下文注入、L3 跨平台会话 + 技能注册、L4 封闭学习回路。那篇文章用这个模型对产品打分。把同一个模型搬到本文讨论的框架层再看一次，能拿到一张完全不同的表——它衡量的不是"框架达到了几级"，而是"这个框架默认带你到几级、要再往上你要自己补什么"。

框架 默认覆盖等级 内置能力 要爬到更高需要补什么
Spring AI L1 MessageWindowChatMemory + JdbcChatMemoryRepository 提供会话持久化；CONVERSATION_ID 隔离 L2 要自己写 system prompt 注入；L3-L4 要自己拼 skill 库、session 全文检索、用户建模
LangChain4j L1 MessageWindowChatMemory / TokenWindowChatMemory + ChatMemoryProvider per-conversation 同上
AgentScope L2-L3 工作记忆 + 长期记忆双层（Mem0LongTermMemory / ReMePersonalLongTermMemory / ReMeTaskLongTermMemory / ReMeToolLongTermMemory），A2A 跨服务通信，OTel + Studio L4 还差自动 skill 自蒸馏；hook（pre/post_reply）层加挂并不困难
LangGraph L1（time-travel 是这一档的最强实现） checkpointer + thread_id + update_state(as_node=...) L2-L4 要自己设计 state schema 与 skill 库；time-travel 不等于自我学习
MAF（SK + AutoGen 后继） L1-L2 session-based state、middleware pipeline、可插拔 memory L3-L4 要自己实现 skill 注册与自蒸馏
CrewAI L1-L2 unified Memory（LanceDB）、Flows @persist、self.remember/recall L3-L4 要自己实现 skill 自蒸馏与跨平台会话
Claude Agent SDK L0 纯编排积木，记忆完全外置 全部要自己实现

读这张表的方式不是"AgentScope 比 Spring AI 高一级所以更好"——而是"框架层默认覆盖到几级，决定了产品层最终能不能廉价地达到那一级"。Spring AI 默认到 L1 是它对自身的诚实定位，因为 Spring AI 明确选了"做 SDK 不做 framework"的路线（前文第三节）；AgentScope 默认到 L2-L3 是它的研究取向决定的——长期记忆和分布式协作是它从 v0.x 时代就在啃的题。

[PATTERN] 框架选择决定了产品的记忆天花板：一个团队选 Spring AI 然后想做 L4 自进化 agent 不是不可能，但路径是"在 Spring AI 之上把封闭学习回路从零写一遍"——这不是框架的功能空白，是框架的职责边界。要让"爬到 L4"变得便宜，要么换默认起点更高的运行时（AgentScope 比 Spring AI 起点高一档），要么干脆跳过框架层直接做 harness（这是 Hermes 选的路）。

8.3 能在 Spring AI 或 AgentScope 上做出 Hermes 吗？

这是把两篇文章论点真正咬合在一起的具体问题。回答它需要把 Hermes 的封闭学习回路四件套拆出来逐项对照——agent-curated memory（自主写 MEMORY.md / USER.md）、autonomous skill creation（任务后蒸馏 skill 文档）、FTS5 session search + LLM summarization、Honcho dialectic user modeling。

Spring AI 路径：可行，但很重。Spring AI 的 @Tool + Advisor + ChatMemory + MCP 已经覆盖 Hermes 的工具层与消息层骨架；缺的是封闭学习回路全部四个子机制——四件套都得用户自己实现，Spring AI 帮不上忙。Advisor 的 interceptor 形态可以方便地把"对话结束后调一次蒸馏 LLM"塞进 post-call 阶段，但 skill 注册表、session 索引、user model 的存储与召回完全要自建。换句话说：Spring AI 的默认天花板在 L1，要到 L4 你要在它之上叠一整层自研 harness，工程量与从零做差不多。

AgentScope 路径：天花板更高，缺口更窄。Mem0LongTermMemory 和 ReMe* 系列已经把长期记忆做成一等公民，tracing 模块走 OTel 与 Studio 直连，A2A 协议把跨服务通信标准化，Trinity-RFT 提供调优后端。要在 AgentScope 上长出 Hermes 等价物，主要还差自蒸馏 skill 这一块——v1.x 的 ReAct 循环里没有显式的"任务结束后自动生成 skill 文档并落盘"机制，但 pre_reply / post_reply hook 是为这种扩展设计的，加挂自蒸馏逻辑不算重活。这与 Spring AI 的差距大约是"叠 30% 工程量" vs “叠 100% 工程量”。

LangGraph 路径：适合写"有可审计性的 L4 agent"。checkpointer + time-travel 让经验回看变得便宜，状态变更天然可 replay。但 LangGraph 同样不带 skill 库或用户建模，仍要自己拼。它的优势在 L4 的"可审计"维度，不在"易构建"维度。

直接用模型 SDK 路径（Hermes 实际选的）：跳过所有框架，自己写 transport ABC（前文 Hermes 横评第 1 层）、自己设计六层架构。代价是工程量最大，收益是没有任何框架预设把封闭学习回路的设计扭曲掉——封闭学习回路要求 memory / skill / session / user-model 四个子系统紧密协同，这种跨子系统的协同与"框架的模块边界"天然有冲突，框架的"清晰抽象"在这种场景下反而是阻力。

[PATTERN] 跳过框架层是一种正当的工程选择：当一个产品的核心命题（如 Hermes 的封闭学习回路）需要跨多个抽象层（memory / tool / runtime / agent loop）做协同设计时，框架的模块边界会变成产品的设计阻力。这也解释了为什么主流的 agent 产品——Hermes、Claude Code、Cursor、Devin、Crush——都没有建立在公共 agent 框架之上。框架不是给产品做的，框架是给"产品里那些不需要发明新协同模式的部分"做的。

8.4 三代 agent 范式与框架选择的对应

Hermes 横评一文还提了三代 agent 范式——工具调用型（ReAct，2022-2023）→ 自主型（AutoGPT 等，2023-2025）→ 自进化型（Hermes 等，2026-）。把这条演化线和框架选择对齐，能得到一个简洁的判断：

你要做的 agent 形态 该用的框架
工具调用型（Gen 1）：单轮 tool calling，企业系统集成 Spring AI / LangChain4j / Semantic Kernel 1.x。SDK 路线足够
自主型（Gen 2）：多步规划、多 agent 协作、会话内自我修正 AgentScope / LangGraph / MAF / CrewAI / AG2。Runtime 路线必要
自进化型（Gen 3）：跨会话经验积累、自动 skill 蒸馏、长期 user model 没有现成框架。基于 Gen 2 框架自建 + 协议层（MCP / A2A）；或像 Hermes 一样跳过框架层直接做 harness

注意第三行的"没有现成框架"不是说不可能——是说做 Gen 3 的边际成本主要不来自框架抽象，来自封闭学习回路的设计本身。框架在这一档的价值从"提供能力"降级为"提供脚手架"，而脚手架的价值取决于它有没有挡住你的设计。这与 Gen 1 阶段"框架直接提供能力"的体验完全不同。

[PATTERN] 框架的价值密度随 agent 代际衰减：Gen 1 阶段框架的价值是"开箱即用"，Gen 2 是"运行时模型对齐"，Gen 3 阶段几乎降为零——产品的核心机制（封闭学习回路）必须自己设计。当你判断自己在做哪一代 agent 时，也就同时判断了框架对你这个产品的边际价值。

8.5 一句话收束两篇文章的关系

Hermes 横评回答的是 “我要交付什么样的 agent 产品”——主轴是记忆架构，分级是 L0-L4，焦点在产品形态。

本文回答的是 “我要用什么搭这个产品”——主轴是抽象密度与运行模型，分裂是 SDK 派 vs Runtime 派、Java 派 vs Python 派、个体协作派 vs 团队隐喻派，焦点在框架形态。

两篇互为镜像。先读 Hermes 横评知道要做什么产品，再读本文能反推该选什么框架；先读本文了解哪些框架在哪个象限，再读 Hermes 横评能理解为什么主流 agent 产品大多绕过框架直接做 harness。

九、写在最后：2026 年 agent 框架的真实分裂

把这七个项目放到一起看，2026 年 agent 框架的分裂线已经清晰：

第一条分裂线：Java 企业派 vs Python 研究派。Spring AI / LangChain4j 在这一边，AgentScope / LangGraph / AutoGen / CrewAI 在另一边。这条分裂线短期不会弥合——A2A / MCP 是协议层互通，不是框架层融合。

第二条分裂线：SDK 派 vs Runtime 派。Spring AI / LangChain4j 是 SDK，把"agent 行为"留给开发者；AgentScope / LangGraph / MAF / CrewAI 是 runtime，把"agent 行为"做成框架预设。这条分裂线决定了你是要灵活性还是要开箱即用。

第三条分裂线：个体协作派 vs 团队隐喻派。AgentScope / AutoGen / LangGraph 强调"agent 之间显式通信"，CrewAI 强调"团队角色分工"。这条分裂线决定了你的客户/同事能不能看懂你的 agent 设计。

任何一条分裂线都不能用单一项目"统治"——这就是为什么 2026 年仍然有七个值得讨论的主流方案。它们各自都解了一道真实的题。

主要引用源：

版本快照（2026-05-17 截止日）：Spring AI 1.1.6 / AgentScope 1.0.20 / LangChain4j 1.14.1 / MAF 1.0 GA / LangGraph 1.2.0 / CrewAI 1.14.4 / AG2 0.13.0