Présentation

Les équipes commencent souvent à développer des agents de la même manière qu'elles développent d'autres fonctionnalités web : en encapsulant le modèle dans un gestionnaire de route, en analysant la requête et en attendant la réponse. Cependant, cette approche est fragile et ne convient pas pour une utilisation en production.

Les agents sont des processus longs, étatiques et non déterministes. Ils appellent des outils, attendent des API externes, se divisent en sous-tâches, atteignent des limites de taux et crashent au milieu de séquences multi-étapes. Si votre agent est lié à une seule requête HTTP, vous avez couplé la fiabilité de votre application au temps de l'horloge d'une boucle non déterministe.

Contexte technique

Les agents ont des propriétés qui les rendent hostiles aux architectures web naïves. Ils sont longs, étatiques et non déterministes. Un agent peut prendre des heures ou même des jours pour se terminer. Les agents sont également étatiques, ce qui signifie qu'une exécution n'est pas une simple appel de fonction, mais plutôt un objectif, un plan, des appels d'outils et des sorties, des réessais, des erreurs, des décisions et une sortie finale.

Les agents sont non déterministes, ce qui signifie que le modèle choisit la prochaine action au moment de l'exécution, ce qui rend la récupération, la répétition et le débogage plus difficiles. Une exécution peut prendre trois étapes ou trente, elle peut se diviser en plusieurs outils, attendre une intervention humaine, produire de grands artefacts intermédiaires ou s'arrêter prématurément.

Modèles d'infrastructure

Il existe plusieurs modèles d'infrastructure pour les applications à agents. Le premier modèle est le modèle file d'attente-travailleur, où la requête crée un enregistrement d'exécution durable, met le travail en file d'attente et retourne immédiatement. Cela donne à l'application une frontière simple : l'API met le travail en file d'attente, la file d'attente stocke le travail de manière durable et le travailleur exécute le travail.

Un autre modèle est le modèle de workflow, où un moteur de workflow fournit une orchestration pour les agents. Ce modèle est utilisé lorsque les exécutions sont complexes et nécessitent une coordination étroite entre les différentes étapes.

Fiabilité et récupération

La fiabilité et la récupération sont des aspects critiques pour les applications à agents. Les agents doivent être conçus pour survivre aux échecs et aux réessais. Deux disciplines sont essentielles pour la fiabilité : l'idempotence et la compensation. L'idempotence signifie que les appels d'outils doivent être conçus pour être sûrs en cas de réexécution. La compensation signifie que les effets secondaires des appels d'outils doivent être inversés en cas d'échec.

idempotence = check_for_completed_record + upsert_running_record + call_tool + mark_complete

La compensation est nécessaire pour les agents qui touchent des services distants. Les agents doivent être conçus pour gérer les échecs et les réessais de manière sûre et fiable.