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_humana

Señ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.