A2A protocol

Die Agent Registry indexiert Agent2Agent-Agentenkarten (A2A-Agentenkarten), Transport-Schnittstellen und Inline-Skills, damit Sie und Ihre Orchestrator-Agenten Agenten in Ihrer Google Cloud -Umgebung finden und aufrufen können. Autonome KI-Agenten können das A2A-Protokoll verwenden, um Nachrichten auszutauschen und Aufgaben zu delegieren, ohne ihren internen Status, ihre Prompts oder ihre Tools preiszugeben.

Beziehung zwischen KI-Agenten, A2A und MCP

In Multi-Agenten-Architekturen können die folgenden offenen Standards kombiniert werden, die in der Agent Registry katalogisiert sind:

  • Agent2Agent-Protokoll (A2A): Standardisiert die Peer-to-Peer-Kommunikation zwischen einem A2A-Client, z. B. einem Orchestrator-Agenten oder einer für Nutzer sichtbaren Anwendung, und einem Remote-A2A-Agenten. Der Client sendet Nachrichten in natürlicher Sprache oder strukturierte Nachrichten und empfängt zustandsorientierte Aufgabenaktualisierungen oder Artefakte, ohne dass er Einblick in das zugrunde liegende Modell, das Speichersubstrat oder die interne Reasoning Loop des Remote-Agents benötigt. Die Agent Registry katalogisiert sowohl integrierte Google-Agenten, die über Google Cloud -APIs bereitgestellt werden, als auch benutzerdefinierte A2A-Agenten, die Sie in Ihrer eigenen Umgebung bereitstellen. Ein Architekturbeispiel für das Hosten benutzerdefinierter A2A-Agenten finden Sie unter A2A-Agenten in Cloud Run – Übersicht.
  • Model Context Protocol (MCP): Standardisiert die Toolausführung zwischen Client und Server, wobei ein Agent eine Verbindung zu einem MCP-Server herstellt, um deterministische Tools aufzurufen und strukturierte Datenressourcen zu lesen.

In Agent Registry kann Ihr Orchestrator-Agent eine einzelne Registry abfragen, um spezialisierte A2A-Sub-Agenten für die mehrstufige Delegation zu finden, sowie MCP-Server und eigenständige Skills für die direkte Tool-Nutzung.

Protokollversionen und Erkennung von Agentenkarten

Jeder A2A-konforme Agent beschreibt seine Identität, Endpunkte und Funktionen in einem JSON-Metadatendokument, das als Agentenkarte (agent-card.json) bezeichnet wird.

Die Agent Registry unterstützt die Versionen 1.0 (empfohlen) und 0.3 der A2A-Protokollspezifikation. Informationen zu bestimmten Agent Card-Feldern und -Strukturen dieser Versionen finden Sie unter Agent Card-Schema.

Wie Agent Registry Agentenkarten indexiert

Unabhängig davon, ob ein A2A-Agent über die automatische Registrierung aufgenommen oder über die manuelle Registrierung hinzugefügt wird, validiert die Agent Registry die Agentenkarte und erstellt eine schreibgeschützte Agent-Erkennungsressource mit den folgenden Informationen:

  • Nutzlast der KI-Agentenkarte: Die Agent Registry speichert die vollständige JSON-Nutzlast im Feld card der Ressource Agent, wobei type auf A2A_AGENT_CARD gesetzt ist.
  • Erkennungsfelder: Die Agent Registry extrahiert die displayName, description, version, den Transport-protocols und die Inline-skills des KI-Agenten aus der Agentenkarte und speichert sie in der Agent-Ressource. Sie können diese Funktionen suchen und filtern, ohne einzelne /.well-known/agent-card.json-Endpunkte über Dienste hinweg abzurufen.

Google Cloud -Dienste und verwaltete Laufzeiten stellen nicht immer eine öffentliche /.well-known/agent-card.json-URL bereit. Stattdessen rufen Sie und Ihre Clientanwendungen die Agentenkarte direkt aus der Agent Registry ab. Einige Agenten bieten auch eine erweiterte Agentenkarte mit zusätzlichen Details, die nur authentifizierten Clients zur Verfügung stehen. Wenn eine Agentenkarte capabilities.extendedAgentCard auf true setzt, können authentifizierte Clients die erweiterte Agentenkarte am Laufzeitendpunkt des KI-Agenten abrufen, um diese Details zu erhalten.

Transportbindungen und Kernvorgänge

Eine Transportbindung definiert, wie ein Client Anfragen formatiert und über das Netzwerk an einen A2A-Agenten sendet. Das A2A-Protokoll unterstützt die folgenden Transportoptionen, damit Agenten, die auf verschiedenen Plattformen erstellt wurden, kommunizieren können:

  • HTTP+JSON: HTTPS-Anfragen, die JSON-Nutzlasten senden und empfangen.
  • JSON-RPC: HTTPS-Anfragen, die den Vorgangsnamen und die Parameter in einer JSON-RPC-Nachricht verpacken.
  • gRPC: Binäre gRPC-Aufrufe über TLS für die Kommunikation mit niedriger Latenz zwischen Diensten.

Die Agent Registry zeichnet die unterstützten Transporttypen jedes Agenten und die Endpunkt-URLs des Agenten in der Ressource Agent auf. Da Endpunkt-URLs je nach Google Cloud -Dienst und -Bereitstellung variieren, sollten Sie URLs in Ihrem Code nicht hartcodieren. Suchen Sie stattdessen zur Laufzeit die Endpunkt-URL und den Transport des KI-Agenten in der Agent Registry.

Unabhängig davon, welchen Transport ein Agent verwendet, interagieren Clients mit dem Agenten über dieselben grundlegenden A2A-Vorgänge:

Vorgang Beschreibung
SendMessage Sendet eine Nachricht, um eine neue Aufgabe zu starten oder eine Unterhaltung fortzusetzen. Der KI-Agent gibt entweder eine sofortige Antwort oder eine Aufgabe zurück, die Sie verfolgen können.
SendStreamingMessage Sendet eine Nachricht und streamt Live-Statusupdates, Teilantworten und Ergebnisse, während der KI-Agent arbeitet, sofern der KI-Agent Streaming unterstützt.
GetTask Prüft den aktuellen Status und ruft alle Ausgaben für eine vorhandene Aufgabe ab.
ListTasks Listet Aufgaben in einer Unterhaltung oder einem Projekt auf, sofern dies vom KI-Agenten unterstützt wird.
SubscribeToTask Stellt die Verbindung zu einer laufenden Aufgabe wieder her, um Live-Updates zu streamen, bis die Aufgabe pausiert oder abgeschlossen ist.
CancelTask Fordert den KI-Agenten auf, eine laufende Aufgabe abzubrechen, wenn der Abbruch unterstützt wird.
GetExtendedAgentCard Ruft die erweiterte Agentenkarte des KI-Agenten mit zusätzlichen Details ab, die nur authentifizierten Clients zur Verfügung stehen.

Aufgabenlebenszyklus und Status mit mehreren Interaktionen

A2A trennt die Kontinuität der Unterhaltung von einzelnen Ausführungseinheiten mithilfe von zwei Kennungen:

  • Kontext-ID (contextId): Gruppiert zusammengehörige Multi-Turn-Interaktionen innerhalb einer gemeinsamen Sitzung, damit der Remote-Agent den Gesprächskontext über aufeinanderfolgende Anfragen hinweg beibehalten kann.
  • Aufgaben-ID (taskId): Identifiziert eine bestimmte asynchrone oder synchrone Arbeitseinheit, die erstellt wird, wenn ein A2A-Client eine Nachricht sendet.

Während ein Remote-Agent eine Anfrage verarbeitet, durchläuft die Aufgabe die folgenden A2A-Lebenszyklusstatus:

Bundesland Kategorie Beschreibung
TASK_STATE_SUBMITTED Aktiv Der Remote-Agent hat die Anfrage akzeptiert und die Aufgabe zur Ausführung in die Warteschlange gestellt.
TASK_STATE_WORKING Aktiv Der Remote-Agent führt aktiv Schlussfolgerungen durch, ruft Tools auf oder generiert Artefakte für die Aufgabe.
TASK_STATE_INPUT_REQUIRED Pausiert Die Ausführung wird pausiert, während auf eine Folgeeingabe, eine Klarstellung oder eine Human-in-the-Loop-Bestätigung für dieselbe taskId und contextId gewartet wird.
TASK_STATE_AUTH_REQUIRED Pausiert Die Ausführung wird pausiert, bis der Client die Authentifizierung oder einen Ablauf zur Nutzereinwilligung für eine nachgelagerte Ressource abgeschlossen hat.
TASK_STATE_COMPLETED Terminal Die Aufgabe wurde erfolgreich abgeschlossen und hat die endgültige Antwort oder die Ausgabeartefakte zurückgegeben.
TASK_STATE_FAILED Terminal Die Aufgabe wurde aufgrund eines Ausführungs- oder Downstream-Dienstfehlers beendet.
TASK_STATE_CANCELED Terminal Die Aufgabe wurde vor dem Abschluss abgebrochen.
TASK_STATE_REJECTED Terminal Der Remote-Agent hat die Ausführung der angeforderten Aufgabe abgelehnt.

A2A-Skills, eigenständige Skills und MCP-Tools

Die Agent Registry indexiert drei verschiedene Funktionsmechanismen, damit Sie für jeden Workflow das richtige Integrationsmuster auswählen können:

  • Inline-A2A-Skills: Das Feld skills in der Agent-Erkennungsressource eines Agenten enthält JSON-Metadaten, einschließlich id, name, description, tags und examples, die in die Agentenkarte eingebettet sind. Inline-A2A-Skills geben an, welche übergeordneten Aufgaben ein Orchestrator-Agent über einen A2A-Transport an diesen Remote-Agenten delegieren kann.
  • Eigenständige Skills: Unabhängige Skill- und SkillRevision-Ressourcen auf oberster Ebene in der Agent Registry enthalten versionierte ZIP-Archive mit Anweisungen in einer SKILL.md-Datei und optionalen Skripts. Ein KI-Agent lädt einen eigenständigen Skill in seinen eigenen Kontext herunter, anstatt die Ausführung an einen anderen KI-Agenten zu delegieren. Einen vollständigen Vergleich zwischen Inline-A2A-Skills und eigenständigen Skills finden Sie unter Unterschiede zwischen eigenständigen und A2A-Skills.
  • MCP-Tools: Das Feld tools in einer McpServer-Erkennungsressource enthält strukturierte Funktionsschemas, die von einem registrierten MCP-Server bereitgestellt werden. Ein KI-Agent ruft diese direkt auf, um Daten abzufragen oder deterministische Vorgänge auszuführen.

Laufzeitsicherheit, Governance und Agentenaufrufe

Die Agent Registry dient als Katalog zum Entdecken von A2A-Agenten. Die Laufzeitauthentifizierung, Autorisierung, Inhaltsprüfung, Audit-Protokollierung und Kontingenterzwingung erfolgen, wenn Ihr Client- oder Orchestrator-Agent den Ziel-Agent aufruft:

Nächste Schritte