Last updated on

Tratamento de Erros e Recuperação no Hermes Agent: Uma Análise Profunda


Quando agentes LLM saem de protótipos e vão para produção, as falhas mais perigosas raramente são respostas erradas — é o sistema cair às 2h da manhã por causa de um 429, um log enorme ou uma API key expirada. Muitos frameworks deixam isso para o try/except do desenvolvedor. O Hermes Agent integra a recuperação diretamente no runtime.

Este artigo disseca as seis camadas de tolerância a falhas do Hermes Agent: classificação de erros, nova tentativa adaptativa, fallback de provedor, compressão de contexto, rollback por checkpoint e recuperação de sessão. Você verá exatamente como o Hermes se recupera sozinho quando algo dá errado.

1. Classifique primeiro, decida depois: o classificador de erros

O Hermes roteia cada falha de API por meio de classify_api_error() em agent/error_classifier.py. Ele não trata cada exceção como um problema de rede genérico; mapeia para uma FailoverReason concreta: rate_limit, overloaded, context_overflow, payload_too_large, long_context_tier, auth, billing, content_policy_blocked, ssl_cert_verification, timeout, stream_drop, thinking_signature, model_incompatible e invalid_request.

Cada motivo carrega três flags: retryable, should_fallback e should_compress. O loop de recuperação age com base nessas flags, não no texto bruto do erro. Isso torna a estratégia previsível, testável e extensível.

2. Nova tentativa adaptativa: leia Retry-After, não apenas durma

O Hermes implementa adaptive_rate_limit_backoff() em agent/retry_utils.py. Não é um backoff exponencial ingênuo. Ele também:

  • Lê o cabeçalho Retry-After da resposta HTTP.
  • Limita a espera a 600 segundos para que um provedor não bloqueie a sessão para sempre.
  • Usa políticas especiais de backoff longo/curto para sobrecarga do Z.AI Coding.
  • Adiciona jitter para evitar que várias instâncias do Hermes retornem ao provedor simultaneamente.

Durante o loop de nova tentativa, o Hermes imprime um bloco de status conciso: tipo de erro, provedor, modelo, tempo decorrido, tamanho do contexto e contagem regressiva. Essa transparência é essencial para depurar gateways ou cron jobs 24×7.

3. Fallback de provedor: da nova tentativa local ao escape entre provedores

O Hermes não fica olhando para um único provedor. Ele escolhe um caminho com base no tipo de erro.

  • Nova tentativa transitória local: para quedas de conexão, 5xx e 408, ele tenta novamente várias vezes no mesmo provedor.
  • Atualização de autenticação e pools de credenciais: em erros auth, tenta atualizar credenciais, atualizar o runtime do Nous Portal e rotacionar keys se houver um pool.
  • Faturamento e rate limits: o provedor atual é marcado como unhealthy e a cadeia de fallback é ativada: primeiro fallback_chain por tarefa, depois global, depois auto-descoberta interna.
  • Política de conteúdo: em content_policy_blocked, ele não tenta novamente; dá ao usuário uma instrução clara.

Para 429s do Nous Portal, o Hermes grava um registro rate_limit compartilhado entre sessões, evitando que todos os workers continuem batendo no mesmo bucket esgotado. É uma proteção projetada para implantações de alta concorrência.

4. Compressão de contexto: transformar “explosão de contexto” em evento rotineiro

A falha mais comum em conversas LLM longas é exceder a janela de contexto. O Hermes lida com isso com precisão:

  • Erros de output-cap: se max_tokens exceder o limite de saída do provedor para aquele modelo, pede ao usuário para diminuir model.max_tokens sem tentativas inúteis.
  • Input-too-large: extrai o limite real da mensagem de erro, atualiza a context_length do compressor e comprime as mensagens.
  • Caso especial Minimax: se o provedor reportar apenas “excedido em X tokens”, mantém a janela original e comprime.

A compressão não é em uma única etapa: primeiro resume mensagens, depois remove payloads de imagem, e só então pede ao usuário /new ou /compress para um 413 verdadeiro. Para erros de long-context tier da Anthropic, reduz temporariamente de 1M para 200K tokens e comprime, sem persistir a redução.

5. Checkpoints e rollback: seguro para arquivos e estado

O Hermes inclui um gerenciador de checkpoints de sistema de arquivos em tools/checkpoint_manager.py. A qualquer momento, você pode executar /rollback para listar e restaurar checkpoints. Para refatorações, mudanças de configuração ou operações em lote de arquivos, é uma camada leve de desfazer.

Snapshots vão mais longe:

/snapshot create before-major-refactor
/snapshot restore 20260717_142030
/snapshot prune 10

/snapshot preserva a configuração e o estado de runtime do Hermes, enquanto /rollback preserva os arquivos do diretório de trabalho. Juntos, cobrem estado e arquivos.

6. Recuperação de sessão: handoff transparente entre CLI e Telegram

O Hermes persiste cada conversão em um banco SQLite em ~/.hermes/state.db, incluindo histórico completo de mensagens, chamadas de ferramentas, contagens de tokens, snapshots do system prompt, timestamps e IDs de sessão pai. Isso significa que:

  • hermes --continue ou hermes -r <session_id> retoma a última conversa CLI.
  • /new payments-refactor nomeia uma sessão, e /resume payments-refactor a recupera depois.
  • Você pode transferir uma sessão entre plataformas: comece no CLI, continue no Telegram e depois retome no desktop com /resume.

Ao retomar, o Hermes mostra um resumo compacto para que você não precise reler todo o log. Sessões longas são controladas com /compress.

7. Tabela de comandos de emergência

Comando Ação
/retry Reenviar a última mensagem ao agente.
/resume [name] Retomar uma sessão anterior.
/new [name] / /reset Iniciar uma nova sessão, opcionalmente nomeada.
/compress [here [N] | focus topic] Comprimir o contexto manualmente.
/undo Remover a última troca usuário/assistant.
/rollback [number] Listar ou restaurar um checkpoint.
/snapshot create/restore/prune Salvar, restaurar ou limpar snapshots.
/stop Matar todos os processos em segundo plano.
hermes --continue Retomar a sessão CLI mais recente.
hermes -r <id> Retomar sessão por ID.
hermes -c "name" Retomar sessão por nome.

8. Comparação com frameworks populares

Capacidade Hermes Agent OpenAI Agents AutoGen/AG2 CrewAI LangGraph
Classificação de erros FailoverReason integrado Erros básicos do SDK Mais simples Nível de ferramenta Projetar manualmente
Fallback automático de provedor Cadeia de fallback integrada Implementação manual Parcial Não suportado Implementação manual
Compressão de contexto Multiestágio integrado Não suportado Não suportado Não suportado Não suportado
Persistência/retomada de sessão SQLite + /resume Salvar manualmente Salvar manualmente Não suportado Checkpoint de máquina de estados
Checkpoints de sistema de arquivos /rollback Não suportado Não suportado Não suportado Não suportado
Handoff entre plataformas Integrado Não suportado Não suportado Não suportado Não suportado

A diferença do Hermes é que o tratamento de erros não é um plugin opcional — faz parte do runtime. Você não escreve try/except, não mantém listas de provedores, não corta contexto manualmente. Tudo isso é comportamento padrão.

9. Recomendações práticas para equipes de engenharia

  1. Configure um provedor de fallback. Pelo menos um em produção para que 429 e 402 não se tornem alertas às 3h da manhã.
  2. Nomeie sessões importantes. Use /new <task-name> para poder retomar e transferir entre plataformas.
  3. Crie snapshots antes de mudanças grandes. /snapshot create <label> permite reverter rapidamente.
  4. Use cron no-agent para tarefas repetíveis. Para jobs críticos recorrentes, scripts no_agent: true com stdout direto evitam a incerteza da inferência LLM.
  5. Faça backup de ~/.hermes/state.db. Lá reside todo o seu histórico de conversas.

Conclusão

O sistema de tratamento de erros do Hermes Agent é muito mais do que “tentar algumas vezes e desistir”. Ele ataca os modos de falha comuns de operações LLM sob seis ângulos: classificação, nova tentativa, fallback, compressão, checkpoints e recuperação de sessão. Para equipes que querem executar agentes em produção, essa capacidade de autocura é tão importante quanto a habilidade de raciocínio do próprio modelo.

Se você ainda escreve scripts ad-hoc para quedas de provedor, inchaço de contexto ou troca de modelo, deixe o Hermes fazer esse trabalho sujo. Configure seu fallback, pressione /resume e continue.