A medida que sus agentes de IA pasan del prototipo a la producción, los desafíos pasan de ponerlos a trabajar a mantenerlos rápidos y eficientes. En la Parte 1 de esta serie, analizamos la depuración de dos fallas comunes de los agentes: bucles infinitos y errores de invocación de herramientas. Esos escenarios trataban de agentes que estaban desmantelados. En esta publicación, abordamos un desafío diferente: agentes que funcionan correctamente pero tienen un desempeño deficiente. Los tiempos de respuesta lentos y el crecimiento ilimitado de la memoria son los problemas operativos más comunes que surgen después de resolver los problemas de depuración iniciales. No activan alertas de error, pero erosionan la confianza del usuario y aumentan los costos con el tiempo.
Con AgentCore Observability, una capacidad de Amazon Bedrock AgentCore y Amazon CloudWatch, aprenderá a identificar cuellos de botella de rendimiento en la ruta de ejecución de su agente y a diagnosticar problemas de memoria en sesiones de larga duración. También implementará prácticas de monitoreo que detecten la degradación antes de que los usuarios la noten. Para obtener información adicional y mejores prácticas, revise AgentCore Assessments, una capacidad de Amazon Bedrock AgentCore y AgentCore Insights.
Necesita una cuenta de AWS con acceso a Amazon Bedrock AgentCore, CloudWatch Transaction Search habilitado y un agente implementado. Consulte la Parte 1 para obtener detalles completos de la configuración.
Escenario 3: cuellos de botella en el rendimiento
Los agentes experimentan cuellos de botella en el rendimiento cuando trabajan correctamente pero responden con demasiada lentitud. Espera respuestas de menos de un segundo, pero experimenta retrasos de varios segundos. Los agentes completan las tareas con éxito, pero la latencia las hace poco prácticas para casos de uso interactivos. Este escenario es particularmente desafiante porque la lentitud es subjetiva. Lo que es aceptable para un agente de procesamiento por lotes es inaceptable para un chatbot de servicio al cliente. Debe establecer presupuestos de rendimiento para su caso de uso específico y luego identificar sistemáticamente qué componentes violan esos presupuestos.
Síntomas a tener en cuenta
La degradación del rendimiento suele manifestarse de forma gradual. Los agentes pueden comenzar con tiempos de respuesta aceptables de 2 segundos, pero a medida que agrega funciones, integra más herramientas o acumula más memoria, la latencia aumenta a 5 segundos, luego a 10 y luego se vuelve inutilizable. Los tiempos de respuesta de P95 superan sus umbrales, los usuarios abandonan las sesiones, pero las tasas de error se mantienen bajas. El agente funciona correctamente pero responde demasiado lento.
Figura 1: Detalles de la sesión que muestran múltiples seguimientos con una latencia alta y constante. Las tres invocaciones tardaron entre 7,5 y 8,2 segundos (latencia promedio), lo que demuestra un cuello de botella en el rendimiento sistémico en lugar de una lentitud ocasional. Este patrón indica que la arquitectura del agente necesita optimización.
Para encontrar cuellos de botella, comience por identificar las solicitudes de alta latencia. Consulte CloudWatch para ver si hay invocaciones de agentes que excedan su presupuesto de rendimiento:
Esta consulta devuelve invocaciones de agentes que tardaron más de 3 segundos (ajuste el umbral según sus requisitos), ordenadas por latencia. Elija una solicitud representativa de alta latencia y anote su RequestId.
A continuación, analice el cronograma de la solicitud para comprender dónde se gasta el tiempo:
La consulta le muestra la secuencia de operaciones dentro de la solicitud y cuánto tiempo tomó cada una. Busque operaciones que consuman un tiempo desproporcionado. Los culpables comunes incluyen operaciones de recuperación de memoria, invocaciones de herramientas, generación de tokens y operaciones secuenciales que podrían ejecutarse en paralelo.
Figura 2: Línea de tiempo de seguimiento de OpenTelemetry que muestra 17 tramos en tres operaciones secuenciales de ejecución_event_loop_cycle. Las herramientas (customer_lookup, order_history) se ejecutan una tras otra en lugar de en paralelo, y cada ciclo espera a que se complete el anterior. Este patrón secuencial agrava la latencia en cada invocación de herramienta.
Verifique la latencia de recuperación de memoria específicamente:
La recuperación de la memoria debería completarse en menos de 200 milisegundos, lo que representa el punto en el que los usuarios comienzan a percibir retrasos notables en las aplicaciones interactivas. Una latencia más alta sugiere una organización de la memoria ineficiente.
Examine la latencia de invocación de herramientas para identificar integraciones lentas:
La consulta identifica qué herramientas contribuyen más a la latencia general. Una sola herramienta lenta puede obstaculizar todo el flujo de trabajo del agente.
Análisis de causa raíz
Los cuellos de botella en el rendimiento suelen deberse a tres causas fundamentales. La ejecución lenta de la herramienta ocurre cuando las herramientas externas tardan unos segundos en responder debido a una mala optimización, sobrecarga o problemas de red. Las latencias se agravan con las llamadas secuenciales, por lo que una herramienta de 2 segundos llamada tres veces se convierte en un cuello de botella de 6 segundos. La generación excesiva de tokens es un factor porque los modelos básicos (FM) producen tokens de forma secuencial, lo que significa que una respuesta de 500 tokens tarda 5 veces más que una de 100 tokens, lo que afecta tanto la latencia como el costo. Finalmente, el procesamiento secuencial, que realiza operaciones independientes una a la vez en lugar de en paralelo, aumenta tanto el costo como los tiempos de cómputo.
La solución
Para una ejecución lenta de la herramienta, implemente el almacenamiento en caché, la agrupación de conexiones y la indexación adecuada de la base de datos para reducir los tiempos de respuesta. Establezca límites de tiempo de espera y considere alternativas de herramientas más rápidas. Si una herramienta se retrasa constantemente, perfilela de forma independiente. El problema podría ser la latencia de la red, los arranques en frío o la contención de recursos en lugar de la lógica de la herramienta en sí.
Para la recuperación de memoria, reemplace los espacios de nombres únicos y grandes con particiones de temas específicos, como preferencias, historial y conocimiento del dominio, para reducir el espacio de búsqueda. Resuma conversaciones antiguas en entradas compactas en lugar de almacenarlas palabra por palabra y establezca límites de tamaño por espacio de nombres, como 100 preferencias, 50 mensajes recientes o 500 datos de dominio.
Para la generación de tokens, optimice las indicaciones para fomentar respuestas breves y directas de 2 a 3 oraciones, a menos que se soliciten más detalles. Agregue restricciones de longitud explícitas y supervise el uso de tokens con alertas para respuestas inesperadamente largas.
Para el procesamiento secuencial, ejecute llamadas a herramientas independientes en paralelo. Las llamadas secuenciales que suman un total de 4,5 s (2 s + 1,5 s + 1 s) se reducen a solo 2 s cuando están en paralelo, lo que a menudo reduce la latencia en un 50 por ciento o más con un mínimo esfuerzo. Para verificar sus optimizaciones, vuelva a ejecutar la consulta de latencia desde la sección de identificación de cuellos de botella. Confirme que los tiempos de respuesta de P95 ahora estén dentro de su presupuesto de rendimiento y que el cronograma de seguimiento muestre la ejecución paralela donde se esperaba.
Escenario 4: problemas de memoria en sesiones de larga duración
Los agentes experimentan problemas de memoria en sesiones de larga duración cuando mantienen sesiones en las que el uso de la memoria crece sin límites. Los agentes acumulan contexto y, finalmente, alcanzan límites simbólicos, pierden contexto importante o agotan la memoria disponible. Las sesiones fallan inesperadamente y se pierde el estado de la conversación. Este escenario es particularmente problemático para los agentes que admiten flujos de trabajo extendidos, como sesiones de servicio al cliente, asistentes de investigación o agentes de seguimiento. Sin una gestión adecuada de la memoria, estos casos de uso se vuelven poco prácticos.
Síntomas a tener en cuenta
Cuando existen sesiones de agente anormalmente largas, el uso de tokens crece linealmente con la duración de la sesión. La latencia de recuperación de la memoria aumenta con el tiempo a medida que crecen las reservas de memoria. Las sesiones finalizan inesperadamente con errores de falta de memoria o errores de ventana de contexto excedida.
Figura 3: Detalles de la sesión para Memorygrowth_Agent que muestran 6 seguimientos, 15,7 000 tokens consumidos en total y una latencia de seguimiento promedio de 3757 ms en una sola sesión. El uso de tokens crece con cada invocación sucesiva, lo que demuestra una acumulación ilimitada de contexto. En sesiones de producción que duran horas, este patrón provoca el agotamiento de la ventana de contexto y errores inesperados en la sesión.
Para identificar sesiones de larga duración con un uso elevado de memoria:
La consulta devuelve sesiones que duran más de una hora (3600 segundos), ordenadas por tamaño de memoria. Elija una sesión con un uso de memoria inusualmente alto y anote su SessionId.
Examine los patrones de extracción de memoria para verificar que se esté produciendo la consolidación:
Figura 4: CloudWatch Logs Insights que muestra 209 entradas de registro relacionadas con la memoria concentradas alrededor de las 18:20. El aumento en las operaciones de memoria indica que el agente almacena información sin consolidación. Cada invocación agrega nuevas entradas de memoria (a través de las herramientas add_conversation_note y add_user_context) sin podar ni resumir datos antiguos, lo que demuestra el patrón de crecimiento ilimitado.
La extracción de recuerdos debe realizarse periódicamente durante toda la sesión. Si ve espacios en los que no se produce extracción durante períodos prolongados, el agente no está consolidando los recuerdos correctamente.
Verifique si hay fallas en la extracción de memoria:
La extracción fallida de la memoria impide que los agentes consoliden el contexto, lo que provoca un crecimiento ilimitado. Los motivos de error comunes incluyen límites de token excedidos durante el resumen, formatos de memoria no válidos que no se pueden procesar, tiempos de espera de red al escribir en el almacenamiento de memoria y errores de permisos que bloquean las actualizaciones de la memoria.
Analice la organización del espacio de nombres de la memoria:
Los recuerdos se distribuyen en espacios de nombres. Una mala organización del espacio de nombres puede provocar una recuperación y consolidación de memoria ineficientes. Si ve un único espacio de nombres que contiene miles de recuerdos, es una señal de alerta que indica que su agente necesita una mejor organización de la memoria.
Análisis de causa raíz
Los problemas de memoria generalmente se deben a configuraciones mal configuradas, filtre los metadatos de fecha y hora incorporados del registro. Para obtener una comprensión más profunda de cómo funciona la memoria AgentCore, consulte Memoria AgentCore.
La solución
Para resolver problemas de memoria, verifique que sus estrategias de memoria incluyan una configuración de consolidación para que la memoria AgentCore combine y resuma registros a lo largo del tiempo en lugar de acumularlos indefinidamente. Organice registros utilizando plantillas de espacios de nombres en las definiciones de su estrategia para asegurarse de que la recuperación se mantenga dentro del contexto relevante. Configure eventExpiryDuration para controlar cuánto tiempo persisten los eventos sin procesar (entre 7 y 365 días). Para obtener detalles de implementación, consulte Implementación de memoria de AgentCore.
Habiendo cubierto los cuatro escenarios de falla en ambas partes, ahora pasamos a las mejores prácticas de producción que detienen estos problemas antes de que ocurran. Los flujos de trabajo de solución de problemas que hemos cubierto lo ayudan a responder cuando algo sale mal, pero una estrategia de observabilidad bien diseñada lo ayuda a detectar problemas de manera proactiva. La integración de AgentCore con CloudWatch proporciona la base para este enfoque proactivo, brindándole visibilidad en tiempo real del estado y el rendimiento de los agentes.
Active instrumentación integral para agentes de producción, sistemas de memoria y puertas de enlace. Configure registros de CloudWatch, métricas de CloudWatch y seguimientos de OpenTelemetry.
Configure alarmas de CloudWatch para métricas críticas. Establezca umbrales para tasas de error (5 por ciento), latencia del percentil 95 (P95) (3 segundos) y uso de token por sesión. No espere a que los usuarios informen problemas. Deje que CloudWatch le avise cuando las métricas superen los umbrales aceptables.
Crear cuadros de mando operativos. Cree un panel principal que muestre el total de invocaciones (últimas 24 horas), la tasa de error (actual en comparación con la línea base), la latencia P50/P95/P99, las tendencias de uso de tokens y el recuento de sesiones activas. Cree paneles por agente que muestren patrones de invocación específicos de cada agente, desglose del uso de herramientas, tendencias de consumo de memoria, distribución de tipos de errores y costo por sesión. Revise estos paneles diariamente para detectar tendencias antes de que se conviertan en problemas.
Invierta en infraestructura de observabilidad antes de que la necesite. Integre el seguimiento en su proceso de desarrollo desde el primer día. Comparta paneles con gerentes de producto y partes interesadas para que todos comprendan el desempeño de los agentes. Cuando alguien diagnostica un problema de producción complicado, comparta el enfoque con el equipo para generar conocimiento institucional sobre patrones de falla comunes.
Para monitorear la precisión de la herramienta a escala, puede utilizar Amazon Bedrock AgentCore Evaluators para evaluar de forma continua y automática el comportamiento de los agentes. En lugar de revisar manualmente los seguimientos después de que ocurren fallas, los evaluadores inspeccionan las sesiones de los agentes en tiempo real y las califican según criterios de calidad predefinidos. Amazon Bedrock AgentCore Insights (versión preliminar) se basa en evaluadores y proporciona análisis de clasificación. Insights puede proporcionar análisis de fallas, extracción de la intención del usuario y resumen de ejecución.
Después de probar las técnicas de optimización en esta publicación, limpie los recursos para evitar cargos innecesarios.
Para los recursos de CloudWatch, elimine los paneles de prueba de CloudWatch creados durante la depuración, elimine las alarmas de CloudWatch configuradas con fines de prueba y considere archivar o eliminar grupos de registros de CloudWatch antiguos si ya no son necesarios.
Para los recursos de AgentCore, si creó agentes de prueba específicamente para este tutorial, elimínelos a través de la consola de AgentCore. Elimine cualquier espacio de nombres de memoria de prueba creado durante las pruebas de optimización de la memoria. Elimine cualquier integración de herramientas temporales utilizada para pruebas de rendimiento.
Para optimizar costos, revise la configuración de retención de Amazon CloudWatch Logs y ajústela según sus requisitos de cumplimiento. Considere utilizar la protección de datos de CloudWatch Logs para reducir los costos de almacenamiento de registros más antiguos.
Para eliminar grupos de registros de CloudWatch:
Para eliminar alarmas de CloudWatch:
Los cuellos de botella de rendimiento y los problemas de memoria representan los desafíos operativos más comunes para los agentes de producción más allá de los escenarios de depuración cubiertos en la Parte 1. Con un diagnóstico sistemático utilizando seguimientos y métricas de CloudWatch, puede identificar si la latencia se debe a herramientas lentas, recuperación de memoria ineficiente, generación excesiva de tokens o procesamiento secuencial. Para sesiones de larga duración, monitorear los patrones de crecimiento de la memoria e implementar estrategias de consolidación mantiene a los agentes estables durante interacciones prolongadas.
Próximos pasos
¿Listo para poner en práctica estas técnicas? Comience activando AgentCore Observability para sus agentes de producción si aún no lo ha hecho. Esta configuración única proporciona la base para todo lo que hemos cubierto. Configure alarmas de CloudWatch para métricas críticas. Cree runbooks de solución de problemas para sus agentes y flujos de trabajo específicos, documentando las consultas que ejecuta, los umbrales que indican problemas y las correcciones que implementa.
Practique la depuración en entornos que no sean de producción. Introduzca fallas deliberadamente y practique su diagnóstico utilizando los flujos de trabajo que hemos cubierto. Desarrolle memoria muscular para solucionar problemas antes de que la necesite en producción. Comparta este conocimiento con su equipo para ayudar a confirmar que todos los que operan sus agentes comprenden estas técnicas de depuración y saben cómo utilizar las funciones de observabilidad de AgentCore.
Los agentes de producción a menudo fracasan por razones que se pueden prevenir. Con las herramientas de observabilidad adecuadas, enfoques sistemáticos de resolución de problemas y una cultura que trata cada problema como una oportunidad de mejorar, puede detectar los problemas a tiempo, resolverlos rápidamente y crear agentes que se ganen una confianza duradera.
Más información
Para obtener más información sobre AgentCore y las funciones de observabilidad, visite la documentación de AgentCore. Para comenzar con AgentCore, visite la consola de AgentCore. Para conocer mejores prácticas adicionales de monitoreo de CloudWatch, consulte la Guía del usuario de CloudWatch.
Sobre los autores
Josué Lacy
Joshua es arquitecto de soluciones en AWS en el sector comercial y brinda soporte a clientes ISV. Le apasiona ayudar a los constructores a integrar la IA en aplicaciones de producción y diseñar arquitecturas que se escalen de forma segura en entornos multiinquilino. Se especializa en IA agente, Amazon Bedrock AgentCore y desarrollo de aplicaciones de IA generativa.
Jenny Shen
Jenny es arquitecta de soluciones en AWS en el espacio de telecomunicaciones, medios y entretenimiento. Le apasiona ayudar a los clientes a crear sistemas listos para producción y encontrar formas de simplificar la forma en que los equipos operan sus cargas de trabajo en la nube. Se especializa en CloudOps y transformaciones AI/ML.