Ir al contenido principal

Por Qué la Infraestructura de Agentes es Crucial


Por Qué la Infraestructura de Agentes es Crucial

En el último año, la industria ha sido testigo del auge de las aplicaciones basadas en agentes, que van desde copilotos de flujo de trabajo hasta asistentes de generación de código e investigadores profundos. Estas aplicaciones combinan el uso de herramientas, la memoria y el razonamiento para completar tareas complejas de varios pasos, superando la simple recuperación de información y el chat para tomar acciones concretas.

Los agentes están transformando la forma en que concebimos las aplicaciones. Ya no se trata solo de una serie de solicitudes y respuestas reducidas a formularios de entrada, botones, elementos visuales o interfaces de chat. En cambio, los agentes recuerdan, razonan y actúan. Trabajan en segundo plano a partir de eventos e información. No solo actúan, sino que también piden ayuda, muestran su trabajo, razonan para resolver problemas y colaboran en grupo. Y si bien la computación sin estado y sin servidor sigue siendo un ideal para los sistemas distribuidos, se queda corta para las aplicaciones basadas en agentes. Este nuevo estilo de aplicación requiere una nueva infraestructura.

A menudo, los agentes son:

  • De larga duración: Razonan y ejecutan una tarea durante minutos, no milisegundos.
  • Con estado: Mantienen la memoria y conservan el contexto entre pasos o de interacciones pasadas.
  • De actividad intermitente: Especialmente en escenarios programados o activados por el usuario.

Intentar encajar un agente con estas características en las arquitecturas de microservicios o sin servidor existentes a menudo conduce a sistemas frágiles y propensos a fallos.

La Necesidad de una Infraestructura de Agentes

Las cargas de trabajo basadas en agentes exigen nuevas primitivas que ni los backends web ni los sistemas distribuidos tradicionales proporcionan. Está surgiendo una nueva capa en la pila de agentes: la infraestructura de agentes. Esta se sitúa entre la lógica del agente y la computación en bruto, proporcionando estructura, control y fiabilidad.

La infraestructura de agentes está construida específicamente para soportar la ejecución duradera, la gestión compleja del estado, la coordinación con intervención humana, el streaming y más, sin necesidad de unirlo todo manualmente. Un ejemplo de solución a nivel de infraestructura de agentes es LangGraph Platform, una plataforma diseñada para implementar y ejecutar aplicaciones LangGraph con una infraestructura de agentes escalable y fiable.

Ejecución Duradera: Los Agentes Tardan Tiempo

La mayoría de los entornos sin servidor están optimizados para tareas de corta duración. Pero los agentes, desde los asistentes de investigación hasta los copilotos de flujo de trabajo, pueden ejecutarse durante varios segundos, a menudo minutos, o incluso horas en casos extremos. Pueden pausarse para llamar a herramientas, esperar a las API o recibir comentarios de personas.

Imagina un agente que debe reservar un vuelo y un hotel. Este proceso puede implicar múltiples llamadas a APIs, esperas para obtener precios, y la necesidad de aprobación por parte de un usuario. Si la infraestructura no soporta la ejecución a largo plazo, el agente podría "olvidar" el contexto o incluso fallar en medio de la reserva.

En LangGraph, estos agentes se suspenden y se reanudan de forma segura más tarde, pero muchos sistemas no pueden manejar estas pausas largas o impredecibles. Sin el tiempo de ejecución adecuado, los agentes de larga duración corren el riesgo de agotarse el tiempo de espera, bloquearse o perder el progreso.

La infraestructura de agentes proporciona:

  • Ejecución en segundo plano para que los agentes puedan ejecutarse independientemente de la solicitud inicial.
  • Señales de latido para evitar tiempos de espera señalando el progreso continuo.
  • Ejecuciones reanudables para restaurar desde puntos de control después de bloqueos o pausas.

Esta durabilidad es esencial para construir agentes fiables y de calidad para la producción que trabajen hasta la finalización exitosa de la tarea, sin importar cuánto tiempo lleve.

Gestión del Estado: Los Agentes Necesitan Más que Buffers de Mensajes

El "estado" de un agente puede incluir resultados intermedios, salidas de herramientas, documentos integrados o contexto multi-turno. La infraestructura tradicional no ofrece una forma estructurada de almacenar, reanudar o editar este estado a mitad de la ejecución. Una infraestructura de agentes puede proporcionar el almacenamiento y el punto de control necesarios OOTB (Out Of The Box) para persistir el estado entre pasos, fallos o intervenciones del usuario.

Para entenderlo mejor, piensa en un agente que está redactando un informe. A medida que avanza, necesita recordar la información que ya ha recopilado, las fuentes que ha consultado y la estructura que está siguiendo. Una infraestructura que gestione el estado permite que el agente retome el trabajo donde lo dejó, incluso si se interrumpe el proceso.

Intervención Humana: Los Agentes Necesitan Esperar, Pausar y Reanudar

Los agentes con frecuencia confían en la retroalimentación humana para la aprobación o aclaración antes de continuar. Eso significa que no puedes simplemente disparar una solicitud y olvidarte de ella. Necesitas un estado reanudable y soporte para retrasos arbitrariamente largos entre pasos.

La infraestructura de agentes te permite utilizar las API para pausar o reanudar sin conectar colas, cachés y puntos finales de sondeo manualmente.

Considera un agente que está automatizando la aprobación de un crédito. En ciertos casos, el agente puede necesitar la intervención de un analista humano para evaluar la solicitud. La infraestructura debe permitir que el agente pause el proceso, notifique al analista, y luego reanude la ejecución una vez que se haya recibido la aprobación.

Concurrencia Intermitente: Los Agentes Deben Absorber los Picos de Tráfico

Las aplicaciones de agentes del mundo real pueden enfrentarse a aumentos repentinos impredecibles, ya sea millones de usuarios que consultan una aplicación de búsqueda de IA a la vez, o un asistente de investigación profunda programado que ejecuta su trabajo de fin de día para equipos enteros. Estos picos pueden provocar atascos de tráfico de solicitudes, solicitudes descartadas o un rendimiento degradado.

Una infraestructura de agentes como LangGraph Platform está diseñada para absorber estas ráfagas con:

  • Colas de tareas, que almacenan en búfer y programan las ejecuciones entrantes de forma eficaz (incluso con una carga pesada).
  • Auto-escalado horizontal, donde se pueden añadir dinámicamente nuevos trabajadores e instancias de cola para garantizar que cada ejecución se procese una sola vez.

Esto elimina así la necesidad de una lógica de equilibrio de carga personalizada y ayuda a que tu agente se mantenga estable incluso bajo un alto rendimiento o cargas de trabajo impredecibles.

Imagina una aplicación que utiliza un agente para responder preguntas sobre un producto durante una campaña de marketing. Si la campaña tiene mucho éxito, la aplicación podría experimentar un aumento repentino en el número de preguntas. Una infraestructura de agentes escalable podría manejar este aumento sin afectar el rendimiento.

Streaming: Observa lo que Piensan tus Agentes

Los agentes no se limitan a devolver un resultado final, sino que piensan, actúan y perfeccionan su respuesta con el tiempo.

Una buena infraestructura de agentes hace que su salida intermedia (por ejemplo, pensamientos, llamadas a herramientas, finalizaciones parciales) sea visible para mejorar la experiencia del usuario y la visibilidad del desarrollador. Por ejemplo, LangGraph Platform permite:

  • Streaming a nivel de token, que te permite transmitir la salida LLM token por token desde cualquier nodo, subgrafo, herramienta o tarea en LangGraph.
  • Streaming de datos personalizado, que emite datos estructurados definidos por el usuario en cualquier punto del gráfico utilizando el modo de streaming personalizado, lo que permite una comunicación flexible más allá de las respuestas de texto estándar.
  • IU generativa de streaming, que renderiza componentes dinámicos para interfaces de usuario enriquecidas.

Dado que todos los modos de streaming contienen metadatos de contexto, puedes rastrear cada salida hasta su origen, lo que facilita la depuración y el control del comportamiento de tu agente también.

El Futuro es Basado en Agentes: Construye Sobre una Base Sólida

Las aplicaciones basadas en agentes han llegado para quedarse. Pero al igual que cada cambio en el software, ya sea de monolitos a microservicios, o de on-premise a la nube, la transición requiere nuevas herramientas.

La infraestructura de agentes es la capa que falta. Y si estás construyendo algo más allá de un prompt sin estado, es hora de pensar seriamente en lo que soporta a tus agentes entre bastidores.

Referencia:

Entradas populares de este blog

Event Driven Architecture & Big ball of mud

EDA Una arquitectura event-driven (EDA) es un estilo de diseño que se basa en la producción, detección y reacción a eventos. Un evento es un cambio de estado significativo en el sistema o en el entorno que puede ser notificado a otros componentes interesados. Una arquitectura event-driven permite una mayor desacoplamiento, escalabilidad y resiliencia entre los componentes del sistema, así como una mejor adaptabilidad a los cambios y a las necesidades del negocio. Sin embargo, una arquitectura event-driven también puede tener sus desafíos y riesgos, especialmente si no se aplica una buena gestión de los dominios y los boundaries. Un dominio es un conjunto de conceptos, reglas y procesos relacionados con un aspecto del negocio o del problema que se quiere resolver. Un boundary es una frontera lógica que separa y protege un dominio de otros dominios o de influencias externas. Un buen diseño de dominios y boundaries facilita la comprensión, el mantenimiento y la evolución del sistema, así ...

¿Qué es el patrón Circuit Breaker y cómo se puede implementar con AWS Step Functions?

En el desarrollo de software, es común que las aplicaciones se comuniquen con servicios o recursos externos, como bases de datos, APIs o microservicios. Sin embargo, estos servicios o recursos pueden fallar o estar temporalmente indisponibles por diversas razones, lo que puede afectar el rendimiento y la disponibilidad de la aplicación. Para manejar estos escenarios de falla, se puede utilizar el patrón Circuit Breaker, que consiste en detectar y prevenir que una operación que tiene alta probabilidad de fallar se ejecute repetidamente, causando más problemas o consumiendo recursos innecesarios.  El patrón Circuit Breaker tiene tres estados posibles: cerrado, abierto y medio abierto. Cerrado : En este estado, el circuito está funcionando normalmente y la operación se ejecuta sin problemas. Si se detecta una falla, se incrementa un contador de fallas y se calcula un umbral de fallas, que puede ser un número o un porcentaje de fallas permitidas. Si el contador de fallas supera el u...

¿Cómo usar Lambda con Amazon SQS para procesar mensajes de forma asíncrona y escalable?

Amazon Simple Queue Service (Amazon SQS) es un servicio de colas de mensajes que permite enviar y recibir mensajes entre componentes de una aplicación de forma fiable y duradera. Con Amazon SQS, se puede desacoplar la lógica de negocio de la fuente de los eventos, y procesarlos de forma asíncrona y en paralelo.   En este artículo, vamos a ver cómo usar Lambda con Amazon SQS para procesar mensajes de una cola de forma eficiente y flexible, aprovechando las características de concurrencia, escalamiento y procesamiento del event source mapping de Lambda, así como la estrategia de backoff que implementa Lambda para manejar errores y reintentos.   Concurrencia del event source mapping Un event source mapping es una configuración que le dice a Lambda qué fuente de eventos debe monitorear y qué función debe invocar cuando se produzca un evento. En el caso de Amazon SQS, el event source mapping se encarga de leer los mensajes de la cola y enviarlos a la función Lambda en lotes. La con...