Propositions et validation
Comment les modifications d’ElevenAgents Architect sont testées, examinées et déployées sur le trafic en direct.
Vue d’ensemble
Lorsqu’ElevenAgents Architect termine une modification, il vous la remet sous forme de proposition : une branche qui contient la modification, des tests qui démontrent qu’elle fonctionne et une proposition de fusion demandant la fusion de cette branche dans main. Cette page explique le fonctionnement de chaque élément, où le trouver et comment une proposition passe d’une conversation au trafic en production.
Qu’est-ce qu’une proposition ?
Une proposition s’appuie sur le modèle existant de gestion des versions :
La proposition de fusion est une proposition de fusion ElevenAgents standard, du même type que celle qu’un collègue ouvre manuellement. Ce n’est pas un type d’objet distinct.
Une proposition de fusion couvre exactement une branche source et une branche cible. Chaque proposition contient donc une solution candidate. Pour comparer plusieurs options, demandez à Architect de placer chacune sur sa propre branche. Chaque branche obtient alors sa propre proposition, et vous pouvez répartir le trafic entre elles dans le cadre d’une expérience.
Architect agit en votre nom. Une proposition de fusion qu’il ouvre est donc enregistrée sous votre nom en tant qu’auteur. Aucun champ n’indique qu’Architect l’a créée. Mentionnez-le dans la description de la proposition si votre équipe souhaite le savoir.
Création d’une proposition
Architect crée une proposition lorsque vous lui demandez de corriger ou d’améliorer un élément, ou lorsque vous lui transmettez un test en échec, un constat Spotlight ou un problème. La séquence complète, avec les outils appelés par Architect à chaque étape, figure dans l’exemple détaillé. En résumé :
- Architect enquête, crée une branche et prépare la modification dans votre brouillon sur cette branche.
- Architect rédige des tests et des simulations pour la modification, puis les exécute dans la conversation avant de vous présenter le résultat.
- Architect ouvre la boîte de dialogue de publication. Vous examinez le diff et sélectionnez Publier, ce qui valide la modification sous la forme d’une nouvelle version sur la branche.
- Architect ouvre une proposition de fusion vers
mainet rédige sa description à partir des validations et exécutions de tests réelles de la branche. - Architect propose d’envoyer une faible part du trafic en production vers la branche pendant l’examen de la proposition. Cela requiert votre approbation.
Vous pouvez vous arrêter à n’importe quelle étape. Une branche avec une version publiée mais sans proposition de fusion reste utile : vous pouvez la tester vous-même ou ouvrir une proposition ultérieurement.
Validation dans la conversation
Architect rédige et exécute les tests lors de la création de la modification, et non lors d’une étape distincte que vous lancez par la suite. Pour une correction, une approche utile consiste à démontrer que les nouveaux tests échouent sans la modification et réussissent avec elle. Architect peut exécuter les mêmes tests sur la branche d’origine et sur le brouillon qui contient la modification.
Architect n’exécute pas automatiquement cette vérification avant/après pour chaque modification. Demandez-la lorsqu’elle est importante, par exemple : « Montrez-moi la nouvelle simulation en échec sur main et réussie sur la branche, puis ouvrez une proposition. »
Un test réussit lorsque toutes les conditions de réussite sont remplies. Pour un test LLM, la réponse de l’agent satisfait les critères de réussite. Pour un test d’appel d’outil, l’outil attendu est appelé avec les paramètres attendus. Pour une simulation, la conversation simulée remplit ses conditions de réussite. Pour vérifier l’absence de résultats instables, demandez à Architect d’exécuter les tests plusieurs fois. Il peut répéter chaque test jusqu’à 50 fois et communiquer le taux de réussite.
Consultez Tests pour savoir comment chaque type de test est défini.
Où trouver les propositions
Ouvrez l’agent, puis accédez à Contrôle de version > Propositions. Vous pouvez filtrer la liste par statut, par auteur (Créé par) et par réviseur (En attente de révision par, Révisé par). Une proposition ouverte par Architect dans votre conversation vous indique comme auteur.
Architect renvoie également un lien vers la proposition dans la conversation dès sa création.
Anatomie d’une proposition
La page d’une proposition affiche les branches source et cible, son statut, si elle peut être fusionnée et le retard ou l’avance de la branche source par rapport à la cible. Elle comporte les onglets suivants :
Vue d’ensemble
Modifications
Exécutions de tests
Conversations
La description, une chronologie d’activité des validations sur la branche source, des révisions et des commentaires, ainsi qu’un champ de commentaire. La barre latérale affiche les réviseurs, les réviseurs recommandés et tout problème associé.
Une description rédigée par Architect comporte toujours trois sections : Résumé (chaque modification importante et sa raison), Tests (les tests exécutés et leurs résultats, ou l’indication qu’aucun test n’a été exécuté) et Comment réviser (les points à examiner et un test à exécuter ou une conversation à essayer).
Révision et fusion
Statuts
Une proposition de fusion présente l’un des statuts suivants :
Lorsqu’une proposition est ouverte, la dernière révision de chaque réviseur est soit Approuvée, soit Modifications demandées. Il n’existe pas de statuts distincts « testé » ou « prêt pour révision ». Les résultats des tests sont affichés dans l’onglet Exécutions de tests.
Les révisions et les commentaires apparaissent dans la chronologie d’activité de l’onglet Vue d’ensemble, à côté de chaque nouvelle version validée sur la branche source.
Qui peut approuver et fusionner
- Toute personne disposant d’un accès éditeur à l’agent peut réviser une proposition, à l’exception de son auteur. Architect agissant en votre nom, vous ne pouvez pas approuver une proposition qu’il a ouverte dans votre conversation. Un collègue doit le faire.
- Une proposition peut être fusionnée dès lors qu’elle a reçu au moins une approbation d’une personne autre que l’auteur et qu’aucune dernière révision de réviseur n’est Modifications demandées. Les administrateurs du Workspace peuvent fusionner sans approbation.
- La fusion dans une branche protégée requiert des autorisations d’administrateur ou l’approbation d’un administrateur.
Architect ne peut pas approuver, commenter, fusionner ou fermer une proposition de fusion. Ces étapes sont toujours réalisées par des personnes. Consultez Propositions de fusion pour connaître l’ensemble des règles de révision.
Architect peut fusionner directement une branche, sans proposition, lorsque vous le lui demandez et que votre rôle autorise
la fusion. En mode Approbation requise, il demande d’abord votre accord. En mode Approbation automatique, ce n’est pas le cas. Utilisez
la protection des branches sur main si chaque modification doit passer par une proposition révisée.
Ce qui se passe lors de la fusion
Il n’y a pas d’étape de publication distincte après une fusion. La fusion écrit une nouvelle version sur la branche cible, et cette version sert immédiatement le trafic en production pour la part de trafic reçue par la cible. Lorsque la cible est main et qu’aucune répartition du trafic n’est définie, cela concerne tous les appelants.
La fusion :
- Transfère vers la cible toute part de trafic en production détenue par la branche source.
- Archive la branche source par défaut.
- Ferme toute autre proposition ouverte provenant de la même branche.
- Résout le problème associé, le cas échéant.
Déploiement progressif
Avant la fusion d’une proposition, vous pouvez envoyer une part du trafic en production vers sa branche afin que de vrais appelants testent la modification.
Lancer la répartition
Demandez par exemple à Architect : « Envoyez 5 % du trafic vers cette branche. » Architect vous indique la répartition
finale complète, y compris la part de main, et demande votre approbation avant de l’appliquer. Vous pouvez
également la définir vous-même : dans Contrôle de version > Branches, sélectionnez Déployer sur la branche.
Observer les résultats
Ouvrez l’onglet Conversations de la proposition pour lire les conversations sur la branche, ou demandez à Architect
de comparer les résultats de la branche avec ceux de main.
Promouvoir ou annuler
Pour promouvoir la branche, fusionnez la proposition. La part de trafic de la branche est transférée avec elle vers main. Pour annuler,
demandez à Architect de définir la part de la branche à 0 %, ou modifiez vous-même le déploiement. Le
trafic en production revient immédiatement vers main.
Le total des parts de trafic doit toujours être de 100 %, et le routage est déterministe pour chaque conversation. Modifier la part d’une branche protégée, notamment en retirant du trafic à un main protégé, requiert un administrateur. Consultez Déploiement du trafic.
Propositions proactives
Architect produit des propositions lorsque vous le lui demandez, ou lorsque vous lui transmettez un test en échec, un constat Spotlight, une alerte ou un problème. Il n’analyse pas encore vos agents selon une planification et n’ouvre pas de propositions de lui-même.
Aujourd’hui, le parcours proactif passe par Spotlight, suivi d’un transfert. Spotlight surveille en continu les conversations de votre agent. Il produit un résumé hebdomadaire avec des investigations suggérées, déclenche des alertes en temps réel et recommande des modifications de configuration. Pour transformer un constat Spotlight en proposition :
Choisir un constat
Ouvrez le résumé hebdomadaire et examinez les Prochaines étapes suggérées, ou ouvrez une alerte en temps réel.
Le transmettre à ElevenAgents Architect
Sélectionnez Ouvrir dans Architect sur une suggestion, Analyser avec Architect sur le résumé ou Examiner avec Architect sur une alerte. Architect reçoit le constat et reçoit pour instruction de le vérifier à partir de conversations réelles et d’identifier la branche concernée avant de proposer une modification.
Les problèmes fonctionnent de la même manière. Votre agent en production peut signaler des problèmes à réviser pendant les conversations, et Discuter avec Architect sur un problème lance son investigation.
Des automatisations planifiées, avec des rapports envoyés vers une boîte de réception Architect, sont en cours de développement. L’onglet Boîte de réception de la page Architect leur est réservé.