Die neue Architektur der Intelligenz: API, RAG, MCP und A2A im Vergleich

Von DerSchneider

Die Welt der Künstlichen Intelligenz entwickelt sich mit einer solchen Geschwindigkeit, dass selbst erfahrene Entwickler Mühe haben, den Überblick zu behalten. Drei Akronyme prägen derzeit die Diskussion um den Bau intelligenter Agenten: RAG, MCP und A2A. Sie stehen für unterschiedliche Schichten im Architekturstapel eines modernen KI-Systems, werden aber oft in einem Atemzug genannt, ohne dass ihre jeweilige Rolle und ihr Zusammenspiel klar verstanden werden. Dabei entscheidet genau dieses Verständnis darüber, ob ein Agent in der Demo überzeugt oder im Produktiveinsatz scheitert – ob er langsam, verwirrt oder sogar unsicher agiert.

Dieser Artikel nimmt eine Systemarchitektur in den Blick und verfolgt die Entwicklung eines fiktiven, aber typischen KI-Agenten. So werden die einzelnen Technologien als Problemlöser innerhalb eines wachsenden Anforderungskatalogs verständlich.

Von der starren API zur flexiblen Anfrage

Jede Geschichte moderner Software beginnt mit der Application Programming Interface (API). Seit Jahrzehnten ist sie der Grundpfeiler der digitalen Kommunikation. Eine API ist ein Vertrag zwischen zwei Programmen. Sie definiert präzise, welche Anfragen gestellt werden können, wie diese zu formatieren sind und welche Antworten zu erwarten sind. Ein Wetterdienst ruft Vorhersagedaten ab, ein Online-Shop verarbeitet Zahlungen, ein Messaging-Dienst versendet Benachrichtigungen – all dies geschieht über klar definierte API-Aufrufe. Diese Vorhersagbarkeit ist ihre Stärke. Die gesamte moderne Internet-Infrastruktur basiert auf diesem Prinzip.

Die Revolution durch große Sprachmodelle (LLMs) führte diese Planbarkeit jedoch ad absurdum. Die Eingabe ist nicht länger ein sauber ausgefülltes Formular, sondern eine natürliche Sprachaufforderung wie: „Finde mir einen guten Flug nach Tokio, vermeide nächtliche Zwischenlandungen und stell sicher, dass ich das Meeting am Montag nicht verpasse.“ Das System muss nun den Kontext verstehen, verschiedene Dienste konsultieren, Rückfragen stellen und seinen Plan anpassen. Die API hingegen wartet weiterhin auf präzise Anweisungen: Welcher Endpunkt, welche Felder, welche Datentypen, welche Credentials?

Ein LLM mag das Ziel verstehen, aber Intelligenz allein schafft noch keine nahtlose Schnittstelle. Der erste Ausweg war rohe Gewalt: Beschreibung jeder Funktion für das Modell – eine Liste von Werkzeugen mit ihren Parametern. Was auf kleiner Flamme funktioniert, wird bei zehn Werkzeugen zum unwartbaren Monstrum. Jede Änderung am Datenformat kann zu stillen Fehlern führen .

RAG: Wissen im richtigen Moment

Unser Agent „Atlas“ hat die Aufgabe, eine Reise nach Tokio zu planen. Ein LLM mag viel über Tokio wissen, aber es kennt nicht das persönliche Ablaufdatum des Reisepasses, den Meilenstand oder die Reiserichtlinie des Unternehmens, die Flüge über 800 Dollar nicht erlaubt. Diese Fakten sind privat, unternehmensspezifisch und veränderlich. Sie waren nie Teil der Trainingsdaten des Modells. Das Modell neigt dazu, Wissenslücken mit plausiblen, aber falschen Informationen zu füllen – eine Halluzination .

Hier kommt Retrieval-Augmented Generation (RAG) ins Spiel . RAG ist kein spezifisches Protokoll oder Werkzeug, sondern ein Systemmuster. Die Idee ist einfach und genial: Zwinge das Modell nicht, sich veränderliche Fakten zu merken. Stattdessen lässt die Anwendung die relevanten Fakten in dem Moment abrufen, in dem sie benötigt werden.

Der Ablauf eines RAG-Systems folgt einer klaren Pipeline :

1. Ingestion: Dokumente wie Reiserichtlinien, persönliche Präferenzen und Notizen werden aufbereitet, in sinnvolle Textabschnitte zerlegt und indexiert.
2. Indexing: Der Index kann auf Stichwortsuchen, semantischen Einbettungen (Vektorsuche) oder einer Kombination aus beidem basieren.
3. Retrieval: Bei einer Anfrage sucht das System in diesem Index nach den relevantesten Textpassagen.
4. Generation: Diese gefundenen Passagen werden in den Kontext des Modells eingefügt, bevor es die Antwort generiert.

Atlas ruft also nicht das Ablaufdatum des Passworts aus dem Gedächtnis ab, sondern liest eine autorisierte Kopie in dem Moment, in dem er sie braucht. Das macht die Antwort frisch und überprüfbar. RAG ist heute das Herzstück vieler Dokumenten-Assistenten, Support-Bots und Unternehmenssuchwerkzeuge. Es ermöglicht es, LLMs mit firmeninternem Wissen zu füttern, ohne sie dafür teuer nachtrainieren zu müssen .

Allerdings löst RAG nur das Problem des Wissens, nicht das der Handlungsfähigkeit. Ein Dokumentenindex kann keinen Live-Flugpreis abfragen, eine Buchung vornehmen oder den Kalender aktualisieren.

MCP: Die standardisierte Werkzeugkiste

Die zweite Mauer, die Atlas einrennt, ist die des Handelns. RAG kann ihm sagen, was zu tun ist, aber nicht, wie er es tun kann. Er braucht Zugang zu Werkzeugen wie einer Flug-API, einem Kalender und einem E-Mail-Dienst.

Die naheliegende Lösung ist Function Calling. Das Modell schlägt in seiner Antwort einen strukturierten Funktionsaufruf vor, etwa search_flights mit den Parametern origin, destination und travel_dates. Die Host-Anwendung validiert den Aufruf, führt den Code aus und gibt das Ergebnis zurück an das Modell. Diese Schleife ist der grundlegende Motor vieler KI-Agenten .

Für jeden Dienst muss ein Entwickler jedoch einen individuellen Connector bauen: die API-Dokumentation lesen, das Datenformat mappen, Berechtigungen einrichten. Das führt zu einem wachsenden Berg an individuellem, schwer wartbarem Code.

An diesem Punkt kommt das Model Context Protocol (MCP) ins Spiel . Anthropic führte es im November 2024 als offenen Standard ein . MCP folgt einer Client-Host-Server-Architektur :

• MCP-Host: Die Anwendung, die den Agenten ausführt (z.B. Atlas‘ Host). Sie erstellt und verwaltet Client-Instanzen und durchsetzt Sicherheitsrichtlinien.
• MCP-Client: Jeder Client wird vom Host erstellt und unterhält eine Verbindung zu genau einem Server.
• MCP-Server: Bieten spezialisierte Kontexte und Fähigkeiten. Sie exponieren Tools (Aktionen), Resources (Daten wie Dateien) und Prompts (wiederverwendbare Vorlagen).

MCP standardisiert, wie ein KI-Anwendung mit externen Werkzeugen spricht. Ein Kalender-Server kann ein Tool find_open_time mit einem maschinenlesbaren Schema anbieten. Ein Flug-Server bietet search_fares und hold_itinerary an. Da beide MCP verwenden, erhält jede Anwendung die Tool-Beschreibungen im gleichen Format. Es ist der „USB-C für KI-Anwendungen“ – ein gemeinsamer Verbindungspunkt.

Dennoch ist es wichtig, den Hype von der Realität zu unterscheiden: MCP ersetzt keine API . Ein MCP-Server sitzt oft auf einer bestehenden REST-API auf. Die API ist weiterhin die zugrundeliegende Regelmenge für die Nutzung des Dienstes. MCP gibt der KI lediglich eine standardisierte Möglichkeit, diesen Dienst zu entdecken und zu nutzen. Die Host-Anwendung muss dennoch Berechtigungen prüfen, Daten validieren und Sicherheitsgrenzen durchsetzen . MCP löst das Problem der standardisierten Werkzeuganbindung – eine notwendige, aber nicht hinreichende Bedingung für komplexe Agentensysteme.

A2A: Die Zusammenarbeit autonomer Agenten

Nachdem Atlas Wissen abrufen (RAG) und Werkzeuge nutzen (MCP) kann, stößt er an eine dritte Wand: die Koordination mit anderen unabhängigen Systemen. In einer realen Organisation hat nicht ein Agent alle Verantwortlichkeiten. Es gibt spezialisierte Agenten für Finanzen, Personal oder Logistik.

Hier kommt das Agent-to-Agent (A2A)-Protokoll ins Spiel, das Google im April 2025 vorstellte . A2A soll unabhängigen KI-Agenten, die von verschiedenen Teams oder Unternehmen mit unterschiedlichen Technologien gebaut wurden, eine gemeinsame Sprache geben . Man kann es sich als das „HTTP für die Welt der Agenten“ vorstellen .

A2A adressiert dabei drei Kernprobleme :

1. Entdeckung (Discovery): Agenten veröffentlichen ihre Fähigkeiten in einer maschinenlesbaren Agent Card (oft unter /.well-known/agent.json). Diese Karte enthält den Namen, die Kontaktinformationen, Fähigkeiten und unterstützte Datenformate .
2. Kommunikation: Die Kommunikation läuft über standardisierte JSON-RPC 2.0-Nachrichten über einen einzigen Endpunkt .
3. Aufgabenlebenszyklus (Task Lifecycle): Jede Interaktion wird in eine Aufgabe (Task) verpackt, die klar definierte Zustände durchläuft: submitted (eingereicht), working (in Arbeit), completed (abgeschlossen) oder failed (fehlgeschlagen) . Dies ermöglicht sowohl synchrone als auch asynchrone Arbeitsabläufe.

Der grundlegende Unterschied zwischen MCP und A2A lässt sich so zusammenfassen: MCP hilft einer KI-Anwendung, Werkzeuge eines anderen Systems zu nutzen. A2A hilft unabhängigen KI-Agenten, bei einer Aufgabe zusammenzuarbeiten . Oracle beschreibt in seiner Dokumentation, wie ein A2A-fähiger Agent in seinen Fusion Cloud Applications mit einem externen Reiseagenten kommunizieren kann, um Angebote einzuholen . Ein weiteres Beispiel ist der Go-basierte Compliance-Agent, der über A2A mit einem Python-Hauptagenten kommuniziert, um Verträge zu prüfen .

Zusammenspiel: Die Reise des Agenten Atlas

Die Reise von Atlas veranschaulicht das Zusammenspiel dieser vier Ebenen in der Praxis :

1. Der Prompt: Der Nutzer sagt: „Atlas, buche meine Tokyo-Reise für die zweite März-Woche.“
2. RAG (Wissen): Atlas ruft über RAG die notwendigen Fakten ab – Präferenzen, Firmenrichtlinien, Meilenstand, Passablaufdatum – und nicht den gesamten Pass-Scan. Erkennt er Risiken, weist er darauf hin, statt zu raten.
3. MCP (Werkzeuge): Über MCP prüft Atlas den Kalender und sucht nach Live-Flugpreisen. Der Host genehmigt jedes Werkzeug, validiert jede Anfrage und protokolliert jede Aktion. Ein passender Flug wird gefunden und reserviert.
4. A2A (Koordination): Der Preis übersteigt die Firmenlimite. Atlas sendet die Reise und den Preis über A2A an den Finanzagenten. Der Finanzagent prüft und gibt eine Freigabe zurück, die an diese exakte Reise gebunden ist.
5. Die Ausführung: Atlas bucht nicht selbst. Er prüft den Preis erneut, zeigt die endgültigen Beträge an und wartet auf die Bestätigung des Nutzers. Erst nach dem „Ja“ des Nutzers wird gebucht, die Quittung gespeichert und der Kalender aktualisiert.

Eine Anfrage, vier klare Rollen.

Fazit: Ein vielschichtiger Architekturstapel

Die Akronyme API, RAG, MCP und A2A repräsentieren keine konkurrierenden Technologien, sondern komplementäre Schichten in der Architektur intelligenter Systeme .

• Die API ist der etablierte, starre Vertrag zwischen zwei Programmen – das Fundament für jede Art von Dienst.
• RAG ist ein Systemmuster für den Abruf von externem Wissen, um LLMs mit aktuellen Fakten zu versorgen und Halluzinationen zu reduzieren.
• MCP ist ein offenes Protokoll, das standardisiert, wie eine KI-Anwendung mit diesen externen Diensten (Werkzeugen und Ressourcen) interagiert.
• A2A ist ein weiteres offenes Protokoll, das die Zusammenarbeit zwischen unabhängigen, autonomen Agenten ermöglicht.

Keine dieser Schichten allein ist die Lösung für alle Probleme. Ein Agent benötigt die API als Fundament, RAG für aktuelles Wissen, MCP für die Nutzung von Werkzeugen und A2A für die Koordination mit anderen Agenten. Dieses Verständnis ist entscheidend, um von magischen Demos zu stabilen, sicheren und produktiven Systemen zu gelangen. Die Zukunft der KI liegt nicht in einem einzigen, allwissenden Modell, sondern in einem intelligenten, orchestrierten Ökosystem spezialisierter Komponenten .

Quellen:

• Architecture – Model Context Protocol 
• How A2A is Building a World of Collaborative Agents 
• Generative AI and cloud deployment for intelligent systems: a retrieval-augmented generation framework using amazon bedrock 
• Collaborate with AI Agents Across Platforms using Agent2Agent (A2A) Protocol 
• Architecture – Model Context Protocol Specification 
• Announcing the Agent2Agent Protocol (A2A) 
• RAG based Chat Bot using Vector Querying 
• AgentCard: A Framework-Neutral Identity and Capability Declaration Format 
• Mastering Multi-agent Systems with Azure OpenAI 
• Build Cross-Language Multi-Agent Team with Google’s Agent Development Kit and A2A 
• RAG Artificial Intelligence 
• A2A endpoint in Agent Server 
• Agentic Orchestration: A Governance-First Reference Enterprise Architecture