ReAct Pattern (Reasoning + Acting)

1. Visión general del concepto y problema sistémico

Antes de la aparición del concepto ReAct (publicado por investigadores de la Universidad de Princeton y Google Research en 2022), existía una división en la comunidad entre dos enfoques para la automatización de LLM:

1. Chain-of-Thought (Solo pensamiento): El modelo escribe largas cadenas de razonamientos, pero no tiene acceso al mundo externo. Como resultado, la lógica del razonamiento parece convincente, pero se basa en hechos ficticios y datos obsoletos.
2. Act-Only (Solo acción): El modelo llama a APIs o ejecuta comandos bash sin un autoanálisis intermedio. Esto conduce a repeticiones caóticas, pruebas ciegas de parámetros y la incapacidad de resolver incluso tareas simples de múltiples pasos.

El patrón ReAct (Reasoning + Acting) unió estas dos fuerzas en un único ciclo iterativo: el modelo primero verbaliza sus pensamientos y planifica el siguiente paso, luego ejecuta la acción objetivo, analiza el resultado real del entorno (Observation) y solo después toma la siguiente decisión.

2. Taxonomía arquitectónica y modelo mental

El paso clásico del ciclo ReAct consta de tres estados secuenciales:

• 1. Thought (Razonamiento interno): El agente analiza el estado actual de la tarea, formula una hipótesis y establece una intención concreta: “Necesito verificar si el servicio Redis está corriendo en el puerto 6379 antes de ejecutar las pruebas”. Esta etapa reduce críticamente la probabilidad de errores en los argumentos de las herramientas.
• 2. Action (Llamada a la acción / herramienta): El agente forma una acción concreta con parámetros estrictos: el nombre de la función y un objeto JSON válido (por ejemplo, execute_bash(command="systemctl status redis")).
• 3. Observation (Observación del entorno): El runtime externo intercepta la acción, la ejecuta en el servidor o en la base de datos y devuelve la salida de texto crudo o un código de error de vuelta al contexto del agente.
• 4. Finish / Final Answer (Estado final): Cuando el agente observa en la última Observation que se ha alcanzado el objetivo, detiene el ciclo y formula la respuesta final al usuario.

3. Pipeline técnico y mecánica interna

El ciclo de vida del agente ReAct en un entorno de software:

1. Context & Scratchpad Injection (Preparación del prompt): Se inyectan en el prompt del sistema las reglas de interacción, descripciones de las herramientas disponibles e historia de iteraciones anteriores de la sesión actual (Scratchpad).
2. Inference with Tool Delimiter (Generación de razonamiento e intención): LLM genera tokens para la sección Thought. Una vez que el modelo llega a la llamada de la herramienta, la generación se detiene por el cliente y se validan los argumentos de la llamada.
3. Execution & Observation Feedback (Ejecución en el entorno): El orquestador envía el comando a la subsistema correspondiente (terminal local, base de datos o navegador), lee la salida, limita su longitud para ahorrar tokens y añade el mensaje Observation: ... al contexto.
4. Loop Progression & Termination Check (Verificación de salida): Si el agente ha alcanzado el objetivo o el contador max_iterations = 10, el ciclo se interrumpe. De lo contrario, comienza la siguiente iteración con un nuevo bloque Thought.

4. Escenarios prácticos de ingeniería en producción

01. Diagnóstico interactivo y reparación de infraestructura de servidores

• Thought: El servicio devuelve un error 502. Primero revisaré los logs de Nginx de los últimos 5 minutos.
• Action: read_logs(service="nginx", lines=20)
• Observation: connect() failed (111: Connection refused) while connecting to upstream 127.0.0.1:3000
• Thought: El upstream en el puerto 3000 ha caído. Necesito verificar el estado del proceso de Node.js a través de PM2.
• Action: execute_cmd(command="pm2 status")
• Observation: app-server: errored (out of memory)
• Thought: El servicio ha caído por falta de memoria. Lo reiniciaré con un límite de heap mayor.

02. Búsqueda iterativa en documentación y API

El agente intenta llamar a un servicio externo de Stripe. En el primer paso recibe un error invalid_api_key. A través del bloque Thought, el agente recuerda que para el modo de prueba se necesita el prefijo sk_test_, recupera la variable de entorno correcta y en el segundo intento crea exitosamente la intención de pago.

03. Depuración paso a paso de pruebas unitarias

El agente de código ve que una prueba falla debido a una discrepancia en el valor esperado. Formula una hipótesis, realiza un ajuste mínimo en una línea, reinicia la prueba, ve el resultado verde y solo entonces informa sobre la finalización de la tarea.

5. Errores comunes, trampas y seguridad

• Ciclo en una hipótesis errónea (Self-Reinforcing Delusion): Si en el primer paso el modelo hace una conclusión errónea, tiende a interpretar todas las siguientes Observations en favor de su error. Solución: añadir obligatoriamente un paso de crítica (Reflection) después de 3 acciones fallidas consecutivas.
• Inflación del contexto por observaciones crudas: El comando cat huge_file.json devuelve 50,000 tokens de basura, desplazando el prompt del sistema. Siempre limite el tamaño de la salida de Observation en tiempo de ejecución (por ejemplo, no más de 2000 caracteres).
• Llamada a herramientas inexistentes (Action Hallucination): El modelo intenta llamar a una herramienta que no está en la lista. Solución: utilizar la API nativa de Tool Calling en lugar de un análisis de texto crudo.