
📺 Vídeo de estudio recomendado hoy: https://www.youtube.com/watch?v=_ZZuzakjgxQ
Domina Spring AI: Construyendo Agentes Complejos con Patrones Simples
La IA generativa no se trata solo de entrenar modelos, sino de cómo usamos su inteligencia como una “caja negra” dentro de sistemas robustos. En este artículo, exploramos cómo Spring AI utiliza conceptos mínimos para orquestar comportamientos agenticos sofisticados y predecibles.
Pregunta central: ¿Cómo pueden unos pocos bloques de construcción como los Advisors y las Tools permitirnos construir casi cualquier patrón complejo en Spring AI?
Puntos clave
- El concepto de “Advisor” como interceptor fundamental para gestionar el estado y la validación.
- La transición del “Prompt Engineering” al “Agent Harnessing” para el control de calidad.
- Estrategias de “Progressive Disclosure” para evitar la saturación del contexto del LLM.
- Implementación de sub-agentes y bucles de retroalimentación para tareas multi-paso.
⏱️ Tiempo de lectura: aprox. 8 minutos · Te ahorra unos 44 minutos frente a ver el vídeo.
¿Quieres tomar notas mientras ves el vídeo? Haz clic en la imagen de abajo y deja que AI Notebook extraiga los puntos clave por ti 👇
El Corazón de Spring AI: Advisors e Intercepción
Comprendiendo la “Caja Negra” del LLM
Para construir aplicaciones eficaces, primero debemos aceptar la naturaleza de los modelos de lenguaje: son apátridas (stateless), no deterministas y tienen una ventana de contexto limitada.
Spring AI introduce el concepto de Advisor (o interceptor) para resolver esto.
Un Advisor actúa como un gancho que intercepta la comunicación antes de que llegue al LLM y después de que este genera una respuesta. Es un patrón similar a los filtros en el desarrollo web, permitiendo aumentar o modificar el contexto de manera transparente para el usuario final. Gracias a esta arquitectura, podemos inyectar memoria de chat, aplicar reglas de seguridad o enriquecer el prompt con datos externos sin contaminar la lógica de negocio principal.

💡 Profundizando
Q: ¿Cuál es la diferencia técnica entre un Interceptor y un Advisor en Spring AI?
A: En esencia son lo mismo; el Advisor es el componente que permite “aumentar” la información que entra y sale, facilitando la modularidad del código.
Q: ¿Por qué es crítica la intercepción en modelos apátridas?
A: Porque sin ella, el LLM no recordaría interacciones previas. El Advisor intercepta el mensaje, busca el historial en un almacenamiento de memoria y lo adjunta al prompt automáticamente.
Q: ¿Cómo afecta esto a la latencia?
A: Cada Advisor añade una pequeña capa de procesamiento, pero es insignificante comparada con el tiempo de inferencia del LLM, y es vital para la calidad de la respuesta.
Validación y Estructura: Guardrails y Salidas JSON
Forzando el orden en el caos textual
Uno de los mayores desafíos es que los LLMs devuelven texto no estructurado, lo que dificulta la integración con sistemas tradicionales que esperan tipos de datos concretos.
Spring AI soluciona esto mediante el StructuredOutputAdvisor. Este componente no solo pide al modelo que responda en un formato específico (como un esquema JSON), sino que también valida la respuesta. Si el modelo falla y entrega un JSON mal formado, el Advisor captura el error, genera un mensaje de retroalimentación indicando qué falló y vuelve a consultar al LLM de forma automática.
Este bucle de autoreparación ocurre sin intervención del usuario.
Es una forma de “harnessing” o arnés de control. Al usar un segundo LLM como “juez”, podemos incluso verificar si la respuesta es veraz o si contiene palabras sensibles. Si el juez detecta un problema, el sistema puede decidir no entregar la respuesta al cliente o intentar una nueva generación con mejores instrucciones.

Progressive Disclosure: Optimizando el Contexto
El problema de tener demasiadas herramientas
Cuando registramos cientos de funciones o “Tools” para que el LLM las use, saturamos su ventana de tokens y aumentamos el riesgo de confusión o alucinaciones.
La solución es el Tool Search Tool.
En lugar de enviar todas las definiciones de herramientas en cada petición, registramos una única herramienta de búsqueda. El proceso es elegante: el LLM recibe el problema y, si nota que le falta información, llama a la “herramienta de búsqueda”. Spring AI busca entonces en un índice (vectorial o de texto) las herramientas más relevantes y las registra dinámicamente para ese turno de conversación.
Este patrón de “revelación progresiva” se aplica también a los Agent Skills. Podemos empaquetar conocimientos o scripts en archivos Markdown o JARs que el agente solo consulta y carga cuando el flujo de la conversación lo requiere específicamente, manteniendo el contexto limpio y eficiente.

Patrones Avanzados: To-Do Lists y Sub-agentes
Asegurando la ejecución de tareas complejas
Los modelos suelen ser demasiado “opinados” o se pierden en tareas largas que requieren múltiples pasos intermedios.
Para mitigar esto, podemos forzar al LLM a crear una lista de tareas (To-Do List) al inicio. Mediante un Advisor específico, obligamos al modelo a seguir un ciclo de vida para cada tarea: pendiente, en progreso y completado. El sistema no le permite avanzar al siguiente paso hasta que el anterior esté validado, garantizando que no se salte procesos críticos.
Finalmente, el patrón de Sub-agentes permite la segregación absoluta de responsabilidades. Si una tarea requiere el uso de herramientas muy específicas que podrían ensuciar el contexto principal, delegamos esa tarea a un agente hijo con su propio contexto aislado. El agente principal solo recibe el resultado final, manteniendo su memoria libre de detalles técnicos irrelevantes del subproceso.
Conclusiones clave
El éxito en la implementación de IA generativa con Spring AI no depende de la complejidad del modelo, sino de la inteligencia de la arquitectura que lo rodea. Los Advisors se consolidan como la herramienta más potente para cualquier desarrollador, permitiendo inyectar lógica de control, validación y memoria de forma modular.
Al adoptar estrategias como la revelación progresiva de herramientas y el uso de sub-agentes, resolvemos el límite de tokens y mejoramos la precisión de las respuestas. La clave es dejar que el LLM decida qué necesita en lugar de intentar predecirlo todo de antemano.
Spring AI se posiciona así no solo como un cliente para interactuar con modelos, sino como un framework completo de “harnessing” capaz de convertir una IA creativa en una herramienta empresarial fiable y estructurada.
Preguntas y Respuestas
Q1: ¿Qué es exactamente el “Agent Harnessing” en el contexto de Spring AI?
A1: Es todo lo que rodea al LLM (memoria, herramientas, validadores, flujos) para que su salida sea útil y segura dentro de una aplicación corporativa.
Q2: ¿Cómo ayuda el Tool Search Tool a ahorrar dinero?
A2: Al enviar menos definiciones de herramientas en cada prompt, consumes menos tokens por cada llamada a la API, lo que reduce drásticamente los costes en modelos de pago por uso.
Q3: ¿Puedo usar diferentes modelos para el agente principal y el agente juez?
A3: Sí, de hecho es una práctica recomendada. Puedes usar un modelo grande para la tarea principal y uno más pequeño y rápido (como GPT-4o-mini) para actuar como Advisor de validación.
Q4: ¿Qué sucede si el LLM entra en un bucle infinito de errores en el Structured Output Advisor?
A4: El Advisor permite configurar un número máximo de intentos para evitar bucles infinitos y consumos excesivos de tokens.
Q5: ¿Cuál es el beneficio de usar Agent Skills en formato JAR?
A5: Permite la portabilidad y el aislamiento. Puedes distribuir capacidades específicas de IA como dependencias estándar de Java que incluyen sus propios prompts y lógica de ejecución.
Q6: ¿Por qué es importante el orden de los Advisors en la cadena?
A6: El orden determina qué se procesa primero. Por ejemplo, si pones el Advisor de memoria antes que el de herramientas, la memoria solo guardará la pregunta inicial y no los pasos intermedios de las llamadas a funciones.
Q7: ¿Los patrones mostrados son compatibles con cualquier modelo (OpenAI, Anthropic, Ollama)?
A7: Sí, Spring AI está diseñado como una abstracción portátil; mientras el modelo soporte capacidades básicas de chat o llamadas a funciones, estos patrones funcionarán.
