Loops infinitos y control de costes
Un agente que repite la misma llamada cien veces no parece peligroso hasta que llega la factura o bloquea un servicio externo.
Objetivos de aprendizaje
- Detectar loops por repetición de intención, tool y argumentos.
- Aplicar presupuestos por tarea, usuario, modelo y ventana temporal.
- Diseñar circuit breakers que detienen el sistema antes del desastre.
En cristiano: circuit breaker. Es una regla que corta llamadas cuando detecta demasiados fallos, coste excesivo o repetición sospechosa.
Terminal
guardrails:
max_steps_per_task: 12
max_tool_calls_per_tool: 4
max_cost_usd_per_task: 0.80
max_repeated_fingerprint: 3
max_runtime_seconds: 300
fingerprint:
campos:
- normalized_goal
- tool_name
- sorted_args_hash
si_repite_3_veces:
parar
guardar_traza
pedir_revision_humanaSeñales de loop
- La misma tool recibe argumentos casi iguales.
- El agente dice “voy a comprobar” muchas veces sin nueva evidencia.
- El coste sube pero no cambia el estado de la tarea.
- Los errores son recuperables, pero la estrategia no cambia.
Idea clave. `max_iterations` ayuda, pero no basta. Un loop puede estar por debajo del máximo y seguir siendo caro o inútil.
Cuidado. No esperes al resumen final para calcular coste. Mide durante la ejecución y corta en caliente.
Comprueba que funciona. Define tres presupuestos: por tarea, por día y por acción crítica. Después decide qué mensaje verá el usuario cuando el sistema corte.
Guardar y reabrir el proyecto.
Un agente responsable sabe rendirse con evidencia.