Cómo probar agentes de IA contra fallos de producción antes que tus usuarios

#ai #programming #tutorial #spanish

💻 Este es el inicio de una serie. Todo el código está en un solo repo: resilient-agent-harness-sample-for-aws. Este post es la columna vertebral de chaos testing (00-agent-resilience-journey); los deep-dives a continuación desarrollan cada corrección por completo. Clona el repo y sigue el paso a paso.

Netflix tiene una herramienta llamada Chaos Monkey que mata servidores en producción, a propósito, en horario laboral. Suena imprudente. Es lo contrario: si la caída de una instancia aleatoria puede tumbar tu servicio, quieres enterarte en una prueba controlada un martes, no a las 3am durante un incidente real. Esa disciplina se llama chaos engineering, y es como se construyen sistemas distribuidos resilientes: asumes que las cosas van a fallar, así que ensayas el fallo primero.

Los agentes de IA casi nunca reciben ese ensayo. Reciben una demo del camino feliz, un pulgar arriba y un deploy. Luego una herramienta se cuelga, una API devuelve basura, una llamada de red falla, y el agente, que nunca ha visto una herramienta rota, le dice al usuario con toda confianza que una tarea se completó cuando en realidad no pasó nada.

La buena noticia: puedes aplicar la idea de Chaos Monkey a un agente ahora mismo, en unas pocas líneas de código. Strands Evals incluye chaos testing que inyecta fallos controlados en las herramientas durante la evaluación, para que encuentres las grietas en el arnés de tu agente antes de que producción lo haga.

Esta es la columna vertebral de una serie. Cada corrección tiene su propio post de deep-dive; este es el mapa y el diagnóstico que los abre.

¿Cuál es la demo?

La demo es un agente de viajes, construido con Strands Agents, con tres herramientas que cada una toca el mundo exterior:

search_flights busca tarifas reales en el sandbox de Duffel.
get_weather consulta una API pública de pronóstico para el destino.
book_flight escribe una reserva en un ledger SQLite local (la "base de datos de referencia" contra la que verificamos).

Es un agente normal y pequeño: busca, revisa el clima, reserva un viaje. En el camino feliz funciona perfecto, y ese es exactamente el problema. Para ver dónde realmente se rompe, tenemos que romper sus herramientas a propósito.

¿Qué es el chaos testing para agentes de IA?

El chaos testing inyecta fallos controlados (timeouts, errores de red, respuestas corruptas) en las llamadas a herramientas de un agente durante la evaluación, para medir cómo se comporta cuando su entorno se rompe en lugar de solo probar el camino feliz. Es la disciplina de Chaos Monkey aplicada a un agente: asumir que la herramienta va a fallar, hacerla fallar en una prueba, y verificar si el agente se recupera o al menos falla honestamente.

La idea clave: estamos endureciendo el arnés, no calificando al modelo. Los fallos y las correcciones son partes deterministas de la arquitectura del agente (hooks, una herramienta de respaldo, un evaluador de ground truth). Se comportan igual sin importar qué modelo corre por dentro. La reacción del modelo ante una herramienta rota varía entre ejecuciones, que es exactamente por qué la resiliencia tiene que vivir en el arnés determinista alrededor del modelo, no en esperar que el modelo se las arregle.

Las dos formas en que una herramienta falla

Strands Evals te da dos familias de fallo, y rompen al agente de formas opuestas:

Familia	Efectos	Qué pasa	Qué ve el agente
Pre-hook (cancela la llamada)	`Timeout`, `NetworkError`, `ExecutionError`, `ValidationError`	la herramienta se cancela antes de ejecutarse, así que una escritura nunca persiste	un error
Post-hook (corrompe el resultado)	`CorruptValues`, `TruncateFields`, `RemoveFields`	la herramienta se ejecuta (la escritura sí persiste), luego su respuesta se corrompe	basura en la que puede confiar

Un fallo pre-hook es ruidoso: la herramienta da error, la base de datos queda vacía, fácil de detectar. Un fallo post-hook es silencioso y peligroso: la reserva realmente se guardó, pero al agente le entregaron una confirmación rota y la reporta como éxito. Mismo agente, dos formas de fallo completamente diferentes, por eso diagnosticas antes de corregir.

Agregar chaos es una línea

Construyes tu agente normalmente, luego agregas el plugin:

from strands import Agent
from strands_evals import Case
from strands_evals.chaos import ChaosCase, ChaosExperiment, ChaosPlugin, Timeout, CorruptValues
from strands_evals.eval_task_handler import TracedHandler, eval_task

# Nombra cada fallo: qué efecto, en qué herramienta.
effect_maps = {
    "book_timeout": {"tool_effects": {"book_flight": [Timeout()]}},
    "book_corrupt": {"tool_effects": {"book_flight": [CorruptValues(corrupt_ratio=1.0)]}},
}
cases = ChaosCase.expand([Case(name="trip", input=TRIP)], effect_maps,
                         include_no_effect_baseline=True)

@eval_task(TracedHandler())
def task(case):
    return Agent(model=MODEL, tools=TOOLS, plugins=[ChaosPlugin()],  # <- toda la configuración
                 system_prompt=PROMPT)

report = ChaosExperiment(cases=cases, evaluators=[...]).run_evaluations(task=task)

ChaosPlugin() en plugins es todo el cableado. Inyecta el fallo de cada caso a través de los hooks nativos de tool-call de Strands. Sin mocks, sin parchear tus herramientas.

Diagnosticar, Corregir, Validar

La documentación de chaos estructura el trabajo como un ciclo, y la demo lo sigue en el agente de viajes de arriba. El diagrama muestra el ciclo completo: el ChaosPlugin inyecta fallos en las herramientas del agente, dos evaluadores puntúan el resultado contra el ground truth para revelar dónde se rompe, agregas una corrección por tipo de fallo, y luego toda la suite se re-ejecuta para confirmar que las correcciones se mantienen y nada regresionó.

Diagnosticar. Golpea al agente naive con los siete efectos en sus herramientas y puntúa contra el ground truth (la base de datos) con dos evaluadores que tienen puntos ciegos diferentes: uno verifica "¿la reserva realmente persistió?", el otro verifica "¿el agente declaró una referencia de reserva que realmente existe?". Los fallos pre-hook aparecen como una base de datos vacía. Los post-hook son la trampa: la fila persistió (así que un check de solo-estado dice "pass") pero el agente reportó una referencia rota. Dos evaluadores atrapan lo que uno no vería.

Corregir, uno a la vez, emparejado con el fallo. Un retry genérico no funciona, porque los fallos no tienen la misma forma:

Corrupción silenciosa se convierte en un hook AfterToolCallEvent que re-lee el resultado contra la base de datos y lo reescribe con la verdad. (El patrón completo está en el deep-dive 03 abajo.)
Una lectura con un segundo proveedor caído (clima) se convierte en un hook BeforeToolCallEvent que conmuta a un proveedor genuinamente diferente. Un fallback real, porque dos APIs de clima realmente existen.
Un fallo sin camino de recuperación (búsqueda caída, sin respaldo) se convierte en conciencia de fallo en el prompt: hacer que el agente comunique honestamente en lugar de fabricar. El resultado correcto no es un éxito falso; es un honesto "no pude hacerlo."

Validar. Re-ejecuta toda la suite de chaos con las correcciones en su lugar. Este es el paso que se gana su lugar: no solo prueba que los casos que antes fallaban ahora pasan, atrapa una corrección que regresionó otro caso. Nuestro primer prompt de conciencia de fallo accidentalmente hizo que el agente dejara de reservar cuando la herramienta de clima fallaba (0/4 vs 3/4 reservas). Solo ves eso re-ejecutando todo, no solo el caso que querías corregir.

No todos los fallos "pasan", y ese es el punto

Cuando la escritura de reserva se cancela y el agente no tiene un segundo proveedor de reservas, el caso queda en rojo. Eso es honesto: es un gap estructural en el arnés, no un fallo del modelo. La corrección también es estructural: agregar un proveedor de respaldo y conmutar, exactamente como el ejemplo del clima. Una buena evaluación de resiliencia separa fallos recuperables de fallos irrecuperables-pero-honestos, para que sepas cuáles necesitan una nueva pieza de arquitectura y cuáles solo necesitan fallar limpiamente.

Los deep-dives: cada fallo, convertido en una demo completa

Esta ejecución de chaos revela fallos de herramientas en miniatura. Cada uno tiene su propio post que construye la cura por completo, en el mismo tipo de agente de viajes. El hilo que los une: un fallo que el modelo no puede auto-detectar, corregido determinísticamente en el arnés en vez de esperarlo en el prompt.

Detener alucinaciones de agentes de IA: Validar antes de que el agente escriba en memoria toma la misma lección que la Corrección #1 (el agente confió en datos malos que no podía verificar) un paso antes: un write-gate BeforeToolCallEvent que valida un hecho antes de almacenarlo, para que una alucinación nunca se convierta en memoria permanente.
Inyección de prompts en agentes que leen contenido no confiable es la versión de seguridad de "el agente confió en su herramienta": una instrucción inyectada se almacena como memoria y dispara una acción peligrosa una sesión después. La cura es el mismo gate en la frontera de herramientas, bloqueando la acción determinísticamente.
Por qué los agentes fallan en tareas multi-paso es el fallo silencioso post-hook (Corrección #1) en una tarea multi-paso completa: una herramienta reporta "listo" mientras nada se guardó. La cura es la misma idea, "verificar contra el ground truth", ejecutada por paso con un retry.
Agentes auto-mejorables que escriben sus propias herramientas convierte trabajo repetido y determinista en una herramienta que el agente escribe una vez y reutiliza exactamente, en lugar de re-razonar (y equivocarse) en cada llamada.

Preguntas frecuentes

¿El chaos testing es solo para Strands o AWS?
No. Inyección de fallos, hooks de tool-call, herramientas de respaldo y evaluación de ground truth son conceptos generales de agentes. Esta demo usa Strands Agents, que es agnóstico al modelo: sus proveedores son intercambiables, así que el mismo código corre en Amazon Bedrock (el default), Anthropic, OpenAI, o un modelo local vía Ollama. La demo usa OpenAI gpt-4o-mini por defecto porque solo necesita una API key para probar, aunque eso sigue siendo una llamada a la nube, no un modelo en tu máquina.

¿Por qué medir la base de datos en vez de la respuesta del agente?
Porque un agente que escribe estado puede declarar éxito mientras los datos están mal. Un check de estado atrapa los fallos ruidosos; un check de honestidad (¿la referencia que el agente declaró realmente existe?) atrapa la corrupción silenciosa que un check de estado no ve.

¿Por qué no simplemente reintentar cada herramienta fallida?
Un retry vuelve a golpear un fallo que está activo durante todo el caso, y no se dispara en absoluto ante una corrupción que devuelve "éxito" con un payload malo. Empareja la corrección con el tipo de fallo en lugar de eso.

¿Necesito infraestructura en vivo para que falle?
No, y ese es todo el valor. El chaos testing inyecta los fallos determinísticamente, así que ensayas la caída sin esperar una real.

Más sobre estos modos de fallo

Los deep-dives de arriba construyen cada cura por completo. Si quieres el panorama más amplio, he escrito sobre varios de estos fallos por su cuenta en los últimos meses:

Alucinaciones: 5 Techniques to Stop AI Agent Hallucinations in Production y Detect AI Agent Hallucinations: Zero-Shot Methods.
El fallo silencioso: How to Stop AI Agents from Hallucinating Silently with Multi-Agent Validation.
Guardrails en la frontera de herramientas: AI Agent Guardrails: Rules That LLMs Cannot Bypass y Runtime Guardrails for AI Agents: Steer, Don't Block.
El patrón más grande: Why AI Agents Fail: 3 Failure Modes That Cost You Tokens and Time y How to Evaluate AI Agents: LLM-as-Judge Tutorial.

Ejecútalo tú mismo

La demo completa de Diagnosticar, Corregir, Validar (un agente de viajes, siete efectos de chaos en tres herramientas, dos evaluadores de ground truth, y el antes/después de cada corrección) corre de principio a fin en un solo notebook. Clona el repo y ejecútalo:

git clone https://github.com/elizabethfuentes12/resilient-agent-harness-sample-for-aws.git
cd resilient-agent-harness-sample-for-aws/00-agent-resilience-journey

uv venv && source .venv/bin/activate
uv pip install -r requirements.txt

# Default: OpenAI gpt-4o-mini (solo necesitas una API key para probar)
cp .env.example .env   # luego llena OPENAI_API_KEY y un DUFFEL_API_KEY gratuito (app.duffel.com)

Luego abre agent_resilience_journey.ipynb y ejecútalo de arriba a abajo.

El patrón sigue a PALADIN (Sep 2025), que entrena agentes para recuperarse de fallos inyectados en herramientas. Las cifras de benchmark y la lectura completa están en el README del repo. Esta demo reproduce el mecanismo (inyectar, medir, recuperar) con su propia salida determinista.

¿Cuál es el fallo que golpeó a tu agente en producción: un timeout, una respuesta corrupta, una mentira con confianza? Cuéntame en los comentarios.

📬 ¿Construyes agentes de IA confiables? Escribo sobre memoria de agentes, guardrails, evaluación y patrones multi-agente. Suscríbete a mi newsletter para recibir el siguiente.

¡Gracias! 🇻🇪
Dev.to
Linkedin
GitHub
Twitter
Instagram
Youtube