Modes d'exécution
Le mode d'exécution détermine quelle machine exécute les sessions de votre agent : la boucle de l'agent, le code de vos outils et vos hooks. Vous avez trois options :
- Local, in-process : l'agent s'exécute dans votre programme. Chaque session vit dans votre processus et se termine avec lui.
- Auto-hébergé (
agents serve) : vous exécutez un worker, un processus de longue durée qui exécute les sessions, sur votre propre machine ou cluster, et le code de vos outils s'exécute là. Le plan de contrôle de Mistral stocke toujours les sessions et route chacune vers un worker, et Mistral sert les appels au modèle. - Managé par Mistral (
agents deploy) : Mistral construit votre projet depuis git et exécute le worker pour vous. Les sessions se comportent comme en auto-hébergé, sans rien à héberger.
La définition de l'agent et les appels de session sont les mêmes dans tous les modes : start_session(),
session.run(), turn.result(), turn.steer(), turn.interrupt() et session.cancel().
Si vous découvrez le SDK, ou si vous construisez encore l'agent, exécutez-le en local : il n'y a rien à configurer, et vous voyez chaque modification immédiatement. Déployez-le avec Studio quand une session doit survivre au programme qui l'a lancée : une tâche qui dure des heures, une approbation à laquelle une personne répond le lendemain matin, une application qui part et revient.
Choisissez agents serve quand vos outils doivent s'exécuter dans votre réseau, près de vos données, ou via votre propre
processus de déploiement. Choisissez agents deploy pour tout le reste en production : les mêmes sessions, sans
rien à maintenir en marche, au prix d'un déploiement depuis un dépôt git.
Comparer les modes
| Local, in-process | Auto-hébergé | Managé par Mistral | |
|---|---|---|---|
| Lancez-le avec | agents.Agent(...) dans votre code, ou agents chat | agents serve | agents deploy |
| Votre application obtient l'agent avec | l'Agent qu'elle construit | Agent.load_from(agent_name=...) | Agent.load_from(agent_name=...) |
| Ce que vous opérez | votre programme | votre programme et le processus agents serve | votre programme |
| Vos outils s'exécutent dans | votre processus | votre processus agents serve | l'infrastructure de Mistral |
| Où la session est conservée | dans la mémoire de votre processus, ou sur disque avec le journal expérimental | stockée par Mistral | stockée par Mistral |
| Traçage dans Mistral Studio | désactivé | activé par défaut, avec le contenu des prompts et des complétions | activé par défaut, avec le contenu des prompts et des complétions |
| Quand le processus s'arrête ou plante | la session est perdue, sauf si elle est sauvegardée avec le journal expérimental | le tour reprend en général : voir plus bas | le tour reprend en général : voir plus bas |
| Idéal pour | le développement, les tests, les scripts | la production sur une infrastructure que vous contrôlez | la production sans rien à héberger |
Durabilité
Une fois déployée, la session est durable : chaque appel au modèle et chaque appel d'outil terminé est enregistré, et la
session survit au worker. Quand le worker s'arrête pendant un tour, le tour reprend en général à sa
dernière étape terminée dès qu'un worker est de retour. Il peut aussi échouer, ou rester Running jusqu'à sa limite de temps.
Le travail en cours au moment où le worker s'est arrêté a un résultat inconnu. Un appel au modèle est refait. Un appel d'outil ne l'est pas : environ une minute plus tard, le modèle reçoit une erreur pour cet appel, et il peut rappeler l'outil. Un outil avec des effets de bord peut donc s'exécuter deux fois, et doit être idempotent : un appel répété avec la même entrée a le même effet qu'un seul appel. Un hook peut aussi s'exécuter à nouveau : gardez donc vos hooks idempotents.
Pour rendre un outil idempotent, envoyez au service qu'il appelle une clé d'idempotence dérivée de la requête, comme l'identifiant de commande pour un remboursement. Le service reconnaît une clé répétée et renvoie le premier résultat au lieu d'agir à nouveau. Si le service n'accepte pas de clé, enregistrez d'abord la clé dans un stockage qui refuse un second enregistrement pour elle, comme une table avec une contrainte d'unicité, et n'agissez que si votre enregistrement est nouveau. Une simple vérification « est-ce déjà fait ? » ne suffit pas : deux appels simultanés peuvent tous deux la passer. Tout ce qu'un outil garde dans la mémoire du worker, comme une variable globale de module ou un cache, est perdu avec le worker.
Dans votre processus, aucun worker ne revient : quand le processus s'arrête, la session est perdue.
Humain dans la boucle. Comme la session est durable, elle peut se mettre en pause pour attendre une intervention humaine, comme une approbation ou une réponse, et reprendre quand celle-ci arrive, sans garder de processus en marche. Chaque attente a une limite de temps, 1 heure par défaut. Voir Délai d'approbation.
Étapes suivantes
- Local, in-process : exécuter des sessions dans votre processus, terminer les sessions locales, et les conserver après la fin du processus.
- Auto-hébergé :
agents serve: exécuter l'agent sur votre propre infrastructure, et vérifier ce que la CLI charge depuis votre projet. - Managé par Mistral :
agents deploy: déployer sur Mistral avec votre propre Dockerfile, vos secrets, le traçage Studio et l'usage des tokens. - Cycle de vie de l'agent : essayer, opérer, mettre à jour et arrêter un agent déployé.
- Cycle de vie et liste des sessions : terminer une session, ses limites, et lister vos sessions.