English

Define el bucle, no el guion

Dale a una IA dos herramientas y diez pasos, y podrá planificar, buscar y calcular por su cuenta — decidiendo qué herramienta llamar a continuación según lo que devolvió la anterior. Dale contexto desordenado, y se atasca con él. El mecanismo detrás del uso de herramientas en varios pasos es un bucle, no un árbol de decisión escrito a mano, y entender cómo funciona ese bucle cambia tanto la forma en que construyes agentes como la forma en que los mantienes rápidos.

El problema de las ramas codificadas a mano

El instinto al conectar el uso de herramientas es escribir tú mismo el flujo de control: llamar a la herramienta A, revisar el resultado, si se cumple la condición X llamar a la herramienta B, si no llamar a la herramienta C, y así sucesivamente. Esto funciona para una secuencia de pasos fija y conocida. Se desmorona en el momento en que la siguiente acción correcta depende de lo que realmente devolvió una llamada de herramienta anterior — que es donde está el comportamiento más interesante de un agente. Terminas codificando a mano un árbol de ramas if que crece sin parar tratando de anticipar cada camino, y aun así resulta frágil frente al único caso que no anticipaste.

El bucle, mecánicamente

El mecanismo que la mayoría de los frameworks de agentes implementa en realidad es más simple que el enfoque del árbol de ramas, y más general: después de que el modelo genera una llamada de herramienta, tu código ejecuta esa herramienta y envía el resultado de vuelta al modelo como parte de la conversación. El modelo genera de nuevo — ahora con el resultado de la herramienta en el contexto — y produce otra llamada de herramienta o texto plano. Esto se repite hasta que el modelo deja de llamar herramientas, o se alcanza un número máximo de pasos, lo que ocurra primero.

step = 0
while step < MAX_STEPS:
    response = model.generate(messages)
    if response.is_plain_text:
        return response.text          # model is done
    tool_result = run_tool(response.tool_call)
    messages.append(tool_result)      # feed it back
    step += 1
# hit MAX_STEPS — stop and handle gracefully

Nada en este bucle es específico de la tarea. El modelo decide, en cada turno, si tiene suficiente información para responder o si necesita otra llamada de herramienta — y cuál llamar a continuación. El trabajo de tu código es solo ejecutar la herramienta que el modelo pidió y devolverle el resultado. Una única implementación de este bucle soporta tareas arbitrariamente distintas porque la lógica de ramificación vive en el razonamiento del modelo, no en tu código.

Por qué importa el límite de pasos

Sin un número máximo de pasos, un modelo que se queda atrapado en un patrón improductivo — llamando repetidamente a la misma herramienta, o persiguiendo un callejón sin salida — seguirá adelante, quemando tokens y latencia sin garantía de detenerse limpiamente alguna vez. El límite de pasos es un tope duro: si el modelo no ha convergido en una respuesta dentro de N llamadas de herramienta, el bucle sale y tu código decide qué hacer. Esto no es una optimización de rendimiento — es la diferencia entre un sistema acotado y uno sin límite superior de costo o tiempo.

Un límite de pasos razonable depende de la tarea. Un agente de una sola consulta podría toparse con un límite de 3 a 5 pasos; un agente de investigación que encadena varias búsquedas y síntesis podría necesitar de 15 a 20. Empieza conservador y sube el límite solo cuando veas que tareas legítimas de varios pasos se están cortando.

La otra mitad: recorta lo que le devuelves

La corrección del bucle depende de lo que entra en ese mensaje con el resultado de la herramienta. Una llamada de herramienta que raspa una página web completa y devuelve todo el HTML crudo al modelo quema una gran parte del contexto en ruido de formato, anuncios y marcado de navegación que el modelo no necesita — y diluye la señal que necesita para decidir su siguiente paso. Filtrar el resultado de la herramienta hasta lo que realmente es relevante antes de devolverlo mejora de forma medible cuán eficazmente el modelo usa ese contexto — no es solo una optimización del costo en tokens, cambia si la siguiente generación es precisa.

Concretamente: extrae el texto relevante antes de devolverlo, resume un resultado largo en lugar de pegarlo entero, y descarta los campos que el modelo no va a usar. Trata "qué necesita ver el modelo" como una decisión de diseño en cada frontera de herramienta, no como algo secundario.

Dónde aplica este patrón

• Investigación en varios pasos — buscar, leer, refinar la consulta, buscar de nuevo, sintetizar.
• Depuración — inspeccionar un stack trace, ubicar la función que falla, revisar cambios recientes, proponer un arreglo.
• Tareas de planificación — revisar restricciones, consultar opciones, comparar, acotar, presentar un plan.

Cada una de estas tiene un número variable de pasos según la entrada — exactamente el caso donde un árbol de ramas codificado a mano se rompe y un bucle con límite de pasos aguanta.

Trucos avanzados

• Un límite de pasos ausente es un incidente de producción esperando a suceder. Siempre define uno, aunque sea generoso, antes de lanzar cualquier bucle de agente.
• No le devuelvas todo "por si acaso". Un resultado de herramienta recortado y relevante supera a uno completo pero ruidoso — más grande no es más seguro aquí, suele ser peor.
• El límite de pasos es un tope de seguridad, no un plan de UX. Decide de antemano qué hace tu app cuando se alcanza el límite — truncar en silencio una tarea de varios pasos sin terminar suele ser peor que dejar claro que no terminó.

Recursos

• El bucle generar-ejecutar-realimentar-repetir con un límite de pasos es un patrón estándar documentado en los frameworks modernos de agentes / llamada de herramientas — busca en la documentación de tu SDK los términos "multi-step", "agent loop" o "max steps".