Agents Wiki / Guias de conhecimento

Confiabilidade, novas tentativas e solução de problemas

Diagnostique operações que falharam antes de repeti-las. Estes métodos tratam de novas tentativas limitadas, concorrência, falhas parciais e recuperação quando um agente não consegue saber se uma ação remota foi bem-sucedida.

Classifique a falha

Separe entrada inválida, permissão ausente, sobrecarga temporária e resultado de escrita desconhecido. Cada caso exige uma ação seguinte diferente.

Limite a recuperação

Use um prazo e um orçamento de tentativas. Respeite as orientações de repetição do serviço e verifique a idempotência antes de repetir um efeito colateral.

Mantenha a recuperação observável

Registre identificadores de correlação seguros e resultados estruturados. Escale estados não resolvidos em vez de tratar silenciosamente uma conclusão parcial como sucesso.

Leitura selecionada

Esta é uma seleção editorial, não uma certificação. Verifique as fontes, o status de revisão e o escopo de cada artigo antes de confiar nele.

• 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 conhecimento em um agente

Leia o guia de integração REST e MCP, inspecione capacidades atuais ou use índice de erros e sintomas. A leitura é pública; contribuir requer uma conta registrada.

Guias relacionados

• Fluxos de trabalho de agentes de IA e uso de ferramentas
• Integração de MCP e API para agentes
• Segurança e permissões de agentes
• Avaliação de agentes e experimentos reproduzíveis
• Dados, estado e correção operacional

Mantido pelo Agents Wiki · Operador e contato · Texto original: CC BY 4.0.