Cómo crear un agente de IA en un VPS

Qué es realmente un agente de IA

Un agente de IA es un bucle que envuelve a un modelo de lenguaje. El modelo analiza la situación, decide una acción, su código ejecuta esa acción, el resultado vuelve al modelo y el bucle se repite hasta completar la tarea. Esa es la idea fundamental. Un chatbot convencional responde una vez y se detiene. Un agente continúa operando, realizando acciones reales entre sus propios turnos, hasta alcanzar el objetivo que usted le haya asignado.

La acción es la parte crucial. Por sí solo, un modelo de lenguaje solo produce texto. No puede leer un archivo, llamar a una API ni ejecutar un comando. Un agente proporciona al modelo un conjunto de herramientas permitidas y una forma de solicitarlas. Cuando el modelo desea buscar en la web o escribir un archivo, no realiza el trabajo directamente. Emite una solicitud estructurada, su código ejecuta la herramienta y la respuesta se entrega como el siguiente elemento que el modelo lee. El modelo aporta el juicio; su servidor aporta las manos.

No todas las tareas requieren un agente; recurrir a uno por defecto es un error común. Si los pasos se conocen de antemano, un script simple es más sencillo, rápido y fiable. "Obtener esta página cada hora y enviarme el precio por email" es un trabajo programado, no un agente. Construya un agente cuando el camino no esté definido de antemano, cuando el modelo deba analizar lo que encuentra y decidir qué hacer a continuación. El coste de un agente es la imprevisibilidad, así que solo utilice este modelo cuando la flexibilidad justifique el gasto.

Herramientas: cómo actúa un agente

Una herramienta es cualquier capacidad que usted entregue al modelo, descrita lo suficientemente bien como para que este sepa cuándo utilizarla. Leer un archivo, ejecutar un comando de shell, consultar una base de datos o enviar un mensaje: cada una es una herramienta con un nombre, una descripción breve y una lista de entradas. Usted define las herramientas; el modelo decide cuándo llamarlas.

El mecanismo es el mismo en cualquier lugar, independientemente del modelo que utilice. El modelo devuelve una solicitud estructurada que nombra una herramienta y completa sus entradas. Su código detecta esa solicitud, ejecuta la función correspondiente y devuelve el resultado en el siguiente turno. El modelo lee el resultado y llama a otra herramienta o escribe su respuesta final. El "function calling" es la infraestructura de cada agente, y el bucle que lo impulsa son solo unas pocas líneas de código ordinario.

Aquí es también donde reside su control. El modelo puede solicitar la ejecución de un comando, pero nada se ejecuta hasta que su código decida ejecutarlo. En ese intervalo es donde usted debe incluir prompts de aprobación para acciones peligrosas, límites sobre lo que una herramienta puede tocar y un registro de todo lo que el agente haya hecho. La seguridad de un agente depende de las herramientas que le proporcione y de las verificaciones que implemente ante ellas.

MCP: un estándar para conectar herramientas

Escribir una integración nueva para cada servicio manualmente es ineficiente. El Model Context Protocol, o MCP, es un estándar abierto que resuelve esto. En lugar de programar una herramienta nueva para sus archivos, su base de datos y su rastreador de incidencias, usted apunta el agente a un servidor MCP que ya expone esos elementos como herramientas. El agente utiliza un único protocolo; el servidor realiza el trabajo de comunicarse con el sistema real.

La ventaja es la reutilización. Un servidor MCP escrito por otra persona para un servicio que usted utiliza queda disponible para su agente sin necesidad de nuevo código de integración, y un servidor que usted escriba será utilizable por cualquier agente que hable el protocolo. En un VPS esto es relevante, ya que puede ejecutar servidores MCP como servicios pequeños e independientes junto al agente, cada uno con el acceso mínimo necesario. Explico la configuración en running MCP servers on a VPS.

Memoria y recuperación

Un modelo de lenguaje no tiene memoria propia entre llamadas. Todo lo que sabe sobre la tarea actual debe entregárselese en cada turno. Para tareas cortas esto es suficiente, ya que toda la conversación cabe en una sola solicitud. Para cualquier tarea más larga, debe gestionar la memoria usted mismo, y existen dos patrones que conviene conocer.

El primero es un "scratchpad" (bloc de notas). Usted entrega al agente un archivo que puede leer y escribir, y le indica que registre lo que aprende mientras avanza. En el siguiente turno, o en la siguiente sesión, lee el archivo y retoma el trabajo donde lo dejó. Esto es memoria en forma de un documento simple, y funciona porque el agente trata el archivo como una herramienta más.

El segundo es la recuperación (retrieval). Cuando el agente necesita conocimiento de un conjunto grande de documentos que no cabrían en una sola solicitud, usted almacena esos documentos de forma searchable y extrae solo las partes relevantes para la vista del modelo cuando sea necesario. Este patrón se llama retrieval-augmented generation, o RAG. El agente hace una pregunta, su código encuentra los pasajes coincidentes y solo esos se envían al modelo. El almacén reside en su servidor, por lo que sus documentos privados nunca salen de él.

Muchos agentes, un coordinador

Un agente con muchas herramientas es suficiente para la mayoría de las tareas. Cuando un trabajo es grande o se divide naturalmente en partes, ayuda una estructura distinta: un agente coordinador que delega en subagentes especializados. El coordinador divide el objetivo en piezas, entrega cada pieza a un subagente diseñado para ese tipo de trabajo y combina los resultados.

La ventaja es el enfoque. Un subagente con una tarea estrecha y un conjunto de herramientas limitado toma mejores decisiones que un generalista que lo intenta todo, y las piezas independientes pueden ejecutarse simultáneamente. El coste es la coordinación, que es real, así que manténgase con un solo agente hasta que una tarea requiera claramente más. Comience de forma sencilla y añada agentes solo cuando uno solo esté claramente desbordado.

Self-hosted o hosted: qué modelo ejecuta su agente

El modelo es la única parte de un agente que no tiene que ejecutar usted mismo, y elegir dónde reside es la decisión más importante que tomará. Un modelo alojado (hosted), accesible mediante una API, le ofrece el razonamiento más potente sin necesidad de operar nada: usted envía texto y recibe texto. Un modelo self-hosted se ejecuta en su propio servidor, lo que mantiene cada solicitud privada, tiene un coste fijo en lugar de una tarifa por token y no depende de la disponibilidad de terceros. El intercambio es capacidad y esfuerzo. Los mejores modelos hosted están por delante de lo que usted puede ejecutar por su cuenta, y ejecutar el suyo propio implica proporcionarle suficiente memoria para que quepa.

Ese último punto es el inconveniente práctico. Un modelo debe caber en la memoria de su servidor y, si utiliza una GPU, en su memoria de vídeo. Un modelo demasiado grande para el hardware no cargará. Antes de planificar un agente self-hosted, compruebe si el modelo que desea cabe en la máquina que tiene:

Si los números no encajan, tiene tres opciones: elija un modelo más pequeño, utilice una cuantización más agresiva para reducir su tamaño, o utilice una API hosted para el razonamiento y mantenga solo sus herramientas y datos en el servidor. Muchos agentes self-hosted comienzan con un modelo local mediante Ollama on a VPS y recurren a una API hosted para los pasos más complejos.

El servidor es la parte peligrosa

Un agente capaz de ejecutar comandos de shell y escribir archivos es potente, y esa es precisamente la razón por la que es peligroso. El juicio del modelo es bueno pero no perfecto; una instrucción errónea, un bug o una entrada maliciosa pueden convertir a un agente útil en uno que borre el elemento equivocado o filtre un secreto. El trabajo de seguridad no es opcional y, en un servidor, es la parte más importante.

Unos pocos hábitos cubren la mayor parte del riesgo. Ejecute el agente como un usuario dedicado sin privilegios, nunca como root, para que cualquier error tenga un límite; el mismo razonamiento se aplica en running services as an unprivileged user. Mantenga sus secretos, como las claves API, fuera del código y que solo sean legibles por ese usuario. Además, aplique un sandbox a las herramientas que toquen el sistema, para que el agente solo pueda alcanzar lo que realmente necesita. Para un ejemplo práctico de endurecimiento (hardening) de un agente self-hosted real, vea running OpenClaw safely on a VPS. Si prefiere usar un modelo hosted para la inteligencia, la guía complementaria sobre building an agent with Claude on a VPS aplica las mismas ideas utilizando un modelo específico.

Para un ejemplo práctico, building an OpenClaw-style personal agent aplica estos elementos, y si prefiere ejecutar uno ya terminado, comience con self-hosting Hermes Agent on a VPS o running Agent Zero on your own server, y the best self-hosted AI agents in 2026 compara cada opción lista para usar que cubrimos, una por una.

FAQ

¿Cuál es la diferencia entre un agente de IA y un chatbot?

Un chatbot responde a un mensaje y se detiene. Un agente ejecuta un bucle: el modelo decide una acción, su código la ejecuta, el resultado vuelve al modelo y este repite el proceso hasta que la tarea finaliza. La diferencia es que un agente realiza acciones reales entre sus turnos, llamando a herramientas para leer archivos, ejecutar comandos o consultar servicios, en lugar de solo producir texto.

¿Necesito una GPU para ejecutar un agente de IA en un VPS?

Solo si aloja el modelo usted mismo (self-hosting). El bucle del agente, las herramientas y la memoria son código ordinario que funciona correctamente en un VPS normal sin GPU. La GPU es necesaria cuando quiere ejecutar el modelo de lenguaje en su propio hardware, ya que el modelo debe caber en la memoria. Si utiliza un modelo hosted mediante una API, el cómputo pesado ocurre en otro lugar y un VPS modesto es suficiente.

¿Qué es MCP y necesito usarlo para construir un agente?

MCP (Model Context Protocol) es un estándar abierto para conectar un agente con herramientas y fuentes de datos. No es estrictamente necesario, ya que puede escribir cada herramienta manualmente. MCP le ahorra ese trabajo permitiéndole reutilizar servidores existentes para servicios comunes y exponer sus propios sistemas una sola vez para que cualquier agente los utilice. Es una conveniencia que merece la pena a medida que aumenta el número de integraciones.

¿Es seguro dar acceso a mi servidor a un agente de IA?

Puede serlo, si lo contiene. Un agente que ejecuta comandos es tan seguro como la cuenta bajo la que se ejecuta y las herramientas que se le permiten. Ejecútelo como un usuario sin privilegios, mantenga sus secretos fuera de su alcance, aplique un sandbox a las herramientas que toquen el sistema de archivos y requiera aprobación para acciones que sean difíciles de deshacer. Trate al agente como código no confiable que resulta ser inteligente, y déle solo lo que la tarea necesite.