Directives opérationnelles pour éviter le gaspillage de jetons de l'agent Hermes et préserver le flux de travail local

Comment gérer les compétences inutiles pour qu'elles ne saturent pas la mémoire

Hermes extrait et sauvegarde automatiquement des compétences une fois sa tâche terminée. Cette autonomie est appréciable, mais si on la laisse faire, le fichier m.txt se remplit rapidement de logiques redondantes et de code poubelle. Une mémoire mal gérée augmente la charge cognitive du modèle et finit par vous faire perdre du temps et de l'argent.

Pour maintenir la qualité du dépôt de compétences, il faut d'abord retravailler le prompt système. Imposez que "toutes les compétences doivent être enregistrées selon une structure IPO (Input-Process-Output)". Le simple fait de contraindre l'agent à spécifier les variables d'environnement, les commandes d'exécution et les résultats attendus réduit la probabilité qu'il divague plus tard. Chaque lundi matin, ouvrez le répertoire ~/.hermes/skills/. Fusionnez les fichiers dont le contenu chevauche des compétences existantes et remplacez les codes contenant des chemins de dossiers spécifiques par des variables telles que $PROJECT_ROOT. Ce simple filtrage permet de réduire les étapes d'inférence inutiles et d'économiser près de 40 % de la consommation totale de jetons.

Séparer les profils pour éviter que les connaissances ne se mélangent par projet

Les ennuis commencent dès que l'agent applique les paramètres du projet A au projet B. Hermes stocke toutes les conversations et métadonnées dans state.db ; si vous êtes freelance, vous devez isoler cette base de données selon la nature du travail. Si les connaissances se mélangent, l'agent s'embrouille et vous perdez du temps à déboguer.

Utilisez la commande hermes profile create <nom_du_projet> dans le terminal pour créer des instances indépendantes. Ensuite, placez un fichier SOUL.md à la racine du projet, qui servira de directive comportementale dédiée à l'agent, et réglez terminal.backend sur local dans config.yaml. À chaque début de session, fixez le nom de la tâche avec la commande /title pour faciliter grandement la recherche de schémas de résolution passés via des requêtes SQLite ultérieures. La mise en place de cette structure prend moins de 5 minutes, mais elle devient un atout qui divise par deux le temps de conception initiale lors de l'acquisition de projets similaires par la suite.

Défendre les coûts d'API en alternant entre Claude et des modèles locaux

Utiliser Claude 3.5 Sonnet pour toutes les questions n'est pas respectueux pour votre portefeuille. Il est nécessaire d'adopter une stratégie de mise en cascade (cascading) : réservez le modèle payant aux tâches exigeant une grande réflexion, comme la conception d'architecture, et confiez l'implémentation de code simple ou l'analyse de logs à un modèle local.

Si vous souhaitez plafonner votre budget mensuel autour de 50 000 wons, déterminez le bon moment pour changer de modèle. Même si vous utilisez Claude le matin, dès qu'un codage répétitif simple commence, passez immédiatement au modèle local Qwen 2.5 Coder 32B via la commande /model custom. Les tâches d'automatisation nocturnes ou le nettoyage de données simples incombent à 100 % au modèle local. Vérifiez régulièrement si vous avez dépassé 80 % de votre budget en tapant /usage. Dès que la limite est atteinte, imposez l'utilisation exclusive du modèle local pour éviter une explosion des frais d'API.

Bloquer la propagation des hallucinations grâce au bac à sable et à l'approbation humaine

Rien n'est plus dangereux qu'un agent injectant des informations erronées dans le dépôt de compétences comme s'il s'agissait de vérités. Une mémoire une fois contaminée continue de produire des résultats incorrects. Respectez l'autonomie, mais contrôlez strictement les droits d'écriture qui pourraient compromettre le système.

Tout d'abord, réglez terminal.backend sur docker dans config.yaml. La priorité est d'isoler l'agent pour que, quoi qu'il fasse, cela reste confiné dans un conteneur. Ensuite, exécutez un script bash qui valide automatiquement le code généré par l'agent via pytest, afin que seul le code ayant réussi les tests soit chargé en mémoire. Le dernier rempart, c'est vous. Modifiez le prompt système pour que l'agent doive impérativement obtenir l'approbation de l'utilisateur lorsqu'il appelle save_skill. Ce triple filtre est indispensable pour empêcher les hallucinations de l'agent de se propager dans vos documents système et pour maintenir un niveau de fiabilité de 99 %.

Extraction de données : transformer les logs de travail en indicateurs de rentabilité

Les données accumulées dans state.db ne sont pas de simples blocs de texte. Ce sont des indicateurs qui montrent votre efficacité au travail. Utilisez la bibliothèque sqlite3 de Python pour extraire la consommation de jetons par session et le nombre de compétences générées au cours de la dernière semaine.

Instaurez une routine consistant à convertir les données extraites en Markdown pour les stocker dans votre base de connaissances personnelle. Vous verrez d'un coup d'œil quels projets ont été coûteux et quelles logiques ont été fréquemment réutilisées. Au-delà du simple archivage, cela constitue un argument solide lors de l'établissement de devis pour vos prochains projets. Aussi important que de bien diriger l'agent, c'est votre capacité à raffiner les traces laissées par celui-ci en informations monétisables. Ainsi géré, Hermes n'est plus un simple outil, mais un second cerveau ayant parfaitement absorbé votre style de travail.