ReAct vs ReWOO: ¿Qué patrón de ejecución encaja con tu agente?
Traducción automática
Este artículo se tradujo automáticamente a partir de la versión original en inglés.
Usa ReAct cuando la siguiente acción dependa de un tool result que no puedas predecir de antemano. Considera ReWOO cuando un modelo pueda describir los pasos necesarios y las dependencias entre sus resultados antes de la ejecución. Un diseño con planificador y ejecutor ayuda cuando un plan explícito necesita una ejecución y una revisión controladas.
Elige el patrón según las dependencias de la tarea y sus requisitos de recuperación ante fallos. Después, mide sus llamadas al modelo y sus errores.
¿Cuándo examina el modelo los tool results?
| Patrón | Decisiones | Compromiso práctico |
|---|---|---|
| ReAct | El modelo elige una acción tras leer las observaciones | Se adapta a nuevas evidencias, con llamadas repetidas al modelo |
| ReWOO | El planificador escribe los pasos y las referencias a los resultados; el módulo de resolución recibe los resultados | Menos contexto de planificación repetido, con dependencias resueltas durante la ejecución |
| Planificador y ejecutor | El planificador crea un plan; la ejecución puede activar una nueva planificación | Progreso y recuperación explícitos, con estado adicional del plan |
El artículo de ReAct alterna razonamiento, acciones y observaciones. Esto encaja con búsquedas exploratorias en las que cada resultado determina la siguiente consulta. Conservar todos los resultados anteriores puede aumentar la longitud de la entrada; la gestión del contexto sigue siendo parte de la implementación.
ReWOO separa la planificación, el trabajo con herramientas y la síntesis final. Sus pasos pueden hacer referencia a resultados anteriores: primero obtener una ubicación y después buscar restaurantes cerca de ella. La segunda llamada debe esperar a la primera. Solo los pasos independientes pueden ejecutarse en paralelo.
Define la recuperación ante fallos antes de comparar costes
Un plan necesita una política para un tool result ausente, unos argumentos no válidos y un resultado que cambie la tarea. Decide si la ejecución vuelve a intentarlo, se detiene, pide una aclaración o vuelve al planificador. Un plan fijo sin esa política puede fallar aunque sus pasos originales parecieran razonables.
Ejecuta las mismas tareas representativas con los patrones candidatos. Cuenta las tareas completadas correctamente, las acciones incorrectas, las llamadas al modelo, los reintentos y los tokens, y mide el tiempo transcurrido. Incluye pasos dependientes y fallos de herramientas; una demostración en la que todo funciona no puede mostrar el comportamiento de recuperación.
No hay un orden universal de coste en tokens entre estos patrones. La longitud de la tarea, el tamaño de la salida de las herramientas, los reintentos y la implementación pueden invertir el resultado de la comparación.
Para la decisión previa sobre la automatización, consulta agente vs flujo de trabajo. La sección sobre patrones de agentes de la LLM Engineering Guide relaciona la orquestación con tool calls y structured output.