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.

En la práctica, puedes tener ambos. Muchos sistemas reales combinan ambos enfoques. Una herramienta invocada por un bucle ReAct puede ejecutar internamente un pipeline planificado al estilo ReWOO. A su vez, un planificador puede delegar cada etapa en subagentes que operan con sus propios bucles ReAct. Son componentes de software que pueden combinarse allí donde sus ventajas resulten útiles.

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

Un flujo de trabajo de agente compensa cuando la tarea se divide en frentes independientes. Si no existe esa estructura, coordinar varios agentes añade sobrecarga sin aportar valor; un solo bucle será más rápido y fácil de depurar.

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.

Ese coste existe para cualquier tarea. La pregunta es si dicha estructura aporta suficiente beneficio para compensarlo. Para una tarea lineal que se pueda resolver con un solo prompt no compensará el coste de las llamadas y rutas adicionales. La división empieza a resultar útil cuando la propia tarea contiene una estructura difícil de resolver con un solo bucle. Cualquiera de estas condiciones puede inclinar la balanza:

La especialización importa. Distintos frentes necesitan prompts de sistema, herramientas o modelos diferentes. Obligar a un solo agente a cubrirlos puede perjudicar ambos.
Existe paralelismo. Dos tareas pueden ejecutarse a la vez, mientras que un solo agente las ejecutaría en secuencia. Tres búsquedas independientes en paralelo terminan en el tiempo de la más lenta.
El contexto crece demasiado. Un agente que hace todo puede acumular un contexto de 10 000 tokens. Los especialistas conservan solo la parte necesaria.
Conviene aislar fallos. El fallo de una subtarea no tiene que detener toda la tarea. El orquestador puede reintentar, omitir la rama o elegir otra ruta.

Aplicado · Pipeline¿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.

Profundo · Fábrica¿Reunir especialistas repetidos en una sola declaración?

Declara especialistas con una factoría

Los cuatro ejercicios anteriores construyeron agentes sencillos con las mismas piezas que el código de producción no debería repetir para cada especialista: una etiqueta de rol, un prompt de sistema, una lista de herramientas y un contrato de invocación. Una factoría parametriza esas cuatro partes para que puedas declarar agentes especialistas en vez de reescribirlos:

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. Las funciones descritas mediante JSON Schema, si las necesita.
Contrato de invocación. Una interfaz uniforme, como specialist.run(input), que devuelve la respuesta final.

CrewAI, LangChain y LangGraph exponen factorías similares con nombres que varían según el framework: Agent, create_agent o una clase de datos para el rol y el objetivo. La celda siguiente usa los mismos cuatro parámetros para construir un tutor de aritmética y un traductor. Ambos procesan la misma entrada y muestran sus respuestas en paralelo.

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

Escribe una pregunta que requiere una respuesta especializada. El artefacto la clasifica con una llamada al modelo, dirige el ticket al prompt de sistema del especialista correspondiente y transmite su respuesta. Ejecuta el mismo patrón de clasificación y enrutamiento mostrado antes. Aquí las categorías cubren facturación, soporte técnico, cuenta y otros ámbitos de atención al cliente, en lugar de especialistas con numeración fija. Al cambiar de dominio solo cambia la lista de categorías; el mecanismo permanece igual.

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