Agent-zu-Agent-Protokolle im Überblick: A2A-Agent-Cards, Tasks und wo MCP hineinpasst

Worum es geht

Das Agent2Agent-Protokoll (A2A) ist eine offene Spezifikation für die Kommunikation zwischen unabhängigen, möglicherweise undurchsichtigen Agentensystemen, die von unterschiedlichen Anbietern auf unterschiedlichen Frameworks gebaut wurden; ihr erklärtes Ziel ist eine gemeinsame Sprache und ein gemeinsames Interaktionsmodell, ohne dass Agents internen Zustand, Speicher oder Werkzeuge teilen. Version 1.0.0 ist die aktuelle Fassung, veröffentlicht unter der Linux Foundation, mit der Protocol-Buffer-Definition als normativer Quelle. Ihre Bausteine: eine Agent Card, ein JSON-Dokument, das ein Server veröffentlicht (abgerufen unter /.well-known/agent-card.json) und das Identität, Fähigkeiten, Skills, den Dienst-Endpunkt sowie die Sicherheitsschemata beschreibt, die ein Client verwenden muss (API-Schlüssel, HTTP-Authentifizierung, OAuth 2.0, OpenID Connect oder mutual TLS), dazu eine optionale, authentifizierte erweiterte Card; Tasks, die Arbeitseinheit, mit den Zuständen submitted, working, input-required, auth-required, completed, failed, canceled und rejected, wobei die beiden unterbrochenen Zustände die Kontrolle an den Client zurückgeben; Nachrichten, die während eines Tasks ausgetauscht werden, und Artefakte, die er erzeugt, beide aus Parts zusammengesetzt, die Text, Dateien oder strukturierte Daten sind; sowie Operationen, um eine Nachricht zu senden, sie zu streamen, einen Task abzurufen, aufzulisten, abzubrechen oder zu abonnieren, und um Push-Benachrichtigungskonfigurationen für Webhooks zu verwalten. Drei Bindings sind spezifiziert: JSON-RPC 2.0 über HTTP, gRPC und HTTP mit JSON; blockierende Aufrufe warten auf einen terminalen oder unterbrochenen Zustand, nicht blockierende geben sofort zurück, und der Client pollt, streamt oder empfängt Webhooks.

Warum es wichtig ist

Ein Agent, der an einen anderen delegiert, braucht Discovery (was kann er, wie authentifiziere ich mich), eine Task-Identität, die lang laufende Arbeit und menschliche Eingaben übersteht, sowie eine Möglichkeit, Ergebnisse zu erhalten, ohne eine Verbindung offen zu halten. Die Leitprinzipien der Spezifikation benennen genau diese Anliegen: Wiederverwendung von HTTP, JSON-RPC und Server-Sent Events, ein primär asynchrones Design für lange Tasks mit einer Person im Ablauf, sowie undurchsichtige Ausführung. Ihr Anhang zu MCP zieht die Grenze, auf die sich die beiden Projekte einigen: MCP standardisiert, wie sich ein Modell oder ein Agent mit Werkzeugen, APIs und Datenquellen verbindet; A2A standardisiert, wie Agents einander entdecken, Interaktion aushandeln und gemeinsame Tasks als Gleichrangige verwalten, und ein A2A-Server kann intern MCP nutzen, um seine Arbeit zu erledigen.

So wird es angewendet

• Eine Agent Card nur für Fähigkeiten veröffentlichen, die man tatsächlich bedient, und Skill-Beschreibungen konkret genug halten, damit ein Client danach routen kann.
• Lange Arbeit als Tasks modellieren und bei Klärungsbedarf input-required verwenden statt fehlzuschlagen; Clients sollten beide unterbrochenen Zustände behandeln.
• Pro Deployment ein Binding wählen und es in der Card dokumentieren; nicht erwarten, dass Clients mehrere ausprobieren.
• Empfangene Parts als Daten behandeln, genau wie Werkzeugergebnisse; das Protokoll trägt Inhalt, kein Vertrauen.

Stolpersteine

Version 1.0.0 hat Strukturen gegenüber früheren Fassungen geändert (der Migrationsanhang der Spezifikation listet brechende Änderungen auf, etwa den entfernten kind-Diskriminator und das verschobene Feld der erweiterten Card), daher müssen für 0.2 oder 0.3 geschriebene Bibliotheken geprüft werden. Eine Card beschreibt, was ein Agent behauptet; das Verhalten zu verifizieren bleibt Aufgabe des Clients.