S22-A02 · LangChain4j vs Spring AI

适用读者：Java 团队要在两个 AI 框架之间选型的人。
前置：S22-J01。
覆盖旧文：192(210) 718(229) = 439 点。
覆盖扩展：E-S22-012（托管 vs 自建边界）。
上一篇：S22-A01 · 数据工程 Agent：Spark 与 DAG 观测
下一篇：S22-X01 · 项目与面试登记。

1. 一句话结论

两者都能"调模型、接工具、做 RAG"，差别在"生态取向"：Spring AI 走 Spring 风格（Bean/Advisor/自动配置），LangChain4j 走链式 DSL 与更丰富的内置组件。

维度	Spring AI	LangChain4j
风格	Spring 生态一致（自动配置/Advisor）	链式 API + 组件库
与 Spring Boot 集成	原生	需集成层
图/状态机	依 Spring AI Graph（较新）	LangGraph4j 独立
生态成熟度	新但稳定	组件更全
学习成本	Spring 开发者低	需学 DSL

2. 选型判据（E-S22-012）

① 团队是 Spring 重度用户吗？ → 是：Spring AI
② 需要复杂图编排吗？         → 是：LangGraph4j（可与 Spring 共用）
③ 需要大量现成组件吗？       → 是：LangChain4j 生态
④ 想减少依赖抽象层？         → 裸 HTTP + 自己的封装

"第 ④ 条不是玩笑"：AI 框架迭代快（S21-J04 的框架锁定风险）——核心链路自研反而更稳。

3. 两者的共同底线

底线	说明
密钥管理	不进代码/日志（S20-A02）
重试与超时	必须显式配置
可观测	请求/响应/token 要能记（S22-B03）
版本锁定	避免上游破坏性变更

4. 迁移成本预估

从 → 到	工作量集中在
Spring AI → LangChain4j	链式改写 + Advisor 重写
LangChain4j → Spring AI	组件替换 + 配置迁移
任一 → 自研	提示词/工具/重试全部自己管

判据："业务代码里有多少处直接依赖框架 API？" 多 → 先抽一层自己的接口再迁。

5. 五个误区

误区	真相
"LangChain4j 更全所以更好"	取决于栈与需求
"Spring AI 只能做简单事"	Advisor/工具/RAG 都支持
"框架能省掉可观测"	仍需自己记
"迁移只是换依赖"	代码要改
"自研一定更贵"	长期可能更省

6. 自检（架构师版）

两者的风格差异？
选型四问？
为什么要考虑"自研"？
四条共同底线？
迁移成本集中在哪里？

7. 下一篇

S22-X01 · 项目与面试登记

最后一篇是附录，随后进入 S24（AI 编程工具）。

本篇属于系列《S22 · AI 工程落地实战》。旧文来源：A-192/718；扩展点 E-S22-012。