Tipos de agentes de IA: guía y opciones para alojarlos
Conozca los agentes de reflejo, objetivos, utilidad, aprendizaje y multiagente: qué hace cada tipo y cuáles puede alojar honestamente por su cuenta.
Tipos de agentes de IA
Los tipos de agentes de IA proceden de una única taxonomía: agentes de reflejo simple, agentes de reflejo basados en modelos, agentes basados en objetivos, agentes basados en utilidad y agentes de aprendizaje. Cada nombre describe una característica: cuánto recuerda el agente y con cuánta anticipación planifica antes de actuar. Otros dos términos, multiagente y jerárquico, describen cómo se conectan varios agentes, no cómo decide cada uno de ellos.
Esta lista es anterior a todos los modelos que haya utilizado. Procede del libro de texto estándar de IA y sobrevivió a la llegada de los modelos de lenguaje grandes porque plantea la pregunta que todavía determina el diseño: ¿qué necesita saber este sistema antes de actuar? Si todavía está determinando dónde termina un agente y dónde comienza un asistente conversacional, lea primero la diferencia entre un agente de IA y el LLM que ejecuta. Esta página comienza después de esa distinción.
Agentes reflejos simples: una condición, una acción
Un agente reflejo simple asigna la entrada actual a una acción y no conserva memoria de nada anterior. Si la temperatura supera 25, enciende el ventilador. Ese es todo el mecanismo.
Casi con toda seguridad ya ha ejecutado uno. Un webhook que activa un flujo de trabajo de n8n, lee el envío de un formulario y escribe una fila en una base de datos es un agente reflejo simple. Sigue siéndolo aunque haya un modelo de lenguaje en medio que elija una categoría para esa fila. Si le pregunta qué hizo hace una hora, no puede responderle, porque nada conservó esa respuesta.
Este tipo funciona correctamente más veces de lo que se suele esperar. Es barato de ejecutar y sus fallos son fáciles de interpretar: la condición coincidió o no coincidió. Cuando la tarea realmente consiste en «cuando llegue X, haz Y», la memoria añade formas de fallar y no aporta nada. Un agente de n8n activado por un webhook pertenece a esta categoría de la taxonomía, con una interfaz de usuario encima.
Falla en cuanto la acción correcta depende del historial. Un bot de respuestas sin estado de la conversación se contradirá en el tercer mensaje, porque los dos primeros nunca formaron parte de su entrada.
Agentes reflexivos basados en modelos: conservar el estado entre eventos
Un agente reflexivo basado en modelos mantiene una representación interna de su entorno y la actualiza cuando llega nueva información. Aquí, «modelo» significa un modelo del mundo, no una red neuronal. El término es anterior a su significado actual en unos cuarenta años y confunde a casi todo el mundo al leerlo por primera vez.
Una regla de automatización doméstica que apaga las luces después de veinte minutos sin detectar movimiento está basada en un modelo. Tiene que estarlo. «No hay movimiento ahora» y «no ha habido movimiento desde las 21:40» son la misma entrada para un agente reflexivo simple. Sólo el estado almacenado permite distinguirlas.
La versión con un LLM es cualquier agente que tenga un almacén de memoria asociado: un resumen continuo de la conversación o un archivo markdown simple que el agente lea al inicio de cada ejecución. Un servicio de memoria local para un agente es esa idea empaquetada. El mecanismo no cambia. La representación que el agente tiene del mundo sobrevive al evento que la creó.
El estado tiene un coste. Un dato obsoleto es peor que no tener ningún dato, porque el agente actúa basándose en él con plena confianza y sin ninguna advertencia. Todo lo que almacene necesita un mecanismo de caducidad o una forma de volver a comprobarlo. De lo contrario, el agente seguirá razonando sobre un servidor que desmanteló en marzo.
Agentes basados en objetivos: planificación hacia un estado que se puede comprobar
Un agente basado en objetivos recibe un estado objetivo y busca una secuencia de acciones que lo alcance. Trabaja hacia atrás desde el resultado que debe obtener, por lo que la ruta no está escrita de antemano.
Un agente de programación es el ejemplo más claro que puede ejecutar usted mismo. «Hacer que la prueba fallida pase» no especifica archivos ni pasos. El agente lee la prueba, crea un plan, modifica algo, ejecuta la prueba, lee el error y vuelve a intentarlo. El ciclo termina con una comprobación que puede ejecutar realmente. Por eso funciona esa instrucción y no «mejorar este código». Un objetivo que el agente puede evaluar es un objetivo que puede alcanzar. Un objetivo que no puede evaluar se convierte en un ciclo infinito con un coste asociado. Ejecutar un agente de programación en su propio VPS coloca ese ciclo en un entorno donde puede ejecutarse sin ocupar su portátil.
El coste se acumula en este proceso. Cada paso de planificación implica otra llamada al modelo con todo el historial disponible hasta ese momento. Por tanto, una tarea de diez pasos no cuesta diez veces más que un paso, sino más. Lo importante desde el punto de vista de la ingeniería es la estructura del ciclo y la condición que lo detiene. Ese es el tema de la ingeniería de ciclos.
Agentes basados en utilidad: elegir entre varias respuestas válidas
Un objetivo es binario. La utilidad es una puntuación. Un agente basado en utilidad se enfrenta a varios resultados aceptables y elige el que obtiene la puntuación más alta según una función que usted ha definido.
Un trabajo de copia de seguridad que debe terminar antes de que empiece la jornada laboral sin saturar el enlace ascendente es un problema de utilidad. No existe una única respuesta correcta, sino una relación de compensación. Un router que decide qué modelo gestiona cada solicitud y pondera el precio frente a la calidad de la respuesta tiene la misma estructura.
El algoritmo no es la parte difícil. Lo difícil es escribir una función de utilidad honesta. Si sólo puntúa el coste, obtendrá el modelo más barato en todas las solicitudes, incluida aquella que necesitaba el modelo caro. El sistema optimiza exactamente lo que ha medido. Esto es un problema cuando eligió esa métrica porque era fácil de medir.
Agentes con aprendizaje: el tipo que la mayoría supone que ya tiene
Un agente con aprendizaje cambia su propio comportamiento a partir de los resultados anteriores. Necesita un componente que evalúe el resultado y otro que modifique la política en respuesta.
Muy pocos sistemas autohospedados cumplen estos requisitos. Un agente que lee notas que escribió la semana pasada es un agente basado en modelos con un archivo de memoria. Sus pesos son idénticos. Su política es idéntica. La recuperación de información no es aprendizaje, y la diferencia es práctica: un sistema basado en memoria repite un error indefinidamente a menos que algo edite la memoria, mientras que un sistema con aprendizaje debería dejar de cometerlo.
Si necesita la parte de aprendizaje, empiece por crear la evaluación. Un conjunto de pruebas puntuado, una ejecución de su cambio contra ese conjunto y una decisión de conservar o descartar el cambio forman un bucle cerrado en el que usted es el componente de aprendizaje. Es más lento de lo que parece y es la única variante que funciona actualmente con componentes autohospedados. Autohospedar un arnés de evaluación es el punto de partida.
Sistemas multiagente y jerárquicos: disposiciones, no tipos
No son un sexto y un séptimo tipo. Describen cómo se organizan los agentes.
Un sistema multiagente ejecuta varios agentes a la vez dentro de un entorno compartido, como una cola o un repositorio git. Como el entorno es compartido, los agentes entran en conflicto. Dos agentes editando un mismo archivo es el fallo habitual. La solución es un bloqueo o una cola de trabajo. Ningún prompt lo resuelve.
Un sistema jerárquico coloca un supervisor por encima de los trabajadores. El supervisor divide una tarea, distribuye las partes y combina los resultados recibidos. Es popular porque coincide con la forma en que las personas dividen el trabajo. También es costoso porque el contexto del supervisor crece con cada informe que lee. Un arnés multiagente muestra cómo se conecta en la práctica.
Un agente que funciona es mejor que cuatro que funcionan a medias.
Cada transferencia de trabajo es un punto donde se puede perder información. Empiece con un único bucle. Divídalo sólo cuando pueda identificar el paso que actúa como cuello de botella.
Por qué casi todos los sistemas reales son híbridos
Considere un agente de despliegue que podría ejecutar usted mismo. Un webhook lo inicia, por lo que es reactivo. Lee el estado actual de la release, por lo que se basa en un modelo. Planifica los pasos desde la versión en ejecución hasta la versión de destino, por lo que se basa en objetivos. Elige una ventana de despliegue según la carga actual, por lo que se basa en utilidad. Nunca modifica su propia política, por lo que no aprende.
Un solo sistema puede pertenecer simultáneamente a cuatro categorías de la taxonomía. La taxonomía resulta útil como lista de comprobación de diseño, no como etiqueta del producto terminado. Cuando el sistema se comporta mal, la pregunta útil es qué capa falla. Un activador que se ejecutó ante el evento equivocado, un estado obsoleto, una comprobación del objetivo que nunca puede cumplirse y una puntuación que recompensa el resultado incorrecto son cuatro errores distintos con cuatro correcciones distintas.
Qué tipo conviene para cada tarea
- Activador fijo, respuesta fija y sin necesidad de historial: reflejo simple.
- La respuesta correcta depende de lo ocurrido antes: reflejo basado en modelos.
- El estado final se puede comprobar, pero la ruta no se conoce de antemano: basado en objetivos.
- Hay varios resultados aceptables y un compromiso real entre ellos: basado en utilidad.
- Necesita que los resultados mejoren con el tiempo: cree un ciclo de evaluación y acepte que usted es el componente que aprende.
¿Puede alojar estos agentes usted mismo y cuánto cuesta?
Sí, y el coste se divide en dos partes. La orquestación es barata. Una instancia de n8n o un bucle de agente en Python pasa la mayor parte del tiempo esperando llamadas de red, por lo que 2 vCPU y 4 GB de RAM son suficientes. El modelo es donde se concentra el coste.
Si el agente llama a una API alojada, el servidor necesita muy pocos recursos y la factura aumenta con el número de tokens. En un agente basado en objetivos, esto significa que el coste aumenta con el número de pasos de planificación permitidos, así que limite el bucle.
Si ejecuta el modelo en su propio hardware, la RAM determina qué modelos puede ejecutar. Las cifras siguientes son tamaños de archivo publicados habituales para pesos cuantizados a 4 bits en agosto de 2026, junto con una cifra orientativa de RAM total, porque la ventana de contexto y el entorno de ejecución también necesitan espacio adicional a los pesos.
The data behind this chart
[
{
"label": "3B model",
"weights_gb": 2,
"ram_needed_gb": 6
},
{
"label": "8B model",
"weights_gb": 4.9,
"ram_needed_gb": 10
},
{
"label": "14B model",
"weights_gb": 9,
"ram_needed_gb": 16
},
{
"label": "32B model",
"weights_gb": 20,
"ram_needed_gb": 32
},
{
"label": "70B model",
"weights_gb": 43,
"ram_needed_gb": 64
}
]Un modelo 8B a 4 bits ocupa aproximadamente 4.9 GB de pesos, y un equipo con 10 GB de RAM puede ejecutarlo sin usar swap. Un modelo 70B con la misma cuantización ocupa 43 GB de pesos y necesita alrededor de 64 GB. Observe lo que no incluyen esas cifras: la velocidad. En un VPS sin GPU, un modelo 8B a 4 bits genera entre uno y nueve tokens por segundo. Esto es suficiente para un agente que procesa una cola durante la noche, pero resulta lento para cualquier tarea que una persona esté esperando. Reserve la inferencia local para trabajos por lotes y use una GPU o una API para las partes interactivas. La selección de agentes de IA que puede alojar usted mismo explica qué proyectos justifican el espacio en disco, y una ruta de aprendizaje para agentes en 2026 explica qué debe aprender y en qué orden.
Cuando la taxonomía deja de ser útil
No dice nada sobre las herramientas ni los permisos. Los agentes del libro perciben y actúan. A nadie que redactara ese capítulo le preocupaba que un agente tuviera un token de API de producción. Un agente basado en objetivos con acceso al shell y otro agente basado en objetivos con una única conexión de solo lectura a una base de datos aparecen en la misma fila de la tabla, pero tienen riesgos completamente distintos. Decida qué puede tocar un agente antes de decidir lo sofisticado que debe ser y lea cómo evitar que los secretos lleguen a un agente de IA antes de entregarle una credencial.
Tampoco dice nada sobre lo que ocurre cuando falla un paso. Los agentes reales pasan la mayor parte de su tiempo de ejecución gestionando errores: un límite de tasa o una herramienta que devuelve algo que el modelo no esperaba. Ese código determina si el sistema es utilizable, pero ninguna fila de la taxonomía lo describe.
FAQ
¿Cuáles son los cinco tipos de agentes de IA?
Agentes de reflejo simple, de reflejo basado en modelos, basados en objetivos, basados en utilidad y de aprendizaje. Se ordenan según cuánto sabe el agente antes de actuar. Un agente de reflejo simple sólo ve la entrada actual. Un agente basado en modelos mantiene el estado de su entorno. Un agente basado en objetivos planifica hacia un estado objetivo. Un agente basado en utilidad puntúa varios resultados aceptables y elige el más alto. Un agente de aprendizaje modifica su propia política a partir de la retroalimentación, algo que en la práctica casi ninguna implementación autoalojada hace.
¿Qué tipo de agente de IA debo usar para una automatización sencilla?
Un agente de reflejo simple, que en la práctica significa un webhook o una tarea programada que activa una secuencia fija. Si la respuesta correcta depende sólo de la entrada que acaba de llegar, la memoria añade modos de fallo sin aportar capacidades. Cambie a un diseño basado en modelos cuando pueda identificar una decisión que necesite saber qué ocurrió antes.
¿Puedo ejecutar mis propios agentes de IA en un VPS?
Sí. La capa de orquestación consume pocos recursos, por lo que 2 vCPU y 4 GB de RAM ejecutan cómodamente un motor de flujos de trabajo o un bucle de agente. La decisión real es dónde se ejecuta el modelo. Una API alojada mantiene el servidor pequeño y traslada el coste a los tokens. Un modelo local necesita una cantidad de RAM proporcional a su número de parámetros y, sin GPU, genera una cantidad de tokens de un solo dígito por segundo. Esto resulta adecuado para trabajos por lotes en cola, no para una ventana de chat.
¿Un modelo de lenguaje grande es un agente de IA por sí mismo?
No. Un modelo transforma texto de entrada en texto de salida y después se detiene. Se convierte en un agente cuando algo lo envuelve en un bucle que puede actuar sobre el entorno y devolverle el resultado, lo que requiere herramientas que pueda invocar y una condición que indique al bucle cuándo detenerse. El envoltorio es el agente. El modelo es uno de sus componentes.
¿Necesito un sistema multiagente?
Normalmente, no. Un solo bucle con varias herramientas gestiona la mayoría de las tareas y es mucho más fácil de depurar. Varios agentes son útiles cuando partes de una tarea son realmente independientes y pueden ejecutarse al mismo tiempo, o cuando una parte necesita un modelo diferente. El coste es la coordinación: el estado compartido y un supervisor cuyo contexto crece con cada informe de los trabajadores que lee. Añada el segundo agente cuando pueda señalar el paso que es lento.