Saltar al contenido principal

Confiabilidad

Las ejecuciones de agentes dependen de sistemas que ocasionalmente fallan: el gateway de LLM aplica límites de tasa, una fuente de conocimiento es brevemente inaccesible, un endpoint de ITSM devuelve un 503. El Runtime absorbe estos fallos automáticamente para que un problema momentáneo no interrumpa la conversación del usuario. Esta página explica qué se reintenta, qué deliberadamente no se reintenta y cómo ajustar el comportamiento.

No se requiere ninguna configuración — cada ajuste descrito aquí se entrega con un valor predeterminado funcional.

Qué Se Reintenta​

El Runtime reintenta una operación fallida solo cuando un reintento puede plausiblemente ayudar y repetir la operación es seguro. Estas son dos preguntas separadas, y la respuesta a la segunda es lo que evita que los reintentos causen daños.

Los fallos se clasifican en tres grupos:

GrupoEjemplosSignificado
Nunca llegóConexión rechazada, fallo de DNS, tiempo de espera del pool de conexiones, 429 Too Many Requests, 503 Service UnavailableLa solicitud comprobadamente nunca llegó al sistema destino, o fue rechazada antes de ejecutarse
Puede haber ejecutadoTiempo de espera de lectura, conexión interrumpida durante la solicitud, 500, 502, 504La solicitud llegó al sistema destino; si se completó es desconocido
No mejorará400, 401, 403, 404, rechazos de política de contenido, argumentos de herramienta inválidosReintentar produce el mismo resultado

Las llamadas a LLM reintentan los primeros dos grupos. Generar una respuesta no tiene efectos secundarios, por lo que repetirla solo consume tokens y nada más.

Las llamadas a herramientas reintentan solo el primer grupo de forma predeterminada. Esta es la distinción importante. Si una herramienta de "crear incidente" agota el tiempo de espera al leer la respuesta, el incidente puede que ya exista — repetirla crearía un duplicado. El Runtime declina ese reintento e informa el fallo en su lugar.

Las herramientas de conocimiento y fuentes de datos reintentan ambos grupos. Solo leen datos, por lo que repetir una consulta no puede duplicar nada.

Los autores de habilidades pueden configurar una herramienta para que adopte el comportamiento más amplio marcándola como idempotente, lo cual es apropiado para cualquier herramienta que solo lea datos o cuya ejecución repetida sea inofensiva.

Qué Nunca Se Reintenta​

Tres casos están excluidos por diseño:

  • Una respuesta que ya comenzó a transmitirse. Una vez que el agente ha comenzado a escribir su respuesta en pantalla, reiniciar la llamada imprimiría el mismo texto dos veces. Si la conexión se interrumpe a mitad de la respuesta, el error se muestra en lugar de ocultarse detrás de una salida duplicada.
  • Rechazos de política de contenido y seguridad. Estos son deterministas — el mismo prompt es rechazado siempre — por lo que reintentar solo consume cuota.
  • Una solicitud cancelada. Si el usuario cierra la conversación o navega a otra parte, la ejecución se detiene inmediatamente.

Temporización de Reintentos​

Los reintentos esperan un intervalo corto y aleatorizado que crece con cada intento, comenzando en aproximadamente medio segundo y con un límite máximo de ocho. La aleatorización importa cuando una dependencia compartida se recupera: sin ella, cada ejecución de agente que falló en el mismo momento reintentaría en el mismo momento y saturaria inmediatamente el servicio en recuperación.

Cuando un proveedor devuelve un encabezado Retry-After, el Runtime lo respeta en lugar de su propio cálculo.

Los reintentos son transparentes para el usuario. Una conversación que tiene éxito en su segundo intento parece una respuesta ligeramente más lenta, sin que se muestre ningún error.

Cuando Se Agotan los Reintentos​

Si todos los intentos fallan, se le informa al agente qué salió mal en lugar de abandonar la ejecución. El modelo recibe el error como resultado de herramienta y puede responder a él — intentando una herramienta diferente, haciendo una pregunta aclaratoria o explicando a qué no pudo acceder. Esta es con frecuencia la diferencia entre una respuesta parcial y ninguna respuesta.

Presupuesto de Tiempo de Ejecución​

Cada agente tiene un tiempo máximo de ejecución (max_execution_time_seconds, predeterminado 300 segundos) que limita una ejecución completa de principio a fin, incluido el tiempo empleado en reintentos.

Cuando una ejecución supera su presupuesto, se detiene y el usuario ve:

Esta solicitud tardó demasiado y fue detenida. La conversación está guardada — inténtelo de nuevo, o divida la solicitud en pasos más pequeños.

El historial de la conversación se guarda continuamente, por lo que nada anterior al tiempo de espera se pierde. El usuario puede continuar en el mismo hilo.

Nota: Este presupuesto se aplica a partir de la versión que introdujo esta página en adelante. Los agentes que legítimamente necesitan más tiempo — agentes de investigación profunda, u orquestaciones multi-agente que llaman a muchas herramientas en secuencia — deben tener su max_execution_time_seconds aumentado para ajustarse a su carga de trabajo real.

Dos límites más específicos se encuentran dentro del presupuesto de ejecución:

  • Tiempo de espera de solicitud a LLM — 120 segundos para una sola llamada al modelo. Reemplaza un valor predeterminado anterior del proveedor de 600 segundos, bajo el cual un gateway bloqueado podía mantener una conversación abierta durante diez minutos antes de informar algo.
  • Tiempo de espera de llamada a herramienta — 180 segundos para una sola herramienta. Las habilidades individuales pueden especificar su propio límite más corto.

Referencia de Configuración​

Estos se establecen por entorno por el administrador de la plataforma. Los valores predeterminados son adecuados para el funcionamiento normal; cámbielos solo en respuesta a un problema observado.

AjustePredeterminadoPropósito
LLM_RETRY_ATTEMPTS3Total de intentos para una llamada al modelo, incluido el primero
LLM_RETRY_INITIAL_BACKOFF0.5Espera inicial, en segundos, antes del primer reintento
LLM_RETRY_MAX_BACKOFF8Espera máxima entre intentos, en segundos
LLM_REQUEST_TIMEOUT_SECONDS120Límite de tiempo para una sola llamada al modelo
LLM_CONNECT_TIMEOUT_SECONDS10Límite de tiempo para establecer la conexión
TOOL_RETRY_ATTEMPTS3Total de intentos para una llamada a herramienta, incluido el primero
TOOL_RETRY_INITIAL_BACKOFF0.5Espera inicial, en segundos, antes del primer reintento
TOOL_RETRY_MAX_BACKOFF8Espera máxima entre intentos, en segundos
TOOL_CALL_TIMEOUT_SECONDS180Límite de tiempo para una sola llamada a herramienta
ENFORCE_AGENT_EXECUTION_TIMEOUTtrueSi se aplica max_execution_time_seconds

Establecer cualquiera de los *_RETRY_ATTEMPTS en 1 deshabilita los reintentos para esa capa mientras mantiene su tiempo de espera activo.

Mejores Prácticas​

  • Aumente max_execution_time_seconds para agentes que realmente requieren ejecuciones largas — En lugar de deshabilitar el presupuesto globalmente. Un límite por agente sigue protegiendo a todos los demás agentes del tenant.
  • Marque las habilidades de solo lectura como idempotentes — Una habilidad que solo consulta o reporta obtiene el comportamiento de reintento más amplio y se vuelve notablemente más resiliente ante endpoints inestables.
  • Establezca un tiempo de espera más corto para habilidades rápidas — Una habilidad que normalmente responde en dos segundos no debería poder bloquearse durante 180. Un límite más ajustado por habilidad detecta problemas antes.
  • Trate los tiempos de espera repetidos como una señal, no como un ajuste a aumentar — Los tiempos de espera consistentes generalmente indican una dependencia no saludable o un agente que asume demasiado en un solo turno, y aumentar el límite oculta eso.
  • Verifique si una herramienta con fallos es realmente inaccesible — Dado que las escrituras no se repiten en fallos ambiguos, una herramienta que reporta un error puede haber completado su acción. Confirme antes de pedirle al agente que lo intente de nuevo.

Páginas Relacionadas​