- Ein Leitfaden, der sechs AI-Agent-Protokolle wie MCP, A2A, UCP, AP2, A2UI und AG-UI in einem einzigen Agentenszenario für die Lieferkette eines Restaurants zusammenführt und Schritt für Schritt mit praxisnahem Code erklärt, welches Problem jedes Protokoll löst
- Mit Googles Agent Development Kit (ADK) als Grundlage startet die Struktur mit einem leeren LLM und ergänzt die Protokolle nacheinander, bis Bestandsprüfung, Angebot, Bestellung, Zahlung und Dashboard-Rendering vollständig umgesetzt sind
- MCP ist jeweils für Tool-/Datenanbindung zuständig, A2A für die Kommunikation zwischen Agenten, UCP für die Standardisierung des Handels, AP2 für die Zahlungsautorisierung, A2UI für den UI-Aufbau und AG-UI für das Streaming
- Alle Protokolle teilen gemeinsame Muster wie Discovery über bekannte URLs, typisierte Schemas und standardisierte Event-Streams und sichern so die Kompatibilität im Ökosystem
- Es ist nicht nötig, alle sechs von Anfang an einzuführen; empfohlen wird ein Ansatz, bei dem sie je nach Bedarf schrittweise ergänzt werden
MCP (Model Context Protocol) — Tool- und Datenanbindung
- Ein Protokoll, das die erste Hürde beim Verbinden von Agenten mit Systemen und Daten löst und die manuelle Erstellung von Custom-Integrationscode für jede einzelne API beseitigt
- Wenn ein MCP-Server seine Tools bekannt macht (advertise), kann der Agent sie automatisch entdecken; dadurch entsteht ein einheitliches Standard-Verbindungsmuster für Hunderte von Servern
- Da MCP-Server von den Teams gepflegt werden, die das jeweilige System gebaut haben, erhält die Agentenseite immer aktuelle Tool-Definitionen, ohne Integrationscode schreiben oder aktualisieren zu müssen
- ADK unterstützt dies nativ über McpToolset; im Beispiel werden Datenbankabfragen gegen PostgreSQL (MCP Toolbox for Databases), Rezeptabfragen über Notion MCP und das Versenden von E-Mails an Lieferanten über Mailgun MCP umgesetzt
- Verbindung zur Inventar-Datenbank mit
ToolboxToolset
- Verbindung zu externen Diensten wie Notion und Mailgun mit
McpToolset
- Ein schlankes Muster, bei dem der MCP-Server per
npx-Befehl gestartet und ohne zusätzlichen Code direkt mit dem Agenten verbunden wird
A2A (Agent2Agent Protocol) — Kommunikation zwischen Agenten
- Ein Protokoll, das nach der Lösung des Datenzugriffs durch MCP das verbleibende Expertise-Problem adressiert und eine standardisierte Discovery- und Kommunikationsmethode für Remote-Agenten bereitstellt, die von unterschiedlichen Teams, Frameworks und Servern betrieben werden
- Jeder A2A-Agent veröffentlicht unter
/.well-known/agent-card.json eine Agent Card mit Name, Fähigkeiten und Endpoint; der Kitchen-Manager-Agent lädt diese und routet Anfragen zur Laufzeit an den passenden Agenten
- Beim Hinzufügen eines neuen Remote-Agenten muss nur die URL ergänzt werden; manuelle Codeänderungen oder Redeployments sind nicht nötig
RemoteA2aAgent in ADK routet pro Turn an genau einen Remote-Agenten; wenn gleichzeitige Anfragen an mehrere Remote-Agenten nötig sind, wird direkt das a2a-sdk verwendet- Mit der Funktion
to_a2a() lassen sich alle ADK-Agenten in einen A2A-Service umwandeln
- Selbst wenn Rohdaten wie Preisprüfung, Qualitätsstufen oder Lieferfenster nicht als API exponiert sind, bleiben sie über ein agentisches Interface zugänglich
UCP (Universal Commerce Protocol) — Standardisierung des Handels
- Ein Protokoll, das Bestellprozesse mit lieferantenspezifischen APIs vereinheitlicht und den Shopping-Lifecycle in modulare Funktionen standardisiert
- Streng typisierte Request-/Response-Schemas sorgen für Konsistenz; unabhängig davon, ob die darunterliegende Transportschicht REST, MCP, A2A oder EP (browserbasiertes Embedded Protocol) ist, funktioniert das Muster identisch
- Wie bei A2A ist die Discovery von Lieferantenkatalogen über das URL-Muster
/.well-known/ucp möglich
- Kein proprietäres SDK erforderlich; die Integration mit der standardisierten REST-API funktioniert direkt mit bestehenden HTTP-Clients
- Im Beispiel werden mit
CheckoutCreateRequest 10 Pfund Lachs und 3 Flaschen Olivenöl bestellt und mit PaymentCreateRequest Zahlungsanfragen aufgebaut
- Das UCP-Beispiel-Repository enthält auch ein Beispiel für einen AI-basierten Shopping-Assistenten, der ADK und A2A kombiniert
AP2 (Agent Payments Protocol) — Zahlungsautorisierung und Audit-Trail
- Während UCP Bestellgegenstand und Lieferant abwickelt, kümmert sich AP2 darum, wer den Kauf freigegeben hat, sowie um den Audit-Trail
- Typisierte Mandates liefern einen nicht abstreitbaren Nachweis der Absicht (non-repudiatable proof of intent), und auf jede Transaktion werden konfigurierbare Guardrails angewendet
- Gesamter Ablauf:
IntentMandate → PaymentMandate (signiert) → PaymentReceipt
- IntentMandate: setzt Guardrails wie erlaubte Händler, Ausgabenlimit, automatische Freigabe, Anforderungen an Erstattungsfähigkeit und Ablaufzeit
- PaymentMandate: eine an einen konkreten Warenkorb und Betrag gebundene Zahlungsfreigabe, die bei Überschreitung des Limits bis zur expliziten Freigabe durch einen Manager unsigniert bleibt
- PaymentReceipt: der Beleg, der den Audit-Trail abschließt
- Funktioniert als Erweiterung (extension) von UCP und ergänzt den Checkout-Flow um einen kryptografischen Autorisierungsnachweis
- Derzeit noch auf Stand v0.1; nicht im ADK-Kern integriert, sondern als separates Paket mit Typen verfügbar
A2UI (Agent-to-User Interface Protocol) — Dynamischer UI-Aufbau
- Ein Protokoll, das es Agenten ermöglicht, statt einfachem Text Dashboards, Bestellformulare und Lieferanten-Vergleichstabellen dynamisch zusammenzustellen
- Neue Layouts werden deklarativ im JSON-Format aus einem festen Katalog von 18 sicheren Komponenten-Primitiven wie Zeilen, Spalten und Textfeldern kombiniert
- UI-Struktur und Daten werden getrennt, sodass nur die Daten aktualisiert werden können, ohne Komponenten erneut zu übertragen
- Komponenten werden als flache Liste übertragen, deren Elemente sich per ID gegenseitig referenzieren
- Daten werden über ein separates
dataModelUpdate übermittelt
- Renderer auf Client-Seite wandeln das JSON in native UIs mit Lit, Flutter, Angular usw. um
- Derselbe Agent kann mit denselben 18 Primitiven völlig unterschiedliche Interfaces erzeugen, etwa Bestands-Checklisten, Bestellformulare oder Lieferantenvergleiche
- In der ADK-Weboberfläche (
adk web) lassen sich A2UI-Komponenten nativ rendern, sodass während der Entwicklung kein separater Renderer gebaut werden muss
- Mit dem A2UI Widget Builder lassen sich Layouts interaktiv zusammensetzen
AG-UI (Agent-User Interaction Protocol) — Streaming-Übertragung
- Anders als klassische REST-APIs haben Agenten komplexe Interaktionsmuster: Sie streamen Text schrittweise, rufen während der Antwort Tools auf und pausieren, um auf menschliche Eingaben zu warten
- AG-UI arbeitet als Middleware und wandelt frameworkspezifische Roh-Events in einen standardisierten SSE-Stream um
- Das Frontend muss nur typisierte Events wie
TEXT_MESSAGE_CONTENT oder TOOL_CALL_START empfangen und muss nicht wissen, welches Agent-Framework sie erzeugt hat
- ADK bietet zwar einen nativen
/run_sse-Endpoint, doch AG-UI löst die Probleme von Boilerplate-Parsingcode und Brüchen bei Änderungen des Event-Formats
- Durch Wrapping mit dem Paket
ag_ui_adk und Mounten in einer FastAPI-App lässt sich ein AG-UI-Streaming-Endpoint aufbauen
Gesamter integrierter Ablauf
- Wenn ein Nutzer „Lachsbestand prüfen, heutigen Großhandelspreis und die Qualitätsstufe abfragen und bei zu geringem Bestand 10 Pfund bei Example Wholesale bestellen sowie die Zahlung autorisieren“ anfordert, arbeiten die sechs Protokolle schrittweise zusammen
- Schritt 1 — Informationsbeschaffung: Inventar-Datenbank per MCP abfragen (
check_inventory) → per A2A den Remote-Agenten für Preis und Qualität abfragen (ask_agent)
- Schritt 2 — Transaktion abschließen: Checkout-Anfrage per UCP (
place_order) → Zahlungs-Mandate innerhalb der konfigurierten Guardrails per AP2 einholen (authorize_payment)
- Schritt 3 — Ergebnis anzeigen: Interaktive Widgets mit A2UI aufbauen → Tool-Aufrufe und Textantworten mit AG-UI in Echtzeit streamen
Tipps zur Nutzung der Protokolle
- Die Architektur bleibt nur dann sauber, wenn genau verstanden wird, welches Problem jedes Protokoll löst
- Nicht alle sechs werden vom ersten Tag an benötigt; in den meisten Fällen beginnt man mit MCP und ergänzt dann schrittweise Multi-Agent-Kommunikation, Commerce, Zahlungen, Rich UI und Streaming entsprechend wachsender Anforderungen
- Bevor auf Basis der Protokolle entwickelt wird, sollten zuerst ADK-Integration, offizielle SDKs und Beispielcode geprüft werden, um unnötige Eigenimplementierungen zu vermeiden
- Die Protokolle befinden sich noch in der Reifung, aber wer Muster wie Discovery über bekannte URLs, typisierte Schemas und standardisierte Event-Streams früh übernimmt, sichert sich Kompatibilität mit dem Ökosystem aus Tools, Services und Agenten
1 Kommentare
Wenn man sie so zusammenfasst, gibt es unglaublich viele Protokolle rund um AI.