Agents IA et utilisation des outils — Agents RAG et IA

Gains :

Définir un agent comme « modèle + outils + boucle » et décider quand il est nécessaire
Écrire la définition de l'outil avec le nom, la description et input_schema
Surveillance du flux et de la gestion des erreurs de la boucle tool_use et tool_result

Jusqu'à présent, le modèle n'a toujours fait qu'un seul travail : recevoir une saisie de texte, produire des réponses textuelles. Mais le vrai travail nécessite souvent plus qu’un simple texte ; effectuer un calcul, interroger une base de données, appeler une API, connaître un taux de change actuel. Le modèle ne peut pas faire ces choses elle-même, mais elle peut décider quand elles doivent être faites et demander à quelqu'un de les faire. C’est ce que l’utilisation des outils donne au modèle, et c’est la base des agents IA. Dans cette unité, nous apprendrons ce qu'est un agent, comment l'outil est défini et comment fonctionne la boucle tool_use.

Qu'est-ce qu'un mandataire ? Modèle + Outils + Boucle

Un agent IA se compose de trois parties : le modèle (le cerveau qui prend la décision), les outils (les fonctions que le modèle peut appeler : météo, requête de base de données, envoi d'e-mails) et la boucle (la boucle ; le modèle appelle l'outil, obtient le résultat, décide à nouveau quoi faire, et ainsi de suite).

Distinction critique : un seul appel de modèle n'est pas un agent. L'agent est un processus dans lequel le modèle procède étape par étape, choisissant à chaque étape le prochain mouvement en fonction du résultat de l'outil. "Pensez comme un humain, utilisez vos mains, regardez le résultat, détrompez-vous."

Un fait important : le modèle lui-même ne fait pas fonctionner le véhicule. Le modèle dit simplement "Je veux appeler cet outil avec ces entrées". Votre application (appelée harnais) exécute l'outil et renvoie le résultat au modèle. Ceci est vital pour la sécurité : le modèle ne touche pas directement votre système ; Chaque action est sous votre contrôle.

Conseil : N'essayez pas de résoudre tous les problèmes avec l'agent. Agent; augmente le risque de retards, de coûts et d’erreurs. Demandez d'abord : « Ce problème sera-t-il résolu par un seul appel ou un flux de travail fixe ? » Si la réponse est oui, il n’est pas nécessaire de recourir à un agent. L'agent est destiné aux tâches ouvertes dont les étapes ne peuvent pas être connues à l'avance.

Définition de l'outil : nom, description, input_schema

Pour introduire un outil dans le modèle, vous donnez trois choses :

nom : identité du véhicule, par ex. get_weather.
description : ce que fait l'outil et quand l'appeler. C’est le domaine le plus important qui permet au modèle de choisir le bon outil au bon moment. Écrivez non seulement « ce qui fait », mais aussi « appeler quand ».
input_schema (schéma d'entrée) : schéma JSON qui définit les paramètres attendus par l'outil, dans quel type.

# Définition du véhicule (conceptuel — schéma JSON){ "name": "get_order_status", "description": "Récupère l'état d'expédition actuel d'une commande. Appeler lorsque l'utilisateur demande où se trouve un numéro de commande ou quand il arrivera.", "input_schema": { "type": "object", "properties": { "order_no": {"type": "string", "description": "Order number, e.g. SP-1024"} }, "obligatoire": ["order_no"] }}

Règles pour une bonne description de l'outil : nom clair et concis, description avec "quand l'utiliser", description de chaque paramètre, en mettant les véritables obligatoires en obligatoire. Gardez le nombre de véhicules concentré ; Des dizaines de modèles de véhicules similaires sont surprenants.

zone

Qu'est-ce que ça fait ?

bon exemple

mauvais exemple

nom

Identifiant du véhicule

order_status_getir

apporter

descriptif

Ce qu'il fait + quand appeler

"Renvoie le statut de la cargaison ; appelez lorsque l'utilisateur demande où se trouve la commande"

"récupère les données"

schéma_d'entrée

Type de paramètre et exigence

{order_no : chaîne, annotée}

pas de schéma / pas de description

tool_use → tool_result Boucle

Le cycle fonctionne comme ceci, étape par étape :

Vous envoyez la question utilisateur + les descriptions des outils au modèle.
Le modèle répond directement ou génère un bloc tool_use : "appelez order_durumu_getir avec order_no=SP-1024."
Votre application exécute réellement l'outil (interroge la base de données).
Vous renvoyez le résultat au modèle sous le nom tool_result.
Avec ce résultat, le modèle produit la réponse finale ou appelle un autre outil. Le cycle continue jusqu'à ce que le modèle dise « J'ai terminé ».

# Boucle d'agent (conceptuel)messages = [user_question]while True : réponse = model.uret(messages, tools=tool_definitions) if réponse.tur == "tool_use": result = harnais.run(response.tool_name, réponse.entries) # L'APPLICATION exécute des messages += [response, tool_result(result)] # renvoie le résultat sinon : break # réponse finale ; la boucle se termine

Les SDK modernes proposent des outils d'exécution qui exécutent cette boucle pour vous ; vous écrivez simplement les fonctions de l'outil. Mais c’est exactement ce qui se passe dans les coulisses.

Gestion des erreurs

Les outils peuvent échouer : commande introuvable, l'API expire, la saisie n'est pas valide. Si vous ne pouvez pas exécuter l'outil, renvoyez l'erreur au modèle sous la forme d'un résultat d'outil descriptif ("erreur : numéro de commande SP-9999 introuvable") et de l'indicateur d'erreur. Le modèle peut voir cela et l'expliquer doucement à l'utilisateur, ou essayer une autre manière. N'avalez pas l'erreur et renvoyez des résultats vides ; Le modèle doit savoir ce qui n’a pas fonctionné.

Description du véhicule faible/fort

Faible (nom indéfini, pas de « quand ») :

nom : "données", description : "récupère les données"# Le modèle ne sait pas quand et comment appeler ; Soit il n'appelle pas du tout, soit il appelle incorrectement.

Strong (nom du réseau + quand + description du paramètre) :

nom : "musteri_bakiyesi_getir"description : "Renvoie le solde actuel du compte d'un client. Appelez lorsque l'utilisateur demande un débit, un crédit ou un solde. N'effectue PAS de paiement."input_schema : {custeri_id : string ("ID client")}# Le modèle appelle au bon moment, avec les bons paramètres, connaissant sa limite.

Trois mini-étuis

Cas 1 — Agent inutile. Une équipe a construit l'activité « résumer du texte » avec un agent multi-outils ; Chaque récapitulatif prend 4 appels de modèle et 9 secondes. Le travail était en fait un travail sur appel unique. Lorsque nous avons supprimé l'agent et l'avons réduit à un seul appel, le temps a été réduit à 1,5 seconde et le coût à un quart. Leçon : utilisez l'agent lorsque cela est vraiment nécessaire.

Cas 2 — Explication faible, mauvais appel. Chez un agent de support, un outil obscur appelé fetch a été appelé au hasard par le modèle à la fois dans la question du solde et dans la question de l'expédition. Lorsque les véhicules ont été divisés en balance_getir et cargo_durumu_getir et que des explications « appeler quand » ont été ajoutées, la mauvaise sélection de véhicule a diminué de 18 à 1 sur 50 exemples.

Cas 3 — Erreur avalée. Un agent renvoyait des résultats vides alors que la commande n'était pas trouvée ; Le modèle a interprété cela comme « la commande a été livrée » et a induit le client en erreur. Lorsque le message d'erreur est écrit explicitement dans tool_result ("commande introuvable"), le modèle dit correctement "Je n'ai pas trouvé ce numéro, pouvez-vous le vérifier ?" commença-t-il à dire.

Erreurs courantes

Tout confier à un agent : même si un seul appel suffit, l'agent ajoute des coûts et des délais.
Description vague du véhicule : le modèle ne sait pas quand appeler ; choisit mal.
Penser que le modèle fait rouler le véhicule : Le harnais fait rouler le véhicule ; le modèle veut juste.
Avaler l’erreur : le modèle doit savoir ce qui n’a pas fonctionné ; Donnez l'erreur comme open tool_result.
Trop de véhicules similaires : le modèle est confus ; Gardez l’ensemble d’outils concentré et minimal.

Attention : Ce n'est pas parce que le modèle dit « appelez ce véhicule » qu'une mesure doit être prise. Sur les outils destructeurs (suppression, extraction, courrier électronique), votre application ne doit pas exécuter aveuglément l'appel — c'est le cœur du sujet sur la sécurité dans l'unité suivante.

En résumé

Agent = modèle (décision) + outils (fonctions) + boucle (appeler l'outil, obtenir le résultat, décider à nouveau).
Un seul appel de modèle n'est pas un agent ; agent est un processus étape par étape.
Le modèle ne fait pas rouler le véhicule ; Votre application s'exécute (harnais) et renvoie le résultat sous la forme tool_result.
L'outil est identifié par son nom, sa description (en particulier « appeler quand ») et input_schema.
La boucle continue pendant que tool_use → harnais s'exécute → tool_result → model continue jusqu'à ce que le modèle dise « terminé » ; les erreurs sont explicitement signalées au modèle.

Tâche de candidature

Concevez 3 outils de votre propre entreprise qui peuvent être remis à l'agent. (1) Écrivez le nom, la description avec « appeler quand » et input_schema pour chacun ; Soit au moins un outil de lecture non destructif et un autre un calcul. (2) Choisissez une question utilisateur réaliste et écrivez manuellement étape par étape (en boucle) lequel de ces outils le modèle appellera avec quelles entrées et ce qu'il fera après l'arrivée du tool_result. (3) Configurez un scénario dans lequel l'un des outils échoue et montrez comment le message d'erreur reviendra au modèle.

liste de contrôle

[ ] Je peux définir l'agent comme "modèle + outils + boucle" et décider quand il est nécessaire.
[ ] Je sais que le harnais fait fonctionner le véhicule, le modèle le veut juste.
Je peux écrire une description solide du véhicule avec le nom [ ], la description ("appeler quand") et input_schema.
Je peux suivre le cycle [ ] tool_use → tool_result étape par étape.
[ ] Je signale les erreurs d'outil au modèle en tant qu'open tool_result.