La conmutación entre proveedores de LLM dirige una solicitud apta hacia una alternativa cuando la ruta preferida no puede atenderla. Puede reducir la dependencia de un proveedor, pero la recuperación útil también depende de la tarea, del modelo sustituto y de lo que ya ocurrió en el flujo del agente.
La pregunta de planificación es concreta: si esta llamada al modelo no termina, ¿qué puede hacer el sistema de forma segura?
Recurre solo a una alternativa aprobada; si no la hay, envía la solicitud a revisión.
Distingue reintento, cambio de ruta y recuperación
Un reintento repite una solicitud, a menudo después de una espera. La conmutación cambia la ruta que la atiende. La recuperación del flujo determina si la tarea completa puede continuar de forma segura. Cambiar de región dentro de un servicio y cambiar de proveedor son diseños diferentes; ninguno restaura automáticamente el estado del agente.
Define límites para la espera y los intentos con alternativas. Los intentos repetidos pueden añadir latencia y costo, por lo que la aplicación necesita un punto de parada y una forma de comunicar un resultado incompleto.
Elige un patrón de enrutamiento alternativo
Cuando falla el modelo preferido, hay dos formas comunes de elegir el siguiente. Un respaldo ordenado prueba modelos aprobados en un orden fijo. Un respaldo por capacidades prueba solo modelos que pueden realizar esta tarea: por sus entradas, formato de salida, herramientas y dónde pueden procesar los datos. En ambos casos, la regla para detenerse importa tanto como la lista de alternativas. Cada intento adicional suma tiempo y puede sumar costo, y un modelo que no puede hacer el trabajo no es una recuperación.
Así se desarrolla una tarea. Un agente redacta un seguimiento de inspección cuando su modelo preferido deja de responder antes de producir algo útil. Reintenta una vez y la llamada vuelve a fallar, así que cambia a la alternativa aprobada que ya superó las mismas pruebas. El borrador llega completo. Antes de ofrecer enviarlo, el agente revisa el registro de entrega. Un intento anterior quizá ya se envió y el nuevo modelo no puede saberlo.
El siguiente paso del agente depende de lo que pueda ver:
Desplázate horizontalmente para ver todas las columnas.
| Lo que ve el agente | Qué hace | Lo que necesita para decidir |
|---|---|---|
| Un error breve antes de una salida útil | Lo intenta de nuevo dentro de un número fijo de intentos y un límite de tiempo. | Qué falló, cuánto tiempo ha pasado y cuántos intentos quedan. |
| El modelo preferido no está disponible | Cambia a una alternativa aprobada si las reglas lo permiten. | Si la alternativa está aprobada para esta tarea y estos datos. |
| No hay un modelo adecuado o no quedan intentos | Se detiene y muestra la tarea como incompleta. | A quién avisar y qué debe hacer esa persona después. |
| Solo llegó una parte del borrador | Marca el borrador como parcial y pregunta si debe empezar uno nuevo. | Qué llegó y qué ya vio la persona usuaria. |
| Una acción, como enviar un mensaje, quizá ya ocurrió | Revisa el sistema conectado antes de repetir nada. | La confirmación de ese sistema, no una suposición del modelo. |
Evalúa un servicio de conmutación por la tarea completa
Pregunta a cualquier proveedor qué errores provocan otro intento, cómo se eligen las alternativas aprobadas, cuándo se detienen los intentos y qué pueden ver tus operadores después. Pregunta si el servicio solo cambia solicitudes de modelo o también lleva el estado de la tarea. Prueba solicitudes normales y fallos con cada alternativa aprobada antes de depender de ella.
Una llamada correcta al modelo no puede decirte si un correo anterior se envió o si una actualización pasó. Recuperar el flujo exige esa comprobación por separado. Compara la calidad de cada alternativa y su costo por tarea completada, no solo su disponibilidad.
Comprueba la alternativa antes de necesitarla
El destino alternativo debe estar aprobado para el trabajo que reciba. Revisa estas cuestiones con la persona responsable del sistema:
Desplázate horizontalmente para ver todas las columnas.
| Comprobación | Por qué importa |
|---|---|
| Compatibilidad de entrada | El sustituto debe aceptar el contexto y los tipos de entrada necesarios. |
| Salida y herramientas | Valida los campos obligatorios y los argumentos de herramientas sin asumir comportamientos idénticos. |
| Calidad | Ejecuta los casos de evaluación de la tarea con cada opción aprobada. |
| Destino de los datos | Confirma dónde se pueden procesar las solicitudes antes de ampliar las rutas. |
| Costo y capacidad | Cada alternativa tiene precios y límites propios. |
| Visibilidad operativa | Registra las rutas intentadas y si la aplicación recibió un resultado utilizable. |
Un modelo capaz de responder preguntas generales puede no ser adecuado para extraer datos de documentos. Vincula la aptitud de cada alternativa a la tarea.
Ejemplo: recuperar un borrador sin repetir una acción
Una empresa ficticia de servicios utiliza un agente para redactar un mensaje posterior a una inspección. El registro de inspección permanece en modo de solo lectura durante la redacción. Si el modelo preferido no está disponible antes de producir un borrador utilizable, el equipo permite que una alternativa evaluada intente ese paso.
Enviar el mensaje es una acción separada que requiere aprobación. Si se produce un fallo posterior a un intento de envío, la aplicación consulta el registro de entrega antes de ofrecer otro intento. Cambiar de modelo no demuestra que el envío anterior haya fallado.
Ante una respuesta interrumpida, la interfaz debe distinguir un borrador parcial de un resultado final. No añadas la salida de otro modelo al texto parcial como si fuera una única respuesta coherente, salvo que ese comportamiento se haya diseñado y verificado.
Prueba los fallos junto con las solicitudes habituales
En un piloto controlado, comprueba:
- Ruta preferida no disponible antes de comenzar la respuesta.
- Alternativa incapaz de cumplir el formato de salida.
- Ninguna alternativa aprobada disponible.
- Respuesta interrumpida tras mostrar texto parcial.
- Acción de herramienta cuyo resultado no se conoce con certeza.
En cada caso, especifica el estado visible, la evidencia para operaciones y el siguiente paso permitido. «Sin completar; requiere revisión» puede ser el resultado correcto. Mide la finalización de tareas por separado del éxito de las llamadas al modelo y consulta la observabilidad de agentes para definir la evidencia necesaria.
En AgentShelf
La arquitectura publicada de AgentShelf describe conmutación automática entre siete o más proveedores. La página de infraestructura explica el acceso a modelos configurados; la disponibilidad depende de la configuración, las credenciales, la región, el plan y el catálogo. Los límites de reintento, lo que sucede con una respuesta interrumpida, si alguna vez se repite una acción de herramienta y cualquier compromiso de disponibilidad dependen de tu configuración. Prueba la recuperación de tu propio flujo antes de depender de ella.
Para conocer el contexto, consulta qué incluye la infraestructura para LLM y qué hace una pasarela.