Sans outils, un modèle ne peut que conseiller. Avec eux, l’agent peut lire, chercher, envoyer et modifier l’état réel. C’est donc l’endroit où capacité et risque augmentent ensemble.
Un bon outil exprime capacité, limites, coût, échec et possibilité de retour arrière.
01 / THREE TOOL TYPESDistinguer d’abord perception, exécution et collaboration
Les outils de perception lisent le monde ; ceux d’exécution le modifient ; ceux de collaboration délèguent à des personnes ou agents. Leurs risques diffèrent : ils ne doivent pas partager les permissions par défaut. Perception lit fichiers, web, base ou écran. Exécution écrit, soumet, envoie, paie ou publie. Collaboration délègue, demande une confirmation humaine ou synchronise un système.
02 / PRACTICEChoisir la granularité autour d’une action vérifiable
Un gros outil universel est commode mais rend paramètres complexes et échecs difficiles à localiser. Des outils trop fins imposent trop d’appels. Une bonne taille correspond à une action métier claire, contrôlable et réessayable. Les méthodes répétées vont dans un Skill ; un outil donne accès à un système externe. L’association est plus maintenable qu’une API nouvelle par tâche.
03 / PRACTICEDescriptions, paramètres et retours doivent préserver le sens
Nom et description déterminent la sélection. Le schéma de paramètres permet l’exécution, le retour permet au tour suivant de juger le succès. Dates, montants, chemins et valeurs énumérées ne doivent pas devenir flous entre couches. Décrivez usages et non-usages ; validez paramètres à risque avec énumérations, plages et champs requis ; retournez état réel, cause d’erreur et conseil de reprise ; séparez demande acceptée et action terminée.
04 / MCPMCP unifie la connexion, pas le choix d’outil
MCP permet à différents agents de découvrir et appeler des capacités externes avec un protocole commun, ce qui réduit le coût d’intégration. Il ne supprime ni sélection, ni permissions, ni contexte lorsque la liste grandit. Organisez toujours les serveurs MCP par domaine, exposez les listes à la demande et gardez permissions et approbations pour ce qui modifie le monde extérieur.
05 / PRACTICELe travail long a besoin d’événements, pas d’un chat bloqué
Approbation, construction, import et réponse humaine peuvent durer minutes ou jours. Un agent asynchrone sauvegarde son état, reprend lors d’un événement et explique son avancement. Identités virtuelles et environnements isolés limitent le périmètre des identifiants et fichiers afin qu’un agent durable n’ait pas de pouvoir illimité.
06 / DISCOVERY & SAFETYLa découverte d’outils doit toujours respecter le moindre privilège
À grande échelle, un agent peut chercher un annuaire ou charger un Skill avant de choisir un appel. La découverte ne contourne pas l’autorisation : trouver un outil ne donne pas son droit. En droit, un agent peut lire un dossier désigné, faire un brouillon et signaler les pièces manquantes. Envoi externe, suppression d’original, changement de délai ou dépôt formel doivent s’arrêter avant confirmation humaine. Premier exercice : dessinez un flux de dossier, marquez lecture seule, écriture ou envoi externe, puis donnez confirmation et retour arrière aux deux derniers.
Livre source et références du chapitre
- bojieli/ai-agent-book.
- Chapter 4 — tools and MCP.
- Chapter 4 experiments.
- Cette page réorganise la pratique sans remplacer le livre source ; utilisez texte et code sources pour les formulations exactes.
COMMENTAIRES DES LECTEURS
Notez l’idée que cet article vous a laissée.
Aucun commentaire. Vous pouvez laisser le premier.