Sistemas de IA: Asistentes autoalojados, RAG e infraestructura local

Índice

La mayoría de las configuraciones locales de IA empiezan con un modelo y un entorno de ejecución.

Descargas un modelo cuantizado, lo inicias a través de Ollama u otro entorno de ejecución y empiezas a generar consultas. Para experimentar, esto es más que suficiente. Pero una vez que vas más allá de la curiosidad —una vez que te preocupas por la memoria, la calidad de la recuperación, las decisiones de enrutamiento o la conciencia de costes—, la simplicidad comienza a mostrar sus límites.

Este clúster explora un enfoque diferente: tratar al asistente de IA no como una única invocación de un modelo, sino como un sistema coordinado.

Esa distinción puede parecer sutil al principio, pero cambia por completo la forma en que piensas sobre la IA local.

Orquestación de sistemas de IA con LLMs locales, RAG y capas de memoria

¿Qué es un sistema de IA?

Un sistema de IA es más que un modelo. Es una capa de orquestación que conecta la inferencia, la recuperación, la memoria y la ejecución en algo que se comporta como un asistente coherente.

Ejecutar un modelo localmente es trabajo de infraestructura. Diseñar un asistente alrededor de ese modelo es trabajo de sistemas.

Si has explorado nuestras guías más amplias sobre:

ya sabes que la inferencia es solo una capa de la pila.

El clúster de Sistemas de IA se sitúa encima de esas capas. No las reemplaza —las combina.

Para un mapa transversal de cómo esas capas encajan juntas en asistentes de producción —LLM, memoria, herramientas, enrutamiento y observabilidad, con OpenClaw y Hermes como sistemas de referencia—, consulta Arquitectura de asistentes de IA: LLM, memoria, herramientas, enrutamiento, observabilidad.

Una vez que la arquitectura del asistente es sólida, el siguiente paso es hacerlo proactivo. Agentes de sondeo en asistentes de IA: 11 patrones de implementación cubre cómo los trabajadores de sondeo en segundo plano, la ejecución basada en colas, los flujos de trabajo duraderos y los evaluadores semánticos de LLM convierten a un asistente reactivo en uno que vigila, decide y actúa por su cuenta.

Cuando un solo asistente no es suficiente y varios agentes necesitan coordinarse, la elección del patrón de coordinación determina todo: latencia, tolerancia a fallos, coste y depurabilidad. Patrones de orquestación multiagente: Una guía práctica cubre los seis patrones canónicos —orquestador-trabajador, pipeline secuencial, fan-out, jerárquico, enjambre y malla— con modos de fallo específicos y un marco de decisión para elegir la arquitectura correcta.

Antes de añadir más autonomía, vale la pena preguntarse qué decisiones deben permitirse en absoluto a cualquiera de los agentes. LLMs de decisión: cuándo un modelo debe decidir —y cuándo no separa el juicio del modelo de la autoridad del sistema: cinco roles de decisión, enrutando cada decisión a la capa competente más pequeña, y las tiendas de decisiones, invariantes y puertas de radio de explosión que hacen que la decisión de un modelo sea auditable a posteriori.

OpenClaw: Un sistema de asistente de IA autoservido

OpenClaw es un asistente de IA de código abierto y autoservido diseñado para operar a través de plataformas de mensajería mientras funciona en infraestructura local.

A un nivel práctico, permite:

  • Utilizar entornos de ejecución de LLMs locales como Ollama o vLLM
  • Integrar recuperación sobre documentos indexados
  • Mantener memoria más allá de una única sesión
  • Ejecutar herramientas y tareas de automatización
  • Poda ser instrumentado y observado
  • Operar dentro de las limitaciones del hardware

No es solo un envoltorio alrededor de un modelo. Es una capa de orquestación que conecta la inferencia, la recuperación, la memoria y la ejecución en algo que se comporta como un asistente coherente.

Para empezar y arquitectura:

Contexto y análisis:

Ampliando y configurando OpenClaw:

Los plugins amplían el entorno de ejecución de OpenClaw —añadiendo backends de memoria, proveedores de modelos, canales de comunicación, herramientas web y observabilidad. Las habilidades amplían el comportamiento del agente —definiendo cómo y cuándo el agente usa esas capacidades. La configuración de producción significa combinar ambas, moldeada en torno a quién usa realmente el sistema.

Hermes: Un agente persistente con habilidades y sandboxing de herramientas

Hermes Agent es un asistente autoservido e independiente del modelo centrado en la operación persistente: puede ejecutarse como un proceso de larga vida, ejecutar herramientas a través de backends configurables y mejorar flujos de trabajo con el tiempo a través de memoria y habilidades reutilizables.

A un nivel práctico, Hermes es útil cuando se desea:

  • Un asistente centrado en la terminal que también puede puente hacia aplicaciones de mensajería
  • Flexibilidad de proveedor a través de puntos finales compatibles con OpenAI y cambio de modelos
  • Limites de ejecución de herramientas vía backends locales y sandboxeados
  • Operaciones de segundo día con diagnósticos, registros e higiene de configuración

Los perfiles de Hermes son entornos totalmente aislados —cada uno con su propia configuración, secretos, memorias, sesiones, habilidades y estado— haciendo que los perfiles sean la verdadera unidad de propiedad de producción, no la habilidad individual.

Conocimiento persistente y memoria

Algunos problemas no se resuelven solo con una ventana de contexto más grande —necesitan conocimiento persistente (grafos, pipelines de ingesta) y plugins de memoria de agentes (Honcho, Mem0, Hindsight y backends similares) conectados a asistentes como Hermes o OpenClaw.

MCP: Servidores del Protocolo de Contexto de Modelo

El Protocolo de Contexto de Modelo (MCP) es un estándar abierto introducido por Anthropic para conectar modelos de lenguaje de IA a fuentes de datos externas, herramientas y sistemas. Resuelve el problema de integración N×M proporcionando una interfaz universal —piensa en ello como un puerto USB-C para aplicaciones de IA. Construir servidores MCP te permite ampliar asistentes de IA con integraciones personalizadas para archivos, bases de datos, APIs y herramientas invocables, usando un simple protocolo basado en JSON-RPC sobre stdio o HTTP.

  • Habilidades de agentes vs Servidores MCP: Marco de decisión — marco de decisión práctico para cuándo usar habilidades, cuándo construir servidores MCP y cómo el patrón de servidor delgado combina ambos
  • Servidor MCP en Go — arquitectura del protocolo, estructura de mensajes JSON-RPC, negociación de capacidades, SDK oficial de Go y un tutorial paso a paso para construir servidores MCP en Go
  • Construyendo servidores MCP en Python — guía de implementación práctica en Python que cubre servidores MCP de búsqueda web y scraping, transportes stdio y SSE e integración con Claude Desktop

A2A: Protocolo de Agente a Agente

El Protocolo Agente2Agente (A2A) es un estándar abierto para la comunicación entre sistemas de agentes de IA desplegados de forma independiente. Donde MCP conecta a un agente con herramientas, A2A conecta agentes con otros agentes —permitiéndoles descubrirse entre sí mediante Tarjetas de Agente, intercambiar tareas y mensajes, transmitir progreso y devolver artefactos tipados. A2A está diseñado para sistemas donde los agentes son propiedad de equipos diferentes, construidos con frameworks diferentes o desplegados como servicios separados que necesitan interoperar.

Qué hace diferentes a los sistemas de IA

Varias características hacen que los sistemas de IA valgan la pena examinarlos más de cerca.

El enrutamiento de modelos como una elección de diseño

La mayoría de las configuraciones locales predeterminan un solo modelo. Los sistemas de IA permiten seleccionar modelos intencionalmente.

Eso introduce preguntas:

  • ¿Deben las solicitudes pequeñas usar modelos más pequeños?
  • ¿Cuándo el razonamiento justifica una ventana de contexto más grande?
  • ¿Cuál es la diferencia de coste por 1.000 tokens?

Estas preguntas se conectan directamente con las contrapartidas de rendimiento discutidas en la guía de rendimiento de LLM y las decisiones de infraestructura descritas en la guía de hospedaje de LLM.

Los sistemas de IA hacen visibles esas decisiones en lugar de ocultarlas.

La recuperación se trata como un componente evolutivo

Los sistemas de IA integran la recuperación de documentos, pero no como un paso simplista de “incrustar y buscar”.

Reconocen:

  • El tamaño de los fragmentos afecta la precisión y el coste
  • La búsqueda híbrida (BM25 + vector) puede superar a la recuperación densa pura
  • El reranking mejora la relevancia al costo de la latencia
  • La estrategia de indexación impacta el consumo de memoria

Estos temas se alinean con las consideraciones arquitectónicas más profundas discutidas en el tutorial de RAG.

La diferencia es que los sistemas de IA incrustan la recuperación en un asistente vivo en lugar de presentarla como una demo aislada. Deep Research lleva esa idea al extremo: en lugar de un solo pase de recuperación, el sistema planifica, ramifica, reconsulta e itera hasta que la evidencia es suficiente. Sistemas de investigación profunda autoservidos: 12 herramientas comparadas recorre doce sistemas autoservidos —árboles de investigación recursivos, diseños de planificador más subagente y bucles de brechas de evidencia entre ellos— y cómo cada uno convierte la recuperación en un bucle de investigación adaptativo.

La memoria como infraestructura

Los LLMs sin estado olvidan todo entre sesiones.

Los sistemas de IA introducen capas de memoria persistente. Eso plantea inmediatamente preguntas de diseño:

  • ¿Qué debería almacenarse a largo plazo?
  • ¿Cuándo debería resumirse el contexto?
  • ¿Cómo se evita la explosión de tokens?
  • ¿Cómo se indexa la memoria de manera eficiente?

Esas preguntas intersectan directamente con las consideraciones de la capa de datos de la guía de infraestructura de datos. Específicamente para Hermes Agent —memoria de dos archivos acotada, caché de prefijos, plugins externos—, empieza con Sistema de memoria de Hermes Agent y la comparación transversal Comparación de proveedores de memoria de agentes. La captura y reflexión automáticas también pueden convertir la propia inferencia del modelo en “evidencia” futura —consulta Bucles de memoria autoreforzados en agentes de IA por el modo de fallo y Mnemosyne para Hermes Agent por una implementación local conservadora. El Centro de memoria de sistemas de IA lista guías relacionadas de Cognee y capas de conocimiento.

La memoria deja de ser una característica y se convierte en un problema de almacenamiento.

La observabilidad no es opcional

La mayoría de los experimentos de IA local se detienen en “responde”.

Los sistemas de IA permiten observar:

  • Uso de tokens
  • Latencia
  • Utilización del hardware
  • Patrones de caudal

Esto se conecta naturalmente con los principios de monitoreo descritos en la guía de observabilidad.

Si la IA funciona en hardware, debería ser medible como cualquier otra carga de trabajo.

Cómo se siente el uso

Desde el exterior, un sistema de IA aún puede parecer una interfaz de chat.

Bajo la superficie, ocurre más.

Si le pides que resuma un informe técnico almacenado localmente:

  1. Recupera segmentos de documentos relevantes.
  2. Selecciona un modelo apropiado.
  3. Genera una respuesta.
  4. Registra el uso de tokens y la latencia.
  5. Actualiza la memoria persistente si es necesario.

La interacción visible permanece simple. El comportamiento del sistema es estratificado.

Ese comportamiento estratificado es lo que diferencia a un sistema de una demo.

Dónde encajan los sistemas de IA en la pila

El clúster de Sistemas de IA se sitúa en la intersección de varias capas de infraestructura:

  • Hospedaje de LLM: La capa de entorno de ejecución donde se ejecutan los modelos (Ollama, vLLM, llama.cpp)
  • RAG: La capa de recuperación que proporciona contexto y anclaje
  • Rendimiento: La capa de medición que rastrea la latencia y el caudal
  • Observabilidad: La capa de monitoreo que proporciona métricas y seguimiento de costes
  • Infraestructura de datos: La capa de almacenamiento que maneja la memoria y la indexación

Comprender esa distinción es útil. Ejecutarlo tú mismo hace la diferencia más clara.

Para una instalación local mínima con OpenClaw, consulta la guía de inicio rápido de OpenClaw, que recorre una configuración basada en Docker usando ya sea un modelo local de Ollama o una configuración de Claude en la nube.

Si tu configuración depende de Claude, este cambio de política para herramientas de agentes aclara por qué ahora se requiere la facturación de API para los flujos de trabajo de OpenClaw de terceros.

Recursos relacionados

A2A: Protocolo de Agente a Agente:

Servidores MCP:

Comparaciones:

Guías de asistentes de IA:

Capas de infraestructura:

Suscribirse

Recibe nuevas publicaciones sobre sistemas, infraestructura e ingeniería de IA.