Raft — Un protocole de messagerie léger

Pensez à Raft comme à une boîte postale pour vos agents IA : ils n’ont pas besoin de garder une ligne téléphonique ouverte, ils consultent simplement la boîte quand ils sont prêts.

Ce qui rend Raft différent

La plupart des systèmes de messagerie poussent chaque message directement dans le cerveau de votre agent. Cela signifie une interrogation constante, un contexte lourd et beaucoup de bruit. Raft inverse la logique : le serveur n’envoie qu’un minuscule « ping de réveil », et votre agent décide lui-même du moment où il va réellement lire son courrier.

Cela garde le contexte de l’agent propre et ses réponses rapides. Vous obtenez la fiabilité d’une file de messages sans la surcharge liée au streaming de tout dans un modèle de langage.

La répartition en trois rôles

Hermes divise l’intégration de Raft en trois rôles bien distincts :

• Le pont gère tout le travail réseau difficile : consommation des signaux de réveil, déduplication, reconnexion et livraison au moins une fois.
• L’adaptateur exécute un point de terminaison HTTP local qui reçoit un avis de réveil sans contenu et l’injecte dans la session de l’agent.
• L’agent fait le travail réel : récupérer les messages et envoyer les réponses via le CLI Raft.

L’adaptateur ne touche jamais aux corps des messages. Il ne détient aucune information d’authentification Raft — seulement un jeton par session pour l’authentification localhost. C’est un joli gain de sécurité.

Configuration : une seule ligne

Ajoutez ceci à ~/.hermes/.env :

RAFT_PROFILE=your-agent-profile

C’est tout. Au démarrage, Hermes détecte la variable, génère un jeton de pont, choisit un port éphémère et lance le pont automatiquement. Aucun câblage manuel.

Comment fonctionne le flux

Raft Server → Bridge (SSE wake hints) → POST /wake → Hermes Adapter → Agent context
Agent → raft message check → Raft Server
Agent → raft message send → Raft Server

Le pont écoute les signaux de réveil via SSE, les transmet à votre adaptateur local, et l’adaptateur injecte un court avis dans le contexte de l’agent. L’agent exécute ensuite :

raft message check

…lit les messages réels, puis répond avec :

raft message send

Sécurité par conception

Les charges utiles de réveil sont sans contenu par conception. Elles ne contiennent que des métadonnées — identifiants d’événement, horodatages, identifiants de message. Pas de texte, pas de noms d’expéditeurs, pas de noms de canaux. L’adaptateur rejette activement toute charge utile contenant des champs de type contenu comme text, body ou content. Ainsi, même si quelque chose tourne mal, votre agent ne voit jamais les données brutes des messages via le canal de réveil.

Réflexion finale

Raft est un excellent modèle pour les agents qui n’ont pas besoin d’être toujours actifs. C’est léger, sécurisé, et cela garde la fenêtre de contexte de votre agent propre.

Astuce pratique : Commencez par un test simple — envoyez un message à votre agent depuis un autre client Raft, puis observez les journaux. Vous devriez voir l’avis de réveil arriver, mais le corps du message n’apparaît que lorsque votre agent exécute raft message check. Cette séparation est tout l’intérêt du système.