Files
nas-runbooks/common/brief-gemini-hermes-botmode-20260825-v3.md
T

6.5 KiB

Brief Nyora → Gemini/AntiGravity : MAJ Hermes Agent (v3 — Bot Mode en périmètre)

Émetteur : Claude (cerveau stratégique) Destinataire d'exécution : hermes-nyora — cadre et pilote Gemini/AntiGravity Date : 2026-08-25 Statut : remplace le brief v2 (common/brief-gemini-hermes-browserless-botmode-20260825-v2.md). Décision de Nabil : Bot Mode est accepté, actif par défaut, pattern Manager + bots spécialistes retenu comme architecture cible.


0. Décisions de Nabil (25/08, ne pas rouvrir sans nouvel élément)

  • Bot Mode validé sur le principe : plusieurs bots spécialisés à tâche précise, coordonnés par un Manager/Cerveau, sont jugés plus fiables qu'un seul agent généraliste portant toute une tâche. Bot Mode actif par défaut (bot_mode_protocol: true) est acceptable — pas besoin de le désactiver.
  • Cible de version : nousresearch/hermes-agent:v2026.8.19 (v0.20.5), pas v2026.8.18. Cette version la plus mûre inclut les correctifs Bot Mode ultérieurs (group-room threads, routing cross-machine stabilisé) et le scan NVIDIA SkillEvaluator sur les installs de skills.
  • Isolation totale, sans aucune exception, y compris en interne : aucune connexion hermes peer entre AUCUNE des instances/déploiements Hermes de Nabil (hermes-tt, hermes-nyora, hermes-perso, hermes-nabil, hermes-hub), ni vers l'extérieur. Nabil a explicitement écarté deux exceptions qui auraient pu sembler naturelles : hermes-nabil (censé le représenter personnellement) et hermes-nyora (qui a une vue transverse et pourrait un jour intervenir sur une autre instance) — aucun des deux n'est une exception légitime. Coordination Bot Mode = strictement intra-instance, entre bots vivant dans le même profil Hermes.

1. Préalable technique bloquant — vérifié en direct, à traiter AVANT tout test Bot Mode

Les 3 conteneurs hermes-agent-tt / hermes-agent-nyora / hermes-agent-perso partagent aujourd'hui le réseau Docker n8n (172.27.0.0/16) — le maillage principal de toute la stack (n8n, Baserow, Gitea, Bifrost, context-hub et une trentaine d'autres conteneurs y sont aussi). Vérifié via docker network inspect n8n : les 3 instances Hermes s'y trouvent avec des IP routables entre elles (172.27.0.35/.37/.33). Rien n'empêche aujourd'hui un hermes peer add d'une instance vers une autre en interne — l'isolation entre sphères repose actuellement sur la discipline, pas sur une barrière réseau.

Retirer les instances Hermes de ce réseau n'est pas la solution : elles en dépendent pour leurs appels légitimes (n8n, Baserow, Bifrost, context-hub). Ce qu'il faut, et c'est la première tâche de Gemini avant tout test Bot Mode :

  1. Identifier le(s) port(s) exact(s) utilisé(s) par le protocole peer Bot Mode (hermes peer, mécanisme de connexion Desktop relay).
  2. Poser une règle de pare-feu ciblée (iptables sur le host, ou règle crowdsec dédiée) qui bloque spécifiquement ce port entre les IP des conteneurs hermes-agent-tt / hermes-agent-nyora / hermes-agent-perso entre eux, sans toucher au reste du trafic sur le réseau n8n.
  3. Vérifier en direct (tentative de connexion peer réelle entre deux instances, doit échouer) que la règle fonctionne.
  4. Appliquer la même logique côté VPS pour hermes-nabil / hermes-hub (probablement plus simple : déploiements séparés, pas de réseau Docker partagé avec le NAS a priori — à confirmer).

Ce verrou réseau doit être en place et vérifié avant l'étape 4 (test Bot Mode) ci-dessous, pas après.


2. Étape 1 — Vérification factuelle (reprise du brief v1, résultats déjà obtenus par Claude)

Déjà fait, pas à refaire : tag v2026.8.19 confirmé disponible sur le registre (Docker Hub), digest vérifié. Browser Use mode présent depuis v0.20.1, Bot Mode présent depuis v0.20.4 (code dans agent_init.py, conversation_loop.py, system_prompt.py — pas un plugin isolé). Flag agent.bot_mode_protocol : défaut True, confirmé par lecture directe du code (_agent_section.get("bot_mode_protocol", True)).


3. Étape 2 — Tests bloquants avant toute mise en prod (gates, pas des curiosités)

  1. Test Tirith sur commande shell émise par un bot : créer un profil bot nu (sans toolset superflu), lui faire tenter une commande shell quelconque, constater si la review Tirith se déclenche. Si elle ne se déclenche pas → remonter à Nabil avant d'aller plus loin, ne pas contourner.
  2. Mécanisme de roster local : deux bots créés dans la même instance (même profil hermes-nyora) se découvrent-ils automatiquement, ou faut-il un enregistrement explicite même en local ? À documenter précisément — ça conditionne comment le Manager/Cerveau doit être configuré pour piloter ses bots spécialistes.
  3. Vérification du verrou réseau (§1.3 ci-dessus) avant tout test Bot Mode réel entre instances (même si aucune connexion n'est prévue, vérifier que la règle empêche bien une tentative).

4. Phase A — Pilote hermes-nyora, architecture Manager + bots spécialistes

Une fois §1 et §3 validés :

  1. Sauvegarder config/mémoire actuelles (comme prévu dans le plan initial).
  2. Bascule image → nousresearch/hermes-agent:v2026.8.19, --force-recreate.
  3. Batterie de re-tests continuité (gateway Telegram, cron, mémoire, webhook veille-backend, MCP context-hub, SMTP) — reprise du plan initial.
  4. Premier cas d'usage réel à construire avec Nabil : décomposer une tâche récurrente de hermes-nyora en bots spécialistes (ex. un bot par sous-tâche bien définie) coordonnés par un Manager. Ne pas improviser la répartition — la faire valider par Nabil avant implémentation, comme il l'a précisé ("c'est à nous de fixer les tâches de chacun").
  5. Test Browser Use mode (repris du plan initial, sans changement).

5. Ce qui reste hors périmètre

Extension à hermes-tt / hermes-perso (Phase C du plan initial) : uniquement après retour positif du pilote hermes-nyora ET validation explicite de Nabil. hermes-nabil / hermes-hub (VPS) : suivent en miroir une fois la version validée sur NAS (cf. décision déjà actée sur le suivi de versions).


Rappel du mécanisme

Claude conçoit le motif → hermes-nyora cadre et fait exécuter → Gemini installe/investigue → Claude audite en un seul passage qui reteste réellement en direct. Le verrou réseau (§1) et les deux tests de gate (§3) ne sont pas optionnels : c'est la condition posée par Nabil pour que "aucune connexion vers l'extérieur, jamais, sans exception" soit une propriété technique vérifiée et pas une promesse.