Idea en 30 segundos
Probar agentes de IA es distinto al testing clásico de software, porque el comportamiento del agente depende no solo del código, sino también del LLM, del contexto, de los tools y de la secuencia de pasos.
Por eso, los sistemas de producción suelen usar una estrategia de pruebas en varias capas: unit tests, datasets de evaluación, comparación de regression contra baseline y replay de trazas reales.
Este enfoque ayuda a encontrar errores antes del release y a controlar la degradación del sistema con el tiempo.
Problema
Los enfoques clásicos de pruebas funcionan mal para agentes de IA. En software tradicional, la misma entrada casi siempre produce la misma salida. En sistemas con LLM, el comportamiento puede cambiar según:
- formulación del prompt;
- versión del modelo;
- contexto;
- resultados de tools.
Por esto, las pruebas locales pueden pasar, pero en producción el agente puede:
- tomar pasos extra e inflar token cost;
- elegir el tool incorrecto en escenarios complejos;
- volverse inestable tras cambio de versión de modelo o prompt.
Sin una estrategia de pruebas estructurada, estos problemas suelen detectarse después del release.
Concepto principal / modelo
La estrategia de pruebas para agentes se construye como múltiples niveles de validación, no como un solo tipo de prueba. Cada nivel captura su propia clase de riesgo en el comportamiento del sistema.
| Método | Qué valida | Cuándo usarlo |
|---|---|---|
| Unit testing | Lógica local del agente: selección de tools, esquema de salida, reglas básicas de runtime | En cada cambio de código, prompt o reglas de policy |
| Golden datasets | Conjunto estable de casos para runs de eval reproducibles | Cuando necesitas resultados comparables entre baseline y candidate |
| Eval harness | Comportamiento del sistema en una eval pipeline estandarizada | Antes del release y para validación de release |
| Regression testing | Diferencias (diff) entre versiones sobre los mismos casos de evaluation y replay | Después de cambiar modelo, prompt, tools o policy |
| Replay & debugging | Incidentes de producción y failure traces para analizar fallos | Cuando necesitas reproducir un incidente y encontrar la causa de una degradación |
Cuanto más alto el nivel de validación, más caro el run, por eso normalmente se ejecuta con menos frecuencia.
Cómo funciona
En sistemas de agentes en producción, las pruebas suelen organizarse como una release pipeline: cambios en código, prompts, versión de modelo o tools pasan por unit tests, datasets de evaluación, comparación de regression con baseline y replay de escenarios reales.
Cómo avanza un cambio por la pipeline
- Change — cualquier cambio en código, prompt, versión de modelo o tools dispara un nuevo run.
- Unit — se valida lógica local: selección de tools, manejo de resultados, reglas básicas de runtime.
- Eval — el agente corre escenarios de evaluación y la calidad se mide con métricas como
tool correctnessytask completion. - Regression — los resultados del candidate se comparan contra baseline para detectar cambios de comportamiento no deseados.
- Gate — CI bloquea release si caen métricas clave o se rompen escenarios críticos.
- Replay — replay se usa antes del release (trazas guardadas en staging) y después del release (monitoring de degradación).
Test pyramid para agentes
En muchos equipos, las pruebas de agentes se organizan como una pirámide:
Aquí regression no es una capa separada, sino una forma de comparar la versión nueva con baseline sobre los mismos tests de evaluación y replay.
- Unit tests — rápidos y baratos, se ejecutan seguido.
- Evaluation — más lentos, pero validan comportamiento del agente.
- Replay — los más costosos, pero cubren escenarios reales de producción.
Implementación
En práctica, esto suele verse como varias validaciones automáticas en la pipeline. Los ejemplos abajo son esquemáticos: muestran la lógica de validación y no dependen de una API de framework concreta.
1. Unit test de lógica del agente
Validamos si el agente elige el tool correcto.
def test_tool_selection():
tools = FakeTools(price_api_response={"symbol": "BTC", "price": 65000})
agent = Agent(tools=tools)
result = agent.run("What is the price of BTC?")
assert result.selected_tool == "crypto_price_api"
assert result.output["symbol"] == "BTC"
En unit tests reales, las llamadas a tools externos normalmente se stub/mockean para validar la lógica del agente, no dependencias de red.
2. Evaluation sobre dataset de escenarios
El agente se ejecuta sobre un conjunto de consultas de prueba.
test_cases = [
{"input": "Find BTC price", "expected_tool": "crypto_price_api"},
{"input": "Search latest AI news", "expected_tool": "web_search"}
]
for case in test_cases:
result = agent.run(case["input"])
assert result.tool == case["expected_tool"]
La calidad de evaluation se mide con métricas de calidad, estabilidad y costo (lista detallada en Métricas de pruebas de agentes más abajo). Para tareas abiertas o complejas, los resultados se validan a menudo además con LLM-as-a-judge. En producción, durante evaluation también se rastrean token cost, latency y cantidad de pasos del agente, para que nuevas versiones no se vuelvan más caras, más lentas o excesivamente multi-paso.
El propio dataset de evaluation también debe versionarse; de lo contrario, con el tiempo no queda claro si cambió el comportamiento del agente o el conjunto de escenarios.
3. Regression test después de cambios
Cuando cambia el modelo o prompt, se ejecuta el mismo conjunto de evaluación.
run_eval_suite(model="baseline-model")
run_eval_suite(model="candidate-model")
Si los resultados difieren mucho, el cambio debe revisarse antes del release.
En práctica también se compara candidate vs baseline sobre datasets de replay, no solo sobre casos sintéticos de evaluation.
4. Replay de escenarios de producción
Las solicitudes de producción se guardan y se usan tanto antes del release (staging replay) como después del release (post-release replay). Muchos equipos guardan failure traces automáticamente y los agregan al regression dataset.
for trace in production_traces:
result = agent.run(trace.input)
evaluate(result, trace.expected_behavior)
Este enfoque valida comportamiento del agente en escenarios reales, no solo en pruebas sintéticas.
5. Qué suele bloquear release en CI
En práctica, las pruebas de agentes se dividen en validaciones deterministas (lógica local, routing, formato de salida) y no deterministas (calidad de respuesta, completitud, adecuación del razonamiento), para las que se usan métricas de eval o LLM-as-a-judge.
En CI se bloquea release normalmente si fallan escenarios críticos, baja task success rate, sube hallucination rate, o crecen fuerte latency y token cost.
Errores típicos
Probar solo prompts
El equipo valida algunos ejemplos manuales y considera el cambio seguro, pero eso no cubre el comportamiento del agente en el loop de ejecución real.
Causa típica: no existe proceso de evaluación sistemático con métricas claras.
En producción esto suele convertirse en AI agent drift después del release.
Falta de datasets de evaluación de escenarios
Sin un conjunto de escenarios de control es difícil comparar baseline y candidate de forma objetiva.
Causa típica: no se construyeron golden datasets.
Consecuencia: la calidad de respuesta se vuelve inestable y las regresiones se detectan tarde.
Sin validación de regression
Tras cambiar modelo o prompt, el sistema puede "funcionar" formalmente, pero con perfil de comportamiento distinto.
Causa típica: no se ejecuta regression testing de forma regular.
En producción suele verse como AI agent drift, al inicio poco visible.
Sin fijar versión de modelo
Los proveedores LLM a veces actualizan modelos sin cambiar el nombre general.
Si la versión no está fijada (por ejemplo, gpt-4o-2024-08-06), las pruebas pueden pasar hoy y empezar a fallar mañana.
Causa típica: configuración usa nombre de modelo "flotante" sin pinning.
En sistemas de producción normalmente se fija una versión concreta del modelo o una versión snapshot.
Sin pruebas de replay
Un incidente ocurre una vez en producción, pero el equipo no puede reproducirlo de forma estable en local.
Causa típica: no se guardan failure traces y no se usa agent replay and debugging.
Consecuencia: el mismo bug vuelve después de releases siguientes.
Probar solo escenarios happy-path
Los datasets de evaluación contienen solo solicitudes "limpias", mientras que en realidad las solicitudes suelen ser incompletas, ambiguas o llegan durante degradación parcial de dependencias.
Causa típica: no hay escenarios con errores de tools y degradación de dependencias.
En producción esto suele verse como tool failure o partial outage.
Métricas de pruebas de agentes
| Métrica | Qué muestra |
|---|---|
| Tool accuracy | precisión al elegir tool |
| Task success rate | finalización de tarea |
| Hallucination rate | frecuencia de hechos incorrectos |
| Token cost | costo de ejecución |
| Latency | tiempo de ejecución de tarea |
| Reasoning steps | cantidad de pasos del agente |
Límites del enfoque
Las pruebas multicapa no eliminan por completo la no determinismo, porque los sistemas con LLM no son totalmente deterministas. Solo reducen riesgo y hacen visibles antes los cambios de comportamiento.
Evaluation y replay también son costosos: aumentan tiempo de run, carga en CI y costo de modelos.
Por eso, en equipos reales el conjunto completo de validaciones suele dividirse entre pruebas rápidas pre-merge y runs más pesados nightly o pre-release.
Resumen
- Para agentes de IA no alcanza un solo tipo de prueba.
- Unit tests validan lógica local.
- Evaluation y regression controlan calidad de comportamiento tras cambios.
- Replay ayuda a reproducir fallos reales de producción.
FAQ
Q: ¿Bastan solo unit tests para agentes?
A: No. Unit tests detectan bien errores locales, pero riesgos de comportamiento se cubren con evaluation, regression y replay.
Q: ¿Qué es evaluation para agentes?
A: Es ejecutar al agente sobre un conjunto de escenarios de prueba y evaluar resultados con métricas clave de calidad, estabilidad y costo.
Q: ¿Cuándo ejecutar regression tests?
A: Después de cualquier cambio que pueda afectar comportamiento del agente: actualización de modelo, cambio de prompt, nuevos tools o cambios en lógica runtime.
Q: ¿Por qué usar replay de trazas de producción?
A: Replay permite reproducir solicitudes reales de producción y comprobar si el sistema se comporta igual tras cambios. Ayuda a detectar fallos difíciles de reproducir con tests sintéticos.
Qué sigue
Si quieres convertir esta estrategia en una pipeline de trabajo, empieza con Unit Testing, luego añade Golden Datasets, y estandariza ejecución/evaluación con Eval Harness. Esta secuencia da feedback rápido en desarrollo y validación estable de calidad en CI.
Cuando actualizas modelo, prompts o tools, Regression Testing se vuelve clave. Y si el problema ya apareció en producción, Replay and Debugging suele funcionar mejor: reproduces traza real y verificas dónde cambió el comportamiento del agente.
Para sistemas multiagente con Orchestrator Agent, agrega pruebas dedicadas para orden de pasos, dependencias entre ramas y fallos parciales. En estos escenarios aparecen más seguido los riesgos clásicos de producción: Infinite Loop, Tool Spam, y Cascading Failures.