Explication de l’appel d’outils : comment les modèles demandent aux logiciels d’agir, et où cela échoue.
Une présentation pratique de l’appel de fonctions et de l’utilisation d’outils : le cycle de demande, les schémas, les outils de lecture par rapport aux outils d’action, les agents, MCP, l’injection de prompts, le suivi et les pannes fréquentes.
Sources: Function Calling and Tool Use: How AI Agents Automate Workflows
Les premiers chatbots étaient des machines à répondre aux questions. Une personne tapait quelque chose, une réponse arrivait, et l’échange s’arrêtait là. Utiles, mais limités. Un modèle pouvait décrire comment réserver un vol sans pouvoir consulter les tarifs du jour. Il pouvait expliquer ce qu’il y a sur une facture sans jamais en créer une dans le système de facturation. Il pouvait proposer un horaire de réunion sans avoir aucun moyen de consulter le calendrier de quiconque, sans parler d’y inscrire l’événement.
Les appels de fonction éliminent ce mur. Un modèle de langage dispose alors d’un moyen de demander de l’aide au logiciel environnant, et le reste de l’infrastructure se développe à partir de cette seule capacité.
Un modèle qui peut demander des choses
Sans outils, un modèle répond en s’appuyant sur ce qu’il a absorbé pendant son entraînement. Avec eux, il peut déterminer qu’une question nécessite une aide extérieure et indiquer quel outil doit la fournir : un service météorologique, un index de recherche, une requête de base de données, une calculatrice, un calendrier, un processus de paiement, une recherche dans un CRM, un interpréteur de code, ou une fonction interne de l’entreprise. Au lieu de deviner, le modèle envoie une demande structurée, l’application la satisfait, et le modèle poursuit avec des informations plus fraîches et plus précises. Les grands fournisseurs tels qu’OpenAI, Anthropic et Google, ainsi que des frameworks comme LangChain, décrivent l’utilisation des outils de la même manière générale : des outils bien définis sont proposés au modèle, celui-ci décide quand les invoquer, transmet des arguments structurés, et intègre les résultats obtenus dans sa réponse ou son action.
Une image mentale utile : le modèle est l’« cerveau » de la conversation, et les outils sont les mains, les yeux, la mémoire, la calculatrice, le classeur et le camion de livraison. Le cerveau détermine ce que l’utilisateur souhaite. Les outils s’occupent des tâches que la génération de texte brute ne peut pas effectuer de manière sûre ou fiable.
Appel de fonction versus appel d’outil
Ces deux expressions sont utilisées de manière interchangeable, mais la seconde est plus précise, car l’idée dépasse les fonctions de programmation classiques. Un outil peut être aussi simple que get_weather(location). Il peut également s’agir d’une recherche dans une base de données, d’une session de navigateur, d’un récupération de documents, d’une calculatrice, d’une commande de shell, d’un processus de conception, ou d’un lien vers un service externe. Dans le vocabulaire d’OpenAI, un outil est une capacité mise à disposition du modèle, et un appel d’outil est un type particulier de réponse du modèle demandant l’utilisation de l’un d’eux.
Il est essentiel de noter que le modèle ne met généralement rien en œuvre par lui-même. Dans la configuration courante côté client, il renvoie une demande structurée, similaire à une appel à get_customer_profile avec un customer_id de 12345. L’application la reçoit, l’analyse, exécute la fonction réelle, collecte les résultats et les renvoie au modèle, qui élabore ensuite sa réponse finale. La séquence documentée est la suivante : fournir les outils disponibles, recevoir un appel à un outil, exécuter le code dans son propre application, envoyer les résultats et recevoir soit une réponse finale, soit d’autres appels à des outils.
Il existe des exceptions. Certains fournisseurs hébergent également des outils côté serveur qui s’exécutent sur leur infrastructure. Anthropic distingue clairement ces deux cas : les outils côté client sont exécutés par votre application et apparaissent sous forme de blocs structurés indiquant l’utilisation d’un outil, tandis que les outils côté serveur, tels que la recherche web ou l’exécution de code, peuvent être exécutés du côté d’Anthropic.
Cette distinction a de l’importance. Dire « le modèle a appelé une API » peut signifier que le modèle a généré une demande à exécuter par votre logiciel, ou bien que la plateforme a lancé un outil intégré au nom du modèle. En environnement de production, cela modifie la posture de sécurité, la gestion des journaux, les coûts, la manière dont les données sont traitées, les personnes habilitées à approuver certaines actions, ainsi que celles qui sont responsables en cas de problème.
Le cycle en cinq étapes
La plupart des systèmes de appel de fonctions répètent un cycle unique.
- Définir les outils. Chaque outil reçoit un nom, une description ainsi qu’une liste des entrées attendues. Un outil météorologique peut avoir besoin d’une ville et d’un pays. Un outil de remboursement peut nécessiter un ID de commande, une raison et un montant maximal. Un outil de planification peut exiger des participants, une date, une heure et un sujet. Les exemples d’OpenAI décrivent les paramètres dans un style JSON Schema, avec des champs obligatoires et des restrictions telles que additionalProperties réglé sur false, tandis que la documentation de Gemini de Google montre des déclarations de fonction construites à partir de noms, de descriptions et de structures d’entrée.
- L’utilisateur demande quelque chose. Le modèle lit la demande et détermine s’il peut y répondre immédiatement. « Expliquez ce qu’est l’appel de fonction » ne nécessite probablement aucun outil. « Quel est le statut de la commande 8472 ? » en a presque certainement besoin.
Le cycle peut s’exécuter une fois ou se répéter de nombreuses fois. Un agent peut rechercher, comparer les résultats, appeler un autre outil, poser une question complémentaire, mettre à jour un enregistrement, et enfin résumer ce qu’il a fait.
Le langage en tant qu’interface
Le véritable avantage de l’utilisation d’outils est que le langage courant devient une interface flexible pour les logiciels.
Traditionnellement, chaque fonctionnalité nécessite ses propres boutons, formulaires, menus et flux. Grâce aux appels de fonction, l’utilisateur peut exprimer directement son intention : localiser la dernière facture d’Acme, vérifier si le paiement est arrivé, et si ce n’est pas le cas, envoyer un e-mail de rappel poli. Une seule phrase cache derrière elle plusieurs outils : une recherche dans un CRM, la récupération d’une facture, la vérification de l’état du paiement, la rédaction d’un brouillon d’e-mail, et éventuellement une demande d’approbation avant d’envoyer quoi que ce soit.
Un bon design de produit n’est pas une option. Ce qui change, c’est le point de départ de l’interface. Plutôt que de faire apprendre aux utilisateurs la structure du logiciel, celui-ci s’adapte à la manière dont les gens parlent déjà de leur travail.
Cela confère une grande importance aux descriptions des outils. Une description vague laisse le modèle indécis quant à l’utilisation de l’outil. Une description claire indique quand l’utiliser, ce qu’il fait, ce que signifie chaque entrée, et ce qu’il ne faut pas supposer. La documentation de LangChain présente les outils comme des fonctions ayant des entrées et des sorties bien définies, et souligne que les indications de type et des descriptions succinctes aident le modèle à les utiliser correctement.
Un bon outil, c’est plus qu’une fonction : c’est un contrat.
Quatre termes qui se chevauchent
Les gens confondent ces termes, bien qu’ils relèvent de niveaux différents.
- Appel de fonction est le mécanisme : le modèle demande l’exécution d’une fonction ou d’un outil structuré.
- Utilisation d’outils est une capacité plus large. Elle englobe les appels de fonction, les outils intégrés, la recherche sur le Web, la recherche de fichiers, l’exécution de code, le contrôle de l’ordinateur, les serveurs distants, ainsi que tout autre moyen permettant à un modèle d’interagir avec des systèmes externes.
- Un agent est un système qui utilise successivement différents outils pour atteindre un objectif. OpenAI décrit les agents comme des applications capables de planifier, d’utiliser des outils, de collaborer avec des spécialistes et de suivre les progrès dans des tâches à plusieurs étapes ; son SDK pour les agents définit un agent comme un LLM configuré avec des instructions, des outils, ainsi que des éléments optionnels tels que des transferts de responsabilités, des contraintes et des sorties structurées.
En d’autres termes : l’appel de fonction constitue le connecteur, les outils sont les appareils branchés, les agents décident comment et quand les utiliser, et l’automatisation fait en sorte que tout fonctionne comme partie d’un système dynamique.
Pourquoi se donner cette peine ?
Les modèles de langage sont doués pour comprendre, combiner et communiquer des informations. Ils ne remplacent pas efficacement les calculatrices, les bases de données ou les moniteurs en temps réel. Ils peuvent écrire sur la météo mais ne peuvent pas connaître la prévision du jour à moins d’être connectés à ces données. Ils peuvent discuter d’une facture mais ne peuvent pas accéder à votre système de facturation à moins qu’il ne soit connecté. Ils peuvent expliquer du code mais ne peuvent pas déterminer si votre service est down sans données de surveillance.
Les outils comblent ces lacunes. Une calculatrice assure la fiabilité des opérations arithmétiques. Les outils de recherche fournissent des informations à jour. Les outils de récupération s’appuient sur des documents privés pour donner des réponses. Un outil de base de données répond aux questions concernant les dossiers de l’entreprise. Un outil de gestion de flux de travail crée des tickets, envoie des messages, met à jour des commandes ou prend des rendez-vous. La documentation de Gemini de Google résume les avantages en trois points : ajouter des connaissances, étendre les capacités et agir via des systèmes externes.
C’est à ce stade que l’expérience cesse de ressembler à une conversation pour devenir celle d’un logiciel. Le modèle ne se contente plus de générer des mots ; il aide également à coordonner les tâches.
Recherches à l’origine de cette idée
Les agents utilisant des outils n’ont pas apparu de nulle part. Quatre recherches antérieures ont façonné ce domaine.
- MRKL Systems (2022) a proposé une conception modulaire reliant les modèles de langage à des modules de connaissance et de raisonnement externes. L’idée de base était simple : ne demandez pas à un seul modèle de faire tout le travail ; assignez chaque tâche à un composant spécialisé.
- ReAct (2022) a étudié la manière dont les modèles peuvent alterner réflexion et action. Plutôt que de ne penser ou d’agir uniquement, l’approche de type ReAct fait en sorte que le modèle réfléchisse, agisse, observe le résultat et ajuste son plan. Ce cycle améliore les performances dans les tâches de réponse à des questions et de prise de décision, et rend le comportement du modèle plus facile à suivre.
- Toolformer (2023) a testé si un modèle pouvait apprendre à utiliser des outils grâce à des API simples. Il a appris quand il était opportun d’utiliser un outil, quoi envoyer et comment utiliser les résultats, en prenant des calculatrices, des moteurs de recherche, des traducteurs et des calendriers comme exemples.
- Gorilla (2023) s’est attaqué aux appels API à grande échelle et à un problème concret : avec de nombreux outils disponibles, les modèles inventent parfois des appels ou fournissent des arguments incorrects. Gorilla a combiné l’entraînement avec la récupération d’informations afin que le système puisse suivre les mises à jour de la documentation API et commettre moins d’erreurs.
Tout cela converge vers une idée : les meilleurs systèmes d’IA ne sont pas des modèles isolés. Ce sont des parties de systèmes plus larges reliés à des outils, à de la mémoire, à des règles, à du logiciel et à une supervision humaine.
À quoi ressemble un bon outil
Les bons outils sont ciblés, compréhensibles et sûrs.
Les outils ciblés sont plus faciles à choisir pour un modèle et à contrôler pour les développeurs. Un outil appelé update_everything est vague et dangereux. create_refund_request est plus clair. approve_refund exige encore plus de prudence, car il modifie le monde réel.
Les outils compréhensibles portent des noms et des descriptions simples. Un modèle ne devrait pas devoir deviner si fetch_record signifie obtenir un profil de client, télécharger un fichier ou récupérer un dossier médical. La description doit indiquer son but, les situations dans lesquelles il est utilisé, la signification de chaque argument ainsi que la forme de la valeur de retour.
Les outils sécurisés disposent de limites intégrées. Ils vérifient les permissions, valident les entrées et évitent d’accorder un accès qui n’est pas nécessaire. Ils génèrent des erreurs claires, conservent des journaux et demandent une approbation humaine avant d’effectuer des actions sensibles. Ils ne confèrent jamais au modèle plus de pouvoirs que ne l’exige la tâche.
OpenAI recommande des schémas stricts afin que les arguments arrivent de manière fiable, et son SDK Agents oriente les développeurs vers des mécanismes de contrôle, une révision par des humains, des résultats clairs, une gestion de l’état et une capacité d’observation à mesure que les workflows se développent. En pratique, les meilleurs outils sont ceux qui sont simples : chacun fait bien une seule chose sans surprendre personne, que ce soit les développeurs, les modèles ou les utilisateurs.
Les schémas en tant que grammaire
Un schéma constitue la grammaire de l’utilisation d’un outil. Lorsque le modèle appelle une fonction, il doit fournir des arguments dans un format compréhensible par l’application. Le schéma définit quels champs existent, quelles en sont les types, lesquels sont obligatoires, et parfois quels valeurs sont autorisées. Un outil météorologique pourrait exiger une localisation sous forme de chaîne de caractères ainsi qu’un champ de unités limité à Celsius ou Fahrenheit.
Les schémas stricts réduisent l’ambiguïté et simplifient la validation. La documentation d’OpenAI explique que le mode strict garantit que les appels respectent strictement le schéma déclaré, en imposant des contraintes telles que additionalProperties mis à false pour chaque champ marqué comme requis, ainsi que l’utilisation de types nullable pour exprimer des valeurs optionnelles.
Cependant, un schéma ne rend pas un système sûr. Une requête parfaitement formatée peut tout de même être problématique. Une appel send_email adressé à all_customers@example.com peut respecter parfaitement le schéma tout en étant une très mauvaise idée. La validation par schéma doit donc s’accompagner de règles métier, d’autorisations, de limites de fréquence, d’étapes de révision et de surveillance.
Lecture versus action
Une décision de conception importante concerne le fait qu’un outil ne se contente de lire ou qu’il agit également.
Les outils en lecture seule permettent de récupérer des informations : rechercher des documents, consulter des fichiers, vérifier les stocks, obtenir des données météorologiques, calculer des totaux, examiner des journaux. Ils peuvent néanmoins exposer des données sensibles et nécessitent un contrôle d’accès, mais ils ne modifient généralement rien.
Les outils d’action permettent d’accomplir des tâches concrètes. Ils envoient des e-mails, passent des commandes, annulent des abonnements, procèdent à des remboursements, mettent à jour des bases de données, ouvrent des tickets, déployent du code ou programment des réunions. Les erreurs commises avec eux ont des conséquences réelles.
Un agent bien conçu traite ces deux types d’outils différemment. Les outils en lecture seule peuvent être utilisés plus librement, mais toujours sous réserve de vérifications de permissions. Les outils d’action exigent généralement des contrôles plus stricts : écrans de confirmation, étapes d’approbation, limites de transaction, journaux d’audit, options de réversion et messages clairs destinés à l’utilisateur.
À ce stade, l’automatisation devient une question de gestion et non seulement une question technique. La question n’est pas de savoir si le modèle peut appeler la fonction, mais plutôt dans quelles conditions tout système devrait être autorisé à effectuer une action au nom d’une personne.
Des appels simples aux agents
Un seul appel à une fonction peut répondre à une question simple. Les agents sont conçus pour des tâches plus longues et plus complexes. Lorsqu’on lui demande de préparer un résumé des ventes hebdomadaires et d’identifier les comptes nécessitant une attention particulière, un agent devra probablement récupérer les données de ventes, les comparer aux semaines précédentes, détecter des schémas inhabituels, lire les notes du CRM, rédiger le résumé et l’envoyer à un manager. Il s’agit d’une chaîne de décisions, et non d’un seul appel.
Les frameworks d’agents gèrent toute la chaîne de traitement. Ils conservent l’état, exécutent des outils, tentent à nouveau les étapes échouées, transmettent le travail entre des agents spécialisés, génèrent des résultats structurés, appliquent des règles de contrôle et conservent des traces. La documentation du SDK d’Agents d’OpenAI décrit deux modèles courants : un modèle de gestionnaire dans lequel un agent central appelle des agents spécialisés comme s’il s’agissait d’outils, et des transferts de contrôle dans lesquels un agent cède le contrôle à un spécialiste.
Ils sont puissants, certes, mais il ne faut pas les idéaliser. Un agent n’est pas un petit employé vivant à l’intérieur de votre logiciel. C’est un système probabiliste construit à partir de code, qui nécessite des responsabilités définies, des permissions limitées, des cas de test, un suivi en temps réel, des procédures d’escalade ainsi que des plans en cas d’échec. Plus un agent dispose de liberté, plus l’ingénierie qui le concerne doit être rigoureuse.
Où l’automatisation rencontre le travail réel
L’automatisation est l’étape à laquelle l’utilisation d’outils se transforme en opérations concrètes.
- Une équipe de support peut utiliser un agent pour classer les tickets, récupérer les documents de politique pertinents, rédiger des réponses et proposer des étapes suivantes.
- Une équipe financière peut rapprocher les factures, retrouver les bons de commande manquants et préparer des rapports d’exception.
- Une équipe d’ingénierie peut examiner les tests qui échouent, rechercher dans les journaux, proposer des correctifs et ouvrir des demandes de fusion de code.
- Une équipe de vente peut enrichir les prospects, préparer des notes de appel et mettre à jour le CRM.
La meilleure automatisation ne part pas de ce que le modèle peut faire, mais d’un flux de travail existant. Où commence le travail ? Quelles informations sont nécessaires ? Quelles décisions sont routinières et lesquelles sont sensibles ? Où les personnes examinent-elles, approuvent-elles ou corrigent-elles actuellement ? Quelles erreurs seraient irritantes et lesquelles seraient coûteuses ?
Avec ces réponses en main, les outils aident à faire progresser le processus plus fluidement. L’agent collecte des faits, remplit des formulaires, rédige des messages, compare des données et formule des recommandations, tandis que les personnes restent impliquées là où le jugement, la responsabilité ou la confiance sont essentiels.
Connexions standardisées
Les premières intégrations étaient sur mesure. Chaque application disposait de sa propre manière de mettre à disposition des outils, des ressources, des prompts et des mécanismes d’authentification. Cela fonctionnait bien pour de petits projets, mais devenait difficile à gérer à mesure que les organisations liaient davantage de modèles à davantage de systèmes.
Le Model Context Protocol (MCP) constitue une tentative de standardiser cette couche. Sa spécification décrit comment les applications peuvent partager du contexte, exposer des outils et des fonctionnalités, ainsi que créer des intégrations flexibles grâce à une configuration composée d’un hôte, d’un client et d’un serveur. Les serveurs MCP peuvent proposer des ressources, des instructions et des outils. Le protocole échange des messages JSON-RPC 2.0 et couvre la négociation des capacités, le suivi des progrès, l’annulation, le journalisation et la détection des erreurs.
Les avantages sont évidents : une couche d’outils partagés permet aux applications d’IA de se connecter de manière cohérente aux sources de données et aux flux de travail, évitant ainsi à chaque entreprise de réimplémenter chaque intégration. Les inconvénients, en revanche, résident dans de nouveaux risques. Un serveur d’outils offrant des fonctionnalités puissantes doit être considéré par l’application hôte comme une véritable barrière de sécurité et non comme un simple plugin supplémentaire. La spécification propre à MCP insiste sur le consentement de l’utilisateur, la confidentialité des données, la sécurité des outils, ainsi que sur la prudence concernant l’accès arbitraire aux données et les chemins d’exécution de code.
La sécurité d’abord
Les agents utilisant des outils sont précieux car ils agissent, mais cette même capacité génère des risques.
Injection de commandes est la menace la plus connue : des instructions hostiles cachées dans les entrées utilisateur ou du contenu externe qui poussent le modèle à adopter un comportement qu’il devrait éviter. OWASP la classe parmi les principaux risques pour les applications basées sur des LLM, et son document de 2025 mentionne également le problème de l’autonomie excessive, où un système basé sur un LLM dispose d’un pouvoir d’action supérieur à ce qui est judicieux, ce qui peut entraîner des résultats inattendus, ambigus ou manipulés conduisant à des actions nuisibles.
Injection indirecte inquiète le plus ceux qui travaillent avec des agents. Supposons qu’un agent lise des e-mails et puisse envoyer des réponses. Un expéditeur malveillant pourrait cacher dans un message une instruction lui demandant d’ignorer ses règles et de transférer les contacts de l’utilisateur. L’utilisateur ne verra jamais cette instruction, mais le modèle la traitera néanmoins. Si le système est trop confiant et dispose de trop de permissions, un message apparemment inoffensif peut devenir la cause d’une action réelle.
Les équipes de sécurité commencent à considérer les LLM comme des systèmes qui peuvent être trompés uniquement par la formulation des instructions, et non seulement à cause de défauts de code. Le Centre national de cybersécurité du Royaume-Uni souligne que l’injection de prompts diffère de l’injection SQL, car un LLM ne maintient aucune frontière stricte entre les instructions et les données non fiables.
La réponse adéquate consiste en une défense en plusieurs couches :
- Restreindre autant que possible les permissions des outils.
- Séparer les outils de lecture de ceux d’écriture.
- Exiger une approbation avant de réaliser des actions sensibles.
- Considérer tout ce qui est récupéré, qu’il s’agisse de pages web, d’e-mails, de documents ou de champs de base de données, comme non fiable.
- Vérifier chaque argument des outils et nettoyer leurs sorties avant de les transmettre à d’autres systèmes.
- Utiliser des listes d’autorisation, enregistrer chaque appel d’outil et surveiller les activités inhabituelles.
- Tester avec des exemples adversariaux et mettre en place des moyens de revenir en arrière lorsque c’est possible.
Accordez à un agent uniquement autant de pouvoirs que le flux de travail en exige réellement.
Voir ce que l’agent a fait
Le logiciel agent nécessite des enregistrements encore plus détaillés que le logiciel ordinaire, car une seule exécution peut inclure du raisonnement de modèle, des appels d’outils, des transferts de tâches, des vérifications de contraintes, des tentatives de réessai et un résultat final. Le suivi permet aux développeurs de suivre l’ensemble du parcours, de la demande au résultat. Selon la documentation de suivi du SDK Agents d’OpenAI, les traces peuvent capturer les générations de modèles de langage, les appels d’outils, les transferts de tâches, les contraintes et des événements personnalisés, aidant ainsi les équipes à déboguer, à visualiser et à surveiller les flux de travail en développement et en production.
Cela a une incidence sur la qualité et la sécurité. Lorsqu’un agent donne une réponse erronée, il faut en trouver la cause : a-t-il choisi l’outil incorrect ? L’outil a-t-il fourni des données obsolètes ? Le modèle a-t-il mal interprété la description ? Une mesure de sécurité a-t-elle échoué ? L’utilisateur n’a-t-il pas les droits nécessaires ? L’agent s’est-il arrêté prématurément ? Sans traces, les équipes doivent deviner. Avec une bonne capacité d’observation, la création d’agents devient une véritable pratique d’ingénierie.
Comment ces systèmes échouent généralement
Les pannes sont prévisibles. Du côté du modèle, il peut choisir l’outil incorrect lorsque les noms ou les descriptions sont flous, envoyer des arguments incomplets ou erronés, appeler un outil au lieu de poser une question pour obtenir des précisions, ou omettre une appelation lorsque des données fraîches sont nécessaires. Il peut également appeler les outils trop souvent, ce qui augmente les coûts et la latence, entrer dans des boucles de rappels sans progresser, ou faire confiance aux résultats d’un outil plus que cela n’est justifié.
L’application peut également échouer. Elle peut accepter des arguments fournis par le modèle sans les valider, exposer trop d’outils en même temps, retourner des résultats volumineux et confus qui perturbent le modèle, masquer des messages d’erreur utiles, associer à tort des résultats aux appels qui les ont générés, ou ne pas disposer de journaux d’audit, de limites de fréquence ni de mécanismes d’approbation.
Les ajustements mineurs des prompts résolvent rarement ces problèmes. La solution réside dans une meilleure conception des outils, des schémas plus clairs, des permissions plus strictes, une gestion plus fiable de l’état, davantage de tests et une surveillance améliorée.
Quand omettre les outils
Appeler une fonction n’est pas toujours justifié. Si une tâche ne nécessite qu’une explication, l’utilisation d’un outil ajoute de la complexité. Si les informations nécessaires se trouvent déjà dans la demande et ne changent pas, il n’y a rien à récupérer. Pour des actions à haut risque qui ne peuvent être vérifiées ou annulées en toute sécurité, une automatisation complète peut être le mauvais choix. De plus, si la sortie d’un outil est peu fiable, non documentée ou peu sécurisée, l’intégration de celui-ci dans un agent aggrave les problèmes.
L’expérience utilisateur a également un prix. Les appels aux outils entraînent des retards, les demandes de permissions perturbent le flux, et les agents complexes peuvent sembler imprévisibles. Parfois, un formulaire simple est préférable à un flux de travail par chat, surtout lorsque les utilisateurs savent exactement ce qu’ils veulent et nécessitent rapidité, cohérence ou conformité.
Le but n’est pas de rendre tout processus automatisé. Utilisez un outil uniquement lorsque le langage, le contexte et l’action se rencontrent réellement.
Habitudes pour construire efficacement
Commencez avec un petit nombre d’outils clairs et précis, et élargissez progressivement l’accès au modèle. Choisissez des fonctions spécifiques ayant des noms simples. Rédigez des descriptions du modèle, destinées non seulement aux ingénieurs. Utilisez des schémas stricts lorsque c’est possible et validez toujours les entrées dans votre propre code. Gardez les sorties courtes et ne transmettez au modèle que ce dont il a réellement besoin.
Définissez les permissions outil par outil. Un agent de support capable de vérifier l’état d’une commande n’a pas nécessairement besoin de procéder à des remboursements. Un assistant de planification peut avoir besoin de connaître les disponibilités calendaires, mais pas des notes sur des événements privés. Un assistant en programmation devrait pouvoir lire un dépôt bien avant de pouvoir soumettre des demandes de fusion.
Exigez que toute action sensible, coûteuse, publique, juridiquement contraignante, financière ou difficile à annuler soit approuvée par une personne, et soyez précis dans votre demande afin que l’expéditeur sache exactement ce qui va se passer.
Lectures complémentaires
- Utilisation des outils en production pour les agents : provenance, tentatives de réessai et observabilité — Un agent d’une banque a appelé à plusieurs reprises une API payante et a inventé un numéro de téléphone. Découvrez les ensembles d’outils minimaux, la provenance des paramètres, les tentatives de réessai en trois niveaux ainsi que les métriques par outil.
- Prises de vue de la mémoire des agents, compétences, dégradation et ciblage par branche — Quatre améliorations apportées à une couche de mémoire basée sur une base de données vectorielle intégrée pour les agents de codage : prises de vue portables pouvant être fusionnées, activation de compétences, dégradation avec vérification des conflits, et mémoire ciblée par branche.