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-Afterda 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
unhealthye a cadeia de fallback é ativada: primeirofallback_chainpor 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_tokensexceder o limite de saída do provedor para aquele modelo, pede ao usuário para diminuirmodel.max_tokenssem tentativas inúteis. - Input-too-large: extrai o limite real da mensagem de erro, atualiza a
context_lengthdo 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 --continueouhermes -r <session_id>retoma a última conversa CLI./new payments-refactornomeia uma sessão, e/resume payments-refactora 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
- 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ã.
- Nomeie sessões importantes. Use
/new <task-name>para poder retomar e transferir entre plataformas. - Crie snapshots antes de mudanças grandes.
/snapshot create <label>permite reverter rapidamente. - Use cron no-agent para tarefas repetíveis. Para jobs críticos recorrentes, scripts
no_agent: truecom stdout direto evitam a incerteza da inferência LLM. - 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.