Arquitectura del Asistente de IA: LLM, Memoria, Herramientas, Enrutamiento, Observabilidad
Cómo se construyen realmente los asistentes serios.
Un asistente de IA de producción no es simplemente “un LLM con un prompt”. Es un sistema que acepta intenciones, mantiene el estado, decide cuándo recuperar información o actuar, y expone suficiente detalle en tiempo de ejecución para depurar fallos.
Esta visión a nivel de sistema es lo que explora el clúster de Sistemas de IA cuando los asistentes van más allá de una sola invocación de modelo.
OpenAI describe los agentes como aplicaciones que planifican, llaman a 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 API principales de los proveedores, por MCP, por entornos de ejecución autoalojados como vLLM y llama.cpp, y por sistemas de asistentes reales como OpenClaw y Hermes.
La memoria debe tratarse como algo más que un “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 las guías de contexto de Anthropic como el artículo “Lost in the Middle” advierten que simplemente meter más tokens en el contexto no garantiza una recuperación fiable.
El uso de herramientas es un límite contractual, no magia. Las llamadas a funciones de OpenAI, el uso de herramientas de Anthropic y MCP se basan en el 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 con lo básico. Un orquestador, un camino de memoria duradera, un trazo 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, ensamble 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 trazabilidad. La API de Respuestas de OpenAI expone interacciones con estado, herramientas integradas y llamadas a 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é ocurre cuando pones esas capacidades detrás de pasarelas persistentes, canales, sesiones y memoria.
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 trazo
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 el trazo indica que el sistema pasó tiempo. OpenTelemetry define los trazos 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 centrales e interfaces
La división de componentes que se muestra a continuación es la que encuentro más duradera. También es la división que mejor se alinea con las API oficiales y los entornos de ejecución de código abierto que la gente realmente opera.
| Capa | Responsabilidad principal | Interfaz típica | Ejemplos de tecnologías |
|---|---|---|---|
| Capa LLM | Razonar, generar, decidir, emitir llamadas estructuradas | API de Respuestas, API de Mensajes, endpoints compatibles con OpenAI o Anthropic | OpenAI, Anthropic, vLLM, llama.cpp, Ollama |
| Capa de Memoria | Mantener el estado de la sesión, notas duraderas y conocimiento buscable | embeddings, búsqueda vectorial, herramientas de lectura/escritura de memoria, APIs de recuperación | Embeddings y almacenes vectoriales de OpenAI, Pinecone, Weaviate, pgvector, Milvus, memoria de Hermes, memoria de OpenClaw |
| Capa de Herramientas | Leer datos y realizar acciones fuera del modelo | Herramientas con esquema JSON, herramientas MCP, búsqueda de archivos y web, herramientas nativas del entorno de ejecución | Llamadas a funciones de OpenAI, uso de herramientas de Anthropic, MCP, herramientas de LangChain, herramientas de consulta de LlamaIndex |
| Capa de Enrutamiento | Elegir modelo, backend, política y ruta del inquilino | alias de modelos, grupos de conmutación por error, comprobaciones de estado, presupuestos, enlaces de canal | LiteLLM, enrutamiento multi-agente de OpenClaw, resolución de proveedor de entorno de ejecución de Hermes |
| Observabilidad | Explicar qué sucedió y por qué | trazos, spans, registros, métricas, ejecuciones de evaluación | OpenTelemetry, LangSmith, OpenLIT |
La tabla anterior se deriva de las interfaces oficiales de los proveedores, MCP, los documentos de bases de datos vectoriales y los documentos de entorno de ejecución para vLLM, llama.cpp, OpenClaw y Hermes.
La capa LLM debe hacer bien tres cosas: consumir un contexto de trabajo actual, emitir una respuesta final o una solicitud de acción estructurada, y devolver suficiente metadatos para soportar reintentos y trazabilidad. La API de Respuestas de OpenAI está diseñada explícitamente para interacciones con estado, herramientas integradas y llamadas a 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 ofrecen 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 similares a las de los proveedores mientras te permiten colocar la inferencia dentro de tu propio entorno.
La capa de Memoria debe dividirse mentalmente en tres categorías: memoria de trabajo, memoria simbólica duradera y memoria semántica buscable. Los embeddings de OpenAI devuelven vectores que pueden indexarse y buscarse; la Recuperación y Búsqueda de Archivos de OpenAI luego superponen búsqueda semántica y por palabras clave sobre almacenes vectoriales. Pinecone, Weaviate, pgvector y Milvus representan cuatro formas comunes de almacenamiento: totalmente gestionado, base de datos vectorial nativa de código abierto, nativa de Postgres y base de datos vectorial distribuida. Hermes y OpenClaw añaden un recordatorio útil: no toda la memoria pertenece a un almacén vectorial: notas respaldadas por archivos, promociones revisadas y instantáneas con alcance de sesión a menudo son el diseño más honesto. Sistemas de Memoria en Asistentes de IA mapea el modelo entre marcos de trabajo; Sistema de Memoria de Agente Hermes desglosa la memoria central acotada y las instantáneas de sesión congeladas en un producto.
La capa de Herramientas es donde un asistente deja de ser un resumidor y comienza a ser software. Las llamadas a funciones de OpenAI tratan 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í mismo. 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 el 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 costo y conmutaciones por error acotadas 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 trabajos principales y auxiliares como resumido, 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 folclore. OpenTelemetry te da la abstracción de trazo. LangSmith te da visibilidad de extremo a extremo sobre los pasos de la aplicación de LLM y soporta formas de implementación en la nube, híbridas y autoalojadas. OpenLIT te da observabilidad de IA nativa de OpenTelemetry con opciones de instrumentación sin código y manual, incluyendo soporte para LLMs, marcos de trabajo de agentes, bases de datos vectoriales y GPUs. Para métricas de producción, trazos y patrones de SLO a través de flujos de trabajo de inferencia y agentes, consulta Observabilidad para Sistemas de LLM. Si tu asistente no tiene un trazo por solicitud, un span por llamada de modelo y un historial de eventos para la ejecución de herramientas, realmente no tienes una arquitectura aún. Tienes “vibes”.
Capturar, enriquecer, responder
La secuencia que sigue apareciendo en sistemas reales es capturar -> enriquecer -> responder -> registrar. Diferentes marcos de trabajo lo envuelven de manera diferente, pero el flujo es lo suficientemente estable como para tratarlo como la columna vertebral.
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ántica de entrega. Si omites esa capa y confías en una abstracción de widget de chat crudo, eventualmente la volverás a montar 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á dividiendo el patrimonio de modelos en ranuras principales y auxiliares, delegando trabajos como compresión, resumido 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 domésticas.
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 llamadas a 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 en parte prosa y en parte plan de ejecución en tiempo 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 duradero. La memoria de Hermes se inyecta como una instantánea congelada por sesión para preservar el rendimiento de la caché de prefijo, 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 optativo en lugar de siempre activo. La lección práctica es que la memoria rara vez es verdaderamente lectura-después-de-escritura en cada capa. Necesitas diseñar para 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 duración con pasarelas, sesiones, herramientas, memoria y múltiples backends de modelo.
| Preocupación arquitectónica | Mapeo de OpenClaw | Mapeo de Hermes |
|---|---|---|
| Ingreso y superficies | Pasarela autoalojada que conecta aplicaciones de chat y superficies de canal | Pasarela de mensajería de fondo única que conecta muchas plataformas externas |
| Orquestación | Plano de control centrado en la pasarela para canales e interacciones de IA | Bucle AIAgent que maneja el ensamble de prompts, selección de proveedor, despacho de herramientas, reintentos y conmutación por error |
| Enrutamiento | El enrutamiento multi-agente vincula el tráfico entrante a agentes aislados con espacios de trabajo y sesiones separadas | Las ranuras de modelo principal y auxiliar dividen el razonamiento central de la compresión, el resumido, las aprobaciones y el enrutamiento MCP |
| Memoria | Memoria respaldada por archivos más memoria activa opcional y promoción de Dreaming en segundo plano | MEMORY.md y USER.md inyectados como una instantánea de sesión congelada, más proveedores de memoria externos |
| Herramientas y extensión | Herramientas integradas, herramientas de sesión, complementos de proveedor, endpoints personalizados y autoalojados | 40+ herramientas, cliente MCP integrado, conjuntos de herramientas, habilidades y complementos de proveedor de memoria |
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 sesgada es que ambos sistemas hacen el mismo argumento arquitectónico en diferentes acentos. OpenClaw es fuertemente centrado en la pasarela. Hermes es fuertemente centrado en el bucle del 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 or openclaw
routing:
proxy: litellm
policy: latency and budget aware
tenancy: session and channel scoped
llm:
primary: openai responses or anthropic messages
local_fallback: vllm
local_dev: ollama or llama.cpp
memory:
session: sqlite or postgres
semantic: pgvector or weaviate
embeddings: openai embeddings or ollama embeddings
tools:
contract: json schema tools plus mcp
examples: filesystem, browser, web search, internal APIs
observability:
traces: opentelemetry
ai_dashboards: openlit or langsmith
evals: openai evals plus app-specific regression sets
Esa pila es un patrón de implementación razonado en lugar de un plano prescrito por un proveedor. Funciona porque las interfaces oficiales se alinean: OpenAI y Anthropic exponen APIs orientadas a herramientas, vLLM y llama.cpp emulan endpoints estilo proveedor, Ollama maneja modelos y embeddings locales, MCP estandariza herramientas externas, LiteLLM maneja el enrutamiento y la 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 API del proveedor. Un asistente centrado en la recuperación trata la memoria y la búsqueda como el principal diferenciador. Un asistente centrado en herramientas 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 de OpenAI, Anthropic, LlamaIndex, LiteLLM, OpenClaw y Hermes respaldan versiones de estos patrones, incluso si los nombran de manera diferente.
| Patrón | Para qué optimiza | Mejor caso de uso | Costo oculto |
|---|---|---|---|
| Asistente gestionado | Velocidad de entrega | Copilotos internos y bots de soporte | Bloqueo del proveedor y menos control sobre los detalles del entorno de ejecución |
| Asistente centrado en la recuperación | Respuestas fundamentadas sobre datos propios | Documentos, soporte, trabajo de conocimiento | La calidad de la recuperación se convierte en el producto real |
| Asistente centrado en herramientas | Acción sobre conversación | Flujos de trabajo de operaciones, extracciones de datos, automatizaciones | Los efectos secundarios, los reintentos y las aprobaciones se convierten en preocupaciones centrales |
| Asistente de pasarela | Acceso ubicuo | Asistentes personales y de equipo a través de superficies de chat | Complejidad de identidad, sesión y seguridad |
| Malla de especialistas | División del trabajo | Flujos de trabajo complejos con límites reales de propiedad | Depuración, orquestación y diseño de evaluación más difíciles |
El patrón de malla de especialistas crece en una disciplina de ingeniería distinta a medida que aumenta el número de agentes. Para los seis patrones de coordinación canónicos — orquestador-trabajador, pipeline secuencial, abanico, jerárquico, enjambre y malla — con modos de fallo específicos y un marco de decisión para producción, consulta Patrones de Orquestación Multi-Agente.
Esta tabla de patrones es una síntesis de los documentos de los proveedores, los documentos de los marcos de trabajo y los sistemas de referencia, en lugar de una afirmación de un solo proveedor.
| Forma de opción | Componentes típicos | Fortaleza | Debilidad |
|---|---|---|---|
| Gestionado | OpenAI Responses o Agentes Gestionados de Anthropic, búsqueda de archivos o almacenes vectoriales alojados | Camino más rápido, menos partes móviles, herramientas alojadas | Menor control sobre la ruta de datos y las semánticas del entorno de ejecución |
| Híbrido | API del proveedor más enrutador y almacén vectorial autoalojados | Buen equilibrio entre velocidad y control | Más contratos para mantener |
| Autoalojado | vLLM o llama.cpp o Ollama, MCP, base de datos vectorial autoalojada, OTel | Fuerte privacidad y control de implementación | Mayor carga de operaciones, sobrecarga de hardware y ajuste |
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 autoadministrada o híbrida en diversos grados.
| Almacén vectorial | Forma | Por qué los equipos lo eligen | Precaución |
|---|---|---|---|
| Pinecone | Servicio vectorial gestionado | Fuerte simplicidad operativa y arquitectura gestionada escalable | Dependencia externa y economía de servicios gestionados |
| Weaviate | Base de datos vectorial de código abierto | Vectores más índices invertidos y opciones de índice flexibles | Más ajuste de clúster que un camino solo alojado |
| pgvector | Extensión de Postgres | Mantener vectores con datos relacionales y stack SQL existente | No es el mejor ajuste para cada carga de trabajo ANN de alta escala |
| Milvus | Base de datos vectorial distribuida | Escala diseñada a propósito y ecosistema alrededor de Zilliz Cloud gestionado | Otro almacén de datos especializado para operar |
Notas de la tabla: Pinecone documenta un plano de control gestionado y planos de datos regionales. Weaviate documenta índices vectoriales e invertidos con múltiples tipos de índice vectorial. pgvector añade búsqueda exacta y de vecinos más cercanos 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.
| Opción LLM | Estilo de interfaz | Mejor en | Precaución |
|---|---|---|---|
| OpenAI Responses | Respuestas con estado más herramientas integradas | Inicio rápido, herramientas alojadas, ciclos estructurados | Heredas abstracciones específicas de la plataforma |
| Anthropic Messages | Acceso directo al modelo con contrato de uso de herramientas explícito | Límites de herramientas claros y buen control en bucles personalizados | Más entorno de ejecución es tu responsabilidad a menos que uses Agentes Gestionados |
| vLLM | Autoalojado compatible con OpenAI y Anthropic | Inferencia autoalojada de alto rendimiento | Trabajo real de infraestructura y servicio de modelos |
| Ollama | Entorno de ejecución de modelo y embedding local simple | Desarrollo local y pilas autoalojadas pequeñas | No es la misma clase de sistema de servicio que un entorno de ejecución distribuido ajustado |
| llama.cpp | Servidor local ligero con rutas compatibles con proveedores | Borde, primero en CPU, entornos limitados | Haces más ajuste manual y coincidencia de capacidades |
Notas de la tabla: OpenAI documenta Responses 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 embedding y modelo locales. llama.cpp documenta rutas de chat, respuestas y embeddings compatibles con OpenAI, más finalización de chat compatible con Anthropic.
| Restricción o compensación | Sesgo hacia gestionado | Sesgo hacia autoalojado | Mitigación práctica |
|---|---|---|---|
| Latencia | A menudo mejor primera iteración y menos tareas de ajuste local | Puede ganar cuando el modelo y los datos están colocalizados y mantenidos calientes | Usa niveles de enrutamiento, cachés calientes y modelos auxiliares más pequeños |
| Costo | Fácil de empezar, variable a escala de tokens | Mejor amortización en utilización constante | Mide el tráfico real antes de optimizar por instinto |
| Privacidad y residencia | Más simple para datos no sensibles | Mayor control para flujos sensibles y regulados | Usa límites híbridos y mantén solo lo que debe moverse |
| Consistencia | Las herramientas alojadas aún tienen semánticas de visibilidad escalonada | Las tuberías de memoria autoalojadas también escalonan y promueven datos | Define reglas de lectura-después-de-escritura explícitamente por capa |
| Escalabilidad | Menos dolor en el plano de control | Mejor ajuste para cargas de trabajo estables y especializadas | Usa procesamiento por lotes, colas e inquilinos aislados |
| Depurabilidad | Fácil perderse en los internals opacos del proveedor | Fácil ahogarse en complejidad autohecha | Traza cada solicitud y evalúa cada ruta |
Esta matriz de compensaciones es una inferencia arquitectónica de los documentos oficiales, no un benchmark de proveedores. La fila de consistencia importa más de lo que admiten muchos blogs: Pinecone separa las rutas de escritura y lectura, Hermes congela la memoria en prompts de inicio de sesión, y OpenClaw promueve memoria duradera 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 adecuado, permite que las herramientas se desvíen o hace que la depuración sea imposible.
| Dónde se rompe | Síntoma típico | Causa habitual | Mitigación |
|---|---|---|---|
| Ensamble de prompt | Respuesta segura pero fuera de objetivo | Demasiado contexto irrelevante, ordenamiento pobre | Presupuesta contexto, reclasifica, mantiene hechos clave cerca del inicio |
| Recuperación | Tono correcto, hechos incorrectos | Fragmentación mala, índice desactualizado, filtros débiles | Evalúa la recuperación por separado, añade filtros de metadatos y búsqueda híbrida |
| Límite de herramienta | Acción incorrecta o duplicada | Esquemas laxos, reintentos sin idempotencia | Esquemas ajustados, claves de idempotencia, puertas de aprobación |
| Enrutamiento | Comportamiento salvamente inconsistente por solicitud | Enrutamiento de costo o latencia sin controles de calidad | Añade sesiones pegajosas y evaluaciones por ruta |
| Memoria | Recuperación desactualizada o envenenada | Escrituras demasiado entusiastas, revisión débil, filtrado entre sesiones | Separa memoria de trabajo y duradera, revisa promociones |
| Observabilidad | No idea de qué sucedió | Trazos faltantes o sin granularidad de span | Emite trazos raíz y subtrazos para recuperación, modelo y llamadas a herramientas |
| Control de alucinación | Afirmaciones plausibles pero sin soporte | Fundamentación débil o sin paso de validación | Validación de documentos de referencia, comprobaciones de autoconsistencia, puertas de evaluación |
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. OpenAI Guardrails incluye detección de alucinaciones contra una base de conocimiento de referencia a través de Búsqueda de Archivos. SelfCheckGPT muestra que la autoconsistencia entre muestras puede ayudar a detectar afirmaciones sin soporte. Los resultados de “Lost in the Middle” y las guías 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 de forma independiente, mantiene herramientas idempotentes y ejecuta evaluaciones de regresión antes de cambiar rutas o política de memoria. Los documentos y repositorio de Evaluaciones 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 a enrutadores y recuperación como a prompts.
Más lectura
Si quieres profundizar, estas son las fuentes primarias más útiles para mantener abiertas mientras diseñas o revisas una arquitectura de asistente.
-
OpenAI: Resumen de Respuestas, Llamadas a Funciones, Uso de Herramientas, Recuperación, Búsqueda de Archivos, Evaluaciones y MCP para servidores de herramientas remotos.
-
Anthropic: Resumen de API, Uso de Herramientas, el contrato de uso de herramientas, Agentes Gestionados, Ventanas de Contexto y el conector MCP.
-
MCP en sí: el Resumen de Arquitectura y la Especificación valen la pena leerse directamente, porque explican hosts, clientes, servidores, herramientas, prompts, recursos, transportes y negociación de capacidades de manera limpia. Para una comparación práctica de MCP con el protocolo Agent2Agent y cuándo un sistema multi-agente necesita ambas capas, consulta A2A vs MCP: ¿Realmente los Agentes de IA Necesitan Ambos Protocolos? y para los conceptos mismos de A2A — Tarjetas de Agente, ciclo de vida de tareas, mensajes, partes y artefactos — consulta ¿Qué es el Protocolo A2A? Tarjetas de Agente y Tareas Explicadas.
-
Asistentes de fondo y proactivos: la capa de herramientas es solo una parte de cómo actúan los asistentes. Para cómo hacer que un asistente observe, decida y actúe por sí mismo — programadores, trabajadores basados en colas, protocolos de reclamación, flujos de trabajo duraderos y sondeo semántico — consulta Agentes de Sondeo en Asistentes de IA: 11 Patrones de Implementación.
-
Protocolo A2A y adopción: una vez que los agentes se despliegan de forma independiente y necesitan colaborar a través de límites de propiedad, A2A se vuelve relevante. Para una visión práctica de 2026 de dónde A2A realmente tiene tracción, las preguntas de seguridad que plantea y un marco de decisión para cuándo adoptarlo, consulta Protocolo A2A de Google en 2026: Adopción, Hype y Realidad. Cuando esos agentes intercambian tareas de larga duración en lugar de turnos de chat únicos, Transmisión A2A y Tareas Asíncronas para Flujos de Trabajo de Agentes de Larga Duración cubre SSE, push y diseño de input_required en el límite del protocolo.
-
Marcos de trabajo y enrutamiento: Resumen de LangChain, documentos de aumento de contexto de LlamaIndex, documentos de enrutamiento de LiteLLM, documentos de observabilidad de LangSmith.
-
Entornos de ejecución autoalojados y sistemas de asistente: vLLM, servidor llama.cpp, embeddings de Ollama, documentos y repositorio de OpenClaw, documentos y repositorio de Hermes.
-
Almacenamiento y observabilidad: Pinecone, Weaviate, pgvector, Milvus, OpenTelemetry, OpenLIT.
-
Artículos de investigación: Generación Aumentada con Recuperación para Tareas de NLP Intensivas en Conocimiento, Lost in the Middle y SelfCheckGPT.
