Spring AI vs LangChain4j: qué framework elegir para IA en Java

Si solo tienes treinta segundos, esta tabla y las tres respuestas que la siguen resumen el artículo. Las valoraciones son heurísticas de arquitectura a fecha de agosto de 2026, no una puntuación absoluta: el detalle y los matices están en las secciones siguientes.

• Si el proyecto usa Spring Boot 4 y el equipo ya trabaja con Spring, Spring AI debería ser normalmente el primer candidato.
• Si necesitas Java independiente del framework, Quarkus, Helidon, Micronaut o mayor portabilidad, LangChain4j parte con ventaja.
• Si el caso consiste únicamente en una o dos llamadas sencillas a un LLM, puede ser mejor usar directamente el SDK oficial del proveedor o un cliente HTTP.

Spring AI nació dentro del ecosistema Spring con una tesis explícita: aplicar a la IA generativa los principios de portabilidad y diseño modular que Spring aplicó a la persistencia o a la mensajería. Alcanzó la versión 1.0 en mayo de 2025 y la 2.0 el 12 de junio de 2026, diseñada para Spring Boot 4.0/4.1 y Spring Framework 7.0, con Java 17 como mínimo, Jackson 3 y anotaciones de null-safety JSpecify en todo el código. La 2.0.1, de 21 de agosto de 2026, es la primera de mantenimiento sobre esa base. Las ramas 1.0.x y 1.1.x siguen recibiendo parches para quien todavía está en Spring Boot 3.

LangChain4j es un proyecto open source independiente, iniciado en 2023 con inspiración en el LangChain de Python pero reescrito con criterios Java —tipado fuerte, POJOs, anotaciones, builders— en lugar de portado. Llegó a 1.0 también en mayo de 2025 y desde entonces publica a un ritmo mucho más alto: la 1.19.0 es del 14 de agosto de 2026, y mantiene en paralelo ramas de mantenimiento como la 1.11.x. Su núcleo es estable, pero varios módulos —el agentic y los starters de Spring, entre otros— siguen versionados como beta, lo que tiene consecuencias que veremos más adelante.

La diferencia de origen explica casi todo lo demás. Spring AI hereda gobernanza, cadencia y soporte comercial del ecosistema Spring, y su público objetivo es el equipo que ya vive en Spring Boot. LangChain4j hereda la ambición funcional del ecosistema LangChain —integraciones con más de veinte proveedores de modelos y más de treinta almacenes de embeddings— y la portabilidad entre frameworks, con una integración especialmente cuidada con Quarkus, que dispone de su propia extensión con dev services, Dev UI y compilación nativa.

En Spring AI el punto de entrada es el ChatClient, una API fluida que se construye a partir de un ChatModel auto-configurado y a la que se encadenan prompts, opciones y respuestas tipadas. La extensibilidad se articula con Advisors: interceptores que envuelven la llamada al modelo y que ya cubren la memoria de conversación, el RAG con el QuestionAnswerAdvisor o las salvaguardas. En 2.0 la propia ejecución de herramientas dejó de vivir dentro de cada ChatModel y pasó a ser un Advisor más, el ToolCallingAdvisor, con puntos de extensión explícitos para inicializar, interceptar y finalizar el bucle de llamadas. Es la misma idea que los interceptores de Spring MVC o los aspectos de Spring AOP, y quien conoce Spring la reconoce al instante.

En LangChain4j el modelo dominante son los AI Services: defines una interfaz Java, anotas sus métodos con @SystemMessage y @UserMessage, declaras parámetros con @V y devuelves un tipo de dominio —un record, una lista, un enum—, y el framework genera la implementación. Es el mismo patrón declarativo que Spring Data aplica a los repositorios, aplicado al LLM. Memoria, herramientas, recuperación y guardrails se conectan a esa interfaz mediante el builder o mediante anotaciones, y en Quarkus o Spring Boot basta con inyectar la interfaz.

Ninguno de los dos enfoques es mejor en abstracto: el ChatClient da control explícito de cada llamada y encaja donde el prompt cambia según el flujo; los AI Services ocultan mejor el LLM detrás de un contrato de dominio. Los tres ejemplos que siguen muestran la diferencia con código, y la tabla resume la correspondencia entre conceptos.

El caso más simple de integrar un LLM en Java: un servicio que resume un documento. En Spring AI se inyecta un ChatClient.Builder auto-configurado y la llamada es una cadena fluida; en LangChain4j se declara una interfaz y el framework la implementa. Los dos fragmentos hacen exactamente lo mismo.

@Service
public class ResumenService {

    private final ChatClient chatClient;

    public ResumenService(ChatClient.Builder builder) {
        this.chatClient = builder.build();
    }

    public String resumir(String documento) {
        return chatClient.prompt()
            .system("Resume documentos en tres frases, en español.")
            .user(documento)
            .call()
            .content();
    }
}

public interface Resumidor {

    @SystemMessage("Resume documentos en tres frases, en español.")
    String resumir(@UserMessage String documento);
}

// Java plano, Quarkus, Helidon...: se construye explícitamente
Resumidor resumidor = AiServices.builder(Resumidor.class)
    .chatModel(chatModel)
    .build();

// Spring Boot: basta anotar la interfaz con @AiService e inyectarla

Aquí está una de las ventajas competitivas de hacer IA generativa con Java frente a Python: el contrato con el modelo puede ser un record inmutable, tipado y validable, no un diccionario. Ambos frameworks convierten la respuesta del modelo en ese tipo, y el resto de la aplicación trabaja con un objeto Java normal.

public record TicketClassification(
    String category,      // facturacion | tecnico | comercial
    double confidence,    // 0.0 - 1.0
    String reasoning
) {}

TicketClassification result = chatClient.prompt()
    .system("Clasifica tickets de soporte en: facturacion, tecnico, comercial.")
    .user(ticket)
    .call()
    .entity(TicketClassification.class);

public interface TicketClassifier {

    @SystemMessage("Clasifica tickets de soporte en: facturacion, tecnico, comercial.")
    TicketClassification classify(@UserMessage String ticket);
}

El tool calling en Java tiene una virtud: la herramienta es un método de un servicio normal, con su inyección de dependencias, sus transacciones y sus tests. Lo único que cambia entre frameworks es la anotación y cómo se registra. El servicio de negocio —OrderService— no sabe que existe un LLM.

@Component
public class OrderTools {

    private final OrderService orderService;
    // ...constructor

    @Tool(description = "Devuelve el estado actual de un pedido a partir de su identificador")
    public String getOrderStatus(
            @ToolParam(description = "Identificador del pedido, p. ej. ORD-10234") String orderId) {
        return orderService.findStatus(orderId).map(Enum::name).orElse("NOT_FOUND");
    }
}

// Por llamada (o como ToolCallback bean con defaultTools):
String answer = chatClient.prompt()
    .user("¿En qué estado está el pedido ORD-10234?")
    .tools(orderTools)
    .call()
    .content();

public class OrderTools {

    private final OrderService orderService;
    // ...constructor

    @Tool("Devuelve el estado actual de un pedido a partir de su identificador")
    public String getOrderStatus(
            @P("Identificador del pedido, p. ej. ORD-10234") String orderId) {
        return orderService.findStatus(orderId).map(Enum::name).orElse("NOT_FOUND");
    }
}

Assistant assistant = AiServices.builder(Assistant.class)
    .chatModel(chatModel)
    .tools(new OrderTools(orderService))
    .build();

// Spring Boot: cualquier @Component con métodos @Tool se registra automáticamente

La comparación completa, con el estado de cada proyecto en el momento de escribir. Conviene leerla con una cautela: ambos publican con frecuencia y varias celdas envejecerán en meses, no en años. La dirección de cada proyecto, en cambio, cambia despacio y es lo que debería pesar en la decisión.

En la llamada básica al modelo y en el RAG sencillo, ambos frameworks se parecen tanto que la elección no debería depender de eso. Donde divergen es en las tres capas que separan un chatbot de una aplicación que hace cosas: herramientas, conexión con sistemas y orquestación.

En herramientas, Spring AI 2.0 dio un paso que conviene entender. Al sacar el bucle de tool calling de cada implementación de ChatModel y convertirlo en un Advisor, el comportamiento es el mismo con cualquier proveedor y se puede interceptar en cada fase: antes de la llamada, después de cada ejecución de herramienta, al cerrar el bucle. Sobre esa base construyó la divulgación progresiva de herramientas —el modelo no recibe cien definiciones de golpe, sino que busca las que necesita—, con la que el propio equipo reporta reducciones de consumo de tokens del 34 al 64 % en sus pruebas. Para aplicaciones con decenas de herramientas es la diferencia entre un contexto manejable y uno que degrada la decisión del modelo, un problema que ya tratamos en harness engineering.

En MCP la ventaja de Spring AI es estructural: el MCP Java SDK oficial se desarrolla en estrecha colaboración con el equipo de Spring AI, y 2.0 lo integra con un modelo de anotaciones para exponer herramientas, recursos y prompts, transporte Streamable HTTP por defecto, seguridad OAuth 2.0 y métricas. Si tu plan pasa por exponer sistemas Java a agentes —el ERP, el core, el sistema de expedientes— como servidores MCP, es el camino más corto. LangChain4j ofrece un cliente MCP al día con la especificación, pero el lado servidor lo delega en el ecosistema Quarkus.

En agentes la ventaja está en el otro lado. LangChain4j ha construido un módulo agentic que cubre los patrones de composición —secuencia, paralelo, bucle con condición de salida, enrutado condicional—, un supervisor que planifica sobre subagentes, un planificador orientado a objetivos, un espacio compartido (AgenticScope) que actúa como pizarra entre agentes, human-in-the-loop con suspensión y reanudación resistentes a caídas y, en 1.19, compensación de acciones para deshacer efectos cuando un paso posterior falla. Spring AI ofrece los bloques —advisors, bucle de herramientas, memoria— y deja la orquestación en tu código o en proyectos que se apoyan sobre Spring, como Embabel. Es una diferencia de filosofía: Spring AI te da primitivas, LangChain4j te da un motor.

• Herramientas a escala (decenas o cientos): Spring AI, por la divulgación progresiva y el bucle unificado.
• Exponer sistemas Java como servidores MCP: Spring AI.
• Orquestación multiagente con patrones de serie: LangChain4j, aceptando que el módulo es beta.
• Workflows deterministas con un LLM dentro: cualquiera de los dos; aquí la diferencia la hace tu código, no el framework.

La tabla informa; estos cinco criterios deciden. Están ordenados por el peso que suelen tener en un proyecto real, y los dos primeros resuelven la mayoría de los casos sin necesidad de seguir. Son heurísticas, no reglas: cada una admite excepciones que conviene razonar.

El primero es el stack. Si la aplicación es Spring Boot 4 y el equipo vive en Spring, Spring AI es la opción por defecto: misma auto-configuración, mismas propiedades, misma observabilidad con Micrometer, mismo ciclo de releases. Si es Quarkus, la extensión de LangChain4j es probablemente la mejor experiencia de desarrollo con IA en Java, con dev services para levantar Ollama o pgvector y compilación nativa probada. Si es Java plano, Helidon o Micronaut, LangChain4j es la única de las dos que aplica de forma natural. Y si todavía estás en Spring Boot 3, Spring AI 1.1.x sigue soportado pero no recibe las novedades de 2.0, así que la decisión se mezcla con la de migrar a Boot 4.

El segundo es cuánta orquestación necesitas de serie, y ya lo hemos tratado: primitivas frente a motor. El tercero es MCP: consumidor o proveedor. Consumir servidores MCP lo hacen bien ambos; exponerlos desde Java con seguridad y métricas es hoy terreno de Spring AI. El cuarto es la tolerancia al cambio. Spring AI se mueve con Spring Boot, con migraciones documentadas y ramas de mantenimiento largas; LangChain4j publica casi cada mes, y sus módulos beta pueden cambiar de API entre versiones. Un equipo con ventanas de despliegue trimestrales y un equipo que despliega a diario no deberían responder igual a esta pregunta.

El quinto es el equipo y el soporte. Spring AI puede cubrirse con el soporte comercial de Spring y con la formación que ya tiene cualquier desarrollador Spring; LangChain4j depende de una comunidad activa, de documentación buena y de la extensión de Quarkus cuando aplica. No es un criterio menor en sectores regulados donde el comité de arquitectura pregunta quién responde cuando algo falla.

• Stack: Spring Boot 4 → Spring AI suele ser el primer candidato; Quarkus, Micronaut, Helidon o Java plano → LangChain4j parte con ventaja.
• Orquestación: primitivas y código propio → Spring AI; patrones multiagente de serie → LangChain4j.
• MCP: solo cliente → cualquiera; servidor con OAuth y métricas → Spring AI.
• Ritmo de cambio: ventanas de despliegue largas → Spring AI; capacidad de absorber releases mensuales → LangChain4j.
• Soporte: contrato comercial y conocimiento Spring existente → Spring AI; comunidad y Quarkus → LangChain4j.

Hay una tercera opción que rara vez se plantea porque no sale en las comparativas: el SDK oficial del proveedor, un cliente HTTP o, en Spring, el propio RestClient. Anthropic y OpenAI publican SDK Java oficiales, tipados y mantenidos, y para una aplicación que hace una o dos llamadas a un único proveedor —clasificar, resumir, extraer campos—, sin RAG, sin herramientas y sin memoria, un framework añade una capa de abstracción, una dependencia con su propio ritmo de cambio y una curva de aprendizaje que no se amortizan. La abstracción se debe pagar solo cuando aporta valor.

La señal para saberlo es sencilla: si puedes describir la integración en una frase —"clasificamos cada ticket entrante en una de cinco categorías", "resumimos el documento antes de archivarlo"— probablemente no necesitas framework. Si la frase incluye "y luego consulta", "y decide si", "y recuerda que", ya estás describiendo herramientas, orquestación o memoria, y ahí un framework empieza a pagar su coste.

También conviene ser honesto con el coste de la portabilidad entre proveedores, que es el argumento estrella de ambos frameworks. Cambiar de modelo cambiando una propiedad es real, pero los prompts, las herramientas y las evals no son portables por arte de magia: un prompt afinado para un modelo se degrada en otro, y sin un conjunto de evals no sabrás cuánto. La portabilidad del framework te ahorra el código de integración; no te ahorra la validación.

Sea cual sea la elección, el riesgo real no es equivocarse de framework sino dejar que el framework se infiltre en el dominio. Las dos librerías evolucionan rápido: Spring AI 2.0 cambió la forma de registrar herramientas y de configurar opciones respecto a 1.x, y los módulos beta de LangChain4j pueden cambiar de API entre releases. Si los tipos del framework aparecen en tus servicios de negocio, cada actualización se convierte en una migración.

La disciplina que funciona es la de siempre: una fachada de dominio propia —"clasificar ticket", "resumir expediente", "proponer respuesta"— con contratos en records de Java, herramientas implementadas como servicios normales sin anotaciones del framework en su interfaz pública, y el ChatClient o el AI Service confinados en un adaptador. Es la arquitectura hexagonal aplicada al LLM: el modelo es un puerto de salida más, como la base de datos o la cola de mensajes, y Spring AI o LangChain4j son adaptadores de infraestructura, no el centro del dominio.

Dominio Java (casos de uso, records, reglas de negocio)
    │
    ▼
Puerto / interfaz propia   →   ClasificadorDeTickets.clasificar(Ticket)
    │
    ├── Adaptador Spring AI        (ChatClient + Advisors)
    │
    └── Adaptador LangChain4j      (AI Service + tools)
            │
            ▼
       OpenAI / Anthropic / Gemini / Mistral / Ollama...

• Fachada de dominio con records propios; ningún tipo del framework fuera del adaptador.
• Herramientas como servicios Java normales; las anotaciones del framework, en una clase envoltorio.
• Prompts versionados junto al código, con evals que los acompañen.
• Tests de integración con Testcontainers y un modelo local; los contratos, sin red.
• Proveedor de LLM aislado tras el adaptador: cambiar de modelo no debe tocar el dominio.
• Observabilidad desde el día uno: tokens, latencia y coste por endpoint y por tenant.

Para cerrar, la versión operativa. Recorre las preguntas por orden con tu caso de uso delante, no con una lista de deseos, y detente en la primera que decide. Cada respuesta es la opción habitual, no una regla: si tu contexto la contradice, razona la excepción y documéntala.

• ¿La integración cabe en una frase sin "y luego", "y decide" ni "y recuerda"? Sí → SDK oficial, cliente HTTP o RestClient suelen bastar.
• ¿La aplicación es Quarkus, Micronaut, Helidon o Java plano? Sí → LangChain4j parte con ventaja.
• ¿Vas a exponer sistemas Java como servidores MCP con seguridad y métricas? Sí → Spring AI es hoy el camino más corto.
• ¿Necesitas patrones multiagente de serie (supervisor, bucles, human-in-the-loop) y puedes absorber un módulo beta? Sí → LangChain4j.
• ¿Es Spring Boot 4 y el equipo es Spring? Sí → Spring AI es normalmente el primer candidato. Es el caso más frecuente y el de menor fricción.
• ¿Sigues en Spring Boot 3 sin fecha de migración? → Spring AI 1.1.x hoy, con la migración a Boot 4 y Spring AI 2.0 en el plan; o LangChain4j si la migración no va a ocurrir.
• Sea cual sea la respuesta: fachada de dominio, herramientas como servicios Java y evals antes de producción.

Este artículo es la entrada de la serie de DatIACode sobre inteligencia artificial con Java. Lo que ya está publicado y encaja con la decisión que acabas de tomar:

• Spring AI, RAG y agentes: cómo construir aplicaciones Java con IA real: la arquitectura completa —memoria, recuperación, herramientas— sobre Spring AI.
• MCP vs RAG: cuándo recuperar conocimiento y cuándo ejecutar herramientas y qué es MCP y cómo conectar agentes a los sistemas de tu empresa.
• Evals: cómo evaluar agentes de IA y harness engineering: las dos disciplinas que hacen portable un prompt y gobernable una herramienta.
• Observabilidad de agentes de IA en producción y LLM en local para empresas: operar y desplegar con control.
• Código generado por IA y ciberseguridad: el otro lado de la IA en el desarrollo Java, el código que escriben los agentes.