Construcción de agentes de IA con múltiples modelos: una guía de arquitectura práctica

La mayoría de los agentes de IA dependen de un solo modelo para manejar cada fase de ejecución. El paso de planificación, las llamadas a herramientas, la extracción de datos, el resumen y la recuperación de errores pasan por el mismo LLM. Si bien este enfoque es sencillo para prototipos iniciales, introduce ineficiencias significativas en entornos de producción.

Un paso de planificación que requiere un razonamiento profundo no necesita el mismo modelo que un paso básico de extracción de JSON. Una tarea de generación de código tiene requisitos diferentes a una tarea de clasificación. Usar un modelo de razonamiento de alto nivel como Claude Fable 5 o Claude Opus 4.8 para formatear una cadena de fecha es una asignación ineficiente y costosa de recursos.

Construir agentes de IA con múltiples modelos le permite dirigir cada paso de un flujo de trabajo al modelo más adecuado para esa tarea específica. Esta guía explora cómo diseñar, implementar y gestionar estas arquitecturas de múltiples modelos.

Si está trabajando en la capa de API en lugar de en la capa de orquestación de agentes, consulte Diseño de API orientado a agentes y Por qué los equipos cambian de APIs de modelos directos a una API de IA unificada junto con esta guía. Los agentes de múltiples modelos funcionan de manera más fiable cuando la superficie de la API subyacente es lo suficientemente estable como para cambiar de modelo sin tener que reescribir el código de orquestación.

:::info

Puntos clave

1. Adapte el modelo a la complejidad de la tarea: utilice modelos pequeños y rápidos para el enrutamiento, la extracción y el formato, reservando los modelos de razonamiento más grandes para la planificación y el análisis complejo.
2. Estandarice los esquemas: implemente una validación de salida estricta (como Pydantic) en cada traspaso para evitar la desviación del contrato al cambiar entre diferentes proveedores de modelos.
3. Diseñe para casos de respaldo (fallbacks): cree rutas de respaldo automatizadas para manejar límites de tasa, interrupciones del proveedor o picos de latencia sin interrumpir el flujo de trabajo del agente.
4. Centralice la telemetría: realice un seguimiento de la latencia, el recuento de tokens de entrada/salida y el costo por paso para optimizar continuamente su lógica de enrutamiento. :::

---

La arquitectura de agentes de múltiples modelos

Una arquitectura de agente de múltiples modelos distribuye las tareas entre modelos especializados según los requisitos de complejidad, costo y latencia.

Solicitud del usuario
    │
    ▼
┌─────────────┐
│   Router     │  ← Clasifica la complejidad de la tarea
│ (modelo rápido)│
└──────┬──────┘
       │
   ┌───┴───┐
   ▼       ▼
┌──────┐ ┌──────┐
│Modelo│ │Modelo │
│Simple│ │Complejo│
└──┬───┘ └──┬───┘
   │        │
   ▼        ▼
┌─────────────┐
│  Agregador   │  ← Combina resultados
│ (modelo rápido)│
└─────────────┘

La arquitectura central consta de cinco componentes principales:

1. El Router: Un modelo rápido y de bajo costo que clasifica las tareas entrantes por complejidad e intención.
2. El Pool de modelos: Una colección de modelos adaptados a diferentes tipos de tareas (como razonamiento, extracción o generación de código).
3. El Agregador: Un modelo rápido que combina los resultados de pasos paralelos en una respuesta final.
4. La Política de respaldo (Fallback): Reglas que dictan qué modelo usar si la elección principal falla, se agota el tiempo de espera o encuentra límites de tasa.
5. La Capa de telemetría: Un sistema de registro que registra las elecciones de modelo, la latencia y los costos exactos de tokens por paso.

Sin políticas de respaldo y telemetría, un agente de múltiples modelos puede volverse difícil de depurar, con perfiles de latencia y costo impredecibles.

---

Implementación con el SDK de OpenAI

El uso de una puerta de enlace (gateway) de API unificada le permite acceder a modelos de diferentes proveedores utilizando un único SDK y clave de API. Esto simplifica el cambio de modelos y el enrutamiento.

El siguiente ejemplo demuestra una implementación básica de enrutamiento. La disponibilidad y los precios de los modelos deben verificarse en el directorio de modelos de TokenLab.

from openai import OpenAI

client = OpenAI(
    api_key="sk-tokenlab-xxx",
    base_url="https://api.tokenlab.sh/v1"
)

# Pool de modelos con niveles de costo y capacidad
MODELS = {
    "router": "deepseek-v4-flash",        # Clasificación rápida
    "simple": "deepseek-v4-flash",        # Extracción, formato
    "reasoning": "claude-sonnet-5",       # Planificación, análisis
    "complex": "gpt-5.5",                 # Generación de código, lógica compleja
    "budget": "deepseek-v4-flash",        # Procesamiento masivo
}

def route_task(task: str) -> str:
    """Utiliza un modelo de menor costo para clasificar la complejidad de la tarea."""
    response = client.chat.completions.create(
        model=MODELS["router"],
        messages=[
            {"role": "system", "content": """Clasifica esta tarea en una sola categoría:
- simple: extracción de datos, formato, traducción
- reasoning: análisis, planificación, comparación
- complex: generación de código, resolución de problemas de varios pasos
- budget: procesamiento masivo, tareas no críticas
Responde solo con el nombre de la categoría en minúsculas."""},
            {"role": "user", "content": task}
        ],
        max_tokens=10
    )
    category = response.choices[0].message.content.strip().lower()
    return MODELS.get(category, MODELS["simple"])

def execute_task(task: str, context: str = "") -> str:
    """Dirige la tarea al modelo seleccionado y ejecútala."""
    model = route_task(task)
    messages = []
    if context:
        messages.append({"role": "system", "content": context})
    messages.append({"role": "user", "content": task})

    response = client.chat.completions.create(
        model=model,
        messages=messages
    )
    return response.choices[0].message.content

---

Agente en el mundo real: Pipeline de revisión de código

Para ver el impacto práctico de construir agentes de IA con múltiples modelos, considere un pipeline diseñado para revisar solicitudes de extracción (pull requests). Este flujo de trabajo divide la revisión en pasos especializados en lugar de enviar todo el diff de código a un solo modelo costoso.

def review_pr(diff: str) -> dict:
    """Pipeline de revisión de PR con múltiples modelos."""

    # Paso 1: Clasificar cambios usando un modelo rápido y de bajo costo
    classification = client.chat.completions.create(
        model="deepseek-v4-flash",
        messages=[{
            "role": "user",
            "content": f"Clasifica estos cambios de código: {diff[:2000]}\n"
                       "Categorías: bugfix, feature, refactor, docs, test"
        }],
        max_tokens=20
    ).choices[0].message.content

    # Paso 2: Realizar un escaneo de seguridad usando un modelo de razonamiento fuerte
    security = client.chat.completions.create(
        model="claude-sonnet-5",
        messages=[{
            "role": "system",
            "content": "Eres un revisor de seguridad. Comprueba: "
                       "inyección SQL, XSS, omisión de autenticación, secretos en el código, "
                       "deserialización insegura. Sé específico sobre los números de línea."
        }, {
            "role": "user",
            "content": f"Revisa este diff en busca de problemas de seguridad:\n{diff}"
        }]
    ).choices[0].message.content

    # Paso 3: Analizar la calidad del código usando un modelo de propósito general
    quality = client.chat.completions.create(
        model="gpt-5.5",
        messages=[{
            "role": "user",
            "content": f"Revisa la calidad del código: nombres, estructura, "
                       f"manejo de errores, cobertura de pruebas.\n{diff}"
        }]
    ).choices[0].message.content

    # Paso 4: Generar un resumen usando un modelo rápido y de bajo costo
    summary = client.chat.completions.create(
        model="deepseek-v4-flash",
        messages=[{
            "role": "user",
            "content": f"Resume esta revisión de PR en 3 puntos clave:\n"
                       f"Tipo: {classification}\n"
                       f"Seguridad: {security[:500]}\n"
                       f"Calidad: {quality[:500]}"
        }]
    ).choices[0].message.content

    return {
        "classification": classification,
        "security": security,
        "quality": quality,
        "summary": summary
    }

Optimización de costos y eficiencia

La siguiente tabla describe la asignación de modelos para este pipeline. Los precios exactos varían según el proveedor y el volumen; verifique las tarifas actuales en el directorio de modelos de TokenLab.

Paso	Modelo	Tokens de entrada	Rol / Especialización
1. Clasificar	DeepSeek V4 Flash	~2,100	Clasificación rápida, enrutamiento de bajo costo
2. Seguridad	Claude Sonnet 5	~2,500	Razonamiento profundo, análisis de seguridad
3. Calidad	GPT-5.5	~2,500	Calidad de código avanzada y revisión estructural
4. Resumen	DeepSeek V4 Flash	~1,200	Agregación de texto rápida y de bajo costo

Ejecutar los cuatro pasos a través de un modelo de razonamiento insignia como Claude Sonnet 5 o GPT-5.5 aumentaría significativamente los costos. Al dirigir tareas más simples a modelos de menor costo como DeepSeek V4 Flash, el pipeline de múltiples modelos reduce el gasto total en tokens mientras preserva el razonamiento profundo para el paso crítico de análisis de seguridad.

---

Enrutamiento por capacidad, no solo por precio

Si bien la reducción de costos es un objetivo común, las decisiones de enrutamiento también deben tener en cuenta las capacidades específicas del modelo. Una política de enrutamiento sólida evalúa los modelos en cuatro dimensiones clave:

• Profundidad de razonamiento: Lógica compleja, planificación y deducción de varios pasos.
• Ventana de contexto: El volumen de información de fondo o código requerido para la tarea.
• Fiabilidad en el uso de herramientas: La precisión de la llamada a funciones y la generación de salidas estructuradas.
• Sensibilidad a la latencia: Los requisitos de velocidad de la aplicación orientada al usuario.

Estas dimensiones ayudan a establecer reglas de enrutamiento claras:

• Las tareas de descomposición y planificación se dirigen a modelos con gran capacidad de razonamiento.
• Las tareas de extracción de datos y formato se dirigen a modelos rápidos y de bajo costo.
• La generación de código y el análisis de sintaxis se dirigen a modelos optimizados para tareas de codificación.
• Las tareas de análisis de todo el repositorio se dirigen a modelos con ventanas de contexto grandes.

Para alinear su router con estos requisitos, consulte la comparativa de modelos de codificación y la comparativa de precios para hacer coincidir los pasos de su flujo de trabajo con los benchmarks de modelos actuales.

---

Integración con LangChain

También puede implementar el enrutamiento de múltiples modelos dentro de marcos de orquestación como LangChain. El siguiente ejemplo configura diferentes modelos utilizando una URL base de API unificada:

from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate

# Inicializar modelos con configuraciones distintas
fast_model = ChatOpenAI(
    model="deepseek-v4-flash",
    api_key="sk-tokenlab-xxx",
    base_url="https://api.tokenlab.sh/v1"
)

reasoning_model = ChatOpenAI(
    model="claude-sonnet-5",
    api_key="sk-tokenlab-xxx",
    base_url="https://api.tokenlab.sh/v1"
)

# Definir cadenas especializadas
classify_chain = ChatPromptTemplate.from_template(
    "Clasifica la intención de esta solicitud: {input}"
) | fast_model

analyze_chain = ChatPromptTemplate.from_template(
    "Realiza un análisis detallado de este problema: {input}"
) | reasoning_model

---

Cuándo usar agentes de múltiples modelos

La introducción de múltiples modelos añade complejidad arquitectónica. Este enfoque suele ser más beneficioso cuando:

• Requisitos de tareas diversos: El agente maneja una combinación de tareas simples (como clasificación o formato) y tareas complejas (como planificación estratégica o generación de código).
• Alto volumen y costo: Los gastos mensuales de API son lo suficientemente altos como para que la optimización genere ahorros significativos.
• Fortalezas de modelos especializados: El flujo de trabajo se beneficia de las fortalezas específicas de los proveedores, como la ventana de contexto de Gemini, las capacidades de codificación de Claude o la velocidad de uso de herramientas de GPT.
• Necesidades de latencia asimétricas: Ciertas partes del flujo de trabajo deben devolver resultados al instante, mientras que otros pasos en segundo plano pueden tardar más.

Para agentes de un solo propósito o interfaces de chat simples, un solo modelo suele ser más fácil de mantener. Es posible que la sobrecarga operativa del enrutamiento no se justifique si cada solicitud requiere el mismo nivel de capacidad.

---

Modos de fallo comunes

Las arquitecturas de múltiples modelos introducen modos de fallo específicos que requieren mitigación:

1. Routers demasiado complejos

Si el prompt del router se vuelve demasiado complejo, el paso de clasificación en sí mismo puede volverse lento y costoso. Mantenga los prompts de enrutamiento concisos y las categorías de clasificación amplias.

2. Desviación del contrato de salida

Diferentes modelos pueden formatear las salidas de manera diferente, incluso cuando se les indica que devuelvan JSON. Un modelo podría devolver JSON sin procesar, mientras que otro lo envuelve en bloques de markdown. Para evitar fallos en el analizador posterior, aplique esquemas estrictos utilizando bibliotecas de validación como Pydantic en cada traspaso de paso.

3. Degradación silenciosa de la calidad

Si una política de respaldo dirige una solicitud a un modelo de nivel inferior durante una interrupción del proveedor principal, el agente puede devolver respuestas de menor calidad sin generar un error. Implementar una estrategia de limitación de tasa clara y un sistema de alertas ayuda a rastrear cuándo están activos los respaldos.

4. Telemetría fragmentada

Cuando el uso del modelo se divide entre múltiples APIs de proveedores directos, agregar métricas de costo y rendimiento se vuelve difícil. Centralizar las solicitudes a través de una única puerta de enlace simplifica el registro y el seguimiento de costos.

---

Un bucle de evaluación mínimo

Para mantener un agente de múltiples modelos, establezca un bucle de evaluación básico para realizar un seguimiento del rendimiento. Puede registrar las siguientes métricas para cada ejecución en una tabla de base de datos:

• Categoría de tarea: La clasificación asignada por el router.
• Modelo seleccionado: El modelo elegido para cada paso.
• Latencia del paso: El tiempo necesario para completar cada paso.
• Uso de tokens: El recuento exacto de tokens de entrada y salida.
• Estado de respaldo: Si se activó un modelo de respaldo.
• Comentarios del usuario: Un indicador binario de si la salida final fue exitosa.

Analizar estos datos ayuda a determinar si el router está seleccionando los modelos correctos, qué pasos están impulsando la mayoría de sus costos y si los modelos de respaldo están manteniendo una calidad aceptable.

---

Preguntas frecuentes

¿Cómo se manejan diferentes formatos de prompt en diferentes modelos?

Diferentes modelos responden mejor a diferentes estructuras de prompt. Por ejemplo, algunos modelos funcionan mejor con prompts del sistema, mientras que otros prefieren instrucciones integradas en el prompt del usuario. Para manejar esto, abstraiga sus prompts en plantillas que se adapten según el modelo de destino, en lugar de enviar cadenas sin procesar idénticas a cada modelo en su pool.

¿El enrutamiento añade demasiada latencia a las aplicaciones orientadas al usuario?

El enrutamiento introduce una pequeña cantidad de latencia para el paso de clasificación. Puede minimizar esto utilizando modelos de baja latencia altamente optimizados para el router, manteniendo los límites máximos de tokens bajos (menos de 10 tokens) o paralelizando pasos cuando la clasificación se puede inferir del estado de la aplicación del usuario o del punto de entrada.

¿Cómo se evitan los errores de análisis JSON al cambiar entre modelos?

Para evitar errores de análisis, utilice funciones de salida estructurada (como el modo JSON o la llamada a herramientas) admitidas por los proveedores de modelos. Además, envuelva todas las salidas del modelo en una capa de validación utilizando Pydantic o bibliotecas similares para analizar, validar y reparar la carga útil antes de pasarla al siguiente paso en su pipeline.

---

Acceda a cada modelo a través de una sola API: Comience con TokenLab para acceder a más de 300 modelos con una única clave de API. Construya agentes de múltiples modelos sin gestionar múltiples cuentas de proveedores ni reescribir la lógica de enrutamiento para diferentes APIs.