AI-Agent-Protokolle erklärt: MCP, A2A, ACP und AG-UI

Kurzantwort

MCP, A2A, ACP und AG-UI ersetzen einander nicht direkt. Sie standardisieren unterschiedliche Grenzen in einem Agent-System.

Protokoll	Hauptproblem	Typische Grenze
MCP	Wie eine AI-App Tools, Daten, Prompts und Kontext nutzt	Agent/Host zu Tool- oder Resource-Server
A2A	Wie ein Agent Arbeit an einen anderen delegiert	Agent-zu-Agent-Aufgaben
ACP	Wie Agenten Fähigkeiten interoperabel anbieten	Agent-Service-Interoperabilität
AG-UI	Wie ein Agent Zustand und Aktionen an die UI streamt	Agent-Backend zu Frontend

Für Produktion lautet die Frage selten "welches Protokoll gewinnt?". Besser ist: "Welche Systemgrenze wollen wir standardisieren?"

Warum Agent-Protokolle wichtig sind

Frühe Agent-Systeme verdrahten Tools, UI-Events und Delegation oft fest in einer App. Das funktioniert für Prototypen, wird aber fragil, wenn mehrere Tools, Teams, Anbieter und Oberflächen beteiligt sind.

Protokolle trennen Verantwortlichkeiten:

Tools und Datenquellen können wiederverwendbar bereitgestellt werden.
Agents können Arbeit delegieren, ohne Implementierungsdetails offenzulegen.
Frontends können Fortschritt, Toolaufrufe und Zwischenzustände konsistent anzeigen.
Security-Teams bekommen klare Grenzen für Rechte und Audit-Logs.

Der Schlüssel ist, das Protokoll zur Grenze zu wählen.

MCP: Tools und Kontext

MCP, Model Context Protocol, verbindet AI-Anwendungen mit externen Tools und Kontext. Ein Host kann Tools entdecken und aufrufen, Ressourcen lesen und Prompt-Templates nutzen.

Nutze MCP, wenn:

Eine AI-App Datenbank, Dateisystem, API, Repository oder internes Tool abfragen muss.
Tools über mehrere Agent-Clients wiederverwendbar sein sollen.
Ressourcen und Prompts standardisiert angeboten werden sollen.
Tool-Schemas und Rechte explizit sein müssen.

MCP ist am stärksten an der Grenze "Agent ruft Tool". Es ist kein vollständiges Multi-Agent-Orchestrierungsprotokoll und definiert keine UI-Darstellung.

AI app / agent host
  -> MCP client
  -> MCP server
  -> database, file system, API, internal tool

Umsetzung:

Tools eng und klar beschreiben.
Breite Schreibrechte vermeiden.
Toolaufrufe und Argumente loggen.
Toolausgaben als nicht vertrauenswürdig behandeln.
Schemas versionieren.

A2A: Agent-zu-Agent-Zusammenarbeit

A2A, Agent-to-Agent, fokussiert Zusammenarbeit zwischen Agents. Ein Agent kann Fähigkeiten anbieten und Aufgaben von einem anderen Agent oder Orchestrator annehmen.

Nutze A2A, wenn:

Mehrere spezialisierte Agents zusammenarbeiten.
Ein Planner Arbeit an Spezialisten delegiert.
Agents verschiedenen Teams oder Services gehören.
Lange Aufgaben Status, Artefakte und Fortschritt brauchen.

A2A ist am stärksten an der Grenze "Agent delegiert an Agent". Es ersetzt MCP nicht; ein A2A-Agent kann intern MCP nutzen.

Orchestrator agent
  -> A2A task request
  -> Specialist agent
  -> status updates and artifacts

Umsetzung:

Definiere, was jeder Agent tun darf.
Ergebnisse validieren.
Timeouts und Budgets setzen.
Handoffs und Ownership aufzeichnen.
Zirkuläre Delegationen vermeiden.

ACP: Interoperable Agent-Services

ACP wird oft als Agent Communication Protocol diskutiert und zielt darauf, Agents als Services auffindbar und interoperabel zu machen. Konkrete Implementierungen unterscheiden sich, aber das Ziel ist ähnlich: Fähigkeiten eines Agents vorhersehbar anbieten.

Nutze ACP-ähnliche Ansätze, wenn:

Agents sich wie Netzwerkservices verhalten sollen.
Capability Discovery wichtig ist.
Unterschiedliche Runtimes oder Anbieter zusammenarbeiten müssen.
Eine Service-Grenze wichtiger ist als ein Library Call.

ACP überschneidet sich konzeptionell mit A2A. Prüfe immer die konkrete Implementierung: Nachrichtenformat, Authentifizierung, Task-Lifecycle, Streaming, SDK-Reife und Governance.

AG-UI: Agent zu Benutzeroberfläche

AG-UI fokussiert die Frontend-Grenze. Es standardisiert, wie ein Agent-Backend Nachrichten, Toolaufrufe, Zustandsänderungen, Fortschritt und UI-relevante Events an eine Client-App streamt.

Nutze AG-UI, wenn:

Du eine Copilot- oder Assistant-UI baust.
Das Frontend Toolaufrufe, Zwischenschritte oder Live-Fortschritt anzeigen muss.
Nutzer Aktionen in der UI genehmigen sollen.
Agent-State mit React, Vue oder anderen UI-Frameworks synchronisiert werden soll.

AG-UI ist am stärksten an der Grenze "Agent-Backend spricht mit UI". Es definiert nicht den internen Workflow oder das Tool-Hosting.

Agent backend
  -> event stream
  -> frontend UI
  -> user approval / input
  -> backend resumes

Umsetzung:

Eventtypen stabil halten.
Sichtbaren UI-State von internen Secrets trennen.
Reconnects und partielle Streams behandeln.
Freigaben explizit und auditierbar machen.
Frontend-Events nie als alleinige Berechtigungsprüfung nutzen.

Zusammenspiel

Die Protokolle ergänzen sich oft:

User interface
  <-> AG-UI events
Agent application / orchestrator
  <-> A2A or ACP for agent collaboration
Specialist agent
  <-> MCP for tools, resources, and prompts
Business systems

Ein Support-System könnte AG-UI für Fortschritt und Bestätigung nutzen, A2A für Delegation an einen Finance-Agent und MCP für Order-, Payment- und Ticketing-Tools.

Vergleich

Dimension	MCP	A2A	ACP	AG-UI
Grenze	Agent zu Tools/Kontext	Agent zu Agent	Agent-Service	Agent zu UI
Hauptobjekt	Tool, Resource, Prompt	Task, Message, Artifact	Capability, Agent, Message	Event, State, Tool Action
Gut für	Tool-Integration	Delegation	Interoperabilität	Interaktive Frontends
Ersetzt App-Logik?	Nein	Nein	Nein	Nein
Kombinierbar?	Ja	Ja	Ja	Ja
Hauptrisiko	Zu mächtige Tools	Unbegrenzte Delegation	Uneinheitliche Implementierungen	UI-State/Security-Leaks

Entscheidungshilfe

Wähle MCP, wenn dein Hauptproblem Tool- oder Datenintegration ist.

Wähle A2A, wenn ein Agent Aufgaben an einen anderen delegieren muss.

Wähle ACP-ähnliche Interoperabilität, wenn Agents als Services mit Capability Discovery auftreten sollen.

Wähle AG-UI, wenn du eine interaktive Agent-UI mit Fortschritt, Freigaben und Zwischenzuständen baust.

Häufige Fehler

Protokolle als Frameworks behandeln

Protokolle definieren Kommunikationsgrenzen. Sie ersetzen keine Orchestrierung, Evaluation, Security, Deployment oder Produktgestaltung.

Multi-Agent-Protokolle für einfache Toolaufrufe nutzen

Wenn dein Agent nur eine Datenbank oder API abfragt, reicht MCP-ähnliche Tool-Integration oft aus.

Zu viel über Tools freigeben

Ein Tool-Server sollte enge Operationen anbieten. "Beliebiges SQL ausführen" oder "Shell ausführen" braucht stark kontrollierte Umgebungen.

Agent-Ausgaben ungeprüft vertrauen

Agent-zu-Agent-Kommunikation braucht Validierung. Artefakte sind Daten, die vor Nutzung geprüft werden müssen.

UI-Events zu Berechtigungen machen

Frontend-Freigaben sind Interaktionssignale, keine vollständigen Sicherheitskontrollen. Das Backend muss Rechte prüfen.

Produktions-Checkliste

Bereich	Fragen
Authentifizierung	Wer darf den Endpoint aufrufen?
Autorisierung	Welche Tools, Agents, Tasks oder UI-Aktionen sind erlaubt?
Audit	Kann man rekonstruieren, wer was angefordert hat?
Timeouts	Was passiert bei hängenden Tools oder Agents?
Budgets	Sind Modellaufrufe, Tools und Task-Tiefe begrenzt?
Validierung	Werden Inputs und Outputs schema-geprüft?
Observability	Sind Traces über UI, Agent, Tool und Task verbunden?
Versionierung	Können Schemas geändert werden, ohne Clients zu brechen?

Zusammenfassung

MCP, A2A, ACP und AG-UI sind Grenzprotokolle. MCP standardisiert Tools und Kontext, A2A Agent-Aufgaben, ACP interoperable Agent-Services und AG-UI interaktive Frontend-Events. Ein reifes Agent-System kann mehrere nutzen, aber jedes sollte nur dort eingeführt werden, wo es eine klarere und sicherere Grenze schafft.