Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Portée de l'outil
Il existe deux approches pour développer des outils : granulaire et grossier.
Granulaire
Dans une approche granulaire, vous créeriez un outil par API, action ou requête. Par exemple, vous pouvez créer descreate_issue,get_issue, add_labelassign_issue, et close_issue des outils pour votre dépôt Git. Cela permettrait au LLM de faire des appels granulaires à chaque API et de les orchestrer selon les besoins. Tenez compte de l'invite suivante : « Créez un problème pour le service produit intitulé « La requête ne renvoie que des résultats partiels », qualifiez-le de bogue et de prioritaire, et attribuez-le à Alice. » L'image suivante montre comment une tool-per-API approche répondrait à cette invite.
Dans cette approche, l'invite du système et chaque définition d'outil enregistrée sont fournies au LLM à chaque appel. Cela consomme du contexte supplémentaire et entraîne une pénalité de latence, car chaque appel d'outil représente un appel individuel au LLM. Cela augmente également la complexité de la gestion des erreurs dans le flux de travail.
À gros grains
Une approche grossière, ou axée sur le flux de travail, consisterait à utiliser des outils orientés vers le flux de travail. L'outil met l'accent sur end-to-end l'intention de l'utilisateur plutôt que sur la structure de l'API. Au lieu de a tool-per-API, vous avez un outil qui en appelle plusieurs de manière déterministe. APIs À l'aide de l'exemple de dépôt Git précédent, vous pouvez créer un create_and_setup_issue outil appelé une fois par l'agent. L'implémentation de l'outil crée le problème, ajoute des étiquettes et l'attribue à un utilisateur, en fonction des paramètres fournis à l'outil. L'image suivante montre comment une approche grossière traiterait la même invite.
Cette approche montre comment toute la complexité reste cachée dans la couche LLM. Lorsque la logique d'orchestration est intégrée à l'implémentation de l'outil, toutes les étapes séquentielles, la journalisation, la logique de nouvelle tentative, les disjoncteurs et la limitation de débit sont effectuées de manière déterministe dans l'outil. L'approche axée sur le flux de travail permet au LLM d'appeler plus facilement le bon outil avec les bons paramètres. Il est important de noter que certaines API peuvent déjà fournir une intention de flux de travail, comme l'API Amazon EC2RunInstances. Dans ces cas, a tool-per-API peut fournir la conception axée sur le flux de travail que vous souhaitez.
Cependant, les outils peuvent également devenir trop grossiers. Si votre seul outil de flux de travail tente de faire trop de choses et comporte de nombreux paramètres possibles, le LLM peut avoir du mal à raisonner sur la manière d'utiliser correctement l'outil. Cela peut également créer des difficultés en termes de sélection des paramètres et de gestion des erreurs. Ainsi, le développement d'outils doit trouver un équilibre qui correspond aux intentions de l'utilisateur et qui évite d'utiliser trop ou trop de fonctionnalités dans un seul outil. Nous vous recommandons de concevoir des outils basés sur des flux de travail utilisateur complets, en regroupant les opérations qui se produisent généralement ensemble (comme trois appels d'API ou plus). Nous vous recommandons également de décomposer les outils qui dépassent huit paramètres ou plus ou qui gèrent plusieurs intentions distinctes de l'utilisateur. Testez avec de vraies instructions pour vérifier que les agents peuvent utiliser correctement chaque outil.
Si vous avez des flux de travail complexes et dynamiques qui ne peuvent pas être facilement encapsulés en tant qu'outil déterministe, vous pouvez envisager d'utiliser le modèle. agent-as-tool Au lieu que votre agent principal essaie d'orchestrer des tâches complexes dans un flux de travail, un agent spécialisé peut agir comme un outil. Ces types d'outils peuvent mettre en œuvre des processus décisionnels et des branchements avancés, et ils peuvent gérer les erreurs et réessayer une logique qui ne peut pas être facilement gérée dans un code déterministe. Ce protocole est similaire mais distinct du protocole Agent2Agent (A2A
Nous vous recommandons de commencer par l'analyse de votre flux de travail en cartographiant vos flux de travail utilisateur les plus courants afin d'identifier les fonctionnalités de base dont chaque agent a besoin. Cela permet d'établir votre ensemble d'outils minimum viable. Sur la base de notre expérience dans le développement de serveurs MCP à grande échelle, nous recommandons les pratiques suivantes. En cas de conflit entre ces pratiques, priorisez l'intention de l'utilisateur et le flux de travail.
Bonnes pratiques en matière de cadrage des outils MCP
-
Pensez aux témoignages d'utilisateurs et regroupez les opérations courantes : les outils doivent correspondre directement à l'ensemble des interactions avec les utilisateurs plutôt que de nécessiter l'orchestration de plusieurs opérations. Si les flux de travail nécessitent généralement au moins trois appels distincts, combinez-les dans un seul outil. Cela réduit la charge cognitive du LLM, minimise le nombre d'appels d'outils, réduit la consommation de contexte et la latence nécessaires à l'exécution des tâches, et améliore la précision et la latence.
-
Limiter les paramètres à huit ou moins : si un outil dépasse huit paramètres, décomposez-le en plusieurs outils. LLMs difficulté à sélectionner les paramètres à mesure que la complexité augmente.
Note
Si les opérations de regroupement nécessitent plus de huit paramètres, privilégiez le regroupement plutôt que le nombre de paramètres, car la simplification du flux de travail est plus précieuse que des limites de paramètres strictes.
-
Opérations de lecture et d'écriture distinctes : fournissez différents outils pour lire les données et les modifier. Cette séparation indique clairement quand les agents exécutent des opérations potentiellement destructrices, permet d'appliquer différentes politiques d'autorisation et réduit le risque de modifications involontaires lors de la collecte d'informations.
-
Fournissez des valeurs par défaut raisonnables — Outils de conception afin que le LLM ne doive spécifier que les paramètres spécifiques à la demande individuelle. Les valeurs par défaut réduisent la complexité des paramètres et améliorent la précision de la sélection des outils en minimisant les informations sur lesquelles le LLM doit raisonner.
-
Préférez l'exécution déterministe — Rendez l'exécution de l'outil et la sortie déterministes lorsque cela est possible. Les outils déterministes sont plus fiables et plus faciles à tester. Pour les flux de travail complexes qui nécessitent une orchestration intelligente, une logique de branchement ou une gestion avancée des erreurs qui ne peuvent pas être facilement gérés dans un code déterministe, envisagez d'utiliser des agents spécialisés comme outils. Toutefois, utilisez ce modèle de manière sélective car il ajoute de la complexité.
