Comprender qué es un flujo de trabajo agéntico (agentic workflow) y por qué produce resultados mucho mejores que una sola petición a un modelo de lenguaje. Al terminar, el lector sabrá:
Ruta del módulo
Concepto → grados de autonomía → beneficios → aplicaciones → descomposición de tareas → evaluación → patrones de diseño → autoevaluación final.
La forma más habitual de usar un modelo de lenguaje grande (LLM, large language model) es escribirle una petición — «escribe un ensayo sobre el tema X» — y recibir la respuesta completa. Esa respuesta se genera palabra a palabra, de la primera a la última, sin volver atrás. Es el equivalente a pedirle a una persona que redacte un ensayo de un tirón y sin poder usar la tecla de retroceso.
Nadie escribe bien así. Una persona competente primero piensa un esquema, busca información, redacta un borrador, lo relee, detecta lo que flojea y lo corrige. Sorprendentemente, los LLM rinden bastante bien incluso bajo la restricción del «tirón único», pero rinden mucho mejor cuando se les permite trabajar como trabaja una persona: por pasos y con iteraciones.
A la petición única se la llama generación directa o zero-shot (cero ejemplos, un solo intento). Al proceso de la derecha, flujo de trabajo agéntico. Tarda más, pero el producto final es claramente superior.
Un flujo de trabajo agéntico de IA es un proceso en el que una aplicación basada en un LLM ejecuta varios pasos para completar una tarea. Cada paso puede ser una llamada al LLM, una llamada a una herramienta externa (un buscador web, una base de datos, un programa) o incluso una petición de revisión a una persona.
En la figura conviene fijarse en dos detalles. Primero, el LLM aparece en todos los pasos, pero con un encargo distinto en cada uno: planificar, decidir qué buscar, redactar, criticar, corregir. Segundo, algunos pasos se apoyan en algo que el LLM no puede hacer solo — consultar la web o pedir la opinión de una persona (human in the loop, «persona en el bucle»), por ejemplo para validar datos clave.
Expresado en pseudocódigo de Python, la diferencia es evidente:
Cada línea del flujo agéntico es sencilla por sí misma. La potencia está en el encadenamiento: la salida de un paso alimenta al siguiente, y el modelo puede criticar y mejorar su propio trabajo.
Un agente de investigación recibe una pregunta abierta — por ejemplo, «¿cómo montar una nueva empresa de cohetes para competir con SpaceX?» — y produce un informe documentado. Internamente recorre estos pasos:
Como consulta y contrasta muchas fuentes, el informe resultante es bastante más reflexivo que lo que produciría una sola petición. El mismo esquema sirve para agentes especializados: cumplimiento normativo en documentos legales, investigación en el sector sanitario o análisis de productos.
El término «agéntico» se ha convertido en una etiqueta de marketing que se pega a casi cualquier producto. Conviene ignorar el ruido: lo relevante es que el número de aplicaciones realmente útiles construidas con flujos agénticos crece muy deprisa — agentes de atención al cliente, investigación profunda, procesamiento de documentos legales complejos o sugerencia de posibles diagnósticos a partir de los datos de un paciente. Muchas de ellas serían imposibles sin este enfoque.
Y hay una habilidad que separa a quien construye buenos flujos agénticos de quien no: la capacidad de llevar un proceso de desarrollo disciplinado basado en evaluaciones y análisis de errores. Se volverá sobre ello más adelante en este mismo módulo.
1. ¿Qué caracteriza a un flujo de trabajo agéntico?
La definición no depende del tamaño del modelo ni de la ausencia total de programación: un flujo es agéntico porque descompone el trabajo en varios pasos (llamadas al LLM, herramientas, revisión humana).
2. La analogía de «escribir un ensayo sin tecla de retroceso» describe…
En la generación directa el modelo produce la respuesta palabra a palabra, de la primera a la última, sin esquema previo ni revisión: como escribir sin poder borrar.
3. ¿Cuál es el principal coste de un flujo agéntico frente a una única petición?
El flujo agéntico invierte más tiempo (y llamadas) a cambio de un producto claramente mejor. La calidad sube, no baja, y las herramientas externas son precisamente una de sus piezas.
Indica cuáles de estos sistemas son flujos de trabajo agénticos y por qué: (a) un chat que responde a «tradúceme este párrafo» con una sola llamada; (b) un sistema que lee un correo, consulta la base de datos de pedidos y redacta una respuesta; (c) un generador de resúmenes que primero resume cada capítulo y después resume los resúmenes; (d) un autocompletado de código que sugiere la siguiente línea.
(b) y (c) son agénticos: ambos ejecutan varios pasos encadenados, y (b) además usa una herramienta (la base de datos). (a) y (d) son generación directa: una sola llamada produce la salida final. Observa que (c) es agéntico aunque no use herramientas externas: basta con que el trabajo se reparta en varias llamadas cuyo resultado alimenta a la siguiente.
Una petición única dice: «Resume este contrato de 40 páginas y señala los riesgos». Rediséñala como flujo agéntico de 4 o 5 pasos, indicando en cada uno si lo ejecuta un LLM, una herramienta o una persona.
Una propuesta razonable:
La clave es que ningún paso pide al modelo «todo de golpe»: cada uno tiene un encargo acotado y verificable.
Durante un tiempo hubo un debate estéril en la comunidad de IA: alguien publicaba «he construido un agente» y otros respondían «eso no es un agente de verdad». Usar agéntico como adjetivo en lugar de agente como etiqueta de sí o no zanja la discusión: los sistemas pueden ser agénticos en distintos grados. En lugar de discutir qué merece el título, la energía se dedica a construir.
Se retoma el ejemplo del ensayo sobre agujeros negros. A partir de aquí, las figuras usan una notación constante: caja negra para la entrada del usuario, caja violeta para una llamada al LLM y caja discontinua para una herramienta o software externo (una API, interfaz de programación de aplicaciones, de búsqueda web; código que descarga una página…).
En el agente de arriba, el LLM solo genera texto (las consultas y el ensayo); qué herramienta se llama y cuándo lo decidió el programador al escribir el código. Es una secuencia determinista y funciona razonablemente bien.
En el de abajo, el LLM decide: si le conviene la búsqueda web general, la de noticias o la de artículos científicos de arXiv; cuántas páginas descargar; si un PDF necesita convertirse a texto; e incluso si, tras reflexionar sobre el borrador, debe volver atrás a buscar más. La secuencia exacta de pasos ya no la fija el programador, sino el modelo.
| Nivel | ¿Quién decide los pasos? | Herramientas | Previsibilidad |
|---|---|---|---|
| Menos autónomo | El programador, de antemano | Llamadas fijadas en el código | Alta |
| Semiautónomo | El LLM toma algunas decisiones | Elige entre un conjunto predefinido | Media |
| Muy autónomo | El LLM decide la secuencia | Puede escribir funciones o crear herramientas nuevas | Baja |
Dos ideas prácticas se desprenden del espectro. La primera: hay muchísimo valor en el extremo menos autónomo; gran parte de las aplicaciones que hoy se despliegan en empresas son flujos con pasos bien definidos. La segunda: los sistemas muy autónomos son más difíciles de controlar y más impredecibles, y siguen siendo un área activa de investigación. Elegir el nivel de autonomía es una decisión de diseño, no una medalla.
Error común
Dar al modelo la máxima autonomía «porque es más agéntico». Cada decisión que se cede al LLM es una fuente más de variabilidad: si la secuencia de pasos se conoce de antemano, fijarla en el código da un sistema más fiable, más barato de evaluar y más fácil de depurar. La autonomía se añade donde aporta, no por defecto.
1. ¿Por qué resulta útil hablar de sistemas «agénticos» en lugar de clasificar si algo «es o no es un agente»?
Como adjetivo, «agéntico» admite grados. Así se evita el debate binario y se reconoce que tanto un flujo sencillo como uno muy autónomo son agénticos, cada uno en su medida.
2. En un agente poco autónomo, ¿dónde reside principalmente la autonomía del LLM?
En el extremo menos autónomo, la secuencia y las llamadas a herramientas están codificadas de antemano; el LLM solo decide el contenido del texto de cada paso.
3. ¿Qué afirmación sobre los agentes muy autónomos es correcta?
La autonomía aporta flexibilidad a costa de previsibilidad y control. Muchas aplicaciones de gran valor viven en el extremo menos autónomo.
Clasifica como menos autónomo, semiautónomo o muy autónomo: (a) un sistema que siempre extrae los mismos cuatro campos de una factura y los guarda; (b) un asistente que, según la pregunta, elige entre consultar el inventario, el estado de un pedido o la política de devoluciones; (c) un agente que, ante una tarea de análisis de datos, escribe y ejecuta sus propios programas, y si le falta una función la programa.
(a) Menos autónomo: pasos y herramientas fijos. (b) Semiautónomo: el LLM elige herramienta, pero entre un conjunto predefinido. (c) Muy autónomo: decide la secuencia y crea herramientas nuevas.
Partes del agente de investigación poco autónomo de la figura 3. Quieres ceder una sola decisión al LLM para mejorar la calidad sin perder demasiado control. ¿Cuál cederías y qué riesgo introduces?
Una buena candidata es la elección de fuente (web general, noticias o arXiv): mejora mucho la pertinencia según el tema y el conjunto de opciones está cerrado. El riesgo es que el modelo elija mal la fuente para algunos temas (por ejemplo, arXiv para una pregunta de actualidad). Se mitiga registrando la elección en cada ejecución y evaluándola, algo que se trata en la sección de evaluación. Ceder en cambio la decisión de «volver a buscar» introduce el riesgo de bucles largos y costes impredecibles.
La razón principal para usar flujos agénticos es que permiten hacer bien tareas que antes simplemente no salían. Un dato lo ilustra: en HumanEval, una prueba estándar en la que el modelo debe escribir programas que superen unos tests, se comparan dos generaciones de modelos con y sin flujo agéntico.
Pasar de GPT-3.5 a GPT-4 en generación directa supone un salto enorme (de 48 % a 67 %). Pero envolver GPT-3.5 en un flujo agéntico — por ejemplo, pedirle que escriba el código, que reflexione sobre él y que lo mejore — lo lleva bastante más arriba, en torno al 95 % con las mejores técnicas. Y GPT-4 dentro de un flujo agéntico también mejora. Conclusión: el diseño del flujo puede pesar más que la generación del modelo.
Un flujo agéntico tarda más que una sola petición, pero puede ser más rápido que una persona haciendo el mismo trabajo. Para escribir sobre agujeros negros, tres llamadas al LLM pueden proponer en paralelo términos de búsqueda; cada búsqueda identifica tres páginas; y las nueve descargas se lanzan a la vez. Una persona tendría que leer esas nueve páginas una tras otra.
Si cada descarga tarda aproximadamente lo mismo, t, la diferencia es directa:
Un flujo agéntico es una cadena de piezas, y cada pieza se puede añadir o sustituir sin rehacer el resto:
En resumen: mejor rendimiento, paralelismo y modularidad.
1. Según los resultados de HumanEval, ¿qué produjo una mejora mayor?
De 48 % a 67 % por cambio de generación; de 48 % a cerca del 95 % al usar GPT-3.5 dentro de un flujo agéntico. El flujo pesó más que el modelo.
2. ¿Por qué un flujo agéntico puede ser más rápido que una persona aunque tarde más que una sola petición?
El paralelismo convierte el tiempo de nueve descargas secuenciales en, aproximadamente, el tiempo de una sola.
3. ¿Qué es un ejemplo de aprovechar la modularidad?
Modularidad significa poder añadir, quitar o intercambiar componentes (herramientas o modelos) de forma independiente.
Un agente lanza 3 búsquedas (2 s cada una); cada búsqueda devuelve 3 páginas que hay que descargar (4 s cada descarga); después, una llamada final al LLM redacta el informe (15 s). Calcula el tiempo total si todo se hace en secuencia y si búsquedas y descargas se paralelizan por etapas.
En paralelo, cada etapa cuesta lo que su tarea más lenta: las 3 búsquedas a la vez (2 s), las 9 descargas a la vez (4 s) y la redacción (15 s). El tiempo baja casi a un tercio. La llamada final no se paraleliza porque necesita todos los resultados.
Construyes un agente que redacta cada mañana un boletín de noticias financieras. Propón dos sustituciones de componentes que probarías y cómo decidirías si mejoran el resultado.
(1) Sustituir el buscador web general por un buscador de noticias o una API de datos de mercado, para obtener información del día. (2) Usar un LLM pequeño y rápido para generar las consultas y otro más potente solo para redactar. Para decidir, se generan varios boletines con cada variante y se comparan con el mismo criterio: por ejemplo, porcentaje de noticias de las últimas 24 horas (medible con código) y calidad de redacción valorada por un LLM juez o por una persona.
Muchos departamentos financieros reciben facturas y alguien debe registrar quién cobra, cuánto y cuándo, para pagar a tiempo. Un flujo agéntico lo automatiza con un proceso claro: convertir el PDF a texto (por ejemplo, a Markdown), que el LLM decida si el documento es realmente una factura y, si lo es, extraiga los campos requeridos y llame a una herramienta que actualice la base de datos.
| Campo | Valor extraído |
|---|---|
| Emisor | TechFlow Solutions LLC |
| Dirección del emisor | 890 Juniper Drive, San Mateo |
| Importe adeudado | 3 000 $ |
| Fecha de vencimiento | 20 de agosto de 2025 |
En código, el flujo cabe en pocas líneas (JSON, notación de objetos de JavaScript, es el formato estructurado de salida):
Un caso algo más exigente: responder correos de clientes sobre sus pedidos. El proceso sigue siendo claro: extraer la información clave (quién escribe, qué pidió, número de pedido), consultar los registros en la base de datos y redactar una respuesta que una persona revisa antes del envío.
La herramienta «solicitar revisión» coloca el borrador en una cola donde una persona lo aprueba. Agentes de este tipo ya están desplegados en muchas empresas.
Más difícil es un agente que responde a cualquier pregunta del cliente, porque la secuencia de pasos depende de la pregunta:
| Pregunta del cliente | Pasos que el agente debe planificar |
|---|---|
| «¿Tenéis vaqueros negros o azules?» | 1. Consultar inventario de vaqueros negros · 2. Consultar inventario de vaqueros azules · 3. Responder |
| «Quiero devolver la toalla de playa que compré» | 1. Verificar que el cliente la compró · 2. Consultar la política de devoluciones (por ejemplo, 30 días y sin usar) · 3. Si procede: emitir la etiqueta de devolución y marcar el registro como «devolución pendiente» |
Aquí el LLM debe decidir por sí mismo qué pasos hacen falta. Eso hace el proceso más difícil, menos predecible y menos fiable que cuando los pasos están escritos de antemano.
En el extremo más difícil están los agentes que manejan un navegador web: leen la página, hacen clic, rellenan campos y razonan sobre lo que ven para decidir el siguiente paso. Por ejemplo, se le pide comprobar si quedan plazas en dos vuelos concretos de San Francisco a Washington; el agente navega por la web de la aerolínea, tiene problemas, cambia a Google Flights, encuentra los vuelos, vuelve a la web de la aerolínea y confirma la disponibilidad.
Es un área puntera y prometedora, pero aún poco fiable para tareas críticas: si una página tarda en cargar el agente puede no entender qué ocurre, y muchas páginas siguen siendo difíciles de interpretar con precisión.
Las tareas más fáciles tienen un proceso claro paso a paso, idealmente un procedimiento operativo estándar que la organización ya sigue (codificarlo puede costar trabajo, pero la implementación resulta más sencilla), y trabajan solo con texto, que es el terreno natural de los modelos de lenguaje. Las más difíciles exigen planificar sobre la marcha o procesar entradas multimodales (sonido, imagen, vídeo).
1. ¿Por qué el procesamiento de facturas es una buena primera aplicación agéntica?
Un proceso claro y paso a paso se traduce en un flujo fiable. Sí usa herramientas (conversión de PDF a texto y actualización de la base de datos).
2. ¿Qué hace más difícil a un agente de atención al cliente general frente a uno de consultas de pedidos?
Las consultas de pedidos siguen siempre los mismos tres pasos; la atención general obliga al agente a decidir la secuencia en cada caso.
3. ¿Cuál de estas tareas sería, en general, la más difícil para un flujo agéntico?
El uso del ordenador combina pasos desconocidos de antemano con entradas visuales: los dos factores que más complican la fiabilidad.
Ordena de más fácil a más difícil y justifica: (a) transcribir notas de voz de técnicos y crear una orden de trabajo; (b) rellenar un registro de incidencias a partir de formularios de texto con campos fijos; (c) responder dudas libres de usuarios sobre cualquier servicio de la empresa; (d) navegar por el portal web de un proveedor para descargar facturas.
(b) → (a) → (c) → (d). (b) es texto con proceso fijo. (a) mantiene un proceso claro pero añade audio, una entrada multimodal. (c) es texto, pero los pasos dependen de cada pregunta. (d) combina pasos no conocidos de antemano con interpretación visual de páginas web, la frontera más difícil. Es aceptable situar (a) y (c) en orden inverso si se argumenta que la transcripción de voz actual es muy fiable.
Escribe el flujo completo para «quiero devolver la toalla de playa que compré», con las herramientas que necesita y las ramas condicionales. Política: 30 días desde la compra y producto sin usar.
Personas y empresas hacen mucho trabajo útil. La habilidad central para construir flujos agénticos es mirar ese trabajo e identificar pasos discretos que el sistema pueda ejecutar uno a uno. Ante cada paso candidato, la pregunta es siempre la misma: ¿puede hacerlo un LLM, un fragmento corto de código, una llamada a función o una herramienta?
Si la respuesta es «no», se pregunta cómo lo haría una persona y si ese paso puede dividirse en subpasos más pequeños, más fáciles de implementar con un LLM o con una de las herramientas disponibles.
La generación directa de un ensayo suele quedarse en la superficie y cubrir solo hechos obvios. ¿Cómo lo haría una persona? Esquema, búsqueda, redacción: tres pasos, y cada uno es factible para un LLM (con un buscador en el segundo). Se implementa… y quizá los ensayos salgan inconexos: el principio no encaja del todo con el medio, ni el medio con el final. Entonces se vuelve a descomponer el paso que falla, «escribir el ensayo», en tres subpasos: primer borrador, detectar qué revisar, revisar.
No hay una descomposición «definitiva»: se construye una inicial, se observan los resultados y se sigue refinando hasta alcanzar el rendimiento deseado.
| Tarea | Paso | Componente |
|---|---|---|
| Responder correo de pedido | 1. Extraer información clave (remitente, artículo, número de pedido) | LLM |
| 2. Buscar los registros del cliente | LLM + consulta a la base de datos de pedidos | |
| 3. Redactar y enviar la respuesta | LLM + API de envío de correo | |
| Extraer datos de una factura | 1. Localizar la información requerida | LLM |
| 2. Crear una entrada nueva en la base de datos y guardarla | LLM + función de actualización |
Descomponer bien exige conocer las piezas con las que se cuenta. Cuantos más bloques se dominan, más flujos se pueden imaginar.
| Bloque | Ejemplos | Usos típicos |
|---|---|---|
| Modelos | LLM (o modelos multimodales grandes, que también procesan imagen o audio) | Generar texto, decidir qué herramienta llamar, extraer información |
| Otros modelos de IA | Convertir PDF a texto, texto a voz, análisis de imagen | |
| Herramientas | API | Búsqueda web, datos en tiempo real (meteorología), enviar correo, consultar calendario |
| Recuperación de información | Bases de datos; RAG (generación aumentada por recuperación, retrieval augmented generation): buscar en una gran colección de textos los fragmentos más relevantes | |
| Ejecución de código | El LLM escribe código y lo ejecuta: calculadora, análisis de datos y mucho más |
1. Al descomponer una tarea, ¿qué pregunta se hace ante cada paso candidato?
La descomposición busca pasos implementables con los bloques disponibles. Si un paso no lo es, se divide en subpasos.
2. Un flujo de 3 pasos produce ensayos inconexos. ¿Cuál es la reacción recomendada?
Se pregunta cómo lo haría una persona: no escribiría el ensayo final al primer intento, sino un borrador que luego revisa.
3. ¿En qué categoría de bloques encaja RAG (generación aumentada por recuperación)?
RAG es una herramienta de recuperación: localiza en una gran colección de textos los fragmentos más relevantes para dárselos al LLM.
Un equipo técnico quiere un informe semanal de incidencias a partir de los tiques abiertos y cerrados en su sistema de gestión. Propón una descomposición inicial, indicando el bloque de cada paso.
Obsérvese que los cálculos se delegan en código, no en el LLM: las cuentas fiables son trabajo de una herramienta.
Asigna el bloque de construcción más adecuado: (a) saber qué tiempo hará mañana en el aeropuerto; (b) calcular la desviación típica de 10 000 lecturas de un sensor; (c) responder preguntas sobre un manual técnico de 800 páginas; (d) leer el texto de una foto de una placa de características; (e) decidir si un correo es una queja o una consulta.
(a) API de datos meteorológicos en tiempo real. (b) Ejecución de código. (c) RAG sobre el manual. (d) Otro modelo de IA de reconocimiento de texto en imagen (o un modelo multimodal). (e) LLM.
La capacidad de llevar un proceso de evaluación disciplinado es uno de los mejores predictores de quién construye buenos flujos agénticos. Y la clave es contraintuitiva: es muy difícil saber de antemano qué fallará. En lugar de diseñar evaluaciones en el vacío, se construye el flujo, se leen sus salidas y se buscan las cosas que debería hacer mejor.
Por ejemplo, al revisar respuestas del agente de pedidos aparece algo inesperado: menciona a la competencia. «Me alegra que haya comprado con nosotros; somos mucho mejores que CompCo». «Claro, tramitamos el reembolso; a diferencia de RivalCo, aquí las devoluciones son fáciles». Si la empresa considera esto un error — crea situaciones incómodas —, ya hay algo concreto que medir.
Mencionar o no a un competidor es un criterio objetivo: o aparece el nombre o no aparece. Con una lista de competidores, basta un poco de código para contar con qué frecuencia ocurre el error:
Al trabajar en eliminar el error, esta cifra debería bajar de una versión a otra. Es el progreso hecho visible.
Como los LLM producen texto libre, muchos criterios son subjetivos — la calidad de un ensayo, por ejemplo — y no se reducen a un sí o no por código. La técnica habitual es usar otro LLM como juez (LLM as a judge):
Se pide al agente de investigación una batería de informes — sobre avances en agujeros negros, sobre robots para cosechar fruta… — y el juez los puntúa (por ejemplo, 3 y 4). A medida que se mejora el agente, las puntuaciones deberían subir.
Una advertencia práctica: los LLM no son muy buenos puntuando en escalas de 1 a 5; las notas resultan poco consistentes. Sirve como primera aproximación, pero suelen dar resultados más fiables los criterios concretos de sí/no (una rúbrica) o pedir al juez que compare dos salidas y elija la mejor.
Las dos clases de evaluación sirven para cosas distintas: la de extremo a extremo dice si el sistema mejora; la de componente y el análisis de trazas dicen dónde conviene invertir el esfuerzo.
Error común
Dedicar semanas a diseñar evaluaciones antes de haber visto una sola salida real. Los fallos importantes (como mencionar a la competencia) casi nunca son los que se imaginan de antemano; un prototipo y una tarde leyendo sus salidas suelen dar mejores evals que cualquier planificación previa.
1. ¿Cuál es el enfoque recomendado para empezar a evaluar un flujo agéntico?
Los fallos reales (como mencionar competidores) son difíciles de prever. Se descubren leyendo salidas y se convierten después en evaluaciones medibles.
2. Para medir si las respuestas mencionan a competidores, ¿qué tipo de evaluación es más adecuada?
Si el criterio es objetivo (aparece o no el nombre), el código es barato, exacto y reproducible.
3. ¿Qué se entiende por análisis de errores en un flujo agéntico?
El análisis de errores examina los pasos intermedios para descubrir qué componente es responsable de un mal resultado final.
Tu política exige que toda respuesta a un cliente sobre un pedido cite su número (formato # seguido de 4 dígitos). Escribe una evaluación en Python que calcule el porcentaje de respuestas que lo incumplen.
Es una evaluación objetiva: no necesita un juez, solo una expresión regular. Una versión más estricta comprobaría que el número citado coincide con el del correo original.
Para un agente de atención al cliente, decide si cada criterio se evalúa mejor con código o con un LLM juez: (a) la respuesta tiene menos de 150 palabras; (b) el tono es empático; (c) incluye un enlace al formulario de devoluciones; (d) responde realmente a la pregunta del cliente; (e) no revela datos de otro cliente.
(a) Código: contar palabras. (b) LLM juez, mejor con una pregunta de sí/no («¿reconoce el problema del cliente antes de proponer una solución?»). (c) Código: buscar la URL. (d) LLM juez, comparando pregunta y respuesta. (e) Mixto: código para detectar nombres, correos o números de pedido que no sean del cliente, y un juez para casos ambiguos.
La mayoría de los flujos agénticos combinan cuatro patrones básicos. Conocerlos es conocer el vocabulario con el que se diseñan estos sistemas.
Se pide al LLM que escriba código para una tarea; después, con otra petición, se le pide revisar ese código «con cuidado: corrección, estilo y eficiencia», y dar críticas constructivas. Con la crítica, genera una versión 2; y así sucesivamente. La crítica puede venir del mismo modelo, de otro agente con el rol de crítico, o de señales externas como los resultados de unos tests («falló el test 3»), que son especialmente valiosas porque no dependen de la opinión del modelo.
Es un patrón sencillo de implementar y que mejora el rendimiento en muchísimas tareas.
Se da al LLM acceso a funciones que puede decidir llamar. Ante «¿cuál es la mejor cafetera según las reseñas?», llama a un buscador web. Ante «si invierto 100 $ al 7 % compuesto durante 12 años, ¿cuánto tendré?», en lugar de calcular «de memoria» — donde los modelos fallan —, escribe y ejecuta código:
| Categoría | Herramientas típicas |
|---|---|
| Análisis | Ejecución de código, Wolfram Alpha, intérpretes de código |
| Recopilación de información | Búsqueda web, Wikipedia, acceso a bases de datos |
| Productividad | Correo, calendario, mensajería |
| Imágenes | Generación de imágenes, descripción de imágenes, OCR (reconocimiento óptico de caracteres) |
Ante una petición compleja, el LLM decide la secuencia de acciones en lugar de seguir una fijada por el programador. Un ejemplo clásico, basado en el sistema de investigación HuggingGPT: «Genera una imagen de una niña leyendo un libro con la misma pose que el niño de example.jpg y describe la nueva imagen con voz». El modelo planifica cuatro pasos y elige un modelo especializado para cada uno:
La planificación es muy potente, pero menos predecible: es más difícil saber de antemano qué hará el sistema.
Igual que una empresa contrata a personas con roles distintos, se pueden instanciar varios agentes con roles especializados — diseñador, programador, revisor, probador… — que colaboran en una tarea compleja, por ejemplo desarrollar un pequeño videojuego. Cada agente es un LLM con instrucciones propias de su rol.
Hay evidencia de que funciona. En un estudio de debate multiagente (Du et al., 2023), varios agentes que discuten entre sí superan a un solo agente:
| Tarea | Un solo agente | Multiagente (debate) |
|---|---|---|
| Biografías (exactitud de datos) | 66,0 % | 73,8 % |
| MMLU (prueba de conocimiento multitarea, Massive Multitask Language Understanding) | 63,9 % | 71,1 % |
| Movimientos de ajedrez válidos | 29,3 % | 45,2 % |
Como regla práctica: reflexión y uso de herramientas son los patrones más maduros y fiables; planificación y multiagente son más potentes, pero también más difíciles de controlar y predecir — de nuevo, el espectro de autonomía.
1. Un sistema genera código, ejecuta los tests y usa los errores para pedir al modelo una versión corregida. ¿Qué patrón aplica?
Generar, criticar y revisar es el patrón de reflexión; los resultados de los tests son una fuente de crítica externa, especialmente fiable.
2. ¿Por qué conviene que el LLM ejecute código para calcular un interés compuesto en lugar de responder directamente?
El uso de herramientas delega en software lo que el modelo hace mal: aquí, aritmética exacta. 100·1,07¹² ≈ 225,22.
3. En el ejemplo de la niña leyendo con la pose de example.jpg, ¿qué decide el LLM?
Es planificación: el modelo convierte una petición compleja en una secuencia (pose → imagen → texto → voz) y elige la herramienta de cada paso.
Indica el patrón dominante: (a) un asistente consulta tu calendario antes de proponer una reunión; (b) tres agentes — investigador, redactor y editor — producen un informe; (c) el modelo relee su resumen y lo acorta donde repite ideas; (d) ante «organiza un viaje», el modelo decide buscar vuelos, luego hotel y después actividades, en ese orden.
(a) Uso de herramientas. (b) Colaboración multiagente. (c) Reflexión. (d) Planificación (que a su vez usará herramientas en cada paso: los patrones se combinan).
Diseña un bucle de reflexión para un agente que traduce preguntas en lenguaje natural a SQL (lenguaje de consulta estructurado). ¿Qué señal externa usarías como crítica? Esboza el código.
La señal externa más directa es ejecutar la consulta: si la base de datos devuelve un error, ese mensaje es una crítica objetiva y precisa. Se limita el número de intentos para evitar bucles infinitos:
Mejora posible: además de los errores, pedir al LLM que compruebe si las filas devueltas responden de verdad a la pregunta (una reflexión sobre el resultado, no solo sobre la sintaxis).
| Término | Significado |
|---|---|
| Flujo de trabajo agéntico | Proceso en el que una aplicación basada en un LLM ejecuta varios pasos (llamadas al modelo, herramientas, revisión humana) para completar una tarea. |
| Generación directa (zero-shot) | Una sola petición al modelo, que produce la respuesta de principio a fin sin revisarla. |
| Autonomía | Grado en que el LLM, y no el programador, decide qué pasos dar y qué herramientas usar. |
| Herramienta | Función o servicio externo (búsqueda web, base de datos, ejecución de código…) que el flujo puede invocar. |
| Persona en el bucle | Paso en el que una persona revisa o aprueba una salida antes de continuar (human in the loop). |
| Descomposición de tareas | Dividir un trabajo en pasos que un LLM, un fragmento de código o una herramienta puedan ejecutar. |
| Eval | Medida sistemática de la calidad de un sistema o de uno de sus pasos. |
| Traza | Conjunto de salidas intermedias de todos los pasos de una ejecución. |
| Análisis de errores | Revisión de los casos fallidos para localizar qué componente es responsable. |
1. Un equipo tiene un procedimiento operativo estándar para validar albaranes de texto. ¿Qué nivel de autonomía es el punto de partida más sensato?
Un procedimiento claro, solo texto, es el caso ideal para un flujo de baja autonomía: fiable y fácil de controlar.
2. Un agente de investigación produce informes con fuentes irrelevantes. Las trazas muestran que las consultas de búsqueda son vagas. ¿Dónde conviene actuar primero?
El análisis de errores localiza el fallo en un componente concreto; se mejora ese paso y se mide de forma aislada.
3. ¿Qué combinación de beneficios explica que un agente prepare en minutos un informe que a una persona le llevaría horas?
El agente lanza búsquedas y descargas a la vez, algo que una persona hace de forma secuencial.
4. ¿Cuál de estos pasos no conviene confiar a un LLM sin herramienta?
La aritmética exacta sobre muchos datos es trabajo para la ejecución de código; el LLM debería llamar a esa herramienta.
5. Un LLM juez puntúa ensayos del 1 al 5, pero las notas varían mucho entre ejecuciones. ¿Qué alternativa es más fiable?
Los LLM no son buenos en escalas numéricas; las rúbricas binarias y las comparaciones por pares dan señales más estables.
6. ¿Qué patrón describe mejor «un agente programador y un agente crítico que se pasan versiones del código»?
Generar y criticar es reflexión; repartir los papeles entre dos agentes añade el patrón multiagente. Los patrones se combinan.
7. ¿Qué indica el resultado de HumanEval sobre cómo priorizar el trabajo?
GPT-3.5 en un flujo agéntico supera a GPT-4 en generación directa, y GPT-4 también mejora dentro de un flujo.
8. Al descomponer una tarea, un paso no puede implementarse con ningún bloque disponible. ¿Qué se hace?
La descomposición es recursiva: un paso demasiado grande se divide hasta que cada subpaso encaje en un LLM o una herramienta.