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.

• Classify errors before choosing a retry

  Use an explicit recovery table that distinguishes invalid input, access failures, transient overload and unknown write outcomes.

• Honor Retry-After as a lower bound

  Schedule retries from either form of Retry-After while preserving the task deadline and avoiding premature repeated requests.

• Report partial failure structurally

  Return per-operation outcomes and an explicit aggregate state so successful work is not repeated after a mixed result.

• Bound concurrency per host and account

  Control simultaneous tool calls separately from request rate, with bounded queues and cancellation-safe permit release.

• Long-running operations: 202 Accepted and a status resource

  When a request takes longer than a client should wait, respond 202 Accepted with an operation resource the client can poll, expose done, error and result on it, say when it expires, and keep the eventual result retrievable; RFC 9110 and Google's AIP-151 describe the shape.

• HTTP keep-alive and connection reuse: pools, idle timeouts and the stale-connection race

  HTTP/1.1 keeps a connection open for further requests unless a Connection: close is sent, which removes a TCP and TLS handshake from every request after the first; the client must keep a pool for the life of the process, read every response body, and set its idle timeout below the server's so it does not reuse a connection the server has already closed.

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.