Partager via


Agents en tant qu’outils

La page précédente a montré comment les fournisseurs de contexte donnent à des agents une mémoire et des connaissances dynamiques , des informations qui sont injectées de manière proactive avant chaque appel. À ce stade, vous disposez d’un seul agent capable d’utiliser des outils, de charger des compétences, d’exécuter des intergiciels et de tirer parti du contexte enrichi. C’est puissant, mais c’est toujours un agent qui fait tout.

Que se passe-t-il lorsque les responsabilités de votre agent dépassent ce qu’un ensemble unique d’instructions peut gérer correctement ? À mesure qu’un agent accumule des outils, la sélection des outils se dégrade : les modèles sont mieux à choisir parmi quelques outils bien décrits que de trier par dizaines. Au fur et à mesure que les instructions s'étendent, la concentration se détériore : une invite système qui tente de couvrir les réservations de voyages, les rapports de dépenses et la gestion du calendrier force le modèle à jongler avec trop de rôles.

Les agents en tant qu’outils résolvent ce problème en vous permettant de composer des agents : un agent (l’agent externe ) peut appeler un autre agent (l’agent interne ) comme s’il s’agissait d’un outil de fonction standard. Chaque agent interne a une portée étroite : ses propres instructions, ses propres outils, son propre expertise. L’agent externe décide quand déléguer et ce à quoi demander , exactement de la même façon qu’il décide quand appeler un autre outil.

Cas d’utilisation :

Utilisez des agents comme outils quand :

  • Vous souhaitez déléguer une sous-tâche spécialisée à un agent ciblé, par exemple un assistant général qui appelle un « agent de réservation de voyage » dédié lorsque l’utilisateur demande des vols.
  • L’agent externe doit décider quand et s’il faut impliquer l’agent interne, en fonction de la conversation : la délégation est pilotée par le modèle, et non codée en dur.
  • Vous n’avez pas besoin d’un contrôle explicite sur l’ordre d’exécution entre les agents : vous êtes bien avec l’agent externe orchestrant les choses par son propre raisonnement.

Conseil / Astuce

Chaque agent peut également utiliser un modèle différent en fonction de sa spécialisation et de ses exigences. Les agents plus complexes peuvent utiliser des modèles plus volumineux pour le raisonnement, tandis que les agents plus simples peuvent utiliser des modèles plus petits et plus rapides pour l’efficacité.

Considérations

Point à considérer Détails
Simplicité Agent-as-tool est le modèle multi-agent le plus léger. Vous convertissez un agent en outil et le transmettez à un autre agent. C’est l’étape suivante naturelle quand un agent n’est pas suffisant.
Latency Chaque délégation est une invocation complète de l’agent : l’agent externe appelle l’agent interne, qui appelle le LLM, qui peut appeler ses propres outils. Les appels imbriqués s’accumulent. Gardez les agents internes concentrés afin qu’ils résolvent rapidement.
Le routage est piloté par le modèle Le LLM de l’agent externe décide quand appeler l’agent interne, comme il décide quand appeler un outil. Cela signifie que le routage peut être imprévisible : si la description de l’outil est vague, le modèle peut appeler l’agent incorrect ou l’ignorer entièrement. Les descriptions spécifiques sont claires et critiques.
Visibilité limitée L’agent externe voit la réponse de texte finale de l’agent interne : il ne voit pas le raisonnement intermédiaire de l’agent interne, les appels d’outils ou le contexte. Si vous avez besoin de visibilité sur le comportement interne de l’agent, utilisez le suivi.
Isolation du contexte L’agent interne s’exécute avec ses propres instructions et outils. Il n’hérite pas automatiquement de l’historique de conversation ou du contexte de l’agent externe. Vous communiquez avec lui par le biais des arguments d’appel de l’outil, comme n’importe quel autre outil de fonction.

Fonctionnement

Les agents en tant qu’outils s’appuient sur la boucle d’appel d’outils que vous connaissez déjà. La seule différence est que la « fonction » appelée est elle-même un agent.

┌──────────────────────────────────────────────────────────┐
│  User: "Book me a flight to Paris and file the expense"  │
└──────────────┬───────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────┐
│  Outer agent reasons about the request                   │
│  → decides to call the travel-booking agent first        │
└──────────────┬───────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────┐
│  Inner agent (travel-booking) runs as a tool:            │
│  • receives: "Book a flight to Paris"                    │
│  • uses its own tools (search_flights, book_flight)      │
│  • returns: "Booked Flight AF123, $450"                  │
└──────────────┬───────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────┐
│  Outer agent receives the tool result                    │
│  → decides to call the expense-filing agent next         │
└──────────────┬───────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────┐
│  Inner agent (expense-filing) runs as a tool:            │
│  • receives: "File expense for Flight AF123, $450"       │
│  • uses its own tools (create_expense, attach_receipt)   │
│  • returns: "Expense report filed"                       │
└──────────────┬───────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────┐
│  Outer agent synthesizes both results:                   │
│  "Done! Booked Flight AF123 to Paris for $450 and filed  │
│   expense report."                                       │
└──────────────────────────────────────────────────────────┘

Points clés :

  1. L’agent interne ressemble à un outil de fonction. Du point de vue de l’agent externe, appeler un agent interne n’est pas différent d’appeler get_weather() ou search_database(). L’infrastructure gère la conversion de l’agent en outil avec un nom, une description et un paramètre d’entrée.
  2. L’agent interne s’exécute de manière autonome. Il possède ses propres instructions, outils et appels LLM. Il ne voit pas la conversation complète de l’agent externe — seulement l’entrée transmise par l’appel de l’outil.
  3. L’agent externe ne voit que le résultat final. Les étapes intermédiaires de l’agent interne (appels d’outils, raisonnement, nouvelles tentatives) sont invisibles pour l’agent externe. Il reçoit une réponse texte, tout comme n’importe quel résultat d’outil.

Étapes suivantes

Maintenant que vous pouvez composer des agents au sein d’un processus unique, l’étape suivante est Agent-à-Agent (A2A), ce qui permet aux agents de communiquer entre les limites du service et de l’organisation à l’aide d’un protocole standard.

Aller plus loin :