Cómo crear tu propio agente de IA en un VPS

Qué es realmente un agente de IA

Un agente de IA es un bucle que envuelve un modelo de lenguaje. El modelo lee la situación, decide una acción, el código ejecuta esa acción, el resultado vuelve al modelo y el bucle se repite hasta completar la tarea. Esa es toda la idea. Un chatbot convencional responde una vez y se detiene. Un agente continúa, ejecuta acciones reales entre sus propios turnos y sigue hasta alcanzar el objetivo que se le haya asignado. El bucle es lo bastante pequeño como para escribirlo uno mismo en una tarde. Ahí comienza un itinerario gradual para aprender a crear agentes desde cero, antes de añadir herramientas, memoria y medidas de seguridad.

La acción es la parte importante. Por sí solo, un modelo de lenguaje sólo genera texto. No puede leer un archivo, llamar a una API ni ejecutar un comando. Un agente proporciona al modelo un conjunto de herramientas que puede usar y un mecanismo para solicitarlas. Cuando el modelo quiere buscar en la web o escribir un archivo, no realiza el trabajo directamente. Emite una solicitud estructurada, el código ejecuta la herramienta y la respuesta vuelve como el siguiente elemento que lee el modelo. El modelo aporta el criterio; el servidor aporta la capacidad de ejecución.

No todas las tareas necesitan un agente, y recurrir a uno por defecto es un error habitual. Si los pasos se conocen de antemano, un script convencional es más sencillo, rápido y fiable. «Obtén esta página cada hora y envíame el precio por correo electrónico» es una tarea programada, no un agente. Cree un agente cuando el proceso no esté definido de antemano y el modelo tenga que analizar lo que encuentra para decidir qué hacer a continuación. El coste de un agente es la imprevisibilidad, así que úselo sólo cuando la flexibilidad lo justifique.

Herramientas: cómo actúa un agente

Una herramienta es cualquier capacidad que se proporciona al modelo y se describe con suficiente detalle para que sepa cuándo utilizarla. Leer un archivo, ejecutar un comando de shell, consultar una base de datos y enviar un mensaje son ejemplos de herramientas. Cada una tiene un nombre, una descripción breve y una lista de entradas. Usted define las herramientas; el modelo decide cuándo llamarlas. La búsqueda web suele ser la primera herramienta que conviene añadir. Si ya ejecuta su propia instancia de SearXNG, puede convertirla en el backend de búsqueda del agente en lugar de pagar por una API de búsqueda comercial.

El mecanismo es el mismo en todos los casos, independientemente del modelo que utilice. El modelo devuelve una solicitud estructurada que indica una herramienta y completa sus entradas. Su código recibe esa solicitud, ejecuta la función correspondiente y envía el resultado en el turno siguiente. El modelo lee el resultado y llama a otra herramienta o escribe su respuesta final. Las llamadas a funciones son la infraestructura subyacente de cualquier agente, y el bucle que las ejecuta sólo requiere unas pocas líneas de código normal.

Este también es el punto donde usted mantiene el control. El modelo puede solicitar la ejecución de un comando, pero nada se ejecuta hasta que su código decide hacerlo. En ese punto puede incorporar solicitudes de aprobación para acciones peligrosas, límites sobre los recursos que una herramienta puede modificar y un registro de todo lo que hizo el agente. La seguridad de un agente depende de las herramientas que se le proporcionan y de las comprobaciones que se aplican antes de ejecutarlas.

MCP: una forma estándar de conectar herramientas

Escribir manualmente una integración nueva para cada servicio deja de ser práctico muy pronto. Model Context Protocol, o MCP, es un estándar abierto que resuelve este problema. En lugar de programar una herramienta nueva para los archivos, la base de datos y el gestor de incidencias, basta con indicar al agente un servidor MCP que ya los expone como herramientas. El agente usa un único protocolo; el servidor se encarga de comunicarse con el sistema real.

La ventaja principal es la reutilización. Un servidor MCP desarrollado por otra persona para un servicio que utiliza queda disponible para el agente sin escribir código de integración adicional, y un servidor que desarrolle podrá usarlo cualquier agente compatible con el protocolo. Algunas aplicaciones autoalojadas ya incluyen uno propio: openGym, un gestor de entrenamientos expone un servidor MCP de solo lectura, de modo que un agente puede responder preguntas sobre su historial de entrenamiento sin poder modificarlo. En un VPS, esto es importante porque puede ejecutar los servidores MCP como servicios pequeños independientes junto al agente, cada uno con los permisos que necesita. Cuando los sistemas situados detrás de esos servidores están en una red que el VPS no puede ver, como una base de datos en casa o en una oficina, anunciar esa red a su tailnet con un router de subred permite que el agente acceda a ellos mediante direcciones privadas sin exponer nada a Internet pública. Explico la configuración en ejecutar servidores MCP en un VPS.

Memoria y recuperación

Un modelo de lenguaje no tiene memoria propia entre llamadas. Todo lo que sabe sobre la tarea actual debe proporcionarse en cada turno. Para una tarea breve, esto no supone un problema, porque toda la conversación cabe en una solicitud. La cantidad que cabe depende de la ventana de contexto. Un modelo autohospedado servido por Ollama usa una ventana predeterminada pequeña que descarta silenciosamente los turnos más antiguos. Por eso, configurar num_ctx para que coincida con el tráfico que genera el bucle antes de atribuir al agente los olvidos es una medida recomendable. Para tareas más largas, debe gestionar la memoria por su cuenta. Hay dos patrones que conviene conocer.

El primero es un bloc de notas temporal. Proporcione al agente un archivo que pueda leer y escribir, e indíquele que registre lo que aprende durante el proceso. En el siguiente turno o en la siguiente sesión, leerá de nuevo el archivo y continuará desde donde lo dejó. Esta es una forma de memoria basada en un documento simple. Funciona porque el agente trata el archivo como una herramienta más.

El segundo es la recuperación. Cuando el agente necesita conocimientos de un conjunto grande de documentos que nunca cabría en una sola solicitud, almacene esos documentos en un formato que permita buscarlos e incorpore al contexto del modelo sólo las partes relevantes cuando sean necesarias. Este patrón se denomina generación aumentada mediante recuperación, o RAG. El agente formula una pregunta, el código busca los pocos fragmentos coincidentes y sólo esos fragmentos se envían al modelo. El almacén está en su servidor, por lo que los documentos privados nunca salen de él.

Muchos agentes, un coordinador

Un agente con muchas herramientas sirve para la mayoría de las tareas. Cuando un trabajo es grande o se divide de forma natural, resulta útil otra estructura: un agente coordinador que delega tareas en subagentes especializados. El coordinador divide el objetivo en partes, entrega cada parte a un subagente preparado para ese tipo de trabajo y combina los resultados. La delegación necesita un canal entre las partes. La versión más sencilla ya está disponible en el servidor: dos sesiones de Claude Code en el mismo VPS pueden enviarse mensajes, una forma económica de comprobar cómo funcionan las transferencias antes de crear su propia infraestructura de coordinación.

La ventaja es el enfoque. Un subagente con una tarea concreta y un conjunto reducido de herramientas toma mejores decisiones que un agente generalista que gestiona todo a la vez. Además, las partes independientes pueden ejecutarse simultáneamente. El coste es la coordinación, que es real. Por eso, mantenga un solo agente hasta que una tarea requiera claramente más. Empiece con una estructura sencilla y añada agentes sólo cuando uno esté claramente sobrecargado.

Modelo autoalojado o alojado: qué modelo ejecuta el agente

El modelo es la única parte de un agente que no tiene que ejecutar usted mismo, y elegir dónde se ejecuta es la decisión más importante. Un modelo alojado, al que se accede mediante una API, ofrece la mayor capacidad de razonamiento sin que tenga que operar nada: envía texto y recibe texto. Un modelo autoalojado se ejecuta en su propio servidor. Esto mantiene privadas todas las solicitudes, tiene un coste fijo en lugar de una tarifa por token y no depende de que ningún tercero mantenga su servicio disponible. La contrapartida está en la capacidad y el esfuerzo necesarios. Los mejores modelos alojados superan a los que puede ejecutar por su cuenta, y ejecutar su propio modelo exige disponer de memoria suficiente para cargarlo.

Este último punto es la limitación práctica. El modelo debe caber en la memoria del servidor y, si usa una GPU, en su memoria de vídeo. Un modelo demasiado grande para el hardware no se cargará. Antes de planificar un agente autoalojado, compruebe si el modelo que quiere utilizar cabe en la máquina disponible:

Si las cifras no encajan, tiene tres opciones: elegir un modelo más pequeño, usar una cuantización más agresiva para reducir su tamaño o usar una API alojada para el razonamiento y mantener únicamente las herramientas y los datos en el servidor. Muchos agentes autoalojados empiezan con un modelo local mediante Ollama en un VPS y recurren a una API alojada para los pasos más complejos.

El servidor es la parte peligrosa

Un agente que puede ejecutar comandos de shell y escribir archivos es potente, y por eso mismo es peligroso. El criterio del modelo es bueno, pero no perfecto. Una instrucción incorrecta, un error de software o una entrada maliciosa pueden convertir un agente útil en uno que elimine el elemento equivocado o filtre un secreto. La seguridad no es opcional. En un servidor, es el aspecto más importante.

Unos pocos hábitos cubren la mayor parte de las necesidades. Ejecute el agente con un usuario dedicado sin privilegios, nunca como root, para limitar el impacto de un error; el mismo principio se explica en ejecutar servicios con un usuario sin privilegios. Mantenga sus secretos, como las API keys, fuera del código y permita que sólo ese usuario pueda leerlos. También debe aplicar sandbox a las herramientas que interactúan con el sistema, para que el agente sólo pueda acceder a lo que realmente necesita. Si prefiere no escribir todos los controles manualmente, los plugins de DeepSeek Harness que conviene instalar cubren las mismas necesidades con componentes ya preparados: reglas de permisos para herramientas, análisis de prompt injection y un límite del gasto que el agente puede realizar antes de detenerse. Para ver un ejemplo práctico de cómo proteger un agente real autohospedado, consulte ejecutar OpenClaw de forma segura en un VPS. Si prefiere usar un modelo alojado para la inteligencia, la guía complementaria sobre crear un agente con Claude en un VPS aplica las mismas ideas con un modelo específico.

Como ejemplo práctico, crear un agente personal al estilo de OpenClaw aplica estos componentes. Si prefiere ejecutar uno ya terminado, empiece por autohospedar Hermes Agent en un VPS o ejecutar Agent Zero en su propio servidor. los mejores agentes de IA autohospedados en 2026 compara, uno junto a otro, todos los agentes ya preparados que cubrimos.

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 ciclo: el modelo decide una acción, el código la ejecuta, el resultado vuelve al modelo y el ciclo se repite hasta completar la tarea. La diferencia es que un agente realiza acciones reales entre sus turnos. Para ello, llama a herramientas que leen archivos, ejecutan comandos o consultan servicios, en lugar de limitarse a producir texto.

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

Sólo si aloja el modelo por su cuenta. El ciclo del agente, las herramientas y la memoria son código normal que funciona en un VPS convencional sin GPU. Una GPU es importante cuando quiere ejecutar el modelo de lenguaje en su propio hardware, porque el modelo debe caber en la memoria. Si usa un modelo alojado mediante una API, el cálculo pesado se realiza en otro lugar y basta con un VPS modesto.

¿Qué es MCP y lo necesito para crear un agente?

MCP, Model Context Protocol, es un estándar abierto para conectar un agente con herramientas y fuentes de datos. No lo necesita estrictamente, porque puede escribir cada herramienta manualmente. MCP evita ese trabajo al permitir reutilizar servidores existentes para servicios habituales y exponer sus propios sistemas una sola vez para que cualquier agente los use. Es una comodidad que resulta más útil 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 aísla. La seguridad de un agente que ejecuta comandos depende de la cuenta con la que se ejecuta y de las herramientas que permite. Ejecútelo como un usuario sin privilegios, mantenga sus secretos fuera de su alcance, aísle las herramientas que acceden al sistema de archivos y exija aprobación para las acciones difíciles de deshacer. Trate el agente como código no confiable con capacidad de razonamiento y concédale sólo lo que necesita para la tarea.