Quand les agents LLM passent du prototype à la production, les pannes les plus dangereuses ne sont pas les mauvaises réponses, mais le système qui tombe à 2 h du matin à cause d’une erreur 429, d’un log trop long ou d’une clé API expirée. Beaucoup de frameworks laissent cela au try/except du développeur. Hermes Agent intègre la récupération directement dans le runtime.

Cet article décompose les six couches de tolérance aux pannes d’Hermes Agent : classification des erreurs, réessai adaptatif, fallback de fournisseur, compression du contexte, rollback par checkpoints et récupération de session. Vous verrez exactement comment Hermes se remet debout tout seul quand quelque chose tourne mal.

1. Classifier d’abord, décider ensuite : le classificateur d’erreurs

Hermes route chaque échec d’API via classify_api_error() dans agent/error_classifier.py. Il ne traite pas chaque exception comme un problème réseau générique, mais la mappe à une FailoverReason concrète : 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 et invalid_request.

Chaque raison porte trois indicateurs : retryable, should_fallback et should_compress. La boucle de récupération agit sur ces indicateurs, pas sur le texte brut de l’erreur. Cela rend la stratégie prévisible, testable et extensible.

2. Réessai adaptatif : lire Retry-After, pas seulement dormir

Hermes implémente adaptive_rate_limit_backoff() dans agent/retry_utils.py. Il ne s’agit pas d’un backoff exponentiel naïf. Il :

• Lit l’en-tête Retry-After de la réponse HTTP.
• Plafonne l’attente à 600 secondes pour qu’un fournisseur ne bloque pas la session indéfiniment.
• Utilise des politiques de backoff long/court spéciales pour la surcharge de Z.AI Coding.
• Ajoute du jitter pour éviter que plusieurs instances Hermes ne retombent sur le fournisseur en même temps.

Pendant la boucle de réessai, Hermes affiche un bloc de statut concis : type d’erreur, fournisseur, modèle, temps écoulé, taille du contexte et compte à rebours. Cette transparence est essentielle pour déboguer des gateways ou des tâches cron 24×7.

3. Fallback de fournisseur : du réessai local à l’échappatoire croisée

Hermes ne fixe pas un seul fournisseur. Il choisit un chemin selon le type d’erreur.

• Réessai transitoire local : pour les coupures de connexion, 5xx et 408, il réessaie plusieurs fois sur le même fournisseur.
• Rafraîchissement d’authentification et pools d’identifiants : sur erreurs auth, il rafraîchit les credentials, le runtime Nous Portal et fait tourner les clés si un pool est configuré.
• Facturation et rate limits : le fournisseur actuel est marqué unhealthy et la chaîne de fallback est activée : fallback_chain par tâche, puis globale, puis auto-découverte interne.
• Politique de contenu : en cas de content_policy_blocked, il ne réessaie pas ; il donne à l’utilisateur une consigne claire.

Pour les 429 de Nous Portal, Hermes écrit un enregistrement rate_limit partagé entre sessions, empêchant tous les workers de continuer à frapper le même bucket épuisé. C’est une protection conçue pour les déploiements à forte concurrence.

4. Compression du contexte : transformer “l’explosion de contexte” en événement routinier

L’échec le plus courant dans les conversations LLM longues est le dépassement de la fenêtre de contexte. Hermes gère cela avec précision :

• Erreurs output-cap : si max_tokens dépasse la limite de sortie du fournisseur pour ce modèle, il demande à l’utilisateur de baisser model.max_tokens sans réessayer inutilement.
• Input-too-large : il extrait la vraie limite du message d’erreur, met à jour la context_length du compresseur et compresse les messages.
• Cas spécial Minimax : si le fournisseur ne rapporte que “dépassé de X tokens”, il conserve la fenêtre originale et compresse.

La compression n’est pas en une seule étape : d’abord résumer les messages, puis retirer les payloads d’images, et seulement alors demander /new ou /compress pour un vrai 413. Pour les erreurs de long-context tier d’Anthropic, il rétrograde temporairement de 1M à 200K tokens et compresse, sans persister la rétrogradation.

5. Checkpoints et rollback : assurance pour fichiers et état

Hermes inclut un gestionnaire de checkpoints de système de fichiers dans tools/checkpoint_manager.py. À tout moment, vous pouvez exécuter /rollback pour lister et restaurer des checkpoints. Pour les refactorisations, changements de configuration ou opérations de fichiers massives, c’est une couche de défaire légère.

Les snapshots vont plus loin :

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

/snapshot conserve la configuration et l’état d’exécution d’Hermes, tandis que /rollback préserve les fichiers du répertoire de travail. Ensemble, ils couvrent l’état et les fichiers.

6. Récupération de session : transfert transparent entre CLI et Telegram

Hermes persiste chaque conversation dans une base SQLite à ~/.hermes/state.db, incluant l’historique complet, les appels d’outils, les compteurs de tokens, les snapshots du system prompt, les horodatages et les IDs de session parent. Cela signifie que :

• hermes --continue ou hermes -r <session_id> reprend la dernière conversation CLI.
• /new payments-refactor nomme une session, et /resume payments-refactor la récupère plus tard.
• Vous pouvez transférer une session entre plateformes : démarrer en CLI, continuer sur Telegram, puis reprendre sur le bureau avec /resume.

Lors de la reprise, Hermes affiche un récapitulatif compact pour que vous n’ayez pas à relire tout le log. Les sessions longues se contrôlent avec /compress.

7. Tableau de commandes d’urgence

Commande	Action
/retry	Renvoyer le dernier message à l’agent.
/resume [name]	Reprendre une session précédente.
/new [name] / /reset	Démarrer une nouvelle session, nommée optionnellement.
/compress [here [N] | focus topic]	Compresser le contexte manuellement.
/undo	Supprimer le dernier échange utilisateur/assistant.
/rollback [number]	Lister ou restaurer un checkpoint.
/snapshot create/restore/prune	Sauvegarder, restaurer ou nettoyer des snapshots.
/stop	Tuer tous les processus en arrière-plan.
hermes --continue	Reprendre la session CLI la plus récente.
hermes -r <id>	Reprendre une session par ID.
hermes -c "name"	Reprendre une session par nom.

8. Comparaison avec les frameworks populaires

Capacité	Hermes Agent	OpenAI Agents	AutoGen/AG2	CrewAI	LangGraph
Classification des erreurs	FailoverReason intégré	Erreurs de base du SDK	Plus simple	Niveau outil	À concevoir
Fallback automatique de fournisseur	Chaîne de fallback intégrée	Implémentation manuelle	Partiel	Non supporté	Implémentation manuelle
Compression du contexte	Multi-étapes intégrée	Non supporté	Non supporté	Non supporté	Non supporté
Persistance/reprise de session	SQLite + /resume	Sauvegarde manuelle	Sauvegarde manuelle	Non supporté	Checkpoint de machine à états
Checkpoints de système de fichiers	/rollback	Non supporté	Non supporté	Non supporté	Non supporté
Transfert entre plateformes	Intégré	Non supporté	Non supporté	Non supporté	Non supporté

La différence d’Hermes : la gestion des erreurs n’est pas un plugin optionnel, mais fait partie du runtime. Vous n’écrivez pas de try/except, ne maintenez pas de listes de fournisseurs, ne coupez pas le contexte à la main. Tout cela est le comportement par défaut.

9. Recommandations pratiques pour les équipes d’ingénierie

1. Configurez un fournisseur de fallback. Au moins un en production pour que les 429 et 402 ne deviennent pas des alertes à 3 h du matin.
2. Nommez les sessions importantes. Utilisez /new <task-name> pour pouvoir reprendre et transférer entre plateformes.
3. Créez des snapshots avant les grands changements. /snapshot create <label> permet de revenir rapidement en arrière.
4. Utilisez cron no-agent pour les tâches répétitives. Pour les jobs critiques récurrents, les scripts no_agent: true avec stdout direct évitent l’incertitude de l’inférence LLM.
5. Sauvegardez ~/.hermes/state.db. C’est là que réside tout votre historique de conversation.

Conclusion

Le système de gestion des erreurs d’Hermes Agent est bien plus que “réessayer quelques fois et abandonner”. Il attaque les modes de défaillance courants des opérations LLM sous six angles : classification, réessai, fallback, compression, checkpoints et récupération de session. Pour les équipes qui veulent déployer des agents en production, cette capacité d’auto-guérison est aussi importante que la capacité de raisonnement du modèle.

Si vous écrivez encore des scripts ad-hoc pour les pannes de fournisseur, le gonflement du contexte ou le changement de modèle, laissez Hermes faire ce sale boulot. Configurez votre fallback, appuyez sur /resume et continuez.