Inicio / Artículos / Por qué los agentes de IA agotan el presupuesto sin terminar, y cómo detenerlos

Por qué los agentes de IA agotan el presupuesto sin terminar, y cómo detenerlos

Aprenda por qué los agentes que utilizan herramientas siguen en bucle cuando “terminado” no está definido, a dónde va el gasto de tokens y qué condiciones de detención son más efectivas que simplemente establecer límites máximos de pasos o presupuesto.

1533 palabras

Un agente autónomo que se bloquea es fácil de manejar. El fallo costoso es aquel que nunca se bloquea: sigue llamando a las herramientas, genera pasos que parecen razonables y nunca llega a la línea de meta mientras el contador de tokens sigue funcionando. Este artículo explica el mecanismo detrás de ese comportamiento, dónde se acumula típicamente el gasto en un agente descontrolado y las condiciones concretas de detención que lo impiden, para que pueda diseñar bucles de agente que sepan cuándo han terminado en lugar de depender de un presupuesto mayor para absorber el desperdicio.

Considere un ejemplo sencillo: una ejecución por la tarde sin supervisión que cuesta 40 dólares y no aporta nada. Según los estándares de operaciones de los agentes, eso es una cantidad insignificante; los equipos comparten historias sobre ejecuciones nocturnas sin supervisión que alcanzaron cifras de cuatro dígitos. El monto no es lo interesante; lo importante es qué se logró con él. El agente no quedó atascado ni generó ningún error al que pudieran recurrir. Estuvo ocupado todo el tiempo, trabajando en nada.

Así se ve un agente descontrolado en el registro

Al abrir el registro de un agente que se desvió de su curso, rara vez encontrará un seguimiento de errores. Lo que encuentra parece el registro de un empleado concienzudo que perdió la noción de cuál era su tarea.

El agente abre un archivo y lo resume, luego abre el mismo contenido presentado de forma ligeramente diferente y lo resume nuevamente. Realiza una búsqueda, considera que la respuesta no es del todo satisfactoria y vuelve a realizar la consulta cambiando un par de palabras. Cada paso, considerado por separado, es defendible. Precisamente por eso es difícil detectar este patrón al leerlo rápidamente: ninguna entrada parece estar defectuosa. La secuencia simplemente nunca converge.

Por qué el modelo decide cuándo ha terminado

Este comportamiento tiene una causa concreta que merece ser comprendida si se desarrollan o operan agentes. Cada respuesta de un modelo que llama a herramientas como Claude termina con una razón de detención extraída de una lista corta y fija. La guía de Anthropic para manejar las razones de detención abarca varios casos; dos son los más relevantes para los bucles de agentes. La primera indica que el modelo considera que su trabajo está completo:

"stop_reason": "end_turn"

La segunda indica que desea invocar una herramienta y continuar:

"stop_reason": "tool_use"

Un bucle de agente es código de aplicación ordinario. Envía una solicitud, ejecuta cualquier herramienta que solicite el modelo, envía el resultado de vuelta y repite hasta que el modelo devuelva end_turn. Nada fuera del modelo declara que la tarea está completada. En cada turno, el modelo realiza esa llamada por sí mismo para determinar si el trabajo que tiene entre manos parece estar terminado. Existen otras razones para detenerse, como alcanzar el límite de tokens de salida, pero esas son interrupciones, no una determinación de que el trabajo está hecho.

Ese único hecho explica todo el fracaso. Cuando el objetivo es demasiado vago como para que el modelo pueda determinar que se ha alcanzado, siempre hay algo más que verificar, y el bucle continúa hasta que interviene un factor externo, generalmente una alerta de presupuesto. Para un tratamiento a nivel de código sobre el diseño de bucles, consulte bucles agentes limitados y patrones fiables de TypeScript para el uso en herramientas de LLM.

Qué tan común es esto

Es tentador considerar esto como una peculiaridad de una herramienta en particular. Sin embargo, pruebas más amplias sugieren lo contrario. Un estudio de la RAND Corporation basado en entrevistas con 65 científicos de datos e ingenieros experimentados indica que la tasa de fracaso de los proyectos de IA supera el 80 por ciento, aproximadamente el doble que en los trabajos informáticos convencionales. Ese estudio se refiere a proyectos de IA en general, no específicamente a agentes, pero los ciclos que giran sin generar valor son uno de los factores cotidianos que contribuyen a ese tipo de desperdicio. Nunca aparecen en los discursos principales de las conferencias; sí se encuentran en las facturas.

También circulan versiones más extensas de este relato. Un informe frecuentemente citado habla de un bucle recursivo cuyos gastos ascendieron a cinco dígitos antes de que alguien interviniera. Esa cifra no ha sido verificada de forma independiente, y cualquier número tan elevado merece cierto escepticismo. Sin embargo, el mecanismo es real y solo tiende a aumentar: el mismo bucle que gasta 40 dólares en una tarde puede gastar 4,000 durante un fin de semana sin supervisión.

Dónde se acumulan los gastos

Cuando se analizan los costos descontrolados y se comparan con lo que informan los operadores de grandes flotas de agentes, el dinero tiende a concentrarse en los mismos pocos lugares:

  • Búsqueda ilimitada en la web. Cada página que se carga y cada búsqueda repetida tiene un costo. Al no haber límite, la investigación continúa indefinidamente mientras el modelo sigue creyendo que podría existir otra fuente valiosa.
  • Un modelo caro para tareas sencillas. Los modelos de vanguardia cuestan más porque razonan mejor, pero muchos pasos del agente, como reformatear un archivo, verificar un estado o intentar una llamada nuevamente, no requieren esa capacidad. Un modelo más pequeño podría manejarlos por una fracción del precio.
  • Hilos de conversación que nunca terminan. Un agente que trabaja dentro de una larga conversación vuelve a procesar toda su historia acumulada en cada turno, lo que hace que un hilo con semanas de antigüedad cueste más por solicitud ahora que al inicio, sin importar cuán pequeña sea la solicitud. El caché de prompts puede atenuar esto si tu proveedor lo admite, pero el contexto sigue creciendo.
  • Horarios olvidados. Un trabajo recurrente configurado una sola vez sigue ejecutándose mucho tiempo después de que alguien utilice sus resultados.
  • Ninguno de estos casos es algo excepcional. Juntos, se comportan como una suscripción olvidada que cobra por token en lugar de por mes. Para comprender mejor cómo se acumulan estos costos, el artículo sobre por qué los costos de la IA agente explotan ofrece una explicación más detallada.

    Arregle la condición de parada, no el límite máximo

    Después de una ejecución costosa, la reacción instintiva es aumentar los límites de pasos o gasto. Eso suele tener efectos negativos, ya que un límite más alto solo permite que el mismo bucle estancado siga funcionando durante más tiempo antes de chocar con él. Lo que realmente ayuda es darle al bucle una forma de darse cuenta de que el progreso se ha detenido, lo cual es una cuestión diferente a saber si ya ha agotado su cantidad permitida de pasos.

    Coloca la línea de meta dentro del objetivo

    Define “terminado” como parte de la tarea, no como algo que se considera después. Una instrucción como “arregla la prueba fallida” deja espacio para tareas adicionales como organizar las importaciones o reformatear todo el archivo. “Haz que esta única prueba pase y luego termina” proporciona un punto final que el modelo puede detectar realmente. Cuanto más observable sea el criterio de finalización, más fácil será para el modelo devolver end_turn en el momento adecuado.

    Haz que los resultados de las herramientas sean inequívocos

    La retroalimentación de las herramientas debe indicar claramente si una acción tuvo éxito o falló. Un resultado poco claro se interpreta por el agente como una invitación a intentarlo de nuevo, y no como una señal para detenerse. Los campos de estado explícitos y los mensajes de error claros eliminan la incertidumbre que impulsa a repetir los intentos.

    Detección de repeticiones en lugar de contar pasos

    Un contador de pasos fijo es un instrumento poco preciso. El mismo contador podría interrumpir una tarea válida de 15 pasos en el paso 11, mientras permite que un ciclo de 2 pasos desperdicie varias llamadas adicionales costosas antes de actuar. Una señal mucho mejor es la repetición: marcar llamadas consecutivas a una herramienta con argumentos idénticos permite detectar directamente el patrón descrito anteriormente, sin penalizar a las tareas que son simplemente largas.

    Añada un punto de control humano y una protección contra gastos excesivos

    Cualquier tarea que se deje sin supervisión por más de unos minutos debe incluir un momento en el que una persona revise su progreso. Las protecciones automatizadas complementan esto. Por ejemplo, gh-aw de GitHub ofrece una barrera de control que se puede configurar para detener un flujo de trabajo en el instante en que sus costos superen un límite establecido, en lugar de dejar que quien lea la factura sea el encargado de detectarlo. Una protección como esta funciona como red de seguridad, no como sustituto de una condición de detención adecuada, pero limita los daños cuando todo lo demás falla.

    La actividad no es progreso

    Lo más preocupante de un proceso descontrolado no es el costo, sino la confianza ciega. La salida del agente nunca expresa dudas ni admite incertidumbre sobre si alguna de las tareas está siendo útil. Genera pasos plausibles hasta que algo externo, a menudo una persona curiosa por una factura inesperada, lo detiene.

    La lección no es desconfiar ciegamente de los agentes en general. Se trata de dejar de confundir el movimiento con progreso, tanto en los sistemas automatizados como en gran parte del trabajo humano.

    Puntos clave

    • En un bucle de llamadas a herramientas, el modelo decide por sí solo cuándo ha terminado devolviendo end_turn; si el objetivo no tiene un punto final reconocible, es posible que nunca lo haga.
    • El gasto descontrolado se concentra en investigaciones ilimitadas, modelos excesivamente grandes para tareas simples, hilos que crecen sin cesar y trabajos programados olvidados.
    • Aumentar los presupuestos o los límites de pasos solo retrasa el mismo fracaso; en su lugar, defina explícitamente cuándo se ha completado la tarea.
    • Devuelva resultados de las herramientas inequívocos y detecte llamadas repetidas e idénticas a las mismas herramientas, en lugar de depender del conteo de pasos.
    • Para ejecuciones sin supervisión, combine puntos de control humanos con límites estrictos de gasto.

    Lecturas relacionadas

  • Diseño de agentes AI ambientales: cono de despertar, sueño económico y despertares seguros — Cómo crear agentes AI impulsados por eventos que permanezcan inactivos de forma económica: triaje en capas antes de cualquier llamada al modelo, reconstrucción segura del despertar, manejo de tormentas y presupuestos de atención.