技术手记

Appearance

Spring AI Alibaba 的 Agent Framework、Graph、Admin 怎么分工 ​

很多人第一次看 Spring AI Alibaba 时，会有一种“东西很多”的感觉：

  • Agent Framework
  • Graph
  • Admin
  • Studio
  • MCP
  • Multi-agent

如果不先把层级理顺，就容易看什么都像“框架能力”，但不知道到底该从哪一层下手。

先说结论 ​

可以先把 Spring AI Alibaba 理解成三层：

text
Spring AI 负责基础 AI 抽象，
Agent Framework 负责更高层的 Agent 构建，
Graph 负责底层编排与运行时，
Admin 负责平台化管理、观测和评估。

更具体一点：

  • Agent Framework：优先面向开发者，帮你更快写出 Agent 和多 Agent 模式
  • Graph：优先面向复杂流程，帮你精确控制状态、节点、路由和执行过程
  • Admin：优先面向平台治理，帮你把 Prompt、评估、观测、MCP 管理长期化

如果再往实战一点落，可以直接记成下面三句话：

  • 先想清楚你缺的是“会调模型”，还是“会编排流程”
  • 大多数团队先从 Agent Framework 起步就够
  • 真正复杂之后，再下沉到 Graph，最后才会明显感受到 Admin 的平台价值

一、先看 Spring AI Alibaba 到底补了什么 ​

Spring AI Alibaba 不是单纯再包一层模型调用。

它真正要补的是：

  • Java 团队在做 Agent / Workflow 时缺的那层工程化能力

这层能力通常包括：

  • 多智能体协作
  • 工作流编排
  • 上下文工程
  • 人机协同
  • 长流程状态管理
  • Prompt / Agent 的平台化运维

也就是说，它更适合回答的问题是：

  • “一个会调用模型的 Spring Boot 服务怎么继续长成 Agent 系统”

这句话的重点不在“更高级”，而在“继续长成”。

也就是：

  • 如果你当前还停留在单次问答、单次抽取、单次摘要
  • Spring AI Alibaba 往往不是第一步

但如果你已经进入：

  • 多阶段任务拆分
  • 多角色协作
  • 多系统协调动作
  • 需要长期运行和运维的平台

那它的价值就会明显上来。

二、先不要从 Graph 起步，先从业务问题起步 ​

很多团队看到 Graph、Workflow、Multi-agent 这几个词时，很容易默认：

  • 这一定是“正确的高级路线”

但真实项目里更稳的判断方式通常不是：

  • “哪个框架看起来更强”

而是：

  • “我的问题现在到底是不是流程编排问题”

一个很实用的判断线是：

1. 还在做单个助手 ​

例如：

  • 企业知识库问答
  • 智能摘要
  • 报表解释
  • 工单归类

这时多数情况下：

  • Spring AI 还够用

2. 开始做多步骤业务流程 ​

例如：

  • 先解析意图，再查知识，再选工具，再组织回复
  • 先路由到不同专家 Agent，再聚合结果
  • 先草拟，再校验，再审批

这时通常才进入：

  • Spring AI Alibaba 更合适的区间

3. 开始做平台化治理 ​

例如：

  • 多个 Agent 并行演进
  • 需要 Prompt 管理
  • 需要评估、观测、MCP 管理

这时 Admin 的意义才真正凸显。

三、Agent Framework 更适合大多数应用开发者 ​

如果你是做业务应用的人，通常最先接触的应该是 Agent Framework。

它更像：

  • 面向 Agent 开发的高层框架

在这层里，Spring AI Alibaba 提供了比较明确的模式和抽象，例如：

  • ReactAgent
  • SequentialAgent
  • ParallelAgent
  • RoutingAgent
  • LoopAgent

这意味着你不需要一上来就自己搭所有控制流。

它更适合：

  • 任务拆分成多个 Agent
  • 需要预置的顺序 / 并行 / 路由模式
  • 需要把上下文工程和 HITL 一起纳入流程

如果你的目标是“尽快把一个能推理、能调工具、能按流程协作的 Agent 应用跑起来”，通常先从这一层开始。

一个更贴近真实项目的例子 ​

比如你要做一个“运维变更助手”，流程可能不是单轮聊天，而是：

  1. 先分析用户意图
  2. 再判断是查文档、查监控还是查发布记录
  3. 然后路由给不同专家 Agent
  4. 最后由汇总 Agent 组织结果

这种问题的关键，不再是：

  • 模型能不能回答

而是：

  • 多步协同怎么表达

这正是 Agent Framework 比单纯模型调用更有价值的地方。

更适合谁先写这一层 ​

通常最适合先写 Agent Framework 的，不是平台团队，而是：

  • 直接负责业务 Agent 场景的人

因为这层最贴近：

  • 流程长什么样
  • 哪些步骤该串行
  • 哪些步骤可并行
  • 哪些地方必须人工确认

四、Graph 更适合复杂编排和状态控制 ​

如果说 Agent Framework 更像“高层开发入口”，那 Graph 更像底层运行时和编排引擎。

它更适合那些对流程控制要求更高的场景：

  • 节点之间存在复杂条件路由
  • 需要更细粒度地定义状态
  • 需要长生命周期流程
  • 需要更灵活地做并行、嵌套和恢复

官方也明确表达了一个很重要的判断：

  • 大多数开发者优先使用 Agent Framework
  • 但直接使用 Graph API 也是可行的

这其实是在告诉你：

  • Graph 不是为了让每个人都直接从它起步
  • 它更像你在复杂度上升后需要下探的那一层

什么场景说明你真的该下沉到 Graph ​

下面这些信号一旦开始频繁出现，通常就说明你已经接近 Graph 适用区间：

  • 预置 Agent 模式表达不清现有流程
  • 一个请求跨很多状态切换
  • 需要节点级失败恢复
  • 需要某个步骤重跑但不想整条链路重来
  • 需要显式控制共享状态，而不是只靠上下文传递

如果这些问题还没出现，过早下沉通常只会增加复杂度。

五、Admin 更像平台层，而不是业务层 SDK ​

很多团队在早期只关注“Agent 能不能跑起来”，但真正落地后很快会遇到平台问题：

  • Prompt 怎么版本化
  • 数据集怎么做评估
  • 多个 Agent 怎么观测
  • MCP 怎么统一管理
  • 线上运行状态怎么排查

Admin 更像是为这些问题准备的。

它适合的不是“单个接口开发”场景，而是：

  • 团队内长期维护多个 Agent
  • 需要评估、调试、Prompt 管理
  • 需要把 Agent 能力纳入更正式的平台治理

所以你可以把它理解成：

  • Agent 平台层

而不是普通业务代码里每天都要直接 import 的那种组件。

什么情况下 Admin 的价值会突然变大 ​

一个很常见的拐点是：

  • 你不再只有 1 个 Agent
  • 而是开始有 5 个、10 个、20 个不同职责的 Agent

这时候最大的难题往往不再是“怎么开发”，而是：

  • 怎么知道谁最近变差了
  • 哪个 Prompt 版本引起了回归
  • 哪个数据集说明回答质量在下降
  • 哪个 MCP 接口最近最不稳定

也就是说，Admin 更像你在“平台阶段”才会真正强烈需要的东西。

六、一个更实用的三阶段引入路线 ​

如果你不想一开始就做得太重，可以直接按下面这条路线理解：

第一阶段：先做单 Agent 或轻流程 Agent ​

目标：

  • 先把一个场景跑通

重点：

  • 模型能力
  • 工具调用
  • 少量上下文工程

这时通常：

  • Spring AI 或少量 Spring AI Alibaba Agent Framework 就够

第二阶段：开始做多步骤协同 ​

目标：

  • 把一个复杂任务拆成多个步骤或多个角色

重点：

  • 顺序 / 并行 / 路由 / 循环
  • HITL
  • 失败重试

这时通常：

  • Agent Framework 成为主角

第三阶段：进入平台化治理 ​

目标：

  • 多个 Agent 长期演进

重点：

  • Prompt 版本化
  • 评估数据集
  • 可观测性
  • MCP 管理

这时通常：

  • Admin 的价值开始明显放大

七、什么时候该用 Agent Framework，什么时候该直接下沉到 Graph ​

一个更实用的判断方式是：

1. 先问自己是不是已经能用预置模式表达问题 ​

如果你的流程本质上是：

  • 顺序执行
  • 并行协同
  • 路由分发
  • 循环尝试

那优先用 Agent Framework。

2. 再问自己是不是需要超细粒度状态控制 ​

如果你开始关心：

  • 每个节点的状态持久化
  • 更复杂的分支
  • 更严格的延迟和可靠性控制
  • 更灵活的节点组合

那就该往 Graph 下沉。

这比一开始就直接写最底层编排，会更稳。

八、它和普通 Spring AI 的边界在哪里 ​

普通 Spring AI 更适合做：

  • 模型接入
  • RAG
  • Tool Calling
  • 会话记忆
  • 基础 AI 能力嵌入 Spring Boot 服务

Spring AI Alibaba 更适合做：

  • 多 Agent 协作
  • 长流程编排
  • 上下文工程
  • HITL
  • Agent 平台运维与评估

可以理解成：

  • Spring AI 回答“怎么把 AI 能力接进应用”
  • Spring AI Alibaba 回答“怎么把 AI 应用长成 Agent 系统”

九、什么团队最适合投入 Spring AI Alibaba ​

它尤其适合下面这些团队：

  • 已经不满足于单次模型调用
  • 正在做企业级 Agent 应用
  • 需要多步骤工作流
  • 需要多智能体协作
  • 需要长期运维、评估和可观测性平台

如果你现在只是：

  • 一个简单聊天接口
  • 一个知识库问答
  • 一个轻量摘要或抽取服务

那通常先用 Spring AI 就够，不必太早上到这一层。

十、最常见的误区 ​

1. 把 Graph 当成起步入口 ​

这会让项目一开始就承受过高复杂度。

2. 把 Admin 当成“可有可无的附属品” ​

当 Agent 数量开始变多后，平台治理能力通常会变成真正的瓶颈。

3. 还没进入流程编排阶段，就先上整套 Agent 平台 ​

这往往会把 PoC 做得过重。

4. 一开始就把所有场景都建成多 Agent ​

很多问题本质上只是：

  • 一个模型
  • 一段检索
  • 一两个工具

这类问题过早多 Agent 化，通常收益不如复杂度增长快。

一句话总结 ​

理解 Spring AI Alibaba 最稳的方式，不是把它当成一个单一框架，而是把它看成：

  • Agent Framework 负责开发入口
  • Graph 负责复杂编排运行时
  • Admin 负责平台治理

如果你要把它真正用进项目里，更稳的路线通常是：

  • 先让单场景 Agent 跑通
  • 再把复杂流程放进 Agent Framework
  • 只有复杂度真的上来后再下沉到 Graph
  • 当 Agent 数量变多时再把 Admin 拉进来

参考资料 ​

把零散经验整理成可查、可复用、可持续更新的企业级知识门户

版权所有 © 2026 技术手记