Del agente ReAct a ARIA: razonar, actuar, observar (y a veces tropezar)

31 October, 2026 | homelab

Serie Homelab · Parte 5 · ← Casi veinte servidores MCP · Local primero, Claude para lo difícil → · Ver la serie

TL;DR: ReAct significa Reason + Act: el modelo piensa un paso, usa una herramienta, mira el resultado y vuelve a pensar, hasta tener respuesta. Mi primer agente era exactamente eso. Hoy ARIA hace lo mismo con más herramientas y más cuidado. Y como todo agente de verdad, a veces tropieza: te muestro un tropiezo real.

ReAct, sin confundirlo con el framework de JavaScript

Es un patrón de agentes, no una librería de interfaces. El ciclo es este:

  1. Pregunta: «¿Hay algo raro en mis nodos?»
  2. Razona: «Necesito el estado de los nodos y las alertas activas.»
  3. Actúa: llama a una herramienta (por ejemplo, listar nodos).
  4. Observa: lee lo que devolvió.
  5. Razona otra vez: «Falta ver las alertas.» Y repite, hasta tener lo necesario para responder.

Un chatbot con documentación te explica qué debería mirar. Un agente ReAct va y mira.

Mi primer agente

Mi primer agente se llamaba Agent-01 y respondía consultas de infraestructura en lenguaje natural. La primera versión usaba GPT-4o-mini con LangChain: era la época de comprobar que esto era posible sin gastar mucho.

Hoy el razonamiento lo hacen Claude y un modelo que corre en mi propia PC, y vive en ARIA, y Agent-01 quedó como una API de solo lectura que alimenta los paneles del Dashboard. La idea es la misma de entonces. Cambió el cerebro y el cuidado con que se usa.

Un tropiezo en vivo

Esta consulta la hice hoy, sin ensayarla:

ARIA responde que hay una alerta de disco activa en Grafana y explica que no pudo identificar qué disco es
ARIA contesta que hay una alerta de disco, pero que no pudo identificar qué disco por un error en la consulta a Prometheus

Mira las herramientas que usó, en la línea gris de abajo. Lo que pasó, en orden:

  1. Buscó qué herramientas tenía (ToolSearch).
  2. Listó las reglas de alerta de Grafana: hay una activa, de disco alto.
  3. Quiso averiguar qué disco con una consulta a Prometheus, y falló: id is invalid.
  4. Revisó los datasources, para ver si había escrito mal algo.
  5. Reintentó la consulta y volvió a fallar.
  6. Respondió con lo que sí sabía y dijo claramente lo que no pudo hacer.

Eso es ReAct funcionando: probó, observó, corrigió, volvió a probar y, al topar con pared, lo reportó. Lo que no hizo es inventar «es el disco de tal nodo, al 87 %», que suena creíble y habría sido mentira. Un agente que dice «no pude» vale más que uno que inventa con seguridad. Que se equivoque está bien; que se equivoque con aplomo, no.

Lo que aprendí

  • El modelo decide, las herramientas ejecutan. Si algo sale mal, sabes en qué lado buscar.
  • Un agente sin tope es un presupuesto sin fondo. Pon un máximo de iteraciones y de tiempo. Con un modelo local, un bucle sin fin es una GPU calentándose para nada.
  • Las descripciones de las herramientas pesan más que el prompt. Sobre todo cuando son muchas (lo cuento aquí).
  • Quiero ver el razonamiento. Cada respuesta trae un enlace «Trace», y ahí veo cada paso. Es el tema de la Parte 12.
  • El tropiezo honesto es una característica. Diseña para que el agente admita lo que no sabe.

Lo que sigue

Todo agente tiene una pregunta de fondo: ¿con qué cerebro responde? Mi regla es gastar el más pequeño que resuelva el problema, y de ahí sale una sorpresa con una GPU de 8 GB. Eso, en el siguiente post.