Spring AI vs LangChain4j vs Eino vs Rig

先看全貌

这里有两个是 JVM 框架，多数企业把它们当成可以互换的东西，而它们并不是。另外两个之所以存在，是因为一个 Go 或 Rust 服务本来就是以单个二进制的形态部署的，而没人愿意为了给它一个工具循环，去支起一个 Python 边车。

你真正要选的是什么

把这四个拿来做功能对比，几乎毫无意义——而这对它们四个都是恭维。对话抽象、工具调用、结构化输出、向量化、向量库适配、会话记忆、流式、可观测性钩子、一个 MCP 客户端，在每一个里面都是标配。如果你把同一个智能体写四遍，有意思的差别会在代码读起来怎么样，而不在它能做什么。

能在真实代码库面前活下来的那个决定，更窄也更无趣：这个依赖对它周围的运行时提出了什么要求，而我要跟着它保持更新三年，代价是多少？这个问题在这里确实有不同的答案，而对那两个 JVM 选项来说，答案跟 AI 一点关系都没有。

在 JVM 上，这是一个关于 Spring Boot 的决定

Spring AI 与 LangChain4j 都在 2025 年 5 月到了 1.0 GA，也都可用于生产——这正是此后写的那些对比文章最后往往落进「口味之争」的原因。Spring AI 2.0 结束了这一点。它面向 Spring Framework 7 之上的 Spring Boot 4.0 与 4.1，并把 Jackson 3 一起带了过来。如果你的资产还在 Boot 3.x 上——而大多数大型 Java 资产都还在，因为 Boot 大版本是跨季度的工程计划，还拖着一长串库的尾巴——那么 Spring AI 2.0 就不是一个你这个冲刺里能给某个服务加上的库。

LangChain4j 对同一个问题的回答刻意地不英雄主义：它为 Boot 3.5 以上发布一套 starter，为 Boot 4 另发一套，所以两个代际上都能跑；而且它根本不与某个 Web 框架绑定——Quarkus、Micronaut 与纯 Java 都是一等公民，Quarkus 那一系扩展也在积极维护（MCP 扩展于 2026 年 8 月 31 日发布了 1.13.1）。对一支想在某个服务里放进智能体、又不想动平台的团队来说，这就是全部理由，而且够了。

反过来看，就是替 Spring AI 说的那句公道话。如果你已经在 Boot 4 上，那份耦合就不再是税，而是产品本身：自动配置、Micrometer 可观测性、Spring 编程模型，以及整个应用上一条统一的升级路径。Boot 4 这个要求不是 Spring AI 路线图上的 bug，它就是那个让人们选它的紧密集成的同一个决定。因为你在 Boot 4 上而选它，而不是明明不在也要选它。

Eino 与 Rig 不是 Python 的移植——它们是部署形态

Go 与 Rust 这两个条目存在的理由，和那对 JVM 框架不一样；把它们读成「Go 版的 LangChain」，会把这里的取舍读反。它们的说法是：那个服务本来就在那儿了。它是一个二进制，毫秒级启动，没有解释器也没有 GIL，而「不用原生智能体库」的替代方案，是在它旁边跑一个 Python 进程，再在两者之间发明一套接口。

Eino 是字节跳动的，在 CloudWeGo 下开源，而这一点看得出来：它是地道的 Go，而不是一套翻译过来的 Python API；它的编排模型是显式的图与工作流，而这些图本身还能被暴露成工具；它的智能体套件覆盖了工具使用、多智能体协作、上下文管理，以及为人在回路准备的中断/恢复。它同时在字节跳动量级的产品内部承重，这比 star 数是个更好的可靠性信号。需要认真对待的保留意见是真的：ADK 那一层发布于 2026 年 4 月，明确标注为 alpha，接口可能会变。

Rig 是 Rust 生态在这件事上的重心，到 2026 年年中越过 7,600 个 GitHub star，其中约 1,900 个是上半年新增的；它带着 20 多家模型厂商、10 多个向量库集成、OpenTelemetry GenAI 语义约定、MCP 支持与 WebAssembly 兼容性。最后这一项才是别处真正难以复刻的——一个能编译成 WASM 的智能体循环，跑得到 JVM 去不了的地方——而 Rig 列出的生产用户包括 Neon、Nethermind 与 St Jude。

这两者放弃掉的是同一样东西，而且不是功能。是周边生态的密度，这正是接下来两节要讲的。

MCP 把过去用来定胜负的那条理由消解掉了

两年前，用 Python 写智能体的理由不是语言本身。而是每一个集成都以编进进程的 Python SDK 包装层的形式存在，于是「你的智能体能碰到多少东西」是你所选语言的一个属性。那条理由已经悄悄失效了。工具如今活在通过普通 HTTP 触达的 MCP 服务器背后，而 2026 年 7 月的规范通过彻底移除传输层的会话管理，让这些服务器规模化运行容易了许多——无状态内核与其说是一个协议故事，不如说是一个负载均衡故事。这里的四个框架都是 MCP 客户端。那份目录是同一份目录。

在你断定 JVM 是那个保守选择之前，有一处细节值得知道。官方 MCP SDK 带有一致性等级，而在 2026-07-28 规范上，TypeScript、Python、C#、Go 与 Rust 位列一级，Java 处在二级——Rust SDK 是在 2026 年 8 月 21 日被提上去的。Java SDK 由与 Spring AI 协作维护，Go SDK 由与 Google 协作维护，所以没有哪一个是无人维护。但如果你在意的轴是协议一致性，那么那个「企业默认」的运行时，眼下落后于你本来当作冒险选项的那两个。

搬不走的，是给智能体打分的那套工具

把离开 Python 的代价说准确，因为这条警告通常含糊到没有用处。它不是集成，也不是模型支持——这里每个框架都覆盖了主流厂商。它是第二环：提示词优化器、评测台、裁判框架、轨迹分析、强化学习环境工具。这些先落地在 Python，也在 Python 里待得最久，因为它们与工具不同，并不待在一条网络边界的另一侧——它们把你的智能体 import 进来并驱动它。

务实的化解办法很无趣，而且管用：用你的语言跑智能体，用 Python 通过 HTTP 对着它跑评测。在智能体前面放一个薄薄的端点，接收一个任务、返回一条轨迹，然后把你偏好的那个评测台指过去。你失去的是进程内的钩子，换来的是一条你迟早也会想要的边界——因为一个只能在构建里跑的评测，是一个给生产打不了分的评测。

不过要为版本落差留出预算。当一项新技术到来时——更好的优化器、新的裁判协议、新的打分约定——你会在第一天就在 Python 里拿到它，而在你的框架里则要等到另一天，如果还等得到的话。如果你的竞争优势就取决于早一步吃到那一环，那这是一条支持 Python 的实打实的理由，再高的框架质量也答不上来。

什么时候该选哪个

表格底下还有一条规则：选那个你的值班团队能在周四下午四点升级的框架。这里其余每一条标准，一个冲刺之内都还救得回来。这一条会复利好几年。

延伸阅读

本站：

• 智能体框架——这一层是干什么的，以及什么时候你并不需要它。
• 智能体外壳——这些库正在争夺所有权的、模型周围那圈代码。
• 什么是 MCP——让这次比较得以成立的那个协议。
• MCP 的可流式 HTTP——无状态内核所跑的那层传输。
• 模型退役与迁移——你的框架选择所处的另一台升级跑步机。
• LangGraph vs CrewAI vs OpenAI Agents SDK vs Google ADK——换一门语言之后的同一个决定。

项目来源：

• Spring AI 2.0.0 GA——这次发布，以及那个 Boot 4 要求。
• LangChain4j 文档——模块、starter 与支持的运行时。
• cloudwego/eino——这个 Go 框架及其 ADK。
• 0xPlaygrounds/rig——这个 Rust 框架。
• 2026-07-28 MCP 规范——无状态内核与 SDK 一致性等级。