Aller au contenu principal

Agents et versions

Configurez l'agent, enregistrez une version, publiez-la. Une version ne change plus une fois enregistrée, et chaque exécution gèle ses droits et ses skills au moment où elle démarre.

La configuration​

Un agent porte cinq groupes de réglages.

  • Instructions : le prompt système, et facultativement un JSON Schema que la réponse doit respecter. Une réponse qui ne le valide pas est renvoyée au modèle, jusqu'à 3 fois, et l'exécution échoue si elle ne le valide toujours pas.
  • Modèles : le modèle principal, les modèles de repli, les paramètres d'échantillonnage (température, top-p, jetons maximum) et l'effort de raisonnement. Un paramètre que le modèle choisi n'accepte pas, selon le registre, est refusé à l'enregistrement, et seuls les efforts de raisonnement que le modèle publie sont proposés.
  • Garde-fous : les règles d'entrée, de sortie et de périmètre que le worker applique autour du modèle, et les plafonds de dépense d'une exécution : un plafond de coût, 1 USD par défaut, et un plafond de jetons facultatif, qui couvrent tous deux les sous-agents. Voir Garde-fous et Budgets et quotas.
  • Capacités : la délégation à des sous-agents, avec leur modèle, leur profondeur et leurs outils bloqués, et les types de pièces jointes que l'agent accepte, dans la limite de ce que l'instance autorise.
  • Droits : les collections qu'il peut interroger, les outils et serveurs MCP qu'il peut appeler, les secrets qu'utilisent ses outils, et les skills qu'il peut charger.

Les quatre premiers groupes forment une version. Les droits appartiennent à l'agent lui-même : une modification s'applique aux exécutions créées ensuite, quelle que soit la version qu'elles exécutent.

Versions et publication​

Enregistrer une version écrit la configuration dans une nouvelle version, avec son auteur, sa date et une note de modification. Les versions sont immuables, et la base de données refuse toute modification. Enregistrer une configuration identique à la version courante ne crée rien. Restaurer crée une nouvelle version dont le contenu est une copie d'une version plus ancienne : l'historique reste une ligne droite.

Publier… ouvre la liste des versions : choisissez-en une et déployez-la sur l'environnement Test ou Production, sur toutes les surfaces actives de cet environnement à la fois (widget, API, Slack). Publier une version plus ancienne permet de revenir en arrière, et ne crée pas de nouvelle version. Avec les contrôles de publication, un module Enterprise, le déploiement en Production peut d'abord exiger que les suites de tests de l'agent passent. L'enregistrement, la restauration et la publication sont tous consignés au journal d'audit.

Exécuter​

Une exécution épingle sa version et gèle ses droits à sa création. Le moteur enregistre chaque étape comme un événement en ajout seul, avec une clé d'idempotence : une panne suivie d'un rejeu produit le même résultat, sans effet de bord en double.

Les skills sont gelés par exécution, pas par version

Un skill n'est pas copié dans la version de l'agent. À la création d'une exécution, chaque skill attribué à l'agent est résolu dans sa version courante, et ses instructions comme ses capacités sont gelées dans les droits de l'exécution. Publier une nouvelle version d'un skill change donc les prochaines exécutions de tous les agents qui le reçoivent, même quand leur version n'a pas changé. Une exécution en cours garde ce qu'elle avait au départ.

Une exécution qui doit attendre se met en sommeil et ne retient aucun worker pendant l'attente : celle de ses sous-agents, de la fin d'une fenêtre de limite de débit chez un fournisseur, de la réponse du visiteur à une question, ou de la décision d'une personne quand le module Enterprise de validation humaine est utilisé. Elle reprend quand ce qu'elle attend arrive.