Évaluer les backends d'agents : un cadre ouvert de condition physique

Lors du lancement de ce blogue, nous avions annoncé que l'une de nos premières publications serait le cadre que nous utilisons pour évaluer les backends d'agents. Le voici : le système de niveaux et la grille d'évaluation que Cloister applique avant qu'un backend ne soit routé vers des travaux à conséquences, extraits de notre documentation interne et publiés ici en entier.

Nous le publions comme une proposition de standard ouvert, non comme du marketing. Alors que les équipes passent d'un modèle unique de confiance à des flottes de backends — modèles variés, agents en ligne de commande, déclinaisons hébergées — il n'existe aucun vocabulaire partagé pour la question qui compte vraiment : non pas quel backend est généralement capable, mais quel backend est apte à quelle classe de travail sous gouvernance. Nous préférons contribuer le mètre étalon et laisser les autres le critiquer et l'enrichir plutôt que de le garder interne. Rien ici n'est propre à l'architecture de Cloister ; les niveaux et la grille s'appliquent partout où un orchestrateur doit décider quel agent mérite sa confiance pour quel travail.

Deux backends peuvent satisfaire la même interface d'agent et différer fortement par leur taux de réussite, la qualité des artefacts de porte, la fiabilité des sorties structurées, la sécurité de l'usage des outils, la complétude de la télémétrie, le comportement de récupération sous rejeu, le coût et la latence, ainsi que l'attention d'opérateur qu'ils exigent. La compatibilité d'interface dit qu'un backend peut être branché. Elle ne dit rien sur le fait qu'il le devrait.

La bonne unité d'évaluation n'est donc pas le backend seul. C'est la combinaison de la classe de tâche, du backend et de la rubrique : la performance d'un backend précis sur une classe de travail précise selon un standard précis. Tous les backends n'appartiennent pas à toutes les lanes.

Une distinction ancre tout le cadre. Certaines propriétés doivent rester invariantes quel que soit le backend en cours d'exécution : l'application des contraintes de loi, de politique et de règle ; l'arrimage de la rubrique pour toute la vie de la tâche ; la persistance des capteurs et la sécurité de rejeu ; la piste d'audit et le suivi de provenance ; la sémantique des points de contrôle humains ; et le comportement outbox et réconciliation pour les travaux déclarés non idempotents. Si un backend ou un chemin d'intégration ne peut pas préserver ces invariants, il n'est pas simplement de moindre qualité — il est incompatible avec l'exécution gouvernée, point final.

Tout le reste varie nécessairement selon le backend : qualité des complétions, suivi des instructions sous contrainte, disposition à produire les artefacts requis, exactitude des sorties structurées, précision des appels d'outils, latence, coût en jetons et en API, signatures de surveillance de santé, et nombre d'interventions humaines requises. Cette variance n'est pas un cas limite. C'est une caractéristique centrale de l'exploitation d'une flotte hétérogène de backends, et tout l'objet de l'évaluation est de la rendre visible plutôt que de la découvrir en production.

Nous classons chaque backend dans l'un de trois niveaux explicites.

Le niveau 1, Natif, rassemble les backends qui prennent en charge directement les sorties structurées, propagent les identifiants d'opération ou l'idempotence, émettent une télémétrie riche, s'intègrent proprement aux frontières d'usage d'outils et de provenance, et appuient le modèle de récupération sans adaptation destructive. Ce sont les backends principaux pour les travaux à conséquences : les cibles de routage privilégiées, et le seul niveau admissible aux classes de tâches sensibles.

Le niveau 2, Compatible-gouverné, couvre les backends qui satisfont tous les invariants de gouvernance requis, mais qui peuvent perdre des capacités optionnelles comme le streaming ou une télémétrie riche, exiger des adaptateurs pour les sorties structurées ou les métadonnées d'outils, et se rétablir avec plus de friction ou moins d'observabilité. Ce sont des backends secondaires : utilisables en secours limité et pour des classes de risque modéré, mais pas comme cible privilégiée.

Le niveau 3, Compatibilité au mieux, vise les backends techniquement branchables mais incapables de fournir de façon fiable certaines capacités importantes. Ils conviennent aux tâches à faible risque ou en lecture seule — exploration, analyses peu risquées — et ne devraient jamais être le défaut pour des travaux à fortes conséquences ni être admis pour des effets de bord significatifs.

Ces niveaux ne classent pas les fournisseurs. Le même backend peut être Natif dans une lane et Au mieux dans une autre. C'est une discipline de routage : elle force la question de l'aptitude à être répondue par classe de tâche plutôt que présumée à partir de listes de capacités.

Chaque backend à l'étude est évalué sur onze dimensions. Le premier groupe demande si le backend reste dans l'enveloppe de gouvernance : conformité de gouvernance (taux de passage des portes, rejet des actions interdites, complétude des artefacts) et performance de tâche (taux de réussite, acceptation par les réviseurs, taux de défauts).

Le deuxième groupe interroge le comportement à la frontière machine et sous défaillance : fiabilité des sorties structurées (taux de conformité aux schémas, taux d'échec d'analyse), sécurité de l'usage des outils (taux d'erreur outil, taux d'appels refusés, incidents d'effets de bord), comportement de récupération sous rejeu, réessai et repli (taux d'effets de bord dupliqués, exactitude du rejeu des capteurs, charge de réconciliation outbox), et préservation des capacités — ce qui se perd sur les chemins de secours ou d'adaptateurs, comme le streaming, la télémétrie ou la provenance.

Le troisième groupe demande si le backend est observable, économique et exploitable : observabilité (complétude de la télémétrie, couverture des traces, lisibilité de l'audit), profil de santé dans le temps (plancher de nouveauté, taux de dérive, fréquence des arrêts, fréquence des abstentions), coût (jetons médians, dollars par tâche réussie), latence (temps de complétion p50 et p95, attente aux portes) et charge d'opérateur (approbations par tâche, réconciliations manuelles, reprises par 100 exécutions).

Un mot sur les signaux de santé, faciles à mal lire. Si un backend provoque à répétition des avertissements de convergence, des abstentions, des échecs de porte ou des réconciliations manuelles, cela peut indiquer une inadéquation backend-tâche plutôt qu'un problème général du système. La santé doit être analysée par partition et par backend, pas seulement au niveau global.

Nous tenons une grille par lane — une classe de tâche précise évaluée contre une rubrique précise, sur un backend et un modèle précis. Chaque grille consigne la classification par niveau, une disposition parmi primaire, secours-seulement ou interdit, et les mesures obtenues : taux de réussite, taux de passage des artefacts de porte, taux de réussite des sorties structurées quand la tâche l'exige, incidents de récupération, réconciliations manuelles, latence médiane et coût par tâche réussie, plus des notes libres.

Un backend ne devrait pas être routé vers une classe de tâche à moins de démontrer, pour cette classe : l'absence de violation des invariants de gouvernance, un taux de réussite acceptable, une qualité acceptable des artefacts de porte, une fiabilité acceptable des sorties structurées si la tâche l'exige, une propagation acceptable des identifiants d'opération sur tout chemin non idempotent, et une complétude de télémétrie acceptable pour la surveillance de santé et l'audit.

L'échec sur ces points se traduit par une disposition explicite, non par un vague « moins bon » : primaire (le backend privilégié de la lane), secours-seulement (utilisable uniquement comme repli contraint) ou interdit (non permis pour cette classe de tâche ou cette rubrique). Rendre la disposition explicite, c'est ce qui transforme les résultats d'évaluation en politique de routage.

Commencez par définir la lane : déclarez la classe de tâche, la rubrique, le backend et sa variante de modèle ou de CLI, et indiquez si les effets de bord sont permis. Construisez ensuite un corpus de tâches fixe pour la classe, incluant des cas de réussite directs, des cas ambigus qui devraient déclencher des portes, des cas avec artefacts exigés par la politique, des cas qui devraient être refusés, et des cas de récupération impliquant réessai, rejeu, délai d'attente et secours. Sans corpus fixe, les comparaisons de backends dérivent vers l'anecdote.

Exécutez plusieurs essais et consignez la variance, pas seulement la moyenne — une comparaison sur un seul essai ne distingue pas un échec isolé d'un décalage récurrent. Testez la récupération explicitement en provoquant des défaillances à dessein : plantage après la réponse de l'agent mais avant la validation, dépassement de délai des capteurs, approbation humaine tardive, bascule vers un backend moins capable, outbox en attente à la récupération, livraison de notifications en double. Un backend n'est pas pleinement évalué tant que l'histoire de récupération n'a pas été exercée.

Évaluez enfin l'expérience d'opérateur. Certains backends sont techniquement conformes mais épuisants à exploiter. Consignez la fréquence des interventions humaines, leur compréhensibilité, la suffisance des commandes de récupération et l'utilisabilité des enregistrements d'audit sans lecture des journaux bruts.

L'une des règles les plus importantes du cadre concerne le secours : le secours n'est pas automatiquement plus sûr que l'échec. Un backend plus faible peut accroître le risque en abandonnant les sorties structurées, en émettant une télémétrie plus pauvre, en omettant les artefacts requis, en interagissant mal avec les outils ou en multipliant les interventions humaines. Chaque arête de secours devrait être évaluée comme une lane à part entière, jamais présumée valide parce que les deux extrémités implémentent la même interface.

Vous n'avez pas besoin de Cloister pour appliquer tout cela. Si vous routez du travail vers plus d'un modèle ou agent, vous pouvez adopter les trois niveaux comme vocabulaire de routage, bâtir une grille par lane pour vos propres classes de tâches, et écrire noir sur blanc la distinction invariant-variable de votre pile : quelles propriétés doivent tenir quel que soit le backend, et lesquelles varieront et devront donc être mesurées. La liste de champs de la grille ci-dessus est un point de départ ; les mesures sont ce qu'il faut adapter à votre domaine.

Nous traitons cela comme une proposition de standard ouvert, non comme un standard achevé, et nous le pensons : nous voulons des critiques, des rubriques alternatives et des grilles d'équipes exploitant des flottes que nous ne verrons jamais. Si vous appliquez le cadre, publiez vos résultats par lane ou dites-nous où les niveaux se trompent — la meilleure façon de l'améliorer est de le voir utilisé ailleurs qu'ici.

Une dernière affirmation, formulée avec le plus grand soin. Un substrat d'exécution gouverné au-dessus d'une flotte hétérogène de backends ne rend pas les agents interchangeables. Il rend leurs différences visibles, gouvernables et mesurables opérationnellement. C'est une affirmation plus forte et plus honnête que de prétendre que tous les backends sont équivalents dès qu'ils satisfont une interface — et c'est la prémisse que ce cadre existe pour éprouver, lane par lane, avec des preuves.