De la aplicación con LLM al agente

La mayoría de las funciones con IA son una sola pregunta y una respuesta: un programa le envía texto a un modelo y usa lo que responde. Un agenteAgente Sistema en el que un modelo, dentro de un bucle, elige la siguiente acción hasta decidir que terminó o alcanzar una condición de parada. funciona distinto. El modelo trabaja en un bucle: mira un objetivo, elige una acción, ve el resultado y elige la siguiente acción, hasta que decide que terminó o un límite lo detiene. Ese cambio traslada una decisión de tu código al modelo, y casi todo lo que implica construir agentes se desprende de ahí.

Esta lección cubre cuatro ideas: una prueba única que separa aplicaciones con LLMLLM Large language model: red neuronal entrenada para predecir el siguiente token y ajustada para seguir instrucciones., workflowsWorkflow Secuencia fija de pasos, algunos con llamadas al modelo, que decide tu código y no el modelo. y agentes; el bucle que hace funcionar a un agente; los límites que permiten operar ese bucle con seguridad; y por qué el bucle es, antes que nada, un tema de seguridad.

Una pregunta: ¿quién decide el siguiente paso?

Piensa en alguien que cocina. Una persona sigue una receta paso a paso. Otra recibe un refrigerador lleno y la indicación "prepara la cena", y decide qué hacer según lo que encuentra. La misma diferencia ordena los sistemas de IA en tres tipos.

Aplicación con LLM: el modelo responde. El programa llama a un modelo en puntos fijos, y todos los demás pasos son código que escribió el equipo. Resumir cada ticket de soporte y guardar el resumen es un ejemplo. Si el modelo falla, el daño es acotado: se guarda un mal resumen.

Workflow: el modelo llena huecos en un plan fijo. Un workflow (flujo de trabajo) es una secuencia de pasos, algunos a cargo de un modelo y otros de código común. Puede ramificarse, correr pasos en paralelo y reintentar, pero cada camino posible existe en el código antes de ejecutar nada; leyéndolo, podrías dibujar el mapa completo. Por ejemplo: el modelo etiqueta un ticket como "facturación", el código busca los artículos de ayuda de facturación y el modelo redacta una respuesta con ellos.

Agente: el modelo elige la acción. Ahora toma "arregla esta prueba que falla en un repositorio que nunca has visto". Nadie sabe de antemano qué archivos leer ni cuántos intentos harán falta, así que ningún mapa fijo sirve. Un agente es un sistema en el que un modelo, dentro de un bucle, elige la siguiente acción a partir de un objetivo y de lo que ha visto hasta ahora, hasta que decide que terminó o algo externo lo detiene.

Etiquetas como "asistente" o "workflow agéntico" difuminan esta línea, y eso tiene un costo: si llamas workflow a un agente, subestimas su riesgo.

El bucle, y por qué la versión simple se rompe

Un agente actúa mediante llamadas a herramientas (tool calls): el modelo pide que se haga algo (leer un archivo, ejecutar un comando, consultar un pedido) y el programa lo hace; los detalles están en Tool calling y harness. El ciclo alrededor de esas llamadas es el bucle del agente. Sigue las flechas: el modelo decide, el programa actúa y el resultado vuelve al modelo.

La versión más simple son una docena de líneas de código: repetir para siempre, ejecutar lo que el modelo pida y parar cuando deje de pedir. Funciona en una demo. En producción se rompe de formas previsibles:

• Nada lo obliga a parar, así que un modelo confundido sigue gastando.
• Nada limita el volumen ni la espera. Una respuesta puede pedir cientos de acciones; una acción trabada bloquea todo.
• Nada revisa lo que se ejecuta, sean cuales sean los datos que escribió el modelo.
• Confía en cada respuesta, aunque venga mal formada o cortada por el límite de longitud.
• Guarda sin cuidado. Una caída pierde el trabajo, y guardar en el momento equivocado puede dejar una acción sin su resultado.
• No deja registro de lo que pasó.

Límites que se deciden en el código

Un bucle que puedes operar conoce todas las formas en que puede terminar. Solo una es éxito: el modelo da una respuesta final y no pide nada más. Cualquier otra salida es un límite o una falla, y cada una debería tener nombre, reportarse y aplicarse desde el programa, no pedirse en el promptPrompt Todo lo que se envía al modelo en una llamada: instrucciones, mensajes de la conversación y las definiciones de herramientas, si las hay..

Tres decisiones muestran que los límites dan forma al bucle en vez de decorarlo:

• El límite de llamadas se revisa antes de un lote, no durante. Si el modelo pide cinco acciones y quedan tres, no se ejecuta ninguna. Ejecutar algunas dejaría solicitudes sin resultado, un estado que el historial nunca debe tener.
• Una respuesta cortada nunca se ejecuta. Puede contener una acción escrita a medias.
• El límite de tiempo total se revisa entre rondas, así que no puede interrumpir una llamada al modelo que ya está en curso; eso lo cubre un límite aparte para cada solicitud.

En conjunto, una ronda del bucle de docket se ve así:

El bucle es una superficie de seguridad

El software tradicional cuida la entrada: valida el input una vez y después confía en su propio código. En un agente, lo que elige la siguiente acción es un modelo que lee todo lo que entra en su contexto: la solicitud del usuario, pero también archivos, páginas web, la salida de comandos y las respuestas de otras herramientas. Cualquiera de ellos puede traer texto que el modelo tome como instrucción. El diagrama compara ambos casos: una sola entrada revisada en el software tradicional, muchas sin revisar en un agente.

Cada ronda trae material nuevo, muchas veces buscado por el propio modelo, y es una nueva oportunidad para que entre texto hostil y para que se ejecute una acción. Por eso revisar solo la primera solicitud no protege al agente, y no puedes contar con que el modelo siempre decida bien. El control tiene que estar donde una decisión del modelo se convierte en una acción real, en cada ronda. Ese punto es un punto de aplicación de políticas (policy enforcement point). En docket es una única función por la que pasa toda llamada a herramientas (Security: Layered & Convention-Based), que vemos en Tool calling y harness; amenazas como la prompt injectionPrompt injection Ataque en el que un texto hostil, escrito directamente u oculto dentro de datos que el modelo lee, cambia lo que hace el modelo. están en Sandboxing y seguridad de agentes.

En la práctica

• Pregunta primero si la tarea necesita autonomía. Si puedes dibujar el mapa antes de ejecutar, construye un workflow: más barato, más fácil de probar y con un peor caso previsible.
• Reserva los agentes para tareas cuyo camino no se puede conocer de antemano, y planifica cómo gobernarlos desde el primer día.
• Fija en el código límites de rondas, acciones, tiempo y gasto, y haz que cada parada informe su motivo.
• Pon los controles donde se ejecutan las acciones, no solo en la entrada.

Para profundizar

La documentación de docket muestra estas ideas en un bucle real (en inglés):

• DOCKET Architecture explica por qué docket ejecuta el bucle por su cuenta en lugar de envolver otro programa, y cómo funcionan sus tareas, reintentos y límites de tiempo.
• Security: layered and convention-based describe el control por el que pasa cada llamada a herramientas antes de ejecutarse, que no se puede desactivar, y cómo una aprobación sin respuesta se deniega sola.
• ADR 0001: harness mode registra cómo docket ejecuta el bucle de un agente hasta el final para otro programa e informa cómo terminó, incluso cuando una aprobación no tenía quién la respondiera.

Para llevar

• Las aplicaciones con LLM, los workflows y los agentes se diferencian en quién decide el siguiente paso.
• Un agente es un modelo en un bucle que elige acciones hacia un objetivo, dentro de límites fijados por código.
• Si puedes dibujar el mapa antes de ejecutar, probablemente necesitas un workflow.
• Un bucle operable nombra y reporta cada forma en que puede parar; esos límites le dan forma al bucle y no se pueden agregar después.
• Cada ronda suma input no confiable, así que el control va donde una decisión se vuelve acción.

Comprueba lo aprendido