Arquitectura de Agentes de IA: Enrutamiento de Modelos y Descubrimiento de Herramientas

Conectar un LLM es suficiente para hacer que una aplicación genere texto. No es suficiente para hacer que un agente de IA complete una tarea del mundo real.

Pide a un modelo que resuma un documento ya en su contexto, y la capa del modelo es suficiente. Pídele que compare los precios de los competidores de hoy, enriquezca un registro de empresa, verifique una cuenta social o elija la mejor API para un trabajo desconocido, y la mitad que falta se vuelve obvia: el agente necesita una forma confiable de acceder a sistemas externos.

Por lo tanto, un agente de producción toma dos decisiones separadas:

1. ¿Qué modelo debería manejar este paso?
2. ¿Qué herramienta o API debería proporcionar los datos o la acción?

AIHubMix aborda la primera decisión con acceso unificado a modelos y enrutamiento de modelos en tiempo de solicitud. Monid aborda la segunda con descubrimiento de herramientas en tiempo de ejecución, inspección de esquemas y ejecución por llamada. Los productos se sitúan en diferentes capas de la misma arquitectura.

Divulgación: Este artículo fue creado como parte de una colaboración de contenido con Monid. AIHubMix es la plataforma de modelos discutida a continuación; Monid es la plataforma de herramientas. Cada uno puede usarse de forma independiente.

Los dos problemas de enrutamiento dentro de un agente de IA

Una ejecución de agente rara vez es una llamada homogénea de modelo. Un agente de investigación puede clasificar una solicitud, buscar información actual, extraer hechos estructurados, comparar resultados y escribir una respuesta final. Esos pasos requieren diferentes capacidades.

Lo mismo ocurre fuera del modelo. Una tarea de investigación de empresa puede necesitar una API de búsqueda hoy, un endpoint de enriquecimiento de empresa mañana y una herramienta de automatización de navegador la próxima semana. Si cada modelo y herramienta está codificado de forma rígida en el momento de la construcción, cada nueva tarea se convierte en un proyecto de integración.

Las dos capas son paralelas:

Esta separación es importante. Un mejor modelo no puede crear acceso a datos en vivo, y un catálogo de herramientas más grande no puede razonar sobre los datos que devuelve. El agente necesita ambas capacidades, con un contrato claro entre ellas.

Monid presenta la vista complementaria del lado de la herramienta en Por qué un Agente de IA Necesita Dos Integraciones. Desde el lado del modelo, la lección arquitectónica es la misma: mantener la selección de modelos y la selección de herramientas independientes, luego optimizar cada capa para su propio trabajo.

Por qué un modelo fijo se vuelve costoso en un bucle de agente

Usar un modelo en todas partes parece simple. En la práctica, obliga a cada paso a aceptar el mismo compromiso entre capacidad, latencia y precio.

Considera un agente de investigación de mercado:

• La clasificación de intenciones es corta y mecánica.
• La selección de herramientas necesita un seguimiento de instrucciones confiable.
• Extraer campos de un JSON devuelto es principalmente transformación.
• El informe final puede requerir un razonamiento más fuerte y una mejor redacción.

Enviar los cuatro pasos al modelo más capaz desperdicia dinero en trabajo rutinario. Enviar los cuatro al modelo más barato puede reducir la calidad de la única salida que el usuario lee. A medida que crece un bucle de agente, ese compromiso se repite en cada llamada.

AIHubMix proporciona un endpoint compatible con OpenAI a través de un amplio catálogo de modelos. Una integración existente del SDK de OpenAI puede apuntar a AIHubMix cambiando la clave de API y base_url:

from openai import OpenAI

client = OpenAI(
    api_key="<AIHUBMIX_API_KEY>",
    base_url="https://aihubmix.com/v1",
)

response = client.chat.completions.create(
    model="auto:balanced",
    messages=[
        {"role": "user", "content": "Clasifica esta solicitud y propone el siguiente paso."}
    ],
)

Establecer model en auto mueve la selección de modelos al camino de solicitud. El enrutador analiza la tarea y la resuelve a un modelo adecuado. Un sufijo de política hace que el objetivo de optimización sea explícito:

El enrutamiento no añade una tarifa separada. La solicitud se factura al precio de lista del modelo que realmente la manejó. El modelo resuelto y los detalles de enrutamiento se exponen en la respuesta, incluyendo el encabezado X-Aihubmix-Router-Resolved-Model, por lo que la decisión permanece observable en lugar de convertirse en una caja negra.

El comportamiento completo, los endpoints soportados, las políticas y las limitaciones actuales están documentados en la guía de AIHubMix LLM Router.

El enrutamiento de modelos no proporciona datos en vivo a un agente

Después de que se configura el enrutamiento de modelos, el agente puede elegir un mejor cerebro para cada paso. Aún no puede saber qué cambió después de los datos de entrenamiento del modelo, acceder a un sistema empresarial privado o realizar una acción en otra aplicación a menos que una herramienta proporcione esa capacidad.

Este es el lugar donde muchos proyectos de agentes acumulan código frágil. Un equipo conecta una API de búsqueda, luego una API de scraping, luego una API de enriquecimiento. Cada integración introduce otra cuenta, credencial, formato de solicitud, modelo de error y relación de facturación. Las descripciones de herramientas a menudo se copian en un aviso del sistema y lentamente se vuelven obsoletas.

El modo de falla es peligroso porque puede parecer exitoso. Un modelo puede producir una llamada plausible contra un esquema desactualizado, recibir una respuesta incompleta y continuar como si la tarea hubiera tenido éxito. La inspección de esquemas en tiempo de ejecución es más segura que pedir al modelo que recuerde un contrato de API de entrenamiento o de un aviso antiguo.

Por lo tanto, la capa de herramientas debería responder tres preguntas antes de la ejecución:

1. ¿Qué herramienta puede satisfacer este objetivo?
2. ¿Qué esquema y precio aplican en este momento?
3. ¿Qué resultado devolvió realmente la llamada?

El descubrimiento de herramientas es la segunda capa de enrutamiento

Monid convierte el acceso a herramientas en un flujo de trabajo de descubrir-inspeccionar-ejecutar. En lugar de requerir que el desarrollador prediga cada API que un agente pueda necesitar, el agente puede buscar un catálogo en lenguaje natural, inspeccionar el contrato de un candidato y ejecutar el endpoint seleccionado.

El flujo básico se ve así:

# 1. Encontrar herramientas que coincidan con el objetivo
monid discover -q "encontrar precios actuales de productos desde una página web pública"

# 2. Leer el esquema y precios del endpoint seleccionado
monid inspect -p PROVIDER_SLUG -e ENDPOINT_PATH

# 3. Ejecutar solo después de que el agente haya verificado el contrato
monid run -p PROVIDER_SLUG -e ENDPOINT_PATH \
  --query '{"url":"https://example.com/product"}'

El descubrimiento y la inspección permiten al agente comparar opciones antes de gastar algo. La ejecución se factura de acuerdo con el modelo de precios del endpoint seleccionado. El desarrollador mantiene una integración mientras el agente obtiene acceso a herramientas de múltiples proveedores.

Para los tiempos de ejecución de agentes que pueden leer instrucciones de configuración, Monid también publica una habilidad legible por máquina:

Configurar https://monid.ai/SKILL.md

La documentación del flujo de trabajo de Monid explica las etapas de catálogo, inspección y ejecución con más detalle.

Cómo funcionan juntas las dos capas

La puerta de enlace del modelo y la capa de herramientas deben permanecer como componentes separados con una pequeña transferencia explícita:

1. El agente recibe un objetivo del usuario.
2. AIHubMix enruta una llamada de planificación a un modelo apropiado.
3. El plan identifica información faltante o una acción externa requerida.
4. Monid descubre herramientas candidatas y expone sus esquemas y precios.
5. El agente selecciona y ejecuta una herramienta dentro de sus permisos y presupuesto.
6. La herramienta devuelve hechos o un resultado de acción.
7. AIHubMix enruta la llamada de síntesis de acuerdo con la calidad, costo o latencia requeridos.
8. El agente devuelve una respuesta fundamentada en el resultado de la herramienta.

En Python simplificado, las llamadas del lado del modelo pueden permanecer sin cambios mientras el resultado de la herramienta se inserta como contexto:

from openai import OpenAI

client = OpenAI(
    api_key="<AIHUBMIX_API_KEY>",
    base_url="https://aihubmix.com/v1",
)

# Un modelo rápido es suficiente para un paso de planificación ligero.
plan = client.chat.completions.create(
    model="auto:latency_critical",
    messages=[
        {
            "role": "user",
            "content": "Planifica cómo comparar los precios actuales de estos productos.",
        }
    ],
)

# Tu agente usa Monid para descubrir, inspeccionar y ejecutar una herramienta apropiada.
# Reemplaza estos marcadores de posición con el resultado estructurado devuelto por esa llamada.
tool_result = {
    "source": "<source-url>",
    "data": "<structured-tool-result>",
}

report = client.chat.completions.create(
    model="auto:quality_first",
    messages=[
        {
            "role": "system",
            "content": (
                "Escribe una comparación concisa. Usa solo el resultado de la herramienta suministrada, "
                "preserva las URLs de origen y indica cuándo falta un valor."
            ),
        },
        {"role": "user", "content": str(tool_result)},
    ],
)

El detalle importante no es el número de líneas. Es que ninguna elección necesita estar permanentemente incrustada en la lógica de la aplicación. El modelo puede cambiar a medida que cambia el aviso, y la herramienta puede cambiar a medida que cambia la tarea.

Los controles de costo pertenecen a ambas capas

Los costos de modelo y herramienta utilizan diferentes unidades, por lo que deben medirse por separado.

En la capa del modelo, el modelo resuelto determina el precio por token. AIHubMix hace que esa decisión sea rastreable y permite a los desarrolladores elegir una política de enrutamiento o restringir los modelos que una clave de API puede usar. Los pasos rutinarios pueden favorecer el costo o la latencia, mientras que las salidas orientadas al usuario pueden favorecer la calidad.

En la capa de herramientas, un endpoint puede cobrar por llamada o por resultado. Monid expone los precios durante la inspección, antes de la ejecución. Un agente puede rechazar un endpoint que exceda su presupuesto, preferir una opción verificada o pedir aprobación antes de una operación inusualmente costosa.

Los controles de producción útiles incluyen:

• Una lista blanca de modelos o un límite de precio para cada clave de API.
• Un presupuesto máximo de llamadas a herramientas por tarea.
• Listas blancas de proveedores o endpoints para datos regulados.
• Registros que conectan la decisión de enrutamiento del modelo con la llamada a la herramienta y la respuesta final.
• Confirmación explícita antes de acciones irreversibles o sensibles.
• Validación de salida para que los datos de la herramienta se traten como entrada no confiable, no como instrucciones.

Esta división también facilita la depuración de costos. Si una ejecución se vuelve costosa, los registros de tokens muestran si el agente razonó demasiado, mientras que los registros de herramientas muestran si obtuvo demasiado. Las soluciones son diferentes, y la arquitectura debería preservar esa distinción.

La confiabilidad requiere contratos actualizados y decisiones visibles

La selección dinámica no debería significar un comportamiento impredecible.

Del lado del modelo, AIHubMix informa el modelo resuelto y la política de enrutamiento para cada solicitud. La consistencia de sesión puede preservar la consistencia del modelo y los beneficios de caché de aviso a través de trabajos de múltiples turnos, mientras que el comportamiento de retroceso puede alejarse de un modelo poco saludable cuando sea necesario.

Del lado de la herramienta, el agente inspecciona el esquema del endpoint actual antes de hacer una llamada pagada. Los resultados del descubrimiento incluyen la información necesaria para comparar candidatos, y el resultado de la llamada real se convierte en la única evidencia externa pasada a la finalización.

Juntas, estos controles crean una útil pista de auditoría:

objetivo del usuario
  -> decisión de enrutamiento y modelo resuelto
  -> herramientas candidatas descubiertas
  -> esquema e precio inspeccionados
  -> endpoint seleccionado y resultado
  -> decisión final del modelo y respuesta fundamentada

Esa pista es más valiosa que simplemente tener acceso a muchos modelos o muchas APIs. Explica por qué el agente tomó cada elección y qué evidencia respaldó su respuesta.

Cuándo no necesitas ambas capas

No todos los flujos de trabajo se benefician de la elección en tiempo de ejecución.

Si una aplicación envía un aviso estable a un modelo evaluado, especificar ese modelo directamente es más simple y determinista que el enrutamiento. Si un pipeline programado siempre llama a una API conocida, integrar esa API directamente puede ser más claro que agregar una capa de descubrimiento.

La arquitectura de dos capas se gana su lugar cuando la variedad es parte de la carga de trabajo:

• Los avisos difieren lo suficiente como para que el mejor modelo cambie por paso.
• Los agentes hacen múltiples llamadas de modelo y necesitan controlar el costo o la latencia acumulativa.
• Las herramientas requeridas no pueden preverse completamente en el momento de la construcción.
• Los datos externos deben ser actuales y su fuente debe ser visible.
• El equipo quiere agregar capacidades sin agregar una nueva integración de proveedor para cada una.

Utiliza la capa de modelo, la capa de herramienta o ambas de acuerdo con las decisiones que tu aplicación realmente necesita tomar.

Construye el agente en torno a decisiones, no a dependencias

Un agente de IA en producción no se define por cuántos modelos o APIs puede alcanzar. Se define por si puede elegir la capacidad correcta para el paso actual, operar dentro de un presupuesto y explicar lo que sucedió.

AIHubMix le da al agente un endpoint de modelo unificado y enrutamiento en tiempo de solicitud a través de prioridades de costo, calidad y latencia. Monid le proporciona descubrimiento de herramientas en tiempo de ejecución, esquemas actuales, precios visibles y ejecución a través de proveedores externos.

Una capa decide cómo piensa el agente. La otra decide cómo descubre y actúa. Mantener esas decisiones separadas produce un agente que es más fácil de extender, observar y controlar.

Comienza con el inicio rápido de AIHubMix, luego conecta el lado de la herramienta a través de Monid.

FAQ

¿Qué es el enrutamiento de modelos para agentes de IA?

El enrutamiento de modelos selecciona un modelo para cada solicitud basado en factores como el tipo de tarea, capacidad, costo y latencia. Con AIHubMix, establecer model en auto o una política como auto:quality_first permite la selección en tiempo de solicitud mientras se preserva una API compatible con OpenAI.

¿Por qué necesita un agente de IA herramientas si el LLM ya tiene conocimiento?

Un LLM genera respuestas a partir del contexto que recibe y lo que aprendió durante el entrenamiento. No puede saber de manera confiable los precios actuales, consultar una base de datos privada o realizar una acción externa sin una herramienta conectada. Las herramientas proporcionan datos en vivo y ejecución; el modelo planifica e interpreta el resultado.

¿Es una puerta de enlace de modelo lo mismo que un servidor MCP o plataforma de herramientas?

No. Una puerta de enlace de modelo enruta solicitudes de inferencia a modelos. Los servidores MCP y las plataformas de herramientas exponen capacidades externas a un agente. Resuelven problemas de integración complementarios y pueden usarse juntos.

¿Pueden AIHubMix y Monid usarse de forma independiente?

Sí. AIHubMix puede enrutar llamadas de modelo para aplicaciones sin requisitos de herramientas dinámicas. Monid puede proporcionar descubrimiento de herramientas a agentes que utilizan otro proveedor de modelos o puerta de enlace. Usar ambos es útil cuando un agente necesita elección en tiempo de ejecución en ambas capas.

¿Cómo puedo mantener el enrutamiento automático auditable?

Registra el modelo resuelto, la política de enrutamiento, la herramienta candidata, el precio inspeccionado, el endpoint seleccionado y el resultado devuelto para cada tarea. AIHubMix expone detalles de enrutamiento de modelos en la respuesta, mientras que Monid separa el descubrimiento y la inspección de la ejecución para que la decisión de la herramienta pueda registrarse antes de la llamada pagada.