EN·ES·PT
Testing de agentes de IA · cómo testear LangGraph y sistemas agénticos

Testing de agentes de IA: qué falla en producción.

Los agentes no fallan como fallan las funciones. Un test unitario compara una entrada contra una salida; un agente planifica, llama a herramientas, recuerda y entra en bucle — así que los errores viven entre turnos, en la frontera de las herramientas y en las partes que no son deterministas. Esta página mapea la superficie de fallo que los tests unitarios no pueden ver, y las sondas que atrapan cada una antes que sus usuarios.

Demo de eval en vivo: califique una respuesta → Servicio: Evaluación y QA de LLM → ISTQB CT-AI + Test Automation Engineer
La lección · por qué las evaluaciones de un solo turno no bastan

Una suite de un solo turno en verde ocultaba un 502 en cada respuesta de seguimiento.

En un build, un chatbot de definición de alcance pasaba sus chequeos de un solo turno limpiamente: se hace una pregunta, se obtiene una buena respuesta, aserción en verde. Pero en el momento en que un usuario enviaba un segundo mensaje en la misma conversación, el endpoint devolvía un 502 — todas las veces. El testing de un solo turno no puede ver eso, porque nunca envía el turno dos. Una sonda golden multiturno — una conversación con guion que reproduce varios turnos y hace aserciones sobre toda la trayectoria — lo atrapó de inmediato. Ese es el núcleo del testing de agentes: se testea la conversación y el bucle, no una sola llamada.

Lección real de un build ya lanzado · ninguna métrica reclamada más allá del propio fallo
La superficie de fallo

Lo que los tests unitarios pasan por alto — y lo que lo atrapa.

Cada fila es un modo de fallo que un test unitario de un solo turno estructuralmente no puede observar, emparejado con la sonda que sí lo hace.

Superficie de fallo del agente → cómo un test unitario lo pasa por alto → la sonda que lo atrapa
Modo de fallo Cómo lo pasa por alto un test unitario La sonda que lo atrapa
Deriva multiturno Hace aserciones sobre un par de entrada/salida; la conversación nunca llega al turno dos, así que el estado que solo se corrompe entre turnos es invisible. Sonda golden multiturno — una conversación con guion de N turnos que hace aserciones sobre la trayectoria completa, no sobre una respuesta.
Errores de llamada a herramientas Simula la herramienta y verifica el camino feliz; nunca ejercita argumentos malformados, selección de herramienta incorrecta o una herramienta que devuelve un error. Aserciones en la frontera de herramientas — verifican que el agente elige la herramienta correcta, con argumentos válidos, y se recupera cuando la herramienta falla.
Inyección de prompts entre turnos Testea solo entradas confiables; el contenido hostil plantado en el turno uno que secuestra el turno tres queda fuera de alcance. Batería de red-team — payloads inyectados en la salida de herramientas y en el historial, verificando que el agente rechace y se mantenga en política.
No determinismo e inestabilidad Una sola pasada se ve en verde; la misma entrada produce en silencio un camino distinto e incorrecto en la siguiente ejecución. Ejecuciones de repetición / robustez — la misma sonda ejecutada K veces, puntuada según la tasa de aciertos, con chequeos de paráfrasis y reintento.
Fallos de bucle y terminación No se ejecuta ningún bucle, así que los bucles de herramientas desbocados, las salidas prematuras y los planes atascados nunca salen a la luz. Límites de trayectoria — verifican el número de pasos, la terminación y que el agente alcance un estado de parada válido.
Salida sin fundamento / sin citas Verifica que el texto se lea bien, no si cada afirmación se remonta a una fuente recuperada. Barrera de cobertura de citas — cada afirmación generada debe mapear a una fuente, exigido por diseño.

Método, no dependencia de un proveedor. Las mismas tres familias — sondas golden multiturno, una batería de red-team y ejecuciones de repetición/robustez — se aplican a LangGraph, a un bucle personalizado o a un framework de agentes listo para usar.

El bucle, instrumentado

Dónde se enganchan las sondas.

Un agente es un bucle: recibir entrada, planificar, llamar a una herramienta, responder — y a menudo repetir. Cada arista de ese bucle es un lugar donde se engancha una sonda. La barrera al final decide publicar o bloquear.

Bucle del agente con puntos de enganche de sondas La entrada fluye hacia Planificar, luego Llamada a herramienta, luego Responder, y vuelve a Planificar para el siguiente turno. Las sondas golden multiturno se enganchan entre turnos, las aserciones en la frontera de herramientas se enganchan en la llamada a la herramienta, y una batería de red-team inyecta en la entrada y en la salida de la herramienta. La trayectoria se puntúa contra una barrera de evaluación que publica o bloquea el lanzamiento. Entrada turno del usuario Planificar elegir siguiente paso Llamada a herramienta actuar sobre el mundo Responder responder / continuar siguiente turno — donde se esconde la deriva multiturno aserciones en la frontera de herramientas inyección red-team trayectoria puntuada Barrera de eval tasa de aciertos + red-team publicar barreras superadas bloquear — falla → de vuelta a corregir
El bucle es la unidad bajo prueba. Las sondas se enganchan en cada arista; la barrera de evaluación convierte una trayectoria puntuada en una decisión de publicar-o-bloquear — la misma disciplina que permitió a mi QA OS bloquear su propio lanzamiento cuando encontró 15 CVEs high/critical.
El método · tres familias de sonda

Sondas golden multiturno + una batería de red-team + robustez.

1 · Sondas golden multiturno

Conversaciones con guion que reproducen varios turnos y hacen aserciones sobre la trayectoria completa — elección de herramienta, estado y respuesta final. Esta es la capa que habría atrapado el 502 del segundo turno el primer día.

2 · Batería de red-team
  • Inyección plantada en la salida de herramientas y el historial, no solo en el prompt
  • Verificar que el agente rechace y se mantenga en política
  • Casos de jailbreak, exfiltración y escape de alcance ejecutados en cada build
3 · Reintento / robustez
  • Ejecutar cada sonda K veces, puntuar según la tasa de aciertos — inestable ≠ aprobado
  • Parafrasear la misma intención; el agente debe mantenerse
  • Acotar los pasos del bucle y verificar una terminación limpia
▸ cómo lo ejecuto como servicio ▸ pruebe la demo de eval en vivo
La prueba · no afirmaciones, recibos

Esto no es teoría — es como ya trabajo.

Una barrera que bloqueó su propio lanzamiento

Mi QA OS atrapó 15 CVEs high/critical, bloqueó el lanzamiento y se parcheó el mismo día hasta 3.759 tests / 13 de 13 barreras. Una barrera que no puede decir «no» no es una barrera.

▸ captura del bloqueo ▸ captura corregida
Fundamentado por diseño

Un dashboard de investigación RAG con 100 % de cobertura de citas — no hay forma de generar una afirmación sin cita. La barrera de citas es estructural, no un simple deseo.

▸ caso de estudio
Suites deterministas que se mantienen

Una suite pública de regresión SDET: 37/37 specs, 0 inestabilidades, 15,3 s. En flujos de trabajo fintech en vivo llevé la tasa de inestabilidad del 10 % a menos del 1 % en más de 500 tests.

▸ la suite en GitHub ↗
Las cifras públicas enlazan a un recibo; las cifras de HighStrike son de un rol anterior, autoinformadas · este sitio ejecuta su propio QA (más de 100 chequeos, limpio con axe)
Relacionado · más sobre testing de IA
Contratar a un ingeniero de QA de IA →Consultor de evaluación de LLM →Evaluación de RAG →Reducir la inestabilidad de tests →

¿Le preocupa que un agente específico se lance roto?

Reserve una llamada y definiremos el alcance de una suite de sondas para su agente — o pegue la respuesta de su IA en la demo de eval en vivo y observe cómo se califica ahora mismo.

Reservar una llamada → ▸ pruebe la demo de eval en vivo Evaluación y QA de LLM →
preguntas frecuentes

Preguntas, respondidas.

¿Por qué es más difícil testear agentes que un solo prompt?
Ejecutan acciones de múltiples pasos con herramientas y memoria, así que los fallos se acumulan a lo largo de los pasos y la misma entrada puede seguir caminos distintos. Se testea la trayectoria completa, no solo la respuesta final.
¿Qué verifica usted realmente en un agente?
La corrección de las llamadas a herramientas, el comportamiento de bucle y terminación, el cumplimiento de las barreras de protección, el coste y la latencia, y la recuperación tras un mal paso — además del resultado de extremo a extremo.
¿Funciona esto con LangGraph o con un bucle personalizado?
Sí. Las mismas familias de chequeos valen para LangGraph, para un bucle de agente personalizado o para otro framework; conecto el harness a su implementación.
¿Puede bloquear los despliegues según las evaluaciones del agente?
Sí. La evaluación del agente se ejecuta en CI y bloquea cualquier lanzamiento que provoque una regresión en las trayectorias que importan.
¿Qué frameworks de agentes admite — LangGraph, CrewAI o un bucle personalizado?
Todos ellos. Los chequeos apuntan a la trayectoria del agente, no al framework, así que LangGraph, CrewAI y los bucles hechos a mano se conectan de la misma manera. Adapto el harness a cualquier runtime que ya tenga en marcha.
¿Cómo bloquea un despliegue según el comportamiento del agente sin bloquear cada lanzamiento?
La evaluación se ejecuta en CI contra un conjunto fijo de trayectorias golden y solo bloquea cuando el comportamiento sufre una regresión en ellas. El no determinismo se maneja con bandas de tolerancia y ejecuciones repetidas, de modo que un lanzamiento en buen estado se publica y una regresión real lo detiene.
¿Cómo son los plazos de un encargo típico?
Comienza con una fase corta de alcance para mapear las trayectorias críticas de su agente, luego una fase de construcción de las sondas golden y la batería de red-team, y después la entrega con el harness conectado a CI. El trabajo se concentra al inicio; el harness sigue funcionando cuando yo ya no estoy.
¿Qué recibo realmente al final del encargo?
Un harness de tests funcionando en su repositorio — sondas golden, una batería de red-team y bloqueo en CI — más un informe escrito de los modos de fallo encontrados y cómo se atrapa ahora cada uno. Todo es suyo para ejecutar y ampliar sin mí.
¿Cómo testea agentes que llaman a herramientas y APIs externas?
Las llamadas a herramientas se ejercitan contra fakes controlados y fixtures grabados para que los tests sigan siendo deterministas, y luego se verifican puntualmente contra la integración en vivo. Eso atrapa las llamadas malformadas, los argumentos incorrectos y los errores de herramienta mal gestionados antes de que lleguen a producción.
¿Cómo se define el alcance y se cotiza un encargo de testing de agentes?
El alcance se ajusta a la superficie de su agente — el número de trayectorias, herramientas y barreras de protección que necesitan cobertura — y el precio es una cotización fija por alcance acordado. Usted recibe la estimación antes de que comience cualquier trabajo, sin un contador de horas en marcha.