RoBrain est une couche de mémoire et de jugement open source pour les équipes qui utilisent des agents de codage d'IA. Son unité distinctive n'est pas une transcription de discussion ou un « fait » vague, mais une décision technique : ce que l'équipe a choisi, pourquoi elle l'a choisi, quelles alternatives elle a rejetées, quels fichiers ont été affectés et si la décision est toujours active. Le même enregistrement sauvegardé par Postgres peut être transmis au code Claude, Cursor, GitHub Copilot, Codex CLI et Hermes.
Cette focalisation résout un problème restreint mais coûteux. Un agent de codage peut se souvenir de la convention actuelle tout en recommandant une bibliothèque, une migration ou une architecture que l'équipe avait précédemment rejetée. Les fichiers de règles ordinaires préservent souvent le gagnant mais omettent les options perdantes et leurs raisons. RoBrain rend ces veto interrogeables et peut avertir avant le début des travaux. Cela ne rend pas les décisions stockées toujours correctes : les erreurs de capture, les contraintes obsolètes et les désaccords organisationnels nécessitent toujours une gouvernance humaine.
Comment fonctionne la boucle décision-mémoire
sessions développeur + agent de codage
|
v
capture passive
rédiger -> classer -> extraire
|
v
Grand livre de décisions Postgres
choix / justification / rejet[] / dossiers / état
| |
v v
synthèse programmée de rappel pré-tâche
veto + conflits de contexte + dérive
| |
'-------------+--------------'
v
réviser / remplacer / exporter
|
signal de résultat git
Le diagramme sépare la capture, le stockage, la récupération et le jugement car chacun échoue différemment. Un classificateur peut rater une décision. L’extraction peut inventer une justification. La récupération peut renvoyer un veto connexe mais non pertinent. Synthesis peut signaler un changement légitime comme une contradiction. Un projet pilote utile mesure chaque étape au lieu de considérer « l’agent s’est souvenu de quelque chose » comme une preuve suffisante.
RoBrain par rapport à une mémoire de projet plus simple
| Approche | Force | Échec typique | Meilleur ajustement |
|---|---|---|---|
| CLAUDE.md, AGENTS.md ou éditeur de règles | Transparent, consultable dans git, pas de service | Entretien manuel ; les options rejetées et les dates sont souvent manquantes | Dépôt petit ou jeune avec des conventions stables |
| Mémoire automatique du chat ou de l'éditeur | Faible configuration et continuité personnelle | Local à un utilisateur/outil ; gouvernance d'équipe faible | Travail en solo où le partage entre outils n'est pas nécessaire |
| Mémoire vectorielle générique | Rappel sémantique flexible | Les morceaux peuvent récupérer de la prose sans cycle de vie ni sémantique de veto | Rappel de connaissances étendues au-delà des décisions |
| RoBrain | Alternatives rejetées structurées, cycle de vie, magasin multi-outils et synthèse | Surcharge opérationnelle et risque de mémoire durable polluée | Multiples développeurs, multiples agents et débats architecturaux récurrents |
Les propres conseils de RoBrain sont rafraîchissants et spécifiques : si un projet ne dispose pas de plusieurs développeurs ou outils, d'un historique suffisant pour que les contradictions s'accumulent ou de propositions rejetées répétées, un fichier de règles statiques peut suffire. C’est un disqualifiant utile. L'infrastructure de mémoire devrait gagner sa place en réduisant les retouches, et non en ajoutant une autre base de données car « les agents ont besoin de mémoire ».
Ce qui est réellement stocké
| Champ | Pourquoi c'est important | Question de révision |
|---|---|---|
| Décision | Indique la contrainte ou l'approche choisie | Est-il suffisamment spécifique pour être appliqué sans geler des travaux non liés ? |
| Justification | Préserve les conditions du choix | La raison observée est-elle une preuve, une préférence ou une spéculation ? |
rejeté[] | Permet de récupérer les options de cible qui ne devraient pas être réintroduites avec désinvolture | Chaque refus comporte-t-il un motif daté et falsifiable ? |
| Fichiers et provenance | Connecte la mémoire à sa source et à la surface affectée | Un réviseur peut-il retracer l'enregistrement jusqu'à une session ou une modification ? |
| Cycle de vie | Distingue les orientations actives, remplacées et invalidées | Qui peut changer d’état et le remplacement est-il lié ? |
| Relations | Relie les conflits, les extensions et les décisions associées | Le graphique aide-t-il à la récupération ou produit-il simplement du bruit ? |
Une option rejetée ne doit pas devenir une interdiction éternelle. « Ne pas utiliser Redis » aurait pu être correct lors d'un gel des coûts et erroné après un changement de charge de travail. Le dossier durable doit inclure la portée, la date, le propriétaire, les preuves et un déclencheur d'expiration ou de révision. RoBrain prend en charge le remplacement et l'invalidation, mais les équipes doivent définir qui exerce ces contrôles.
Architecture auto-hébergée et limite de données
Le chemin auto-hébergé gratuit démarre Postgres plus le service Perception dans Docker, puis connecte les éditeurs pris en charge via MCP, des plugins ou des hooks. Selon le site officiel, les décisions restent dans Postgres de l’équipe et le contenu complet du fichier n’est pas ingéré ; de courts extraits de session, des chemins de fichiers et des métadonnées de décision peuvent être stockés. Les secrets sont effacés lors de la capture et de l’ingestion. Cependant, le chemin d’extraction et d’intégration par défaut peut toujours appeler des fournisseurs de modèles externes à l’aide des clés API de l’opérateur.
| Composant | Données qu'il voit | Contrôle de l'opérateur | Risque à tester |
|---|---|---|---|
| Hook de l'éditeur ou intégration MCP | Invites, tours d'agent et contexte de projet sélectionnés pour la capture | Installation par référentiel | Capture inattendue de sessions sensibles |
| Perception | Tour de candidat et décisions extraites | Conteneur auto-hébergé et authentification API | Erreur de classification, service non corrigé ou point de terminaison exposé |
| Postgres/pgvector | Corpus de décision, extraits, intégrations et métadonnées | Infrastructure d'équipe, sauvegarde et conservation | Accès étendu, enregistrements obsolètes et fuite de sauvegarde |
| Fournisseur LLM/intégration | Charge utile requise pour l'extraction ou la vectorisation | Choix du fournisseur ; les modèles locaux sont pris en charge | Rétention de tiers, résidence et limites contractuelles |
| Nuage Rory Plans | Traitement au niveau du cloud et données d'équipe | Compte et plan fournisseur | Vérifier les conditions actuelles, la région, les rôles et le chemin de suppression |
« Auto-hébergé » ne signifie donc pas automatiquement « aucune donnée ne quitte le réseau ». Une configuration entièrement locale utilisant Ollama, LM Studio ou vLLM peut réduire le traitement sortant, mais les équipes doivent vérifier la trace réseau réelle et la configuration du modèle. Protégez également les sauvegardes de bases de données, les jetons API, les registres générés et les journaux d'observabilité ; ceux-ci peuvent révéler des choix d'architecture ou des vulnérabilités passées, même sans code source.
La récupération, les analyses de veto et la synthèse sont des contrôles différents
Le Perception API auto-hébergé expose une approche déterministe POST/veto-scan qui recherche des mentions littérales d’options actives rejetées. Ceci est prévisible et peu coûteux, mais peut manquer de synonymes et de propositions indirectes. Les intégrations prises en charge peuvent ajouter une récupération sémantique pour une correspondance plus large. Au début de la session, un résumé permanent fournit un contexte hautement prioritaire. Le programmé synthétiseur Robin Job analyse le corpus à la recherche de contradictions, de dérives de position et d'entités récurrentes ; les évaluateurs inspectent les résultats avec Critique de Robin.
| Mécanisme | Quand il court | Bon à | Angle mort |
|---|---|---|---|
| Résumé toujours actif | Début de séance | Contraintes stables de haut niveau | Budget contextuel et classement obsolète |
| Analyse de veto littérale | Avant une invite/action dans les hooks pris en charge | Noms d'options connus avec un comportement déterministe | Alias, équivalents conceptuels et invites vagues |
| Recherche/injection sémantique | Sur demande ou via intégration | Décisions connexes exprimées différemment | Fausses correspondances et provenance manquante dans l’interprétation de l’agent |
| Synthesis | Lot manuel ou programmé | Dérive et contradictions à l’échelle du corpus | Nécessite un examen humain ; pas un moteur de politique en temps réel |
| Commentaires sur les résultats de Git | Après que des retours soient observés | Décisions de rétrogradation associées à des résultats échoués | Un retour est un indicateur imparfait de la qualité des décisions |
Comment lire la réclamation VetoBench
RoBrain publie VetoBench, un benchmark conçu autour d'une question utile : lorsqu'une tâche invite à une approche que l'équipe avait précédemment rejetée, l'agent de codage la propose-t-il à nouveau et cite-t-il la raison précédente ? Les résultats officiels de juillet 2026 indiquent qu'aucune nouvelle proposition n'a été rejetée pour RoBrain lors des tests archivés, tandis que les conditions d'absence de mémoire ont refait surface à plusieurs reprises aux approches ayant fait l'objet d'un veto. Le référentiel comprend des invites, le contexte récupéré, des réponses et des verdicts, ce qui constitue une preuve plus solide qu'un pourcentage marketing non inspectable.
Il s'agit toujours d'un benchmark créé par le fournisseur avec des scénarios synthétiques, des modèles sélectionnés et un pipeline d'ingestion particulier. Cela démontre que la récupération structurée du veto peut fonctionner dans ces conditions ; cela ne prouve pas une réduction des incidents de production pour chaque référentiel. Réexécutez un sous-ensemble représentatif avec votre modèle, votre langage, vos règles, la taille de l'historique et votre intégration. Incluez les cas contradictoires : des bibliothèques renommées, un veto expiré, deux équipes avec des contraintes contradictoires et une décision dont la justification contient une chaîne de type secret.
Une évaluation pratique de deux semaines
- Choisissez un référentiel. Préférez une base de code datant de plus de six mois avec au moins deux développeurs actifs et des inversions documentées.
- Construisez un ensemble en or. Sélectionnez 20 décisions : dix alternatives actives, cinq remplacées et cinq alternatives rejetées. Enregistrez le problème faisant autorité, l'ADR ou la demande d'extraction pour chacun.
- Démarrez à chaud avec précaution. Importez uniquement les décisions examinées. Ne transformez pas une archive de discussion entière en mémoire fiable.
- Exécutez des tâches jumelées. Donnez les mêmes 15 tâches réalistes à un agent avec et sans contexte RoBrain. Randomisez l’ordre et conservez le modèle/les paramètres fixes.
- Passez en revue chaque capture. Mesurez la précision, la justification manquante, la portée du fichier incorrecte, la rédaction secrète et le temps d'approbation.
- Testez les modifications du cycle de vie. Annuler trois décisions et confirmer que les anciens vetos restent historiques sans bloquer le remplacement.
- Simulez un échec. Arrêtez Perception, faites pivoter un jeton, restaurez une sauvegarde et confirmez que les hooks de l'éditeur échouent en toute sécurité sans perdre le travail de développement.
| Métrique | Comment calculer | Porte pilote suggérée |
|---|---|---|
| Précision de capture | Corriger les décisions durables/tous les enregistrements capturés | Au moins 90 % après stabilisation des règles de révision |
| Rappel de capture | Décisions d'or correctement capturées / décisions prises | Au moins 80 % ; enquêter sur les échecs par intégration |
| Veto sur la précision du coup | Avertissements utiles / tous les avertissements affichés | Au moins 80 % pour éviter la fatigue des avertissements |
| Taux de mémoire obsolète | Enregistrements invalides ou remplacés apparus comme actifs/rappels | En dessous de 5 % |
| Taux de rejets répétés | Tâches qui proposent à nouveau un veto connu / tâches éligibles | Nettement inférieur au niveau de référence |
| Charge de révision | Minutes passées à réviser par développeur et par semaine | Inférieur au temps gagné grâce à des enquêtes répétées |
Ces seuils sont des points de départ et non des garanties officielles. La décision commerciale doit utiliser le temps gagné et les retouches évitées. Si le système évite la réintroduction d’une dépendance coûteuse mais nécessite des heures de nettoyage hebdomadaire, sa valeur dépend de la répartition des coûts de ces pannes.
Gouvernance : la mémoire est une infrastructure partagée
| Rôle | Responsabilité | Contrôle requis |
|---|---|---|
| Développeur | Crée des décisions et signale les captures incorrectes | Provenance visible et correction facile |
| Responsable technique | Approuve la mémoire d’architecture à fort impact | Examiner la file d'attente et la propriété par sous-système |
| Sécurité/confidentialité | Définit les référentiels et les classes de données exclus | Tests de rédaction, journaux d'accès, conservation et suppression |
| Propriétaire de la plateforme | Fonctionne avec Postgres, Perception et les intégrations | Sauvegardes, mises à niveau, rotation des jetons et surveillance |
| Auditeur | Reconstruit pourquoi les conseils ont changé | Provenance immuable et historique de remplacement |
Ne laissez pas la capture passive établir silencieusement une politique. Étiqueter les enregistrements comme étant proposés, examinés ou faisant autorité ; réserver l’injection automatique de vetos forts aux enregistrements approuvés ou de haute confiance. Segmentez les projets et les équipes afin qu’une expérience front-end ne devienne pas une interdiction à l’échelle de l’entreprise. Ajoutez des déclencheurs de révision pour les mises à niveau de dépendances, les incidents, les modifications réglementaires et le temps écoulé.
Auto-hébergé par rapport au cloud Rory Plans
L'édition auto-hébergée Apache-2.0 fournit le système de décision de base : capture, vetos structurés, cycle de vie, synthèse, récupération multi-outils, exportation et fonctionnement local. La comparaison officielle de RoBrain indique que le cloud Rory Plans ajoute une injection plus automatique des limites des tâches, des verdicts de conflit avant la validation, une administration d'équipe, un tableau de bord et une gestion plus riche des conflits. L'accès au cloud est lié aux offres Rory Plans payantes plutôt qu'à un simple prix RoBrain autonome indiqué sur la page du projet.
Avant d'acheter, vérifiez le plan actif actuel, y compris l'utilisation, les dépassements, l'isolation de l'organisation, le support, le contrôleur de données, le processus de suppression et le comportement d'exportation. Pour l'auto-hébergement, évaluez les coûts les moins visibles : Postgres, sauvegardes, appels de modélisation et d'intégration, mises à niveau, réponse aux incidents et temps de révision.
Alternatives et quand les choisir
| Options | Choisissez-le quand | Compromis par rapport à RoBrain |
|---|---|---|
| Fichiers ADR plus CLAUDE.md/AGENTS.md | Vous voulez des décisions natives git, rédigées par des humains, avec une infrastructure minimale | Un examen délibéré plus rigoureux ; capture passive plus faible et rappel proactif multi-outils |
| Mem0 | Vous avez besoin d'une mémoire à usage général API pour toutes les applications | Primitives de mémoire plus larges ; Les alternatives rejetées peuvent nécessiter un schéma/gouvernance personnalisé |
| Zep/Graphiti | Les graphiques de connaissances temporelles et les relations entre entités sont essentiels | Modèle de graphique plus général ; plus de travail pour créer des flux de travail de décision de codage |
| OpenViking ou systèmes contextuels orientés fichiers | Vous voulez des connaissances de projet navigables et une récupération explicite | Organisation d'un contexte plus large ; RoBrain est plus spécialisé dans les vetos et le cycle de vie |
| Postgres personnalisé + MCP | Vous disposez d’une forte capacité de plateforme et de besoins politiques inhabituels | Contrôle maximal ; vous êtes propriétaire de l'extraction, de l'évaluation, des crochets et de la maintenance |
RoBrain est plus convaincant lorsque l'alternative rejetée est aussi importante que la convention choisie. Si le problème réel concerne la découverte de documentation, la recherche de code ou les notes personnelles, un outil plus restreint peut avoir un coût opérationnel inférieur.
FAQ
RoBrain est-il un agent de codage ?
Non. Il s’agit d’une couche de mémoire et de jugement connectée aux agents de codage existants. Il stocke et récupère les décisions ; Claude Code, Cursor, Copilot, Codex CLI ou Hermes effectuent toujours le travail de codage.
Un développeur solo peut-il en bénéficier ?
Oui, en particulier sur une base de code de longue durée où d'anciennes erreurs reviennent dans tous les outils. Cependant, un fichier de règles maintenu ou un dossier ADR peut suffire. Pilotez par rapport à cette ligne de base plus simple.
L’auto-hébergement conserve-t-il toutes les données locales ?
La base de données et le service Perception peuvent s'exécuter localement, mais l'extraction et l'intégration peuvent faire appel à des fournisseurs externes configurés. Utilisez les modèles locaux pris en charge et vérifiez le trafic réseau si une localité complète est requise.
Un veto empêchera-t-il l’agent d’agir ?
Pas universellement. Les analyses littérales et les avertissements d'intégration fournissent le contexte ; le comportement dépend de l’outil et du niveau connectés. Traitez-les comme une aide à la décision, à moins que vous n'ayez testé séparément une voie d'application.
Comment gérer une mémoire incorrecte ?
Rejetez ou modifiez la capture, préservez la provenance et marquez les enregistrements obsolètes comme remplacés ou invalidés. Suivez les fausses captures en tant que mesure opérationnelle plutôt que de supprimer discrètement les preuves d'erreurs de pipeline.
VetoBench est-il une preuve indépendante ?
Non. Il s’agit d’un benchmark transparent, géré par le fournisseur, avec des reçus archivés. Il s’agit d’une preuve utile et d’un modèle reproductible, mais l’adoption en production devrait dépendre d’une évaluation couplée spécifique au référentiel.
Sources et vérification
- Page produit officielle RoBrain, architecture et comparaison
- Dépôt source officiel Apache-2.0
- Concepts officiels et modèle de mémoire
- CLI officielle et référence d'installation
- Méthodologie VetoBench et preuves archivées
- Format d'exportation de mémoire officiel
- Lancement de Product Hunt et explications du fabricant
- Conseils de sécurité du protocole de contexte du modèle
- PostgreSQL documentation d'authentification client
Dernière révision le 26 juillet 2026. RoBrain évolue rapidement. Confirmez les intégrations actuelles, les commandes, les termes cloud, le traitement des données et les artefacts de référence avant utilisation en production.
