Agente basado en LLM: cómo un bucle de modelo y herramientas sustituyó al chatbot

Tres fechas definen al agente LLM moderno: 2022, cuando se publicó el trabajo sobre el enfoque ReAct; junio de 2023, cuando OpenAI añadió a su API la llamada a funciones; y noviembre de 2024, cuando Anthropic presentó el protocolo MCP para conectar herramientas. En Habr se ha publicado un texto sobre cómo está construido un agente sobre un LLM. El autor advierte desde el principio que no hablará de la arquitectura de los transformers y que mira el sistema desde el lado práctico.

En el anuncio por RSS solo está disponible la introducción, por lo que a continuación se desglosa el esquema general en el que se apoya la mayoría de los agentes, sin resumir los detalles del artículo en sí.

Un bucle en lugar de una sola respuesta

Un chat convencional funciona de forma sencilla: el usuario hace una pregunta y el modelo responde. El agente trabaja de otra manera. El modelo recibe una tarea y una lista de herramientas disponibles, y después decide qué hacer: responder de inmediato o llamar a una función. El resultado de la llamada vuelve al contexto y el modelo da el siguiente paso. Esto continúa hasta que el modelo considera la tarea completada o hasta que un código externo interrumpe el bucle.

El modelo, por sí mismo, no ejecuta nada. Genera una solicitud estructurada, por ejemplo el nombre de una función y sus argumentos en JSON. La ejecuta un programa ordinario, al que se llama orquestador o runtime. Ahí reside la lógica de reintentos, tiempos de espera y restricciones.

De qué se compone un agente

El conjunto de componentes es parecido en la mayoría de las implementaciones, ya sea código propio o un framework ya hecho:

• Modelo: recibe el contexto y devuelve texto o una llamada a una herramienta.
• Herramientas: funciones con una descripción en texto y un esquema de argumentos. Búsqueda, SQL, shell, navegador, API internas.
• Memoria: el historial de pasos dentro de la ventana de contexto más un almacenamiento externo, por ejemplo una base de datos vectorial o archivos.
• Orquestador: código corriente que hace girar el bucle, valida las llamadas y lleva los registros.
• Condición de parada: la respuesta final del modelo, un límite de pasos o un presupuesto de tokens.

Merece mención aparte el MCP. El protocolo define una forma unificada de describir herramientas y recursos, y un mismo servidor puede conectarse a distintos clientes. Para el desarrollador, esto reduce el coste de las integraciones: la descripción de la herramienta se escribe una sola vez.

Dónde fallan los agentes

Los problemas suelen aparecer no en el modelo, sino a su alrededor. El primer problema típico es que el agente entra en un bucle: llama a la misma herramienta con los mismos argumentos y espera un resultado distinto. El segundo es que el contexto crece con cada paso. Las respuestas de las herramientas, sobre todo los volcados largos, desplazan las instrucciones importantes, y el coste de cada paso siguiente aumenta. El tercero es que los errores se acumulan. Si la probabilidad de acertar en cada paso es del 95%, alrededor del 60% de las ejecuciones completará diez pasos seguidos sin errores. Por eso las cadenas largas sin verificaciones funcionan notablemente peor que las cortas.

Otro riesgo tiene que ver con los permisos. Un agente con acceso a shell o a una base de datos ejecuta lo que le propone el modelo, y al modelo se le puede empujar en la dirección equivocada con una entrada desafortunada o con texto de una página web que haya llegado al contexto.

Cómo construir el tuyo

Conviene empezar con un bucle mínimo sobre un solo modelo y dos o tres herramientas. Un límite estricto de pasos y un presupuesto de tokens hacen falta desde el primer día, igual que un registro de cada llamada con sus argumentos y su respuesta: sin él, depurar se convierte en adivinar. Las acciones peligrosas, como escribir, borrar y pagar, es mejor hacerlas pasar por la confirmación de una persona.

Los resultados de las herramientas conviene recortarlos y resumirlos antes de que entren en el contexto. Los frameworks serán útiles más adelante, cuando quede claro qué partes del bucle realmente hay que complicar. El autor publica el análisis completo con ejemplos en Habr, y de ahí conviene tomar los detalles concretos de implementación.