Une intervention humaine encadrée par des contrats
Cette note technique décrit l’architecture de l’assistant IA dans Curling IO v3. Elle s’adresse aux ingénieurs logiciels et aux autres personnes qui conçoivent des systèmes d’agents. Elle approfondit Rust, la persistance, l’autorisation et le traitement des échecs davantage que nos articles habituels sur le produit.
Le schéma habituel d’intervention humaine dans un agent IA ressemble à ceci : le modèle demande un appel d’outil, l’environnement d’exécution de l’agent s’arrête, une personne approuve l’appel, puis l’exécution reprend pour permettre à l’outil de s’exécuter.
C’est une conception généraliste raisonnable. Elle est aussi plus stricte que de laisser simplement un agent appeler tous les outils qu’il voit. Pour Curling IO, nous voulions exposer au modèle la plus petite surface possible et placer un garde-fou contrôlé par l’application sur chaque chemin menant à une écriture. Cela nous a amenés à poser une question plus stricte :
Si l’application possède déjà les détails exacts de l’appel, pourquoi redonner le contrôle à l’agent?
Au moment où nous demandons à un gestionnaire de club d’approuver une opération, Curling IO a analysé la requête du modèle, résolu chaque valeur par défaut, vérifié l’état actuel de l’application, produit un aperçu fixe et conservé les arguments exacts. Le modèle n’a plus rien d’utile à apporter à l’exécution. Nous ne le laissons donc pas exécuter l’opération et ne le relançons pas simplement pour donner suite à l’approbation.
L’agent propose. L’application transforme cette proposition en contrat. Une personne approuve le contrat. Rust l’exécute.