为什么选择 Spring AI + LangGraph4j

最近常被问：Java 做 Agent，直接上 Spring AI Alibaba 不就行了？为啥还要官方 Spring AI 再配 LangGraph4j？

先说清楚——不是踩 Alibaba。多智能体开箱、通义 / DashScope、Nacos A2A、Studio，它确实能打；团队若已押宝阿里云 AI，选它往往更省事。

我要的是另一件事：流程可控、能测、能恢复，而不是尽快拼出云上 Agent 脚手架。所以模型与工具走官方 Spring AI，编排交给 LangGraph4j。

本系列示例：Spring AI 2.0.1 × LangGraph4j 1.8.25。Alibaba 以公开文档为准（java2ai.com）。

---

先别比错对象

三个东西别扔进同一个擂台：

• Spring AI 官方：把大模型接进 Spring——ChatClient、工具、RAG、MCP

• LangGraph4j：流程怎么画、怎么停、怎么续——状态、边、Checkpoint、人工审批

• Spring AI Alibaba：在 Spring AI 之上的 Agent / Graph 产品层 + 阿里云集成，不是官方平替

要比就比：官方 Spring AI + LangGraph4j vs Alibaba（含 Graph / Agent）。两边都能编排；差别是要一套显式、可拆换的图引擎，还是一套更贴云平台的 Agent 产品层。

---

我看重 LangGraph4j 的几点

复杂 Agent 需要图——两边都认。分歧不在「要不要图」，而在图以什么姿态出现在代码里。

概念少而硬。 State、Channel、Node、Edge、checkpoint、interrupt / resume，开会可以直接指着图说话：从哪进、从哪出、状态怎么合。不必先绕进一层厂商特有的 FlowAgent 词汇。

出事时能指到边上。 线上最怕流程黑盒：工具跑了三轮，不知道卡在哪。LangGraph4j 逼你把分支写成条件边，状态更新写清楚。Alibaba 的 Sequential / Parallel / Routing 写起来更快，排障却可能要穿过 Agent DSL 再进 Graph。我宁可图啰嗦一点，也不想关键路径藏在默认行为里。

Checkpoint 和人工审批是及格线。 存档后续跑、关键操作先停再批——LangGraph4j 把这些当图的一部分，MemorySaver 就能单测「暂停 → 审批 → 继续」。我更在意恢复语义跟图绑在一起，前端「继续」走自己的线程 ID 和 SSE，不绑死某个 Studio。

底座共用，编排能换。

模型、工具、记忆 / RAG 做底座；普通对话走 ChatClient，真要分支循环再上 LangGraph4j。很多场景根本不必上图；要上也不用重写工具接入。Alibaba 打包快，但业务更容易沾上框架类型——以后只换编排会更肉疼。

换模型不该换编排。 通义、OpenAI 都是 Provider。Nacos 做注册配置，和要不要 Spring AI Alibaba 是两件事。

---

一张图看差异 + 什么时候用 Alibaba

人话：Alibaba 适合快点在阿里云上做出 Agent；LangGraph4j 适合把流程写清楚、测得动、挂了还能续。 我盯的是后者。

下面这些情况，我会劝你直接用 Alibaba：已全面用通义 / 百炼 / A2A / Studio；两周内要交多智能体 Demo；编排不是竞争力，云上工具链一体更重要；团队想少画图、多配 Agent。

先问痛点是接模型、控流程，还是上阿里云 Agent 平台——问清楚就好选。

版本提一句：Alibaba 主线还多在 Boot 3.5 + Spring AI 1.1，我这边跟 Boot 4 + AI 2，引入要单独评估兼容。这是落地成本，不是否定它 Graph 的理由；就算以后对齐了，我多半仍优先 LangGraph4j。

---

尾声

我想把 Agent 从「跑得起来的黑盒」，变成「能画、能测、挂了还能续」的状态图。要云上平台速度，选 Alibaba；要编排可控和长期演进，我把票投给 LangGraph4j。