Spring AI 和 LangChain4j 有什么区别？Java 开发 Agent 应该怎么选？

知识点详解：Java 框架选型，先拆开“能调用”与“能运行”

名字相似，不意味着是一套产品

Java 团队容易因为 LangChain4j 的名字，直接套用 Python LangChain 的概念和调用方法。这样做会导致查错文档，甚至写出不存在的 API。

LangChain4j 的官方介绍说明了它面向 Java 的设计；Spring AI 官方参考则以 Spring 应用中的 AI 集成为主线。两者各自维护 API、版本和模块。

因此，这道题不能靠比较两段“翻译后的代码”回答。先确认实际使用的框架、模型适配器和版本，再讨论能力。这里不提供 TypeScript、Python 的对应实现，因为它们不能代表这两个 Java 框架的真实 API；跨语言框架比较属于另一个问题。

用一个查询任务，检查集成是否顺手

咱们假设已有 Spring Boot 系统，准备增加一个订单查询助手。系统已经有认证、订单服务和日志，AI 功能只负责理解问题、选择查询工具、解释结果。

这时，Spring AI 的集成方式可能比较符合团队已有习惯。但“符合习惯”也需要落实到实际代码：模型配置是否接入原有配置管理，工具是否能够复用服务对象，测试能否替换模型和外部接口。

如果团队采用 LangChain4j，也要检查同样的问题。AI Services 等抽象是否简化了业务入口？工具参数和调用结果是否方便追踪？适配器是否支持目标模型的所需功能？

不能只比较成功路径的一次模型调用。两个框架都能输出一句回答，这还不足以判断哪个更适合现有项目。

工具调用的执行细节，要沿着链路看

大致过程是：应用提供工具定义，模型提出工具名称和参数，框架或应用执行工具，再把结果送回模型继续生成。

Spring AI 的工具文档和LangChain4j 的工具教程分别描述了自己的处理方式。自动工具执行、手动控制和相关选项应按实际采用的接口核对，不能认为两边默认行为一样。

对订单助手来说，最关键的问题是：模型提出参数以后，用户身份与权限在哪里验证？ 这些必须由服务端决定，不能把模型传入的 userId 当成授权依据。

如果以后开放创建订单，还要处理幂等键、业务校验和人工确认。这些属于业务执行机制，不会因为框架帮忙调用了工具就自动完成。

Agent 的任务状态，和一次对话不是同一回事

假设工具超时，任务需要等一会儿继续。如果系统只保存聊天内容，没有记录工具是否真正执行、任务现在停在哪一步，恢复时就可能重复操作。

因此，需要区分聊天历史与执行状态。对话记录帮助模型理解上下文；执行状态帮助运行器判断哪些动作已经完成、哪些需要确认、哪些不能再做一次。

选型时应列出项目真正需要的能力：同步问答、工具循环、持久化状态、人工介入、长任务恢复和可观测性。然后逐项确认哪些由当前框架提供，哪些依赖其他模块，哪些仍要自己实现。

不要把“有工具注解”“能保留聊天记录”直接写成“完整支持可靠 Agent”。一次示例运行成功，只能说明这一条路径跑通了。

面试官继续追问

已经使用 Spring，是不是必须选 Spring AI？

不是。已有 Spring 基础是重要的集成因素，但模型能力、工具执行方式和团队熟悉程度也需要比较。可以用实际任务验证，不必把生态习惯当成唯一理由。

能否同时引入两个框架？

技术上可以，但模型适配、消息类型和工具定义可能重复。除非各自解决了明确问题，否则维护两套依赖和转换逻辑未必划算。

升级框架时最需要测什么？

除了编译和基本问答，还要测工具参数、错误返回、重复调用、状态恢复和日志追踪。模型供应商的行为也可能变化，不能只看 Java 方法签名有没有变化。

面试速记卡

• 两者定位：都是 Java AI 框架，各有接口和模块。
• 名称误区：LangChain4j 不是 Python API 的直接翻译。
• 集成判断：结合现有配置、服务、测试和模型需求。
• 执行边界：工具调用支持不等于完整任务运行保证。
• 业务责任：鉴权、幂等、确认和恢复必须明确归属。