Agentes de IA multipaso en modelos locales: arquitectura y patrones

Los agentes de IA de un solo paso son un problema resuelto. El usuario dice algo, el modelo elige una herramienta, la herramienta devuelve un resultado. Un modelo 7B ajustado maneja esto de manera confiable — lo hemos cubierto en profundidad en nuestra guía de fine-tuning para llamadas a herramientas.

Los agentes multipaso son diferentes. El modelo necesita planificar una secuencia de acciones, rastrear el estado entre pasos, manejar errores a mitad de cadena y decidir cuándo la tarea está completa. Aquí es donde los modelos pequeños históricamente se desmoronan: pierden contexto, repiten pasos, alucinan llamadas a herramientas o entran en bucles infinitos.

Pero "históricamente" está haciendo mucho trabajo en esa oración. Con los patrones de arquitectura correctos, los agentes multipaso se ejecutan de manera confiable en modelos locales 7B-14B hoy. Esta guía cubre tres patrones probados, benchmarks reales y los detalles de ingeniería que los hacen funcionar.

El desafío central: por qué lo multipaso es difícil para modelos pequeños

Un agente de un solo paso necesita una habilidad: mapear la intención del usuario a una llamada a herramienta. Un agente multipaso necesita al menos cuatro:

1. Planificación — descomponer un objetivo en pasos ordenados
2. Ejecución — llamar a la herramienta correcta en cada paso con los parámetros correctos
3. Seguimiento de estado — llevar resultados del paso N al paso N+1
4. Recuperación de errores — detectar fallos y decidir entre reintentar, omitir o escalar

Los modelos 7B de propósito general tienen dificultades porque fueron entrenados en tareas amplias, no en cadenas de razonamiento secuencial. La ventana de atención se llena de ruido después de 2-3 pasos. El modelo "olvida" lo que ya hizo o lo que planeaba hacer.

La solución no es un modelo más grande. La solución es una mejor arquitectura.

Patrón 1: cadena de especialistas ajustados

En lugar de un modelo haciendo todo, divide el agente en roles especializados:

Solicitud del usuario → Router → Planificador → Ejecutor → Validador → Respuesta

Cada modelo es pequeño pero hiperfocalizado:

• Router (clasificación): Determina el tipo de solicitud. ¿Es un pedido? ¿Una consulta de soporte? ¿Una búsqueda de datos? Esta es una tarea de clasificación simple — incluso un modelo 1B la maneja.
• Planificador (descomposición): Toma una solicitud clasificada y produce una lista de pasos ordenada. Ajustado con tus flujos de trabajo específicos, no necesita planificar tareas arbitrarias — solo TUS tareas.
• Ejecutor (llamada a herramientas): Toma un paso a la vez y produce la llamada a herramienta. Esto es llamada a herramienta de un solo paso — el problema resuelto.
• Validador (verificación): Revisa los resultados acumulados. ¿Están presentes todos los campos requeridos? ¿La salida coincide con el esquema esperado? Marca problemas para reintento o escalamiento.

Por qué esto funciona en modelos pequeños

Cada especialista está ajustado en una tarea estrecha. El router ve miles de ejemplos de "este tipo de entrada se mapea a esta categoría." El planificador ve miles de ejemplos de "esta categoría se descompone en estos pasos." Ningún modelo individual necesita mantener la cadena de razonamiento completa.

La compensación

Latencia. Cuatro llamadas a modelo en secuencia significa 4x el tiempo de inferencia de una sola llamada. En una GPU local, cada inferencia de modelo 7B toma 200-500ms (dependiendo de la longitud del contexto y la cuantización). Una cadena de 4 pasos es 0.8-2.0 segundos en total.

Para la mayoría de los flujos de trabajo empresariales, esto está bien. Para chat en tiempo real, es perceptible. La mitigación: ejecutar especialistas en paralelo donde el grafo de dependencias lo permita.

Benchmark: cadena de especialistas vs modelo único

El modelo único ajustado mejora sobre el genérico, pero la arquitectura de cadena es un cambio de nivel. Cada especialista hace una cosa bien.

Patrón 2: modelo único con scratchpad (fine-tuning CoT)

No todo equipo quiere mantener cuatro modelos separados. El Patrón 2 usa un solo modelo, pero lo ajusta para pensar paso a paso antes de actuar.

La clave: entrenas al modelo para producir un "scratchpad" — una traza de razonamiento explícita — antes de generar la llamada a herramienta. Esto es fine-tuning de cadena de pensamiento (CoT), pero específicamente para TUS tareas de planificación.

Formato de datos de entrenamiento

{
  "input": "Process order #4521 for customer acme-corp",
  "output": "<scratchpad>\nStep 1: Validate order #4521 exists and is in pending status\nStep 2: Check inventory for all line items\nStep 3: Calculate shipping based on customer location\nStep 4: Confirm order and send notification\nCurrent step: 1\n</scratchpad>\n<tool_call>{\"function\": \"validate_order\", \"params\": {\"order_id\": 4521}}</tool_call>"
}

Después de cada resultado de herramienta, el modelo recibe el contexto actualizado y produce su siguiente scratchpad:

{
  "input": "[Previous context + tool result: order valid, status: pending]\nContinue processing.",
  "output": "<scratchpad>\nStep 1: Validate order — DONE (valid, pending)\nStep 2: Check inventory for all line items\nCurrent step: 2\n</scratchpad>\n<tool_call>{\"function\": \"check_inventory\", \"params\": {\"order_id\": 4521}}</tool_call>"
}

Por qué esto funciona

El scratchpad externaliza la "memoria de trabajo" del modelo. En lugar de rastrear implícitamente qué hizo y qué viene después (lo cual los modelos pequeños pierden de vista), el plan está literalmente en la salida. El modelo lee su propio razonamiento previo en cada paso.

Ajustar con 500-1,000 ejemplos de tus flujos de trabajo específicos enseña al modelo TUS patrones de pasos. No necesita planificar tareas arbitrarias — solo los 5-15 tipos de flujo de trabajo que tu agente maneja.

Cuándo usar el Patrón 2 sobre el Patrón 1

• Tienes menos de 5 tipos de flujo de trabajo distintos
• La latencia importa (una llamada a modelo vs cuatro)
• Quieres un despliegue más simple (un modelo para servir, no cuatro)
• Tus pasos son mayormente secuenciales (oportunidad limitada de paralelismo)

Benchmark: scratchpad vs fine-tuning convencional

El modelo CoT usa ~2.7x más tokens por paso (debido al scratchpad), pero el salto de precisión lo vale. Si estás ejecutando localmente, los tokens son gratis.

Patrón 3: híbrido — modelo local + respaldo frontera

A veces la respuesta honesta es: tu modelo local maneja el 85% de las solicitudes, pero el 15% restante genuinamente necesita más capacidad. El Patrón 3 hace esto explícito.

Solicitud del usuario → Router local (clasificar complejidad)
  ├── Simple/Conocido → Agente local (Patrón 1 o 2)
  └── Complejo/Ambiguo → API frontera (GPT-4, Claude) solo para planificación
       └── Plan → Ejecutor local (ejecuta las herramientas localmente)

Cómo funciona

El router local clasifica cada solicitud en dos ejes:

1. Complejidad: ¿Cuántos pasos? ¿Los pasos son de plantillas conocidas o novedosos?
2. Ambigüedad: ¿La intención del usuario es clara? ¿Hay múltiples interpretaciones válidas?

Las solicitudes de plantilla conocida con intención clara van completamente local. Las solicitudes novedosas o ambiguas envían SOLO el paso de planificación a una API frontera. El modelo frontera produce un plan de pasos. El modelo local ejecuta cada paso (llamada a herramientas).

Matemáticas de costo

Supongamos 1,000 solicitudes de agente por día:

• API frontera completa: 1,000 x $0.03 promedio = $30/día = $900/mes
• Completamente local: 1,000 x $0.00 por consulta = $0/día (solo costos de hardware)
• Híbrido (división 85/15): 150 x $0.01 (solo planificación, prompt más corto) = $1.50/día = $45/mes

El enfoque híbrido cuesta 95% menos que la API completa y maneja casos extremos que el modelo local resolvería mal.

Topes de costo y barreras de seguridad

Establece un presupuesto mensual fijo para el respaldo frontera. Cuando lo alcances, todas las solicitudes se enrutan al modelo local con una bandera de confianza. La aplicación puede decidir: servir el resultado local con un descargo, o encolar la solicitud para procesamiento posterior.

Gestión de estado entre pasos

Sin importar qué patrón uses, los agentes multipaso necesitan gestión de estado. Esto es lo que funciona:

Objeto de contexto de conversación

{
  "session_id": "abc-123",
  "original_request": "Process order #4521 for acme-corp",
  "current_step": 2,
  "total_steps": 4,
  "completed_steps": [
    {"step": 1, "tool": "validate_order", "result": {"valid": true, "status": "pending"}, "latency_ms": 340}
  ],
  "pending_steps": ["check_inventory", "calculate_shipping", "confirm_order"],
  "error_count": 0,
  "max_errors": 3
}

Pasa este objeto (o una versión condensada) como contexto a cada llamada al modelo. El modelo no necesita recordar — el estado es explícito.

Presupuesto de ventana de contexto

Un modelo 7B con una ventana de contexto de 4,096 tokens se llena rápido cuando incluyes esquemas de herramientas + resultados anteriores + scratchpad. Presupuéstalo:

• Prompt del sistema + esquemas de herramientas: ~800 tokens (fijo)
• Contexto del paso actual: ~200 tokens
• Resultados de pasos anteriores (condensados): ~150 tokens por paso
• Salida del scratchpad: ~120 tokens

Para una tarea de 5 pasos: 800 + 200 + (4 x 150) + 120 = 1,720 tokens. Cómodo dentro de 4K. Para cadenas más largas, resume los resultados de pasos anteriores en lugar de incluir la salida cruda.

Manejo de errores: cuando el paso 3 falla

Los agentes multipaso fallarán a mitad de cadena. La pregunta es qué pasa después.

Lógica de reintento

El paso falla → Verificar tipo de error
  ├── Transitorio (timeout, límite de tasa) → Reintentar mismo paso (máximo 2 reintentos)
  ├── Error de entrada (parámetros incorrectos) → Regenerar llamada a herramienta con contexto de error
  └── Error lógico (estado imposible) → Escalar

Para la ruta de "regenerar", agrega el mensaje de error al contexto del modelo:

Previous tool call failed: "inventory_check returned 404: order_id 4521 not found in warehouse_east"
Adjust your approach and try again.

Los modelos ajustados manejan esto bien cuando tus datos de entrenamiento incluyen ejemplos de recuperación de errores. Incluye 10-15% de escenarios de error en tu conjunto de entrenamiento.

Escalamiento

Cuando el reintento falla o el error es un error lógico, escala:

1. Al modelo frontera: Re-ejecuta el paso fallido a través de GPT-4/Claude con contexto completo
2. A un humano: Marca la solicitud en una cola de revisión con el historial completo de pasos
3. Degradación elegante: Completa los pasos que tuvieron éxito, devuelve un resultado parcial con una explicación clara de lo que falló

Barreras de seguridad: prevenir bucles infinitos y costos desbocados

Máximo de pasos

Límite duro. Si tu flujo de trabajo más largo conocido tiene 6 pasos, establece max_steps en 8. Si el modelo llega al paso 9, mata la cadena y escala.

MAX_STEPS = 8
STEP_TIMEOUT_MS = 5000

for step in range(MAX_STEPS):
    result = execute_step(context, timeout=STEP_TIMEOUT_MS)
    if result.status == "complete":
        return result
    if result.status == "error" and context.error_count >= MAX_ERRORS:
        return escalate(context)

return escalate(context, reason="max_steps_exceeded")

Topes de costo (patrón híbrido)

Para el Patrón 3, rastrea el gasto en API frontera por hora, por día y por mes. Establece alertas al 50%, 80% y 100% del presupuesto. Al 100%, deja de enrutar a la frontera y registra cada solicitud que se habría enrutado — esto se convierte en tu dataset de fine-tuning para la próxima iteración.

Humano en el circuito

Para flujos de trabajo de alto riesgo (transacciones financieras, decisiones de salud, acciones legales), agrega un paso de confirmación antes de la acción final:

Pasos 1-3 completos → Presentar resumen al humano → El humano aprueba → El paso 4 se ejecuta

Esto funciona naturalmente tanto en interfaces asíncronas (basadas en cola) como síncronas (basadas en chat).

Cuándo lo multipaso funciona en 7B vs cuándo necesitas 14B+

La línea divisoria: si el modelo necesita DECIDIR qué hacer (planificación dinámica), usa 14B+. Si el modelo sigue un PATRÓN CONOCIDO con variaciones menores, 7B está bien con la arquitectura correcta.

Ejemplo: agente de procesamiento de pedidos de 4 pasos

Aquí hay una implementación concreta usando el Patrón 2 (scratchpad) en un Qwen 2.5 7B ajustado:

Paso 1 — Validar pedido

Input: "Process order #4521 for acme-corp"
Scratchpad: "4 steps needed: validate → inventory → shipping → confirm. Starting with validation."
Tool call: validate_order(order_id=4521, customer="acme-corp")
Result: {valid: true, items: [{sku: "W-100", qty: 50}, {sku: "W-200", qty: 25}]}

Paso 2 — Verificar inventario

Scratchpad: "Order valid. 2 line items. Checking inventory for both SKUs."
Tool call: check_inventory(skus=["W-100", "W-200"], quantities=[50, 25])
Result: {W-100: {available: 200, allocated: 50}, W-200: {available: 30, allocated: 25}}

Paso 3 — Calcular envío

Scratchpad: "All items available. Customer acme-corp is in warehouse zone east. Calculating shipping."
Tool call: calculate_shipping(order_id=4521, zone="east", weight_kg=37.5)
Result: {method: "ground", cost: 42.50, eta_days: 3}

Paso 4 — Confirmar pedido

Scratchpad: "Shipping calculated. All checks passed. Confirming order."
Tool call: confirm_order(order_id=4521, shipping_method="ground", shipping_cost=42.50)
Result: {confirmed: true, confirmation_id: "CNF-88421"}

Latencia total en una RTX 4090: 1.8 segundos para los cuatro pasos. Costo total de API: $0.00.

Este mismo flujo en GPT-4 costaría ~$0.04 por pedido. A 500 pedidos/día, eso son $20/día o $600/mes — por algo que un modelo local hace en menos de 2 segundos.

Primeros pasos

La ruta más rápida a agentes multipaso en modelos locales:

1. Mapea tus flujos de trabajo. Lista cada proceso multipaso que tu agente maneja. La mayoría de los equipos tienen 3-8 tipos distintos.
2. Elige tu patrón. ¿Menos de 5 tipos de flujo de trabajo con pasos lineales? Patrón 2. ¿Más variedad o necesitas paralelismo? Patrón 1. ¿Necesitas una red de seguridad? Patrón 3.
3. Construye datos de entrenamiento. 200-500 ejemplos por tipo de flujo de trabajo, incluyendo 10-15% de escenarios de error.
4. Ajusta con LoRA. Un modelo 7B se ajusta en menos de una hora con Ertas en una sola GPU.
5. Prueba la cadena de extremo a extremo antes de desplegar. Ejecuta tu suite completa de flujos de trabajo y mide la precisión paso a paso, no solo la precisión del resultado final.

Lectura adicional

• Fine-tuning para llamadas a herramientas: cómo construir agentes de IA confiables — la base para llamadas a herramientas de un solo paso que usa el ejecutor del Patrón 1
• Cuándo un modelo 7B supera a una llamada API — benchmarks que muestran dónde los modelos pequeños igualan el rendimiento frontera
• Fine-tuning de modelos pequeños vs GPT-4: cuándo el modelo pequeño gana — los datos detrás de que el fine-tuning específico de tarea supere a los modelos de propósito general