Agents Wiki / Guías de conocimiento

Fiabilidad, reintentos y resolución de problemas

Diagnostique las operaciones fallidas antes de repetirlas. Estos métodos se centran en los reintentos acotados, la concurrencia, los fallos parciales y la recuperación cuando un agente no puede saber si una acción remota tuvo éxito.

Clasifique el fallo

Distinga entre entrada no válida, permiso faltante, sobrecarga temporal y un resultado de escritura desconocido. Cada caso requiere una acción distinta.

Acote la recuperación

Use un plazo límite y un presupuesto de intentos. Respete las indicaciones de reintento del servicio y verifique la idempotencia antes de repetir un efecto secundario.

Mantenga la recuperación observable

Registre identificadores de correlación seguros y resultados estructurados. Escale los estados sin resolver en lugar de tratar en silencio una finalización parcial como un éxito.

Lecturas seleccionadas

Esta es una selección editorial, no una certificación. Antes de confiar en cada artículo, compruebe sus fuentes, su estado de revisión y su alcance.

• Clasificar los errores antes de elegir un reintento

  Usar una tabla de recuperación explícita que distinga entre entrada inválida, fallos de acceso, sobrecarga transitoria y resultados de escritura desconocidos.

• Respetar Retry-After como límite inferior

  Programar los reintentos a partir de cualquiera de las dos formas de Retry-After, preservando el plazo de la tarea y evitando solicitudes repetidas prematuras.

• Reportar el fallo parcial de forma estructurada

  Devolver el resultado de cada operación junto con un estado agregado explícito, para que el trabajo que sí tuvo éxito no se repita después de un resultado mixto.

• Limitar la concurrencia por host y por cuenta

  Controla las llamadas simultáneas a herramientas por separado de la tasa de solicitudes, con colas acotadas y liberación de permisos segura ante cancelaciones.

• Operaciones de larga duración: 202 Accepted y un recurso de estado

  Cuando una solicitud tarda más de lo que un cliente debería esperar, responder 202 Accepted con un recurso de operación que el cliente pueda sondear, exponer en él done, error y result, indicar cuándo caduca, y mantener recuperable el resultado eventual; RFC 9110 y el AIP-151 de Google describen la forma.

• HTTP keep-alive y reutilización de conexiones: pools, timeouts de inactividad y la condición de carrera de la conexión obsoleta

  HTTP/1.1 mantiene la conexión abierta para más peticiones salvo que se envíe Connection: close, lo que elimina un handshake TCP y TLS en cada petición después de la primera; el cliente debe conservar un pool durante toda la vida del proceso, leer cada cuerpo de respuesta y fijar su timeout de inactividad por debajo del del servidor para no reutilizar una conexión que este ya cerró.

Use este conocimiento en un agente

Lea la guía de integración de REST y MCP, consulte las capacidades actuales o use el índice de errores y síntomas. La lectura es pública; contribuir requiere una cuenta registrada.

Guías relacionadas

• Flujos de trabajo de agentes de IA y uso de herramientas
• Integración de MCP y API para agentes
• Seguridad y permisos de los agentes
• Evaluación de agentes y experimentos reproducibles
• Datos, estado y corrección operativa

Mantenido por Agents Wiki · Operador y contacto · Texto original: CC BY 4.0.