Arquitectura de Asistentes de IA: LLM, Memoria, Herramientas, Enrutamiento, Observabilidad

Un asistente de IA de producción no es “un LLM con un prompt”. Es un sistema que acepta la intención del usuario, mantiene el estado, decide cuándo recuperar información o actuar, y expone suficientes detalles en tiempo de ejecución para depurar fallos.

Esa visión a nivel de sistema es lo que el clúster de Sistemas de IA explora cuando los asistentes van más allá de una simple invocación de modelo.

OpenAI describe los agentes como aplicaciones que planifican, invocan herramientas, colaboran y mantienen suficiente estado para trabajos de múltiples pasos, mientras que Anthropic enmarca el mismo problema como un sistema de gestión que puede ejecutar archivos, comandos, acceso web y código de forma segura.

La arquitectura más limpia divide las responsabilidades en cinco capas: LLM, Memoria, Herramientas, Enrutamiento y Observabilidad. Esta división coincide con las capacidades expuestas por las APIs principales de los proveedores, por MCP, por entornos de ejecución autoalojados como vLLM y llama.cpp, y por sistemas de asistencia reales como OpenClaw y Hermes.

La memoria debe tratarse como algo más que “contexto más largo”. Los sistemas de recuperación transforman el conocimiento externo en memoria no paramétrica explícita, el mismo espacio de diseño cubierto en profundidad por Generación Aumentada con Recuperación (RAG) — y tanto la guía de contexto de Anthropic como el paper “Lost in the Middle” advierten que simplemente apilar más tokens en el contexto no garantiza una recuperación fiable.

El uso de herramientas es un límite contractual, no magia. La invocación de funciones de OpenAI, el uso de herramientas de Anthropic y MCP dependen todos del mismo patrón: el modelo emite una solicitud estructurada, algún entorno de ejecución la ejecuta y el resultado fluye de vuelta a la conversación. Si ese límite es laxo, el asistente se vuelve laxo.

Mi sesgo es simple: empieza aburrido. Un orquestador, un camino de memoria durable, un traza por solicitud y una política explícita para la ejecución de herramientas. Los gráficos multi-agente son útiles, pero solo después de que puedas explicar los casos de fallo de tu agente único sin adivinar.

Qué es un sistema de asistente de IA

Una definición práctica es esta: un sistema de asistente de IA es un entorno de ejecución que transforma la intención del usuario en una respuesta o acción combinando una interfaz de modelo, ensamblaje de contexto, ejecución de herramientas, gestión de estado y telemetría. Por eso los documentos útiles no son solo fichas de modelo. Los documentos útiles son referencias de API, contratos de herramientas, guías de recuperación, documentos de enrutamiento y documentos de trazabilidad. La API de Respuestas de OpenAI expone interacciones con estado, herramientas integradas e invocación de funciones. La API de Claude de Anthropic expone acceso directo a Mensajes así como Agentes Gestionados. OpenClaw y Hermes van un paso más allá y muestran qué sucede cuando pones esas capacidades detrás de pasarelas, canales, sesiones y memoria persistentes.

En otras palabras, un sistema de asistente tiene un contrato más amplio que una finalización de chat. Un buen contrato interno se parece a esto:

SolicitudAsistente  = intención del usuario + identidad + sesión + adjuntos + política
RespuestaAsistente   = respuesta + acciones + citas + cambios de estado + ID de traza

Este contrato importa porque cada desacuerdo en producción eventualmente se reduce a una de estas preguntas: qué contexto era visible, qué herramienta se ejecutó, qué modelo respondió, qué memoria se leyó o escribió, y dónde la traza indica que el sistema pasó el tiempo. OpenTelemetry define las trazas como el camino de una solicitud a través de una aplicación, que es exactamente la abstracción que los asistentes serios necesitan. LangSmith y OpenLIT luego especializan esa idea para LLMs, herramientas, almacenes vectoriales y flujos de trabajo de agentes.

Componentes e interfaces principales

La división de componentes a continuación es la que encuentro más durable. También es la que mejor se alinea con las APIs oficiales y los entornos de ejecución de código abierto que la gente realmente opera.

La tabla anterior se deriva de las interfaces oficiales de los proveedores, MCP, documentos de bases de datos vectoriales y los documentos de ejecución para vLLM, llama.cpp, OpenClaw y Hermes.

La capa LLM debería hacer tres cosas bien: consumir un contexto de trabajo actual, emitir una respuesta final o una solicitud de acción estructurada, y devolver suficientes metadatos para soportar reintentos y trazabilidad. La API de Respuestas de OpenAI está diseñada explícitamente para interacciones con estado más herramientas integradas e invocación de funciones. La API de Mensajes de Anthropic expone el mismo ciclo principal a través de bloques tool_use y retornos tool_result, mientras que los Agentes Gestionados te dan un sistema alojado si no quieres construir el ciclo tú mismo. Los entornos de ejecución autoalojados como vLLM y llama.cpp importan porque preservan interfaces estilo-proveedor mientras te permiten colocar la inferencia dentro de tu propio entorno.

La capa de Memoria debería dividirse mentalmente en tres categorías: memoria de trabajo, memoria simbólica durable y memoria semántica buscable. Las incrustaciones de OpenAI devuelven vectores que pueden indexarse y buscarse; la Recuperación y Búsqueda de Archivos de OpenAI luego apilan búsqueda semántica y por palabras clave sobre almacenes vectoriales. Pinecone, Weaviate, pgvector y Milvus representan cuatro formas de almacenamiento comunes: totalmente gestionado, vector nativo de código abierto, nativo de Postgres y base de datos vectorial distribuida. Hermes y OpenClaw añaden un recordatorio útil de que no toda la memoria pertenece en un almacén vectorial: notas respaldadas por archivos, promociones revisadas y instantáneas con alcance de sesión suelen ser el diseño más honesto — patrones desglosados en Sistema de Memoria del Agente Hermes para memoria principal limitada e instantáneas de sesión congeladas.

La capa de Herramientas es donde un asistente deja de ser un resumidor y se convierte en software. La invocación de funciones de OpenAI trata las herramientas como funcionalidad definida por esquema que el modelo puede decidir invocar. Anthropic dice lo mismo de manera más explícita: el uso de herramientas es un contrato entre tu aplicación y el modelo, y el modelo nunca ejecuta nada por sí solo. MCP generaliza ese contrato en un protocolo cliente-servidor donde los hosts se conectan a uno o más servidores que exponen herramientas, prompts y recursos — el mismo límite descrito paso a paso en Servidor MCP en Go. LangChain y LlamaIndex se sienten cómodos aquí como bibliotecas de orquestación: LangChain se centra en una arquitectura de agente preconstruida e integraciones, mientras que LlamaIndex se centra en acceso a datos aumentados con contexto, motores de consulta y flujos de trabajo.

La capa de Enrutamiento existe porque “¿qué modelo?” nunca es la única pregunta. También necesitas “¿qué ruta de proveedor, qué inquilino, qué presupuesto, qué clase de latencia y qué conmutación por error?”. LiteLLM es útil porque sus documentos oficiales son refrescantemente concretos: selección ponderada, menos ocupado, basado en latencia, basado en costos y conmutaciones por error limitadas son todos patrones de primera clase. OpenClaw extiende el enrutamiento hacia arriba en aislamiento de canal y agente, mientras que Hermes lo extiende hacia abajo en ranuras de modelo para trabajo principal y auxiliar como resumen, compresión de contexto y enrutamiento de herramientas MCP. Ese es el modelo mental correcto: el enrutador elige más que un modelo, elige un carril de ejecución.

La capa de Observabilidad es lo que evita que la arquitectura se convierta en folklore. OpenTelemetry te da la abstracción de traza. LangSmith te da visibilidad de extremo a extremo sobre los pasos de la aplicación LLM y soporta formas de despliegue en la nube, híbrido y autoalojado. OpenLIT te da observabilidad de IA nativa de OpenTelemetry con opciones de instrumentación sin código y manual, incluyendo soporte para LLMs, frameworks de agentes, bases de datos vectoriales y GPUs. Para métricas de producción, trazas y patrones de SLO a través de flujos de inferencia y agentes, consulta Observabilidad para Sistemas LLM. Si tu asistente no tiene traza por solicitud, span por llamada de modelo e historial de eventos para la ejecución de herramientas, realmente no tienes una arquitectura aún. Tienes “vibes” (sensaciones/intuiciones).

Capturar, enriquecer, responder

La secuencia que sigue apareciendo en sistemas reales es capturar -> enriquecer -> responder -> registrar. Diferentes frameworks lo envuelven de manera diferente, pero el flujo es lo suficientemente estable para tratarlo como la columna vertebral.

sequenceDiagram
    participant U as Usuario o Canal
    participant G as Pasarela o UI
    participant R as Enrutador
    participant M as Memoria y Recuperación
    participant L as LLM
    participant T as Herramientas o MCP
    participant O as Observabilidad

    U->>G: mensaje, archivo o comando
    G->>O: iniciar traza raíz
    G->>R: solicitud + identidad + sesión + política
    R->>M: cargar estado de sesión y recuperar contexto
    M-->>R: notas, fragmentos, metadatos
    R->>L: prompt + contexto + esquemas de herramientas
    L-->>R: respuesta o llamada de herramienta
    alt llamada de herramienta
        R->>T: ejecutar herramienta o acción MCP
        T-->>R: resultado de herramienta
        R->>L: resultado de herramienta + contexto actualizado
        L-->>R: respuesta final
    end
    R->>M: persistir cambios de sesión y candidatos de memoria
    R->>O: spans, métricas, eventos de evaluación
    G-->>U: respuesta

El paso de captura suele ser más importante de lo que parece. Tanto OpenClaw como Hermes ponen una pasarela persistente frente al asistente porque el ingreso no es solo entrada de texto. Incluye metadatos de canal, identidades, autorización, límites de sesión, mensajes directos, grupos, ticks cron y semánticas de entrega. Si omites esa capa y te confías en una abstracción de widget de chat crudo, eventualmente la volverás a atar como middleware ad hoc de todos modos.

El paso de enriquecimiento es donde los sistemas maduros se separan de las demostraciones de juguete. La Recuperación y Búsqueda de Archivos de OpenAI hacen explícita la recuperación a través de almacenes vectoriales y llamadas de búsqueda. LlamaIndex formaliza el mismo patrón a través de conectores de datos, índices, motores de consulta y flujos de trabajo. Hermes va más allá al dividir el parque de modelos en ranuras principales y auxiliares, delegando trabajos como compresión, resumen y enrutamiento a modelos más pequeños o especializados. Ese es un patrón de diseño que vale la pena robar: no gastes los tokens de tu modelo más caro en tareas rutinarias.

El paso de respuesta no es “generar texto”. Es “cerrar el ciclo actual”. Si el modelo puede responder directamente, lo hace. Si necesita una herramienta, emite una solicitud estructurada. El contrato de uso de herramientas de Anthropic y la guía de invocación de funciones de OpenAI hacen esto explícito. La razón por la que esto importa arquitectónicamente es que las salidas ahora incluyen tanto lenguaje como flujo de control. Tu objeto de respuesta es parcialmente prosa y parcialmente plan de ejecución.

El paso de registro es donde aparecen las semánticas de consistencia. Pinecone separa las rutas de escritura y lectura y procesa las escrituras después de un reconocimiento durable. La memoria de Hermes se inyecta como una instantánea congelada por sesión para que pueda preservar el rendimiento de la caché de prefijos, lo que significa que las nuevas escrituras no aparecen automáticamente en el prompt de la sesión actual. El sistema Dreaming de OpenClaw solo promueve candidatos revisados y fundamentados a MEMORY.md, y es opcional en lugar de estar siempre activo. La lección práctica es que la memoria rara vez es realmente lectura-después-escritura a través de cada capa. Necesitas diseñar para una visibilidad escalonada.

OpenClaw y Hermes como sistemas de referencia

OpenClaw y Hermes son casos de referencia útiles porque no son solo envoltorios alrededor de una API de proveedor. Ambos presentan un asistente como un sistema de larga ejecución con pasarelas, sesiones, herramientas, memoria y múltiples backends de modelo.

Este mapeo se basa en los documentos y repositorios oficiales de OpenClaw y Hermes. OpenClaw documenta una arquitectura de pasarela, enrutamiento multi-agente, soporte para proveedores personalizados y autoalojados incluyendo vLLM y Ollama, memoria activa opcional y promoción basada en Dreaming. Hermes documenta una pasarela de mensajería, un bucle central AIAgent, ranuras de modelo principal y auxiliar, memoria integrada e integración nativa de MCP.

Mi lectura ligeramente opinada es que ambos sistemas hacen el mismo argumento arquitectónico con diferentes acentos. OpenClaw es fuertemente primero-pasarela. Hermes es fuertemente primero-bucle-agente. Pero ambos rechazan la idea superficial de que un asistente es solo “prompt más modelo”. Modelan canales, identidades, semánticas de memoria, superficies de herramientas y heterogeneidad de backend como preocupaciones de primera clase. Eso es exactamente lo que debería hacer una arquitectura de producción.

Una pila híbrida práctica inspirada por ambos sistemas se ve así:

edge:
  gateway: hermes o openclaw

routing:
  proxy: litellm
  policy: consciente de latencia y presupuesto
  tenancy: alcance de sesión y canal

llm:
  primary: respuestas openai o mensajes anthropic
  local_fallback: vllm
  local_dev: ollama o llama.cpp

memory:
  session: sqlite o postgres
  semantic: pgvector o weaviate
  embeddings: incrustaciones openai o incrustaciones ollama

tools:
  contract: herramientas de esquema json más mcp
  examples: sistema de archivos, navegador, búsqueda web, APIs internas

observability:
  traces: opentelemetry
  ai_dashboards: openlit o langsmith
  evals: evaluaciones openai más conjuntos de regresión específicos de la aplicación

Esa pila es un patrón de despliegue razonado más que un plano prescrito por un vendedor. Funciona porque las interfaces oficiales se alinean: OpenAI y Anthropic exponen APIs orientadas a herramientas, vLLM y llama.cpp emulan puntos finales estilo-proveedor, Ollama maneja modelos e incrustaciones locales, MCP estandariza herramientas externas, LiteLLM maneja enrutamiento y conmutación por error, y las plataformas compatibles con OpenTelemetry pueden trazar todo el camino.

Patrones, tablas y compensaciones

Hay algunos patrones de asistente repetibles que vale la pena nombrar. Un asistente gestionado mantiene la mayor parte del entorno de ejecución dentro de las APIs del proveedor. Un asistente primero-recuperación trata la memoria y la búsqueda como el principal diferenciador. Un asistente primero-herramienta se comporta más como un operador que como un chatbot. Un asistente de pasarela prioriza el acceso siempre activo a través de superficies de mensajería. Una malla de especialistas descompone el trabajo en múltiples agentes o rutas. Los documentos oficiales a través de OpenAI, Anthropic, LlamaIndex, LiteLLM, OpenClaw y Hermes soportan versiones de estos patrones, incluso si los nombran de manera diferente.

Esta tabla de patrones es una síntesis de los documentos de los proveedores, documentos de frameworks y sistemas de referencia, más que una afirmación de cualquier vendedor individual.

Notas de la tabla: La Búsqueda de Archivos alojada de OpenAI es una herramienta gestionada, Anthropic ofrece un sistema de gestión gestionado, Pinecone es un servicio vectorial gestionado, mientras que vLLM, llama.cpp, Ollama, pgvector, Weaviate, Milvus, LangSmith autoalojado y OpenLIT soportan operación auto-gestionada o híbrida en diversos grados.

Notas de la tabla: Pinecone documenta un plano de control gestionado y planos de datos regionales. Weaviate documenta vectores e índices invertidos con múltiples tipos de índice vectorial. pgvector añade búsqueda de vecinos más cercanos exacta y aproximada a Postgres. Milvus se posiciona como una base de datos vectorial de alto rendimiento y escalable de código abierto, con Zilliz Cloud como la opción gestionada.

Notas de la tabla: OpenAI documenta Respuestas como su interfaz avanzada para respuestas con estado y herramientas integradas. Anthropic documenta la API de Mensajes y el contrato de uso de herramientas por separado de los Agentes Gestionados. vLLM expone un servidor compatible con OpenAI más soporte para la API de Mensajes de Anthropic. Ollama documenta flujos de trabajo de incrustación y modelo local. llama.cpp documenta rutas de chat, respuestas e incrustaciones compatibles con OpenAI, más finalizaciones de chat compatibles con Anthropic.

Esta matriz de compensaciones es una inferencia arquitectónica de los documentos oficiales, no un benchmark de vendedor. La fila de consistencia importa más de lo que muchos blogs admiten: Pinecone separa las rutas de escritura y lectura, Hermes congela la memoria en prompts de inicio de sesión, y OpenClaw promueve memoria durable a través de revisión escalonada. Eso significa que “memoria actualizada” y “memoria visible para la respuesta actual” a menudo son verdades diferentes.

Modos de fallo y mitigaciones

La mayoría de los asistentes no fallan porque el modelo base es “malo”. Fallan porque el sistema circundante miente al modelo, lo priva del contexto correcto, permite que las herramientas se desvíen o hace que la depuración sea imposible.

La base de evidencia para esta tabla es amplia pero consistente. Los documentos de herramientas de Anthropic dejan claro que el uso de herramientas es un límite contractual. Los Guardrails de OpenAI incluyen detección de alucinaciones contra una base de conocimiento de referencia vía Búsqueda de Archivos. SelfCheckGPT muestra que la autoconsistencia a través de muestras puede ayudar a detectar afirmaciones sin soporte. Los resultados de “Lost in the Middle” y la guía de contexto de Anthropic refuerzan la misma lección operativa: más tokens no eliminan la necesidad de curación de contexto.

La pila de mitigación preferida podría ser aburrida y repetitiva: traza cada solicitud, versiona prompts, evalúa la recuperación independientemente, mantén las herramientas idempotentes y ejecuta evaluaciones de regresión antes de cambiar rutas o política de memoria. Los documentos y repositorio de Evals de OpenAI son directos sobre el porqué: sin evaluaciones, es difícil y consume tiempo entender cómo los cambios de modelo o prompt afectan tu caso de uso. Eso aplica tanto para enrutadores y recuperación como para prompts.

Más lectura

Si quieres profundizar, aquí están las fuentes primarias más útiles para mantener abiertas mientras diseñas o revisas una arquitectura de asistente.

• OpenAI: Visión General de Respuestas, Invocación de Funciones, Uso de Herramientas, Recuperación, Búsqueda de Archivos, Evals y MCP para servidores de herramientas remotos.

• Anthropic: Visión General de API, Uso de Herramientas, el contrato de uso de herramientas, Agentes Gestionados, Ventanas de Contexto y el conector MCP.

• MCP mismo: la Visión General de Arquitectura y la Especificación valen la pena leer directamente, porque explican hosts, clientes, servidores, herramientas, prompts, recursos, transportes y negociación de capacidades de manera limpia.

• Frameworks y enrutamiento: Visión General de LangChain, documentos de aumento de contexto de LlamaIndex, documentos de enrutamiento de LiteLLM, documentos de observabilidad de LangSmith.

• Entornos de ejecución y sistemas de asistente autoalojados: vLLM, servidor llama.cpp, incrustaciones Ollama, documentos y repositorio de OpenClaw, documentos y repositorio de Hermes.

• Almacenamiento y observabilidad: Pinecone, Weaviate, pgvector, Milvus, OpenTelemetry, OpenLIT.

• Papers de investigación: Generación Aumentada con Recuperación para Tareas NLP Intensivas en Conocimiento, Lost in the Middle y SelfCheckGPT.