Módulo 2 · Parte A de 3

El agente de flujo de trabajo

Un solo agente ReAct resuelve la mayoría de tareas puntuales. Problemas más complejos, sin embargo, a veces necesitan una estructura que organice el trabajo antes de recibir el siguiente resultado de una herramienta. Un flujo de trabajo de agente es un sistema en el que el entorno de ejecución controla un flujo compuesto por llamadas al modelo, etapas de código determinista, llamadas a herramientas y bucles especializados. Esta estructura resulta útil cuando varias subtareas pueden ejecutarse en paralelo y compartir resultados, cuando conviene escribir un plan antes de usar las herramientas o cuando el enrutamiento debe seguir una regla en vez de una observación reciente.

El motor de ejecución puede delimitar un flujo de trabajo alrededor de una llamada al modelo, una etapa determinista, un bucle especializado o un conjunto de ramas paralelas. En cada caso decide qué contexto usar, qué trabajo puede ramificarse y qué resultados alimentan la siguiente etapa del flujo de trabajo. Esta sección usa fan-out (de uno a muchos) y enrutamiento fijo para demostrar el comportamiento sin cambiar el agente ReAct de la sección anterior.

Compara un mismo incidente de soporte. Para “Me cobraron dos veces la misma suscripción”, un único bucle ReAct lee el resultado de cada consulta antes de elegir la acción siguiente. Un workflow estructurado puede enrutar la verificación de la facturación y las comprobaciones del historial de la cuenta por ramas independientes y después combinar sus evidencias. Usa el bucle cuando el siguiente paso dependa de la observación más reciente. Usa el workflow cuando las ramas y su unión se conozcan antes de la ejecución.

Dos patrones que difieren en cuándo el modelo decide

REACTIVO · PASO A PASO

ReAct (razonamiento y acción)

En cada etapa, el modelo lee la observación más reciente antes de elegir una acción y usar una herramienta. Después evalúa el resultado y vuelve a decidir. El agente reacciona a cada llamada, por lo que el recorrido por las herramientas toma forma durante la ejecución. ReAct funciona bien cuando los pasos dependen de resultados intermedios, pero pierde eficiencia cuando varias etapas independientes podrían ejecutarse a la vez.

Artículo: Yao et al., 2022.

DELIBERATIVO · PLANIFICAR Y EJECUTAR

ReWOO (razonamiento sin observación)

El modelo escribe el plan completo en una sola llamada antes de ejecutar cualquier herramienta. Un ejecutor determinista usa las herramientas indicadas, a menudo en paralelo, y una segunda llamada al modelo sintetiza los resultados. Como el plan no ve las respuestas de las herramientas, el modelo «razona sin observación». ReWOO funciona bien cuando las etapas son independientes, pero no cuando un paso posterior debe reaccionar al resultado de uno anterior.

Artículo: Xu et al., 2023.

ReAct intercala razonamiento y llamadas a herramientas; cada observación informa la siguiente decisión.

ReWOO escribe el plan completo, ejecuta sus etapas sin volver a consultar al modelo y sintetiza una sola vez.

Una herramienta de un ciclo ReAct puede ejecutar un pipeline planificado. Una etapa planificada también puede llamar a un ciclo ReAct cuando necesita adaptarse a resultados intermedios. Las etapas con un procedimiento fijo pueden ejecutarse como funciones normales, como hace el ejecutor del ejemplo siguiente.

Cuando un único bucle supera la división en agentes

El coste de coordinación, en términos concretos. Cada interacción entre agentes añade latencia a las llamadas al modelo y lógica de enrutamiento. También introduce otra fuente de mensajes mal formados, además de sustituir una secuencia fácil de leer por un recorrido distribuido entre varios trabajadores.

Compara las llamadas y la coordinación adicionales con el trabajo que permiten realizar. Distintos prompts o herramientas pueden ayudar a los especialistas a centrarse en su tarea; los trabajos independientes pueden solaparse. Mide la latencia y la calidad de las respuestas antes de decidir si dividir la tarea. Aislar los fallos también requiere un manejo explícito: los ejemplos siguientes usan Promise.all, que se rechaza si se rechaza alguna rama.

¿Ejecutar el pipeline completo de planificación, ejecución y síntesis?

Ejecuta un pipeline ReWOO sobre el glosario de NVIDIA

La celda siguiente ejecuta un pipeline ReWOO sobre el glosario de NVIDIA. Para cada consulta del plan usa helpers.webSearch, la búsqueda ordenada por relevancia que usaste en el Módulo 1c. El explorador del glosario muestra el índice completo y permite probar cualquier consulta que pueda emitir el planificador.

Promise.all permite iniciar varias tareas asíncronas en paralelo (promesas) de JavaScript y esperar a que todas terminen. Aquí solo aporta concurrencia: no llama al modelo ni decide qué búsquedas ejecutar.

Planificador. Una llamada al LLM, restringida por un esquema, genera una lista JSON con entre tres y cinco consultas.
Ejecutor. JavaScript sin llamadas al modelo. Promise.all ejecuta todas las consultas de forma concurrente.
Sintetizador. Una segunda llamada al LLM lee los resultados y redacta el informe, citando cada búsqueda por su índice.

En total: dos llamadas al LLM y N búsquedas paralelas en el glosario. Edita el objetivo y observa cómo cambia la lista de consultas.

ReWOO planifica las llamadas a herramientas, las ejecuta en paralelo y sintetiza los resultados en una llamada final. Xu et al. (2023).

Envía un ticket a un especialista con una enumeración fija

El enrutamiento es otra forma de componer agentes: un agente clasifica una entrada y la entrega a un especialista. Como el clasificador debe devolver una categoría de una enumeración fija, su salida necesita un contrato estricto. Una enumeración fija es una lista cerrada de etiquetas permitidas. Si el modelo devuelve otro valor, el router debe rechazarlo o reintentar con instrucciones más precisas, nunca adivinar. Cada especialista recibe un prompt de sistema acotado y no necesita conocer el razonamiento del clasificador.

La enumeración de cuatro valores selecciona exactamente un especialista para atender la solicitud.

Distribuye una entrada entre varios especialistas

El pipeline ReWOO ya era paralelo: cada consulta planificada se ejecutó de forma concurrente sobre el glosario. Otro patrón habitual distribuye una entrada entre varios especialistas, cada uno con su propio prompt de sistema, y los ejecuta a la vez. En la traza, el tiempo total corresponde al especialista más lento; los demás se solapan dentro de la misma ventana. El diagrama de Gantt muestra la duración de cada uno. Todos comparten un solo resultado de búsqueda web, lo que mantiene acotado el coste.

¿Reunir especialistas repetidos en una sola declaración?

Declara especialistas con una factoría

Cada especialista anterior define una etiqueta de rol, un prompt del sistema, una lista de herramientas y una invocación. La fábrica siguiente expone estos elementos como parámetros para que otro especialista pueda reutilizar la misma construcción.

Rol. Una etiqueta breve para registros y enrutamiento.
Prompt de sistema. El contrato de comportamiento: qué hace, qué rechaza y cómo redacta sus respuestas.
Herramientas. Esquemas opcionales que el modelo puede solicitar. Este envoltorio de una sola llamada devuelve las solicitudes para inspeccionarlas; no las ejecuta.
Contrato de invocación. specialist.run(input) devuelve una respuesta del modelo, incluido el motivo de finalización y las solicitudes de herramientas.

La celda siguiente crea dos especialistas con una fábrica: un tutor de aritmética y un traductor. Ambos reciben la misma entrada y sus respuestas aparecen una junto a la otra.

Antes de continuar

El planificador ReWOO genera una lista JSON de consultas. ¿Qué falla si una consulta necesita un dato obtenido por otra consulta anterior? ¿A cuál de los dos patrones de esta página cambiarías?
El router usa una enumeración fija. ¿Qué debe hacer si el modelo devuelve una categoría no permitida? ¿Basta el esquema JSON o también necesitas validación en la aplicación?
La factoría parametriza rol, prompt de sistema, herramientas e invocación. ¿Qué quinto parámetro añadirías para impedir que un especialista invada el dominio de otro cuando la entrada sea ambigua?

Las dos partes siguientes amplían esta idea de composición. La Parte B (Indexación) aplica el mismo principio a un corpus de información: una capa de conocimiento envuelve los datos tras una interfaz de consulta. La Parte C (Agentes profundos) presenta un agente planificador que delega trabajo en subagentes con contextos nuevos y conserva el estado en un sistema de archivos virtual.

Referencias

Xu et al., ReWOO: Decoupling Reasoning from Observations (2023). Presenta la separación entre planificador, trabajador y solucionador que implementa el agente de flujo de trabajo de este módulo.
Wang et al., Plan-and-Solve Prompting (2023). Antecedente más sencillo: una llamada escribe el plan y el mismo LLM lo ejecuta paso a paso. ReWOO separa planificación y ejecución.
Madaan et al., Self-Refine: Iterative Refinement with Self-Feedback (2023). Explica el patrón de investigación iterativa en varias pasadas: el agente critica su salida y repite hasta alcanzar un umbral de calidad.
LangGraph. Framework de producción que formaliza el patrón de flujo de trabajo o máquina de estados que este módulo construye de forma explícita.

Lista completa en Para ir más lejos · Referencias.

Prueba · router de selección en vivo

Plantea una pregunta de soporte. Una llamada al modelo la clasifica como facturación, problema técnico, cuenta u otro; después responde el especialista seleccionado. Se reutiliza el patrón de clasificación seguida de un especialista, con un prompt de clasificación, un contrato de categorías, un analizador y prompts de especialistas diferentes.

← Módulo 1c: Herramientas a escala Módulo 2b: El agente de indexación →