- Démarrage
- Meilleures pratiques
- Modélisation de l'organisation dans Orchestrator
- Meilleures pratiques d'automatisation
- Optimisation de l'infrastructure Unattended à l'aide de modèles de machine
- Organisation des ressources avec des balises
- Exportation des grilles dans l'arrière-plan
- Appliquer la gouvernance de la connexion Integration Service au niveau de l'utilisateur
- Locataire
- À propos du contexte du locataire
- Recherche de ressources dans un locataire
- Gestion des Robots
- Connexion des Robots à Orchestrator
- Enregistrement des identifiants du Robot dans CyberArk
- Stockage des mots de passe de l’Unattended Robot dans Azure Key Vault (lecture seule)
- Stockage des informations d’identification de l’Unattended Robot dans HashiCorp Vault (lecture seule)
- Stockage des informations d'identification du robot Unattended dans AWS Secrets Manager (lecture seule)
- Suppression des sessions Unattended déconnectées et qui ne répondent pas
- Authentification du Robot
- Authentification du Robot avec les informations d'identification du client
- Configurer les capacités d’automatisation
- Solutions
- Audit
- Intégration des magasins d'identifiants
- Gestion des magasins d'identifiants
- Accès au dossier du magasin d’informations d’identification
- Affectation de magasins d'informations d'identification à des dossiers
- L'Orchestrator Credentials Proxy
- Débogage d'Orchestrator Credentials Proxy
- Managing credential proxies
- Paramètres
- Registre
- Notifications
- Contexte des dossiers
- Processus (Processes)
- Tâches (Jobs)
- Apps
- Déclencheurs (Triggers)
- Journaux (Logs)
- Surveillance
- Index
- Files d'attente (Queues)
- Actifs
- À propos des actifs
- Gestion des actifs dans Orchestrator
- Gestion des actifs dans Studio
- Stockage des ressources dans Azure Key Vault (lecture seule)
- Stockage des ressources dans HashiCorp Vault (lecture seule)
- Stockage des ressources dans AWS Secrets Manager (lecture seule)
- Stocker des ressources dans Google Secret Manager (lecture seule)
- Connexions
- Règles métier
- Compartiments de stockage
- Passerelle d’agent
- Tests d'Orchestrator
- Service de catalogue de ressources
- Intégrations
- Résolution des problèmes
À propos des agents A2A
Agent2Agent est un protocole ouvert pour les conversations multi-tours entre les agents et son intégration avec MCP dans Agent Gateway.
Les agents A2A sont disponibles en version préliminaire.
Agent2Agent est un protocole ouvert pour la communication entre les agents d'IA. Il offre aux agents créés dans des environnements et des fournisseurs différents un moyen de communiquer entre eux.
UiPath utilise A2A pour les agents conversationnels, où un agent envoie un message, l'agent de l'autre côté tient le contexte et l'échange se poursuit sur plusieurs tours. A2A prend également en charge les échanges uniques, mais le cas multi-tours est ce sur quoi Agent Gateway est construit.
Pour plus de détails sur le protocole lui-même, vérifiez la spécification A2A. Pour connaître l'endroit où A2A s'intègre avec MCP sur la plateforme, vérifiez About Agent Gateway.
Pourquoi les appels passent-ils par la plate-forme
L'enregistrement d'un agent dans Agent Gateway fait plus que stocker une adresse et vous donne plus qu'un proxy vers une ressource distante. L'agent devient une ressource de plateforme qui réside dans un dossier, donc:
- Les autorisations de dossier régissent qui peut appeler l'agent.
- Les garde-fous peuvent filtrer les messages avant qu'ils ne quittent la plate-forme.
- Les appels apparaissent dans Traçages.
- Les modifications apportées à l’agent sont auditées.
- L'agent peut être déployé dans le cadre d'une solution au lieu d'être reconfiguré manuellement dans chaque environnement.
Directions A2A entrantes et sortantes
Les appels A2A s'exécutent dans l'une des deux directions. Elles diffèrent sur presque tout ce qui suit: ce que vous configurez, le nombre d’authentifications, et ce qui peut échouer. Les pages ci-dessous sont divisées le long de cette ligne, il est donc utile de spécifier celle dans laquelle vous vous trouvez.
| Direction | Ce que cela signifie | Ce que vous configurez |
|---|---|---|
| Entrant (externe à UiPath) | Un agent ou un client externe tient une conversation avec un agent conversationnel que vous avez déployé sur la plateforme. UiPath est la destination. | Rien du côté UiPath. Chaque agent conversationnel déployé parlera déjà en A2A et dispose d’une carte d’agent. |
| Sortant (UiPath vers externe) | Un agent hébergé en dehors d'UiPath est appelé depuis la plateforme, soit directement, soit en tant qu'outil dans un agent UiPath. UiPath agit plutôt comme une passerelle gouvernée. | Vous enregistrez l'agent une fois dans Agent Gateway > Agents A2A, en fournissant sa carte et les informations d'identification qu'il attend. |
La direction est déterminée par l'endroit où réside l'agent, et non par qui effectue l'appel. Un client externe peut faire les deux: s'adresser à l'un de vos agents conversationnels et appeler un agent distant que vous avez enregistré, via son URL UiPath.
Dans ce guide
- Entrant (externe à UiPath): un client externe appelle un agent que vous avez déployé. Rien à enregistrer.
- Sortant (UiPath vers externe): la plateforme appelle un agent hébergé ailleurs, via Agent Gateway.
- Tester et résoudre les problèmes A2A: comment appeler directement un agent et comment résoudre les erreurs que vous êtes le plus susceptible de rencontrer.