Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
La page précédente a montré comment composer des agents au sein d’un processus unique : un agent appelle un autre en tant qu’outil de fonction, et l’infrastructure gère le reste. Ce modèle fonctionne bien lorsque tous vos agents vivent dans la même application, partagent le même runtime et sont gérés par la même équipe.
Mais les systèmes d’agents réels doivent souvent communiquer entre les frontières. Agent-to-Agent (A2A) est un protocole ouvert conçu pour cela exactement. Il définit une méthode standard pour que les agents se découvrent, échangent des messages et coordonnent les tâches ( via HTTP, sur n’importe quelle limite, dans n’importe quel langage ou infrastructure). Agent Framework fournit une intégration A2A intégrée afin de pouvoir héberger et appeler des agents conformes à A2A avec une configuration minimale.
Cas d’utilisation :
Utilisez A2A lorsque vos agents doivent franchir une limite que la composition in-process ne peut pas gérer.
- Limites du service. Votre agent de réservation de voyage s’exécute en tant que microservice, et votre agent de classement des dépenses s’exécute comme un autre. Ils ne peuvent pas s’appeler les uns les autres en tant qu’outils de fonction intégrés au processus; ils nécessitent un protocole réseau.
- Limites de l’équipe. Une équipe partenaire possède un agent de « conformité-révision ». Vous n’avez pas accès à leur code, à leur modèle ou à leur déploiement. Vous devez simplement lui envoyer une demande et obtenir une réponse.
- Limites organisationnelles. Un fournisseur tiers propose un agent spécialisé (traitement des documents, révision légale, triage médical). Vous avez besoin d’un moyen standard de le découvrir, de comprendre ce qu’il peut faire et de communiquer avec lui, quel que soit le framework ou le langage avec lequel il est créé.
- Évolution indépendante. Vos agents ont besoin de différents cycles de mise en production, de différentes équipes ou de différentes langues, sans couplage étroit de leurs implémentations.
Conseil / Astuce
Si vos agents vivent tous dans le même processus et sont gérés par la même équipe, les agents en tant qu’outils sont plus simples et ont moins de surcharge. A2A ajoute de la valeur lorsque vous franchissez une limite de processus, de service ou d’organisation.
Considérations
| Point à considérer | Détails |
|---|---|
| Interopérabilité | A2A est indépendant du framework. Votre agent .NET peut appeler un agent Python, un agent LangChain ou tout agent qui implémente le protocole. Il s’agit de la valeur principale d’A2A : c'est le « HTTP de la communication entre agents ». |
| Surcharge réseau | Chaque appel A2A est une requête HTTP. Cela ajoute une latence par rapport aux appels d’agent en tant qu’outil intraprocessus. Pour les voies sensibles aux performances, maintenez les agents colocalisés ou utilisez A2A uniquement lorsqu’une limite existe réellement. |
| Complexité opérationnelle | Les agents distants sont des services distribués. Vous devez gérer les défaillances réseau, les délais d’attente, les nouvelles tentatives et le contrôle de version, les mêmes problèmes que ceux que vous avez avec toute communication de service à service. |
| Découverte au moment de l’exécution | Les cartes d’agent rendent la découverte dynamique, mais vous devez toujours savoir où regarder. En production, vous allez généralement configurer des points de terminaison d’agent connus ou utiliser un registre. |
| État de la conversation | L’agent distant gère son propre état de conversation (repéré par l'ID de contexte). Votre agent ne voit pas le raisonnement interne de l’agent distant, mais seulement ses réponses. Si l’agent distant redémarre et perd l’état, votre contexte de conversation peut être perdu. |
Étapes suivantes
Maintenant que vos agents peuvent communiquer au-delà de n’importe quelle frontière, l’étape finale du parcours est les workflows: orchestration explicite en graphes pour les processus multi-étapes, multi-agents où vous avez besoin d’un contrôle total sur l’ordre d’exécution, l’état et la récupérabilité.
Aller plus loin :
- Intégration A2A : guide d’implémentation pour l’hébergement et l’appel d’agents A2A
- Agents en tant qu’outils — un modèle de composition dans le processus plus simple