Comment créer un agent avec Agent Builder?

Agent Builder est l’outil visuel d’OpenAI pour concevoir des agents, lancé en bêta le 6 octobre dans le cadre d’AgentKit. Au lieu d’écrire une boucle en Python, vous placez des nœuds (des boîtes qui font chacune une tâche) sur un canevas et vous les reliez par des flèches. Le canevas fonctionne sur la même Responses API que les développeurs appellent depuis leur code, et son utilisation coûte les tarifs normaux de l’API pour les modèles et les outils en jeu.

Un agent, ici, est un flux de travail dans lequel un modèle de langage lit une demande, décide quoi faire, peut appeler des outils comme une recherche dans vos documents et produit un résultat. Agent Builder ajoute trois choses que les débutants sautent habituellement : des garde-fous (guardrails) pour bloquer ou nettoyer les entrées risquées, des exécutions d’aperçu (preview runs) pour observer chaque étape, et des évaluations (evals), c’est-à-dire des tests reproductibles qui notent les réponses de l’agent.

Planifier avant d’ouvrir le canevas

Mettez d’abord quatre choses par écrit. Que doit faire l’agent, exactement? De quelle information a-t-il besoin? Que ne doit-il jamais faire? Comment saurez-vous qu’il fonctionne? Pour notre exemple :

• Tâche : répondre aux questions des clients sur les retours pour une petite boutique en ligne.
• Information : le document de la politique de retour de la boutique.
• Jamais : promettre un remboursement hors de la politique ou demander des numéros de carte.
• Réussite : des réponses justes sur un ensemble de 10 questions de test, et un transfert poli à une personne quand la politique ne couvre pas le cas.

Un exemple concret : un flux d’aide pour les retours

Vous pouvez partir d’un canevas vierge ou de l’un des modèles d’OpenAI. Voici le flux de travail, nœud par nœud.

Les consignes de l’agent, tapées dans le nœud d’agent, pourraient se lire ainsi :

Tu aides les clients de Maple & Thread, une boutique de vêtements en ligne, pour leurs retours.
Réponds uniquement à partir du document de la politique de retour. Cite la règle pertinente en
une phrase, puis explique au client ce qu’il doit faire ensuite.
Si la politique ne couvre pas la question, ou si le client est fâché,
réponds : « Je transmets votre demande à un membre de notre équipe » et arrête-toi.
Ne demande jamais les renseignements d’une carte de paiement. Ne promets jamais un remboursement
que la politique ne permet pas.

Le nœud de garde-fous utilise la couche Guardrails d’OpenAI, à code source ouvert. Ses vérifications intégrées comprennent la détection du débridage (jailbreak), la détection des renseignements personnels, la modération, un filtre d’URL, une vérification des sujets hors propos et une vérification des hallucinations. N’activez que ce qui convient à la tâche; chaque vérification supplémentaire ajoute un peu de temps et de coût.

Le tester avant tout le monde

Utilisez les exécutions d’aperçu pour envoyer des messages d’exemple et observer le déclenchement de chaque nœud. Transformez ensuite votre critère de réussite en évaluation. Les outils Evals d’AgentKit vous permettent de constituer un jeu de données d’entrées de test, de noter des exécutions complètes (ce qu’OpenAI appelle la notation des traces, ou trace grading) et même de suggérer de meilleures consignes. Un petit jeu de données pourrait ressembler à ceci; les comportements attendus sont des illustrations :

Lancez l’ensemble après chaque changement. Agent Builder conserve les versions : si un nouveau jeu de consignes obtient un moins bon résultat, revenez au précédent.

Publication et supervision

Quand le flux de travail réussit les tests, publiez une version. Pour le mettre devant les clients, OpenAI propose ChatKit, une trousse d’outils pour intégrer une interface de clavardage à un site Web ou à une application. Continuez à surveiller après le lancement : lisez chaque semaine un échantillon de vraies conversations, ajoutez tout nouvel échec à l’ensemble d’évaluation et gardez une personne disponible pour les transferts.

Au lancement, OpenAI a cité des clients qui ont créé des agents rapidement; TechCrunch a rapporté qu’une ingénieure d’OpenAI avait construit sur scène un flux de travail à deux agents en moins de huit minutes. La rapidité de création est réelle, mais c’est aux tests qu’il faut consacrer le temps.

Quand devriez-vous plutôt passer au code?

Restez dans Agent Builder tant que le flux de travail est une suite claire d’étapes, que les outils dont vous avez besoin sont offerts sur le canevas et que les personnes qui l’examinent ne sont pas toutes des programmeurs. Un diagramme est plus facile à lire qu’un fichier Python pour un gestionnaire de produit ou un juriste.

Passez au code quand vous avez besoin d’une logique que le canevas exprime mal, comme des boucles complexes, un traitement de données sur mesure ou des appels à vos propres systèmes internes. Le code a aussi du sens quand vous voulez soumettre l’agent aux pratiques logicielles habituelles : conservé dans Git, testé automatiquement à chaque changement et déployé sur vos propres serveurs. L’Agents SDK d’OpenAI, lancé en mars, est la voie qui passe par le code, et le paquet Guardrails est offert comme bibliothèque pour Python et JavaScript : les mêmes vérifications de sécurité peuvent donc vous suivre. Sa version Python peut envelopper le client OpenAI standard ou se greffer à un agent de l’Agents SDK.

Gardez en tête qu’Agent Builder est en bêta : ses fonctions peuvent changer. Beaucoup d’équipes esquisseront et testeront sur le canevas, puis reconstruiront le tout en code une fois la conception stabilisée.