Spring AI 与 Spring AI Alibaba 技术调研与选型
一、背景与概述
随着AI大模型的爆发式发展，Java/Spring生态亟需一套标准化的AI工程框架。Spring官方于2023年秋季启动Spring AI项目，定位为"AI领域的JDBC"——提供统一的模型抽象API层。阿里云团队在此基础上推出Spring AI Alibaba（SAA），定位为"AI领域的MyBatis-Plus"——在Spring AI之上提供深度扩展，聚焦企业级AI工作流编排与多智能体协作。
核心关系：SAA不是Spring AI的替代，而是其之上的深度扩展。
二、Spring AI 原理与架构
2.1 架构全景
2.2 三层架构详解
| 层级 | 核心组件 | 职责 |
|---|---|---|
| API层 | ChatClient, Prompt Template, Structured Output, Advisor Chain, Tool Calling | 面向开发者的Fluent API，提供对话、模板、结构化输出、拦截器链、工具调用 |
| 抽象层 | ChatModel, ImageModel, EmbeddingModel, VectorStore, RAG | 统一的模型接口抽象，屏蔽底层模型差异 |
| 实现层 | OpenAI, Anthropic, Azure, Ollama, Gemini, Mistral, Bedrock等20+提供商 | 各模型提供商的具体实现 |
2.3 核心设计原则
- 可移植性（Portable）：一套API适配多种模型，切换模型只需改配置
- 模块化（Modular）：各功能独立模块，按需引入
- POJO构建块：用Java对象而非JSON构建AI应用
- 可组合（Composable）：Advisor Chain实现功能可插拔组合
2.4 核心特性
- ChatClient Fluent API：链式调用风格，简化对话开发
- Prompt Template：参数化提示词模板，支持外部化配置
- Structured Output：将LLM输出自动映射为Java POJO
- Advisor Chain：拦截器链模式，支持请求/响应的横切关注点
- Tool/Function Calling：让LLM调用Java方法，实现Agent基础能力
- RAG：检索增强生成，结合向量数据库提供上下文
- ETL框架：DocumentReader → DocumentTransformer → DocumentWriter，标准化数据处理流水线
- VectorStore：支持PGVector、Milvus、Chroma、Pinecone、Redis、Elasticsearch等10+向量数据库
2.5 版本演进
| 时间 | 版本 | 里程碑 |
|---|---|---|
| 2023秋 | 0.x | 首次发布，社区孵化 |
| 2025.5 | 1.0.0 GA | 首个正式发布版，API稳定 |
| 2025.11 | 1.1 GA | 引入Agents框架、Bench评估工具 |
三、Spring AI Alibaba 原理与架构
3.1 架构全景
3.2 四层架构详解
| 层级 | 核心组件 | 职责 |
|---|---|---|
| Studio应用层 | ChatBot, Workflow, Multi-Agent, JManus | 面向应用的三种开发范式 |
| Agent框架层 | StateGraph, OverAllState, Node+Edge, MCP Client | 智能体编排与状态管理 |
| Graph核心运行时 | GraphBuilder, StateGraph, AsyncNode, SubGraph, ConditionalEdge | 工作流图引擎，支持条件分支/子图/异步节点 |
| Spring AI基础层 | 继承Spring AI全部能力 | 底层模型抽象、RAG、VectorStore等 |
3.3 核心扩展特性
3.3.1 Graph多智能体框架
SAA的核心创新是引入了有状态的工作流图（StateGraph），区别于Spring AI的无状态模式：
- OverAllState：跨步骤的全局状态管理，支持状态在节点间传递和更新
- Node + Edge：节点（处理逻辑）+ 边（流转规则）的图结构编排
- ConditionalEdge：条件分支，根据状态动态选择下一节点
- SubGraph：子图嵌套，支持复杂工作流的模块化
- AsyncNode：异步节点，支持并行执行提升效率
3.3.2 JManus自主规划智能体
JManus是SAA内置的自主规划Agent，采用三Agent协作架构：
Planning Agent → Executor Agent → Supervisor Agent- Planning Agent：分析任务，拆解执行计划
- Executor Agent：按计划逐步执行，调用工具
- Supervisor Agent：监督执行结果，决定是否重规划
3.3.3 MCP + Nacos集成
- MCP协议：Model Context Protocol，Anthropic推出的标准化AI模型与外部工具交互协议
- Nacos注册发现：MCP Server通过Nacos注册，实现分布式工具发现
- 自动Router：根据MCP Server注册信息自动生成路由
- 动态MCP Server代理：运行时动态发现和调用MCP Server
3.3.4 阿里云深度集成
| 集成项 | 说明 |
|---|---|
| 通义千问（Qwen） | 默认模型系列，包括Qwen-Max/Qwen-Plus/Qwen-Turbo |
| 百炼平台 | 阿里云AI平台，模型管理/部署/监控一体化 |
| ARMS可观测 | 应用实时监控，链路追踪/指标采集 |
| Langfuse | LLM可观测性平台，Token追踪/成本分析 |
| 云原生网关 | MCP Server的网关管理和模板管理 |
3.4 版本演进
| 时间 | 版本 | 里程碑 |
|---|---|---|
| 2024.10 | 0.x | 开源发布，社区孵化 |
| 2025.6 | 1.0.0.2 GA | 首个正式发布版 |
| 2025 | 1.1.0.0-RC1 | Graph框架增强、JManus完善 |
四、深度对比分析
4.1 对比全景图
4.2 核心维度对比
| 对比维度 | Spring AI | Spring AI Alibaba |
|---|---|---|
| 架构定位 | 模型抽象层（JDBC） | 深度扩展层（MyBatis-Plus） |
| 核心理念 | 可移植性 + 模块化 | Graph工作流编排 + 多智能体 |
| Agent能力 | v1.1引入Agents框架（基础） | Graph多Agent + JManus（完整） |
| 状态管理 | 无状态（单次请求） | 有状态OverAllState（跨步骤） |
| 默认模型 | OpenAI等海外模型 | 通义千问Qwen系列 |
| MCP集成 | MCP Client基础支持 | MCP + Nacos注册发现 + Router |
| 可观测性 | 无内置 | ARMS + Langfuse |
| 工作流编排 | 无（需自行实现） | StateGraph完整支持 |
| 云绑定 | 无云绑定 | 阿里云深度绑定 |
| 学习曲线 | 低（Spring开发者友好） | 中（需理解Graph/State概念） |
| 生态兼容 | Spring生态通用 | Spring + 阿里云生态 |
4.3 关键差异解读
差异一：有状态 vs 无状态
这是两个框架最本质的区别。Spring AI采用无状态设计，每次请求独立处理；SAA引入OverAllState，支持跨步骤的状态传递和累积，这是实现复杂工作流编排的基础。
差异二：Graph工作流 vs 链式调用
Spring AI通过Advisor Chain实现简单的拦截器链式调用；SAA通过StateGraph实现完整的图结构工作流，支持条件分支、循环、子图嵌套、并行执行等复杂编排模式。
差异三：单Agent vs 多Agent协作
Spring AI v1.1引入的Agents框架偏向单Agent+工具调用模式；SAA的JManus实现了Planning-Executor-Supervisor三Agent协作架构，支持任务自主拆解和执行监督。
差异四：模型生态差异
Spring AI以OpenAI等海外模型为默认，适合全球化部署；SAA以通义千问为默认，适合国内合规场景和阿里云生态。
五、适应场景分析
5.1 Spring AI 适合的场景
| 场景 | 说明 |
|---|---|
| 简单对话机器人 | ChatBot、FAQ问答、客服对话 |
| RAG知识库问答 | 结合向量数据库的企业知识检索 |
| 多模型A/B测试 | 需要频繁切换/对比不同模型效果 |
| 海外模型集成 | 主要使用OpenAI/Anthropic等海外模型 |
| 轻量级AI增强 | 在现有Spring应用中快速添加AI能力 |
| 无云绑定需求 | 需要跨云/混合云部署 |
| Function Calling | 让LLM调用Java方法完成特定任务 |
5.2 Spring AI Alibaba 适合的场景
| 场景 | 说明 |
|---|---|
| 复杂工作流编排 | 多步骤、有分支、需状态管理的AI流程 |
| 多智能体协作 | 多个Agent分工协作完成复杂任务 |
| 自主规划Agent | 需要Agent自主拆解任务、规划执行步骤 |
| 阿里云生态部署 | 已在阿里云上，需要与百炼/Nacos/ARMS集成 |
| 国内合规场景 | 需要使用国产模型（通义千问） |
| MCP工具生态 | 需要分布式MCP Server注册发现 |
| 企业级可观测 | 需要LLM链路追踪、Token成本监控 |
六、选型建议
6.1 决策树
是否需要复杂工作流编排（多步骤/分支/状态）？ ├── 是 → 是否使用阿里云生态？ │ ├── 是 → Spring AI Alibaba │ └── 否 → Spring AI + 自行实现工作流 └── 否 → 是否需要多Agent协作？ ├── 是 → Spring AI Alibaba（JManus） └── 否 → 是否需要国产模型/合规？ ├── 是 → Spring AI Alibaba（通义千问） └── 否 → Spring AI6.2 选型矩阵
| 评估因素 | 权重 | Spring AI | SAA | 说明 |
|---|---|---|---|---|
| 开发效率 | 高 | ★★★★★ | ★★★★ | Spring AI更轻量上手快 |
| 工作流能力 | 高 | ★★ | ★★★★★ | SAA的Graph是核心优势 |
| Agent能力 | 高 | ★★★ | ★★★★★ | SAA的JManus更完整 |
| 模型可移植性 | 中 | ★★★★★ | ★★★ | Spring AI无绑定更灵活 |
| 企业级特性 | 中 | ★★★ | ★★★★★ | SAA可观测/网关更完善 |
| 社区活跃度 | 中 | ★★★★★ | ★★★ | Spring AI社区更大 |
| 学习成本 | 低 | ★★★★★ | ★★★ | Spring AI更简单 |
6.3 渐进式引入策略
推荐策略：先Spring AI，后按需引入SAA
由于SAA基于Spring AI构建，两者底层兼容，可以采用渐进式引入：
- Phase 1：使用Spring AI快速构建基础AI能力（对话、RAG、Tool Calling）
- Phase 2：当需要工作流编排时，引入SAA的Graph模块
- Phase 3：当需要多Agent协作时，引入SAA的JManus
- Phase 4：当需要企业级特性时，接入SAA的MCP+Nacos/ARMS等
6.4 总结
| 场景 | 推荐 |
|---|---|
| 快速原型/简单AI增强 | Spring AI |
| 多模型切换/全球化部署 | Spring AI |
| 复杂工作流/多Agent | Spring AI Alibaba |
| 阿里云生态/国产模型 | Spring AI Alibaba |
| 不确定/渐进演进 | 先Spring AI，后按需引入SAA |
七、参考资料
- Spring AI 官方文档
- Spring AI GitHub
- Spring AI Alibaba 官方文档
- Spring AI Alibaba GitHub
- MCP 协议规范
- 通义千问 API