- Erste Schritte
- Best Practices
- Organisationsmodellierung im Orchestrator
- Beste Praktiken für die Automatisierung (Automation Best Practices)
- Optimieren von Unattended-Infrastruktur mithilfe von Maschinenvorlagen
- Organisieren von Ressourcen mit Tags
- Exportieren von Rastern im Hintergrund
- Durchsetzung der Governance der Integration Service-Verbindung auf Benutzerebene
- Mandant
- Über den Kontext „Mandant“
- Suche nach Ressourcen in einem Mandanten
- Verwaltung von Robotern
- Verbindung von Robotern mit Orchestrator
- Speicherung von Roboterzugangsdaten in CyberArk
- Speichern der Kennwörter von Unattended-Robotern im Azure Key Vault (schreibgeschützt)
- Speichern der Anmeldeinformationen von Unattended-Robotern im HashiCorp Vault (schreibgeschützt)
- Speichern der Anmeldeinformationen von Unattended-Robotern im AWS Secrets Manager (schreibgeschützt)
- Löschen von getrennten und nicht reagierenden Unattended-Sitzungen
- Roboter-Authentifizierung
- Roboter-Authentifizierung mit Client-Anmeldeinformationen
- Konfigurieren von Automatisierungsfunktionen
- Solutions (Lösungen)
- Audit
- Enforced encryption
- Einstellungen
- Registrierung
- Benachrichtigungen
- Events
- Anzeigen und Zugreifen auf Benachrichtigungen
- Anzeigen und Zugreifen auf E-Mail-Benachrichtigungen
- Es werden nur ungelesene Benachrichtigungen angezeigt
- Alle Benachrichtigungen als gelesen markieren
- Alle Benachrichtigungen löschen
- Löschen von Benachrichtigungen
- Abonnieren von Ereignissen
- Abbestellen von Ereignissen
- Ordnerkontext
- Prozesse
- Jobs
- Apps
- Auslöser
- Protokolle
- Überwachung
- Indizes
- Warteschlangen
- Assets
- Über Assets
- Verwalten von Assets in Orchestrator
- Verwalten von Assets in Studio
- Speichern von Assets im Azure Key Vault (schreibgeschützt)
- Speichern von Assets im HashiCorp Vault (schreibgeschützt)
- Speichern von Assets im AWS Secrets Manager (schreibgeschützt)
- Speichern von Assets in Google Secret Manager (schreibgeschützt)
- Verbindungen
- Geschäftsregeln
- Speicher-Buckets
- Agent-Gateway
- Testverfahren in Orchestrator
- Ressourcenkatalogdienst
- Integrationen
- Fehlersuche und ‑behebung
Über A2A-Agents
Agent2Agent (A2A), ein offenes Protokoll für mehrstufige Konversationen zwischen Agents, und wie es neben MCP in Agent Gateway passt.
A2A Agents ist in der Vorschau verfügbar.
Agent2Agent (A2A) ist ein offenes Protokoll für die Kommunikation zwischen KI-Agents. Sie bietet Agents, die auf unterschiedlichen Frameworks und von verschiedenen Anbietern basieren, eine gemeinsame Möglichkeit, miteinander zu kommunizieren.
UiPath verwendet A2A für Conversational Agents, bei denen ein Agent eine Nachricht sendet, der Agent auf der anderen Seite den Kontext enthält und der Austausch über mehrere Gesprächsrunden fortgesetzt wird. A2A unterstützt auch einzelne Austausche, aber der mehrstufige Fall ist das, worum es in Agent Gateway gibt.
Weitere Informationen zum Protokoll selbst finden Sie in der A2A-Spezifikation. Wo A2A neben MCP auf der Plattform passt, finden Sie unter Über Agent Gateway.
Warum Anrufe über die Plattform laufen
Bei der Registrierung eines Agents in Agent Gateway wird nicht nur eine Adresse gespeichert, sondern Sie erhalten mehr als einen Proxy für eine Remote-Ressource. Der Agent wird zu einer Plattformressource, die sich in einem Ordner befindet, also:
- Ordnerberechtigungen regeln, wer den Agent aufrufen kann.
- Guardrails können Nachrichten überprüfen, bevor sie die Plattform verlassen.
- Aufrufe werden in der Ablaufverfolgung angezeigt.
- Änderungen am Agent werden geprüft.
- Der Agent kann als Teil einer Lösung bereitgestellt werden, anstatt in jeder Umgebung manuell neu konfiguriert zu werden.
Eingehende und ausgehende A2A-Richtungen
A2A-Aufrufe werden in eine von zwei Richtungen ausgeführt. Sie unterscheiden sich in fast allem, was schief läuft: was Sie konfigurieren, wie viele Authentifizierungen es gibt und was schief gehen kann. Die folgenden Seiten sind entsprechend dieser Linie geteilt, sodass Sie wissen können, auf welcher Sie sich befinden.
| Richtung | Was es bedeutet | Was Sie konfigurieren |
|---|---|---|
| Eingehend (extern zu UiPath) | Ein externer Agent oder Client führt ein Gespräch mit einem Conversational Agent, den Sie auf der Plattform bereitgestellt haben. UiPath ist das Ziel. | Nichts auf der UiPath-Seite. Jeder bereitgestellte Agent spricht bereits A2A und verfügt über eine Agent-Karte. |
| Ausgehend (UiPath nach extern) | Ein Agent, der außerhalb von UiPath gehostet wird, wird über die Plattform aufgerufen, entweder direkt oder als Tool innerhalb eines UiPath-Agents. UiPath fungiert als gesteuertes Gateway davor. | Sie registrieren den Agent einmal unter Agent Gateway > A2A Agents und geben seine Karte und die von ihm erwarteten Anmeldeinformationen an. |
Die Richtung wird durch den Ort des Agents bestimmt, nicht durch den, der den Anruf tätigt. Ein externer Client kann beides tun: mit einem Konversationsagenten von Ihnen sprechen und einen von Ihnen registrierten Remote-Agent über seine UiPath-URL aufrufen.
In diesem Handbuch
- Eingehend (extern zu UiPath): Ein externer Client ruft einen von Ihnen bereitgestellten Agent auf. Nichts zu registrieren.
- Ausgehend (UiPath nach extern): Die Plattform ruft einen Agent auf, der an anderer Stelle über das Agent Gateway gehostet wird.
- Testen und Fehlerbehebung bei A2A: Wie Sie einen Agent direkt aufrufen und wie Sie die Fehler beheben, die am wahrscheinlichsten auftreten.