Deutsch

A2A vs MCP: Zwei komplementäre Protokolle für das aufkommende Agenten-Ökosystem

Dieser Artikel stellt A2A und MCP vor — zwei aufkommende Protokolle, die die Zukunft von KI-Agentensystemen prägen. Er erklärt, wie sie funktionieren, wie sie sich unterscheiden und warum das Verständnis dieser Architektur für Entwickler, Designer und KI-Produktentwickler wichtig ist.

Guamian

Product & Design

4/11/2025

Verschwenden Sie keine Wochen mit Benutzerauthentifizierung

Bringen Sie sichere Apps schneller mit Logto auf den Markt. Integrieren Sie Benutzerauthentifizierung in Minuten und konzentrieren Sie sich auf Ihr Kernprodukt.

Jetzt starten

Der zunehmende Einsatz von KI-Agenten — autonome oder halbautonome Softwareeinheiten, die im Auftrag von Benutzern Denken und Handeln ausführen — führt zu einer neuen Schicht in der Anwendungsarchitektur.

Anfang 2025 traten zwei unterschiedliche Protokolle auf den Plan, um diesem Bedarf gerecht zu werden — A2A (Agent-to-Agent) und MCP (Model Context Protocol). Eine einfache Möglichkeit, ihre Rollen zu verstehen, ist:

A2A: Wie interagieren Agenten miteinander

MCP: Wie interagieren Agenten mit Werkzeugen oder externen Kontexten

Referenz: https://google.github.io/A2A/#/topics/a2a_and_mcp

Sie adressieren die Kernherausforderung beim Aufbau von Systemen mit mehreren Agenten, mehreren LLMs und mehreren Kontextquellen — die alle zusammenarbeiten müssen.

Eine Möglichkeit, dies zu umreißen, lautet: „MCP bietet eine vertikale Integration (Anwendung-zu-Modell), während A2A eine horizontale Integration (Agent-zu-Agent) bietet

Egal, ob du Entwickler bist oder nicht, jeder, der KI-Produkte oder agentenbasierte Systeme aufbaut, sollte die grundlegende Architektur verstehen — da sie beeinflusst, wie wir Produkte, Benutzerinteraktionen, Ökosysteme und langfristiges Wachstum gestalten.

Dieser Artikel stellt beide Protokolle in einer einfachen, leicht verständlichen Weise vor und hebt wichtige Erkenntnisse für Entwickler und KI-Produktentwickler hervor.

Was ist A2A (Agent-to-Agent)?

A2A (Agent-to-Agent) ist ein offenes Protokoll, das von Google und über 50 Industriepartnern entwickelt wurde. Sein Zweck ist es, die Interoperabilität zwischen Agenten zu ermöglichen — unabhängig davon, wer sie gebaut hat, wo sie gehostet werden oder welches Framework sie verwenden.

A2A-Protokollmechanismus

A2A verwendet JSON-RPC 2.0 über HTTP(S) als Kommunikationsmechanismus, mit Unterstützung von Server-Sent Events (SSE) zum Streamen von Aktualisierungen.

A2A-Kommunikationsmodelle

A2A definiert ein strukturiertes Modell dafür, wie zwei Agenten interagieren. Ein Agent übernimmt die Rolle des „Client-Agenten“, der eine Anfrage oder Aufgabe initiiert, und ein anderer fungiert als „Remote-Agent“, der die Anfrage erhält und versucht, sie zu erfüllen. Der Client-Agent kann zuerst eine Fähigkeitsermittlung durchführen, um herauszufinden, welcher Agent am besten für eine bestimmte Aufgabe geeignet ist.

Nun stellt sich die Frage, wie Agenten einander entdecken. Jeder Agent kann eine Agentenkarte veröffentlichen (ein JSON-Metadokument, das oft unter einer Standard-URL wie /.well-known/agent.json gehostet wird), die seine Fähigkeiten, Fertigkeiten, API-Endpunkte und Authentifizierungsanforderungen beschreibt.

Durch das Lesen einer Agentenkarte kann ein Client-Agent einen geeigneten Partneragenten für die jeweilige Aufgabe identifizieren – im Grunde ein Verzeichnis dessen, was der Agent weiß oder tun kann. Sobald ein Zielagent gewählt ist, formuliert der Client-Agent ein Aufgaben-Objekt, das gesendet wird.

Referenz: https://google.github.io/A2A/#/

Aufgabenmanagement

Alle Interaktionen in A2A sind darauf ausgerichtet, Aufgaben auszuführen. Eine Aufgabe ist ein strukturiertes Objekt (definiert durch das Protokollschema), das Details der Anfrage enthält und deren Status verfolgt.

In A2A spielt jeder Agent eine von zwei Rollen:

Client-Agent: initiiert eine Aufgabe
Remote-Agent: empfängt und verarbeitet die Aufgabe

Aufgaben können jede Form von Arbeit umfassen: einen Bericht erstellen, Daten abrufen, einen Arbeitsablauf starten. Ergebnisse werden als Artefakte zurückgegeben, und Agenten können während der Ausführung strukturierte Nachrichten senden, um zu kooperieren oder zu klären.

Zusammenarbeit und Inhaltsverhandlung

A2A unterstützt mehr als einfache Aufgabenanfragen — Agenten können reichhaltige, mehrteilige Nachrichten austauschen, die Text, JSON, Bilder, Videos oder interaktive Inhalte enthalten. Dies ermöglicht eine Formatverhandlung basierend darauf, was jeder Agent verarbeiten oder anzeigen kann.

Zum Beispiel könnte ein Remote-Agent ein Diagramm entweder als Rohdaten oder als Bild zurückgeben oder bitten, ein interaktives Formular zu öffnen. Diese Gestaltung unterstützt eine flexible, modalitätenunabhängige Kommunikation, ohne dass Agenten interne Werkzeuge oder Speicher teilen müssen.

Anwendungsbeispiel

Hier ist ein realistisches Beispiel, wie A2A in einem Unternehmensszenario eingesetzt werden könnte:

Ein neuer Mitarbeiter wird in einem großen Unternehmen eingestellt. Mehrere Systeme und Abteilungen sind im Onboardingprozess involviert:

Die Personalabteilung muss einen Datensatz erstellen und eine Willkommens-E-Mail senden
Die IT-Abteilung muss einen Laptop und Firmenkonten bereitstellen
Das Facility-Management muss einen Schreibtisch und eine Zugangskarte vorbereiten

Traditionell werden diese Schritte manuell oder durch eng gekoppelte Integrationen zwischen internen Systemen abgewickelt.

Anstatt benutzerdefinierter APIs zwischen jedem System, stellt jede Abteilung ihren eigenen Agenten unter Verwendung des A2A-Protokolls zur Verfügung:

Agent	Verantwortlichkeit
hr-agent.company.com	Arbeitnehmerakten erstellen, Dokumente senden
it-agent.company.com	E-Mail-Konto erstellen, Laptop bestellen
facilities-agent.company.com	Schreibtisch zuweisen, Zugangskarte drucken

Ein Multi-Agentensystem — nennen wir es OnboardingPro (z.B. onboarding-agent.company.com) — koordiniert den gesamten Onboarding-Arbeitsablauf.

Ermittlung: Es liest die .well-known/agent.json jedes Agenten, um Fähigkeiten und Authentifizierung zu verstehen.
Aufgabenzuweisung:
- Sendet eine createEmployee-Aufgabe an den HR-Agenten.
- Sendet setupEmailAccount und orderHardware-Aufgaben an den IT-Agenten.
- Sendet assignDesk und generateBadge an den Facility-Agenten.
Streaming-Updates: Agenten streamen Fortschritte zurück, indem sie Server-Sent Events verwenden (z.B. „Laptop versendet“, „Schreibtisch zugewiesen“).
Artefaktsammlung: Endergebnisse (z.B. PDF-Ausweis, Bestätigungs-E-Mails, Zugangsdaten) werden als A2A-Artefakte zurückgegeben.
Abschluss: Der OnboardingPro benachrichtigt den Einstellungsleiter, wenn das Onboarding abgeschlossen ist.

Was ist MCP (Model Context Protocol)?

MCP (Model Context Protocol), entwickelt von Anthropic, adressiert ein anderes Problem: Wie externe Anwendungen strukturierter Kontext und Werkzeuge einem auf Sprachmodellen basierenden Agenten zur Laufzeit zur Verfügung stellen können.

Statt die Kommunikation zwischen Agenten zu ermöglichen, konzentriert sich MCP auf das Kontextfenster — den Arbeitsgedächtnis eines LLM. Sein Ziel ist es:

Relevante Werkzeuge, Dokumente, API-Funktionen oder den Benutzerstatus dynamisch in eine Inferenzsession eines Modells einfließen zu lassen
Modelle Funktionen aufrufen oder Dokumente abrufen zu lassen ohne die Eingabeaufforderung oder Logik fest im Programmcode zu verankern.

MCP-Schlüsselarchitektur

Um MCP zu verstehen, musst du zunächst die Gesamtarchitektur verstehen — wie alle Teile zusammenarbeiten.

MCP-Host: „Das KI, mit dem du sprichst“

Denke an den MCP-Host als die KI-Anwendung selbst — wie Claude Desktop oder dein Codierungsassistent.

Es ist die Schnittstelle, die du benutzt — der Ort, an dem du schreibst oder sprichst.

Es möchte Werkzeuge und Daten einbeziehen, die dem Modell helfen, bessere Antworten zu geben.

MCP-Client: „Der Verbinder“

Der MCP-Client ist das Software-Element, das deinen KI-Host (wie Claude) mit der Außenwelt verbindet. Es ist wie eine Vermittlungsstelle — es verwaltet sichere, Eins-zu-Eins-Verbindungen zu verschiedenen MCP-Servern. Wenn die KI auf etwas zugreifen möchte, geht dies über den Client.

Es ist hilfreich, Tools wie ChatGPT, Claude-Chat oder Cursor IDE als MCP-Hosts zu betrachten — sie stellen die Schnittstelle bereit, mit der du interagierst. Im Hintergrund verwenden sie einen MCP-Client, um sich mit verschiedenen Werkzeugen und Datenquellen über MCP-Server zu verbinden.

Referenz: https://modelcontextprotocol.io/introduction

MCP-Server: „Der Werkzeuganbieter“

Ein MCP-Server ist ein kleines, fokussiertes Programm, das ein spezifisches Werkzeug oder eine Fähigkeit bereitstellt — wie:

Dateien auf deinem Computer durchsuchen
Daten in einer lokalen Datenbank nachschlagen
Eine externe API aufrufen (z.B. Wetter, Finanzen, Kalender)

Jeder Server befolgt das MCP-Protokoll, sodass die KI verstehen kann, was er tun kann und wie man ihn aufruft.

Lokale Datenquellen: „Deine eigenen Dateien & Dienste“

Einige MCP-Server verbinden sich mit Dingen auf deinem eigenen Rechner — wie:

Dokumenten und Ordnern
Code-Projekten
Datenbanken oder lokalen Anwendungen

Dies ermöglicht es der KI zu suchen, abzurufen oder Dinge zu berechnen, ohne deine Daten in die Cloud hochladen zu müssen.

Entfernte Dienste: „APIs & Online-Tools“

Andere MCP-Server sind mit dem Internet verbunden — sie kommunizieren mit:

APIs (z.B. Stripe, Notion, GitHub)
SaaS-Tools
Unternehmensdatenbanken in der Cloud

So kann die KI beispielsweise sagen: „Rufen Sie den GitHub-Server auf und holen Sie sich die Liste der offenen PRs.“

MCP unterstützt jetzt die Verbindung zu entfernten MCP-Servern. Dies bedeutet, dass ein MCP-Client leistungsfähigere Fähigkeiten erhalten kann. Theoretisch,

Mit dem richtigen Satz an MCP-Servern können Benutzer jeden MCP-Client in eine „Alles-App“ verwandeln.

Referenz: https://a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/

Alles zusammenfügen

Jetzt lass uns mit einem Diagramm sehen, wie alles zusammenarbeitet.

Du stellst dem KI etwas Komplexes
Die KI (der Host) bittet den Client um Hilfe
Der Client ruft den richtigen MCP-Server auf — vielleicht einen, der Dateien überprüft oder eine API ansteuert
Der Server sendet Daten zurück oder führt eine Funktion aus
Das Ergebnis fließt zurück in das Modell, um die Aufgabe zu unterstützen

A2A vs MCP — Vergleich

Kategorie	A2A (Agent-to-Agent)	MCP (Model Context Protocol)
Hauptziel	Ermöglicht Austausch von Aufgaben zwischen Agenten	Ermöglicht LLMs den Zugriff auf externe Werkzeuge oder Kontexte
Entwickelt für	Kommunikation zwischen autonomen Agenten	Verbesserung der Fähigkeiten eines einzelnen Agenten während der Inferenz
Fokus	Multi-Agenten-Arbeitsabläufe, Koordination, Delegation	Dynamische Werkzeugnutzung, Kontextanreicherung
Ausführungsmodell	Agenten senden/empfangen Aufgaben und Artefakte	LLM wählt und führt Werkzeuge während des Denkens aus
Sicherheit	OAuth 2.0, API-Schlüssel, deklarative Bereiche	Wird auf der Anwendungsebene gehandhabt
Entwicklerrolle	Erstellen von Agenten, die Aufgaben und Artefakte über Endpunkte bereitstellen	Definieren strukturierter Werkzeuge und Kontexte, die das Modell verwenden kann
Ökosystem-Partner	Google, Salesforce, SAP, LangChain usw.	Anthropic, mit aufkommender Adoption in werkzeugbasierten LLM-UIs

Wie sie zusammenarbeiten

Anstatt Alternativen zu sein, sind A2A und MCP komplementär. In vielen Systemen werden beide zusammen verwendet.

Beispiel-Arbeitsablauf

Ein Benutzer übermittelt eine komplexe Anfrage in einer Unternehmensagenten-Schnittstelle.
Der orchestrierende Agent verwendet A2A, um Unteraufgaben an spezialisierte Agenten zu delegieren (z.B. Analysen, Personalwesen, Finanzen).
Einer dieser Agenten verwendet intern MCP, um eine Suchfunktion aufzurufen, ein Dokument abzurufen oder etwas mit einem Modell zu berechnen.
Das Ergebnis wird über A2A als Artefakt zurückgegeben, wodurch eine vollständige Agentenzusammenarbeit mit modularem Werkzeugzugriff möglich wird.

Diese Architektur trennt die Kommunikation zwischen Agenten (A2A) von der Fähigkeitenausführung innerhalb von Agenten (MCP) — was das System einfacher zu komponieren, zu skalieren und zu sichern macht.

Fazit

A2A dreht sich darum, dass Agenten über ein Netzwerk miteinander kommunizieren — sicher, asynchron und aufgabenorientiert.

MCP dreht sich darum, strukturierte Fähigkeiten in eine Modellsitzung zu integrieren, sodass LLMs kontextuell über Werkzeuge und Daten nachdenken können.

Zusammen verwendet, unterstützen sie komposable, multi-agentenbasierte Systeme, die sowohl erweiterbar als auch interoperabel sind.

Wie die MCP + A2A-Basisinfrastruktur die Zukunft von Agentenproduktmarktplätzen gestalten könnte

Abschließend möchte ich darüber sprechen, wie diese Kerntechnologie die Zukunft des KI-Marktplatzes gestalten könnte – und was das für diejenigen bedeutet, die KI-Produkte entwickeln.

Der Wandel der Mensch-Computer-Interaktion

Ein klares Beispiel für diesen Wandel lässt sich in Entwickler- und Dienstleistungsarbeitsabläufen erkennen. Mit jetzt in IDEs und Codierungsagenten integrierten MCP-Servern ändert sich die Art und Weise, wie Entwickler mit Werkzeugen interagieren, grundlegend.

Bisher beinhaltete ein typischer Arbeitsablauf die Suche nach dem richtigen Dienst, das Einrichten des Hostings, das Lesen der Dokumentation, das manuelle Integrieren von APIs, das Schreiben von Code in der IDE und das Konfigurieren von Funktionen über ein Low-Code-Dashboard. Es war eine fragmentierte Erfahrung, die bei jedem Schritt Kontextwechsel und technischen Overhead erforderte.

Jetzt kann diese Komplexität mit MCP-verbundenen Codierungsagenten weitgehend abstrahiert werden. Entwickler können Werkzeuge natürlicher durch konversationelle Aufforderungen entdecken und verwenden. Die API-Integration wird Teil des Codierungsflusses selbst — oft ohne dass eine separate Benutzeroberfläche oder manuelle Einrichtung erforderlich ist. (Denken Sie nur daran, wie komplex AWS- oder Microsoft-Dashboards sein können.) Die Interaktion wird geschmeidiger – mehr über Verhaltenssteuerung als über Funktionszusammenstellung.

In diesem Modell verschiebt sich die Interaktion des Nutzers oder Entwicklers von der Konfiguration von Funktionen zur Orchestrierung von Verhaltensweisen. Dies ändert auch die Rolle des Produktdesigns.

Anstatt Benutzeroberflächen zu verwenden, um technische Herausforderungen zu überbrücken (z.B. „das ist zu schwer zu programmieren, lassen Sie uns ein Konfigurationspanel erstellen“), müssen wir jetzt:

Über das End-to-End-Erlebnis nachdenken
Gestalten, wie und wann KI + Benutzerinteraktionen zusammenkommen sollten
Lassen Sie die KI die Logik übernehmen und führen Sie die Benutzer durch Absicht und Fluss.

Die Herausforderung besteht darin, zu entscheiden, wann und wie KI- und Benutzereingaben zusammenkommen sollten, die KI die Logik übernehmen zu lassen und Benutzer durch Absicht und Fluss zu führen und wie die richtigen Interaktionen zur richtigen Zeit eingefügt werden können.

Ich habe einen Entwicklerdienst und ein API-Produkt als Beispiel verwendet, um zu zeigen, wie sich die Benutzerinteraktion ändern könnte — aber das gleiche gilt für Unternehmenssoftware. Geschäftstools waren lange Zeit komplex und schwer zu bedienen. Natürliche Sprachinteraktion hat das Potenzial, viele dieser Arbeitsabläufe zu vereinfachen.

Agentenbasierte Produktparadigmen und ihre Auswirkungen auf SaaS

Wir beginnen zu sehen, dass eine wachsende Anzahl von MCP-Servern entsteht. Stellen Sie sich vor, Airbnb bietet einen Buchungs-MCP-Server an oder Google Maps stellt einen Karten-MCP-Server bereit. Ein Agent (als MCP-Client) könnte sich mit vielen dieser Server gleichzeitig verbinden — und so Arbeitsabläufe freischalten, die zuvor benutzerdefinierte Integrationen oder eng gekoppelte Apps erforderten.

Im Vergleich zur SaaS-Ära, in der Integrationen oft manuell und starr waren, ermöglicht dieses Modell mehr autonome Arbeitsabläufe und flüssige Verbindungen zwischen Diensten. Hier sind zwei Beispiele:

Design aus Dokumenten

Sie schreiben einen PRD in Notion. Ein Figma-Agent liest das Dokument und erstellt automatisch ein Drahtmodell, das die Kernkonzepte darlegt — keine manuelle Übergabe erforderlich.
Konkurrenzanalyse, von Anfang bis Ende

Sie bitten um eine Konkurrenzanalyse. Eine Gruppe von Agenten durchsucht das Web, registriert sich im Auftrag von Ihnen für relevante Dienste (mit sicherer Authentifizierung), sammelt die Ergebnisse und liefert die Artefakte zurück — bereits in Ihrem Notion-Arbeitsbereich organisiert.

Herausforderungen mit Authentifizierungs- und Autorisierungsgrenzen

Mit dem Aufkommen von Agent-zu-Agent-Verbindungen und MCP-Client-zu-MCP-Server-Verbindungen gibt es viele zugrundeliegende Bedürfnisse hinsichtlich Authentifizierung und Autorisierung, da Agenten im Auftrag von Menschen und Benutzern handeln und Anmeldeinformationen durch diese Reise gesichert werden müssen.

Bisher gibt es mehrere Szenarien, die spezifisch für den neuen Aufstieg der Agent-zu-Agent-Verbindungen und MCP sind.

Agent vs SaaS & WebsiteApp
MCP-Client (Agent) vs MCP-Server
Benutzer vs Agent
Agent vs Agent

Ein weiterer interessanter Anwendungsfall ist die Multi-Identitätsföderation, die Google erwähnt:

Zum Beispiel arbeitet Benutzer U mit Agent A zusammen, der die A-System-ID benötigt. Wenn Agent A dann auf Werkzeug B oder Agent B angewiesen ist, das die B-System-ID erfordert, muss der Benutzer möglicherweise Identitäten für sowohl das A-System als auch das B-System in einer einzigen Anfrage bereitstellen. (Angenommen, A-System ist eine Unternehmens-LDAP-Identität und B-System ist eine SaaS-Anbieter-Identität).

Logto ist ein OIDC- und OAuth-Anbieter, der sich gut für die Zukunft von KI-Integrationen eignet.

Mit seiner flexiblen Infrastruktur erweitern wir aktiv seine Fähigkeiten und haben eine Reihe von Tutorials veröffentlicht, um Entwicklern den schnellen Einstieg zu erleichtern.

Hast du Fragen?

Nimm Kontakt mit uns auf — oder tauche ein und entdecke, was du heute mit Logto aufbauen kannst.

Probieren Sie Logto Cloud kostenlos aus

Was ist A2A (Agent-to-Agent)?#

A2A-Protokollmechanismus#

A2A-Kommunikationsmodelle#

Aufgabenmanagement#

Zusammenarbeit und Inhaltsverhandlung#

Anwendungsbeispiel#

Was ist MCP (Model Context Protocol)?#

MCP-Schlüsselarchitektur#

MCP-Host: „Das KI, mit dem du sprichst“#

MCP-Client: „Der Verbinder“#

MCP-Server: „Der Werkzeuganbieter“#

Lokale Datenquellen: „Deine eigenen Dateien & Dienste“#

Entfernte Dienste: „APIs & Online-Tools“#

Alles zusammenfügen#

A2A vs MCP — Vergleich#

Wie sie zusammenarbeiten#

Beispiel-Arbeitsablauf#

Fazit#

Wie die MCP + A2A-Basisinfrastruktur die Zukunft von Agentenproduktmarktplätzen gestalten könnte#

Der Wandel der Mensch-Computer-Interaktion#

Agentenbasierte Produktparadigmen und ihre Auswirkungen auf SaaS#

Herausforderungen mit Authentifizierungs- und Autorisierungsgrenzen#