Wann man dazu greift
- Agenten aus verschiedenen Frameworks interoperieren müssen.
- Interne Logik privat bleiben muss.
- Verteilte Skalierung oder vendor-neutrale Schnittstellen erforderlich sind.
/pattern/a2a/
Offener Standard für interoperable Agent-zu-Agent-Kommunikation über System- und Netzwerkgrenzen hinweg. Entfernte Agenten können als Tools, innerhalb von Graphen oder in Schwärmen aufgerufen werden, als wären sie lokal.
In der PraxisEin auf Google ADK aufgebauter Planungs-Agent ruft einen auf Microsoft Agent Framework aufgebauten Reisebuchungs-Agenten über A2A auf, ohne dass eines der Systeme eigenen Connector-Code benötigt.
Wann man dazu greift
Wann es nach hinten losgeht
Die Abwägung
Anbieterunabhängigkeit und Isolation werden auf Kosten eines noch unreifen Tooling-Ökosystems und zusätzlichen Protokolloverheads gewonnen.
Stell dir andere Agenten als Dienste in einem gemeinsamen Netzwerk vor. Ein Agent — der Client — orchestriert einen Auftrag; er ruft Remote-Agenten auf, jeder wie ein Tool aufrufbar, egal auf welcher Maschine, von welchem Anbieter oder Framework er läuft.
Der Haken, der es zu einem Protokoll und nicht nur zu einer API macht: Jeder Remote-Agent ist opak. Der Aufrufer sieht eine Capability und ein Ergebnis — nie die Prompts, das Memory, die Tools oder das Reasoning des Remote-Agenten. Agenten arbeiten als opake Peers zusammen, ohne mit der Codebasis des jeweils anderen zu verschmelzen.
Zwei Agenten arbeiten über ein gemeinsames Protokoll zusammen.
A2A nutzt bewusst den Web-Stack wieder: HTTP, JSON-RPC 2.0 und Server-Sent Events fürs Streaming. Ein Client-Agent entdeckt einen Remote-Agenten über dessen Agent Card, authentifiziert sich und sendet dann Nachrichten, die der Remote-Agent in einen Task mit definiertem Lebenszyklus verwandelt.
discover → authenticate → message/send → Task & Artefakte streamen
Der Agent, der initiiert. Er entdeckt Remote-Agenten, entscheidet, was er delegiert, sendet Nachrichten und führt die zurückkommenden Artefakte in seine eigene Antwort zusammen.
Ein A2A-Server, der eine Agent Card bewirbt und Tasks erfüllt. Er ist opak: Aufrufer sehen Capabilities und Ergebnisse, nie seine Tools, sein Memory oder sein Reasoning.
JSON-Metadaten, bereitgestellt unter /.well-known/agent-card.json — die Visitenkarte des Remote-Agenten: Skills, Endpoint-URL, Version und die Sicherheitsschemata, die ein Aufrufer erfüllen muss.
Bewirbt, wer der Agent ist und was er kann, sodass ein Aufrufer entscheiden kann, ob und wie er ihn aufruft — ohne Code zu lesen.
Eine ID-basierte Arbeitseinheit mit definiertem Lebenszyklus. Das gemeinsame Objekt zwischen Aufrufer und Aufgerufenem — was verlangt wurde, was in Arbeit ist, was beendet wurde oder fehlschlug.
Messages tragen Gesprächszüge zwischen Agenten; Artefakte sind die gegen einen Task zurückgelieferten Ergebnisse — Dokumente, Daten, Bilder. Interner Zustand wird nie mitübertragen.
Gebaut für den Enterprise-Einsatz und den Dauerbetrieb. A2A geht davon aus, dass Arbeit asynchron ist: Tasks können Minuten oder Stunden laufen, ihren Fortschritt über SSE streamen oder Push-Benachrichtigungen auslösen, wenn sie fertig sind. Es ist modalitätsunabhängig (Text, Dateien, Audio, Video) und stützt sich auf standardmäßige HTTPS-Auth — dieselben Kontrollen, die du bereits für jede Web-API betreibst.
# flight_agent.py — expose an agent over A2A
from a2a.types import AgentCard, AgentSkill, AgentCapabilities
from a2a.server.apps import A2AStarletteApplication
from a2a.server.request_handlers import DefaultRequestHandler
card = AgentCard(
name="Flight Booking Agent",
description="Searches and books flights between cities.",
url="https://flights.example.com/a2a",
version="1.0.0",
capabilities=AgentCapabilities(streaming=True),
skills=[AgentSkill(
id="search_flights",
name="Search flights",
description="Find flights between two cities on a date.",
)],
)
handler = DefaultRequestHandler(agent_executor=FlightExecutor())
# served at /.well-known/agent-card.json + the A2A endpoint
app = A2AStarletteApplication(agent_card=card, http_handler=handler)Zwei offene Protokolle überqueren die Grenze eines einzelnen Frameworks. MCP standardisiert, wie ein Agent mit einem Tool spricht; A2A standardisiert, wie ein Agent mit einem anderen Agenten spricht. Häufig werden beide eingesetzt.
Ein lokaler Agent ruft einen entfernten Agenten über A2A für eine einfache Abfrage auf, die ein direkter Funktionsaufruf wäre. Latenz und Kosten vervielfachen sich.
Lösung · A2A für grenzüberschreitende oder framework-übergreifende Aufrufe reservieren. Für gleiche-Runtime-Operationen In-Process-Tools verwenden.
Ein interner Agent akzeptiert eine A2A-Nachricht von einem externen Agenten, ohne die Identität oder Berechtigungen des Absenders zu prüfen.
Lösung · Gegenseitiges TLS und signierte Claims für jede A2A-Interaktion. Externe Agenten standardmäßig als nicht vertrauenswürdig behandeln.
Der Client blockiert auf message/send für einen lang laufenden Job, ignoriert Streaming und läuft in einen Timeout, bevor die Aufgabe abgeschlossen ist.
Lösung · Den Task-Lifecycle handhaben. Über SSE streamen oder eine Push-Benachrichtigung für Jobs registrieren, die länger als die Anfrage dauern.
Nächstes Pattern
Patterns, Frameworks und Seiten durchsuchen.