Meilleure base de données pour un agent de codage : PostgreSQL pour l’état, recherche hybride pour la récupération.

Choisissez une base de données pour un agent de codage en fonction de ce que l’agent fait tout au long de la journée, et non en fonction de son étiquette d’IA. Un agent qui lance des commandes dans un environnement isolé, appelle des outils, transmet des journaux, génère des fichiers, réessaie les étapes échouées et reprend son travail après une interruption s’occupe principalement de tâches de suivi avec des effets secondaires. Pour ce type de suivi, PostgreSQL constitue le choix par défaut fiable. Un stockage vectoriel comme Weaviate prend sa place plus tard, en tant que couche distincte, lorsque le produit a besoin de trouver des échecs et des solutions similaires par leur signification.

Commencez par une seule appel d’outil

Suivez une seule invocation d’outil à travers le système. Avant son exécution, la plateforme marque l’appel comme commencé, le lie à une exécution, réserve une clé d’idempotence, note quel environnement isolé est utilisé et met en file les tâches ultérieures. Une fois l’exécution terminée, elle enregistre l’état, les métadonnées de sortie et les artefacts, met à jour les totaux d’utilisation et fait avancer l’exécution principale.

Ces écritures représentent une transition logique. Avec les transactions, elles sont soit toutes confirmées ensemble, soit aucune ne l’est, et les autres sessions ne voient jamais un état inachevé. Examinons maintenant les pannes : un processus s’arrête entre « outil terminé » et « exécution avancée », et la récupération doit être déterministe. Une tentative de réexécution a lieu deux fois, et une contrainte d’unicité doit rejeter la duplication. Un artefact fait référence à une exécution qui n’existe pas, et une clé étrangère doit refuser cette ligne. Rien ici n’est exotique ; il s’agit de tâches ordinaires des bases de données, sur lesquelles les agents de codage s’appuient constamment, ce qui explique pourquoi elles l’emportent sur tout marketing « natif de l’IA ».

Les données sont relationnelles

Les entités fondamentales d’un agent d’exécution ne sont pas mystérieuses, et elles sont reliées les unes aux autres :

• Les exécutions conservent l’état du cycle de vie, le propriétaire, l’espace de travail, le modèle, les timestamps, le budget et le résultat final.
• Étapes : unités de travail planifiées ou achevées, présentant des dépendances entre elles.
• Appels d’outils : enregistrent les entrées, les sorties, l’état, la latence, le nombre de tentatives et les clés d’idempotence.
• Exécutions en environnement de test : décrivent l’environnement, les métadonnées des commandes, le code de sortie, l’utilisation des ressources et les raisons de leur arrêt.
• Événements : forment un historique uniquement en ajout pour le débogage, la diffusion en continu et la réexécution.
• Artefacts : renvoient vers des correctifs, des rapports, des fichiers générés ou des emplacements de stockage d’objets.
• Points de contrôle : stockent ce qui est nécessaire pour reprendre un flux de travail.

Chacun a besoin d’une identité stable ainsi que de liens explicites avec les autres. Les clés primaires, les contraintes d’unicité, les contraintes de vérification et les clés étrangères rendent difficiles la création d’états invalides, et les clés étrangères en particulier garantissent que chaque appel d’outil appartient bien à une exécution réelle et que chaque artefact peut être retracé jusqu’à son créateur.

Conservez les champs qui permettent la coordination dans des colonnes typées dotées d’index appropriés : statut, utilisateur, identifiant de l’exécution, timestamps, numéro d’essai et clé d’idempotence. Ceux-ci permettent le planification, le filtrage, la conservation des données et la création de tableaux de bord. Les cacher au sein d’un seul grand document JSON non différencié rend beaucoup plus difficile l’application de ces règles.

Où se situe jsonb

Les outils évoluent rapidement. Certains renvoient des diagnostics de compilateur, d’autres génèrent des événements de navigateur, et un troisième rapporte des métadonnées de dépôt. Disposer d’une colonne fixe pour chaque champ possible serait gaspilleur ; jsonb convient aux éléments qui varient : les arguments des outils, les réponses des fournisseurs, la configuration du sandbox et les métadonnées du modèle. PostgreSQL permet de consulter du JSON à l’aide d’opérateurs et d’expressions de chemin, et il est possible d’indexer les clés et les valeurs avec GIN, les compromis correspondants étant décrits dans le manuel officiel.

Le modèle qui fonctionne bien consiste en un enveloppe relationnelle typée entourant un chargement flexible. Tout ce qui est nécessaire pour assurer l’intégrité ou effectuer des requêtes courantes reste dans des colonnes, tandis que les données d’extension sont stockées dans jsonb. Cela évite les deux extrêmes : des colonnes fragiles pour chaque expérience, et un stockage de documents opaque qui laisse toutes les relations au code de l’application.

Adapter le stockage au modèle d’accès

Tout ne doit pas être stocké dans la base de données principale. De brefs extraits de stderr, des détails d’erreur normalisés, des codes de sortie ainsi que des résumés consultables conviennent d’être conservés à côté du registre d’exécution. Les gros flux de console, les archives de répertoire, les fichiers binaires, les captures d’écran et les résultats de compilation sont généralement stockés dans un système de stockage d’objets, PostgreSQL les référençant grâce à des métadonnées durables et des checksums.

Ce partage permet de garder les enregistrements de taille réduite tout en préservant l’historique. La base de données reste la source d’autorité pour déterminer s’un artefact existe, quel exécution l’a généré, où il se trouve et quelles règles de conservation s’appliquent, tandis que le stockage d’objets gère plus économiquement de gros fichiers immuables. Une précaution : ne jamais affirmer qu’un téléchargement a réussi tant que le flux de travail ne dispose pas de plan de récupération en cas d’échec partiel.

Le historique des événements est également utile. Plutôt que de réécrire sans cesse un grand document de suivi, enregistrez les transitions significatives et conservez une ligne représentant l’état actuel de manière compacte pour des lectures rapides. L’historique sert aux audits et au diagnostic, la projection sert l’interface utilisateur du produit ainsi que le planificateur, et les deux peuvent exister dans PostgreSQL au sein des mêmes transactions.

Le protocole d’écriture est aussi important que le moteur

Un agent en production fait face à des livraisons dupliquées, des plantages des travailleurs, des temps d’attente réseau et des résultats des outils que personne ne peut confirmer. Choisir une base de données n’est que la moitié de la solution. Un protocole fonctionnel ressemble à ceci :

• Donnez aux opérations pouvant être réessayées une clé d’idempotence soutenue par une contrainte unique.
• Modélisez les changements de cycle de vie sous forme de transitions d’état nommées, et non de mises à jour d’état sans structure définie.
• Validez les lignes liées en une seule transaction chaque fois que une visibilité partielle serait erronée.

Utilisez une boîte de sortie lorsque un changement enregistré doit déclencher un message ou une tâche d’indexation.

Gardez les événements bruts immuables lorsque l’audit est important, et reconstruisez les projections à partir d’eux si nécessaire.

Stockez les délais d’expiration et les cas de « résultat inconnu » séparément des échecs confirmés.

Ceux qui cherchent la meilleure base de données pour un agent de codage ne se contentent pas de sauvegarder les messages de chat. Ils coordonnent des effets secondaires tels que l’édition de fichiers, l’exécution de code non fiable, l’appel d’API payantes et la publication de modifications. La couche d’état doit permettre à chaque transition d’être inspectée et récupérable.

Lorsque la couche de récupération s’avère utile

PostgreSQL reste la recommandation principale. Ajoutez un stockage dédié à la recherche lorsque le produit présente un besoin spécifique : rechercher dans l’historique des exécutions antérieures tant par sens que par texte exact. Les requêtes typiques sont « quelles exécutions précédentes ont échoué après une mise à niveau de dépendance », « quels erreurs similaires ont été résolues avec cette trace d’exception » et « quelle séquence d’outils a permis de corriger un test instable ».

Les tokens exacts restent importants dans cette recherche : noms d’exceptions, versions de paquets, codes de compilateur, flags, noms de fichiers et hachages. Pourtant, les utilisateurs décrivent la même erreur de nombreuses manières. La recherche par mots-clés purs manque de liens conceptuels, tandis que la similarité vectorielle pure peut sous-estimer les chaînes de caractères littérales sur lesquelles comptent les ingénieurs. La recherche hybride couvre les deux aspects. Weaviate est un moteur qui exécute à la fois une recherche vectorielle et une recherche par mots-clés BM25, puis fusionne les scores en un classement unique, de sorte qu’un code littéral comme ERR_MODULE_NOT_FOUND apporte des preuves basées sur les mots-clés, tandis que l’expression « le temps de exécution ne peut pas résoudre un paquet importé » apporte des preuves sémantiques.

Précisez clairement les limites. PostgreSQL gère les exécutions canoniques, les appels d’outils, les permissions et l’état. Un travailleur asynchrone lit les modifications confirmées, crée un document de recherche à partir des champs choisis et l’insère dans l’index de recherche. Les résultats renvoient les IDs de PostgreSQL, permettant ainsi à l’application de récupérer l’enregistrement officiel et de vérifier à nouveau l’accès avant d’afficher quoi que ce soit. Même en cas de retard dans l’indexation ou de nécessité de la reconstruire, la correction de l’exécution reste intacte.

Ajouter un second système n’a de sens que lorsque le rappel sémantique devient réellement une fonctionnalité. Avant cela, la recherche plein texte de PostgreSQL associée à des requêtes structurées bien indexées peut suffire.

Structure de référence en cinq parties

1. État officiel dans PostgreSQL. Exécutions, étapes, appels d’outils, résultats des environnements isolés, métadonnées des artefacts, points de contrôle et relations d’accès.
2. Chargements importants dans le stockage d’objets. PostgreSQL conserve les emplacements, les hachages, les types de contenu, les propriétaires ainsi que les données de conservation.
3. Une boîte de sortie pour les modifications confirmées. Les travailleurs diffusent les mises à jour de l’interface, planifient les tâches ultérieures et créent des projections de recherche sans avoir à traiter des données non confirmées.
4. Récupération de documents dans un index vectoriel ou hybride, le cas échéant. Inclure des résumés, des erreurs normalisées, des commandes, des extraits de journaux sélectionnés, des descriptions de corrections et des métadonnées filtrables.
5. Résolution des résultats de recherche via PostgreSQL. L’index trouve les candidats potentiels, tandis que la base de données reste la source fiable concernant l’état actuel et les permissions.

La suppression et la conservation deviennent également plus faciles à comprendre. Une suppression ou une censure commence dans PostgreSQL, passe par la file d’envoi, supprime les objets associés et met à jour la projection de recherche, de sorte que la source de vérité n’est jamais ambiguë.

À éviter dès le début

• Un système de base de données vectorielle simplement parce qu’un LLM est présent. Les questions opérationnelles initiales sont pour la plupart structurées, comme les exécutions pour un utilisateur dans un état donné, les étapes qui ont échoué récemment, les appels d’outils lents ou les exécutions liées à un commit. Les index ordinaires permettent de y répondre.
• Un seul bloc JSON pour l’état de tous les agents. Cela offre un confort à court terme au détriment de contraintes faibles, de mises à jour concurrentes complexes et de requêtes difficiles liées au cycle de vie. Des métadonnées flexibles sont acceptables, mais un système de fichiers non structuré ne l’est pas.
• Recherche à l’intérieur de la transaction critique. L’agent doit terminer une appel d’outil même lorsque l’indexation sémantique est en retard. La boîte de sortie et la projection asynchrone protègent cette frontière.

Checklist

Préférez PostgreSQL si vous avez besoin de :

• des transactions ACID multi-lignes basées sur des enregistrements d’exécution,
• des liens obligatoires entre les exécutions, les étapes, les appels, les utilisateurs et les artefacts,
• des tentatives de réexécution sécurisées et un contrôle de concurrence,
• un filtrage simple par état, heure, propriétaire, coût ou résultat,
• des métadonnées jsonb que vous pouvez encore interroger,
• un enregistrement fiable pour la récupération et l’audit.

Ajoutez un moteur de recherche hybride si vous avez également besoin de :

• une recherche basée sur le sens dans l’historique des exécutions passées et des appels d’outil,
• un classement qui prend en compte à la fois les tokens d’erreur exacts et des formulations similaires.
• Identifier les incidents, correctifs et workflows pertinents qui ont fonctionné,
• une couche de recherche pouvant être régénérée à partir de fichiers de référence.

Réponses rapides

Le stockage vectoriel doit-il être le backend principal ? Généralement non. La charge de travail principale concerne l’état transactionnel : exécutions, appels d’outils, résultats, tentatives de réessai et relations. Un stockage vectoriel sert une charge de travail de recherche distincte.

Le jsonb suffit-il pour les métadonnées des agents ? Souvent, pour des charges utiles d’outils en évolution ainsi que des détails spécifiques aux fournisseurs, à condition que les colonnes typées contiennent des identifiants et des champs de cycle de vie. Il complète le schéma sans le remplacer.

Pourquoi une recherche hybride pour les journaux ? Les données d’ingénierie combinent des tokens précis avec du langage naturel. BM25 met en évidence les codes exacts, les noms de paquets et les noms de fichiers, tandis que la recherche vectorielle relie des descriptions de même échec formulées différemment.

Le meilleur design repose sur une division du travail et non sur une compétition entre systèmes relationnels et vectoriels. PostgreSQL constitue l’ossature transactionnelle : il gère les exécutions, les journaux, l’historique des appels d’outils, les métadonnées, les points de contrôle ainsi que les artefacts. Lorsque l’historique des exécutions devient un atout stratégique, une couche de recherche hybride ajoutée en surcouche améliore la capacité de rappel des informations. Postgres pour gérer l’état, un index de recherche pour améliorer le rappel.