{"id":6939,"date":"2026-08-24T16:28:30","date_gmt":"2026-08-24T16:28:30","guid":{"rendered":"https:\/\/technodidact.de\/?p=6939"},"modified":"2026-08-24T16:28:30","modified_gmt":"2026-08-24T16:28:30","slug":"die-neue-architektur-der-intelligenz-api-rag-mcp-und-a2a-im-vergleich","status":"publish","type":"post","link":"https:\/\/technodidact.de\/en\/die-neue-architektur-der-intelligenz-api-rag-mcp-und-a2a-im-vergleich\/","title":{"rendered":"Die neue Architektur der Intelligenz: API, RAG, MCP und A2A im Vergleich"},"content":{"rendered":"

Von DerSchneider<\/strong><\/p>\n\n\n\n

Die Welt der K\u00fcnstlichen Intelligenz entwickelt sich mit einer solchen Geschwindigkeit, dass selbst erfahrene Entwickler M\u00fche haben, den \u00dcberblick zu behalten. Drei Akronyme pr\u00e4gen derzeit die Diskussion um den Bau intelligenter Agenten: RAG, MCP und A2A. Sie stehen f\u00fcr 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\u00e4ndnis dar\u00fcber, ob ein Agent in der Demo \u00fcberzeugt oder im Produktiveinsatz scheitert \u2013 ob er langsam, verwirrt oder sogar unsicher agiert.<\/p>\n\n\n\n

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\u00f6ser innerhalb eines wachsenden Anforderungskatalogs verst\u00e4ndlich.<\/p>\n\n\n\n

Von der starren API zur flexiblen Anfrage<\/h2>\n\n\n\n

Jede Geschichte moderner Software beginnt mit der Application Programming Interface (API)<\/strong>. Seit Jahrzehnten ist sie der Grundpfeiler der digitalen Kommunikation. Eine API ist ein Vertrag zwischen zwei Programmen. Sie definiert pr\u00e4zise, welche Anfragen gestellt werden k\u00f6nnen, 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 \u2013 all dies geschieht \u00fcber klar definierte API-Aufrufe. Diese Vorhersagbarkeit ist ihre St\u00e4rke. Die gesamte moderne Internet-Infrastruktur basiert auf diesem Prinzip.<\/p>\n\n\n\n

Die Revolution durch gro\u00dfe Sprachmodelle (LLMs) f\u00fchrte diese Planbarkeit jedoch ad absurdum. Die Eingabe ist nicht l\u00e4nger ein sauber ausgef\u00fclltes Formular, sondern eine nat\u00fcrliche Sprachaufforderung wie: „Finde mir einen guten Flug nach Tokio, vermeide n\u00e4chtliche Zwischenlandungen und stell sicher, dass ich das Meeting am Montag nicht verpasse.“<\/em> Das System muss nun den Kontext verstehen, verschiedene Dienste konsultieren, R\u00fcckfragen stellen und seinen Plan anpassen. Die API hingegen wartet weiterhin auf pr\u00e4zise Anweisungen: Welcher Endpunkt, welche Felder, welche Datentypen, welche Credentials?<\/p>\n\n\n\n

Ein LLM mag das Ziel verstehen, aber Intelligenz allein schafft noch keine nahtlose Schnittstelle. Der erste Ausweg war rohe Gewalt: Beschreibung jeder Funktion f\u00fcr das Modell \u2013 eine Liste von Werkzeugen mit ihren Parametern. Was auf kleiner Flamme funktioniert, wird bei zehn Werkzeugen zum unwartbaren Monstrum. Jede \u00c4nderung am Datenformat kann zu stillen Fehlern f\u00fchren <\/a>.<\/p>\n\n\n\n

RAG: Wissen im richtigen Moment<\/h2>\n\n\n\n

Unser Agent „Atlas“ hat die Aufgabe, eine Reise nach Tokio zu planen. Ein LLM mag viel \u00fcber Tokio wissen, aber es kennt nicht das pers\u00f6nliche Ablaufdatum des Reisepasses, den Meilenstand oder die Reiserichtlinie des Unternehmens, die Fl\u00fcge \u00fcber 800 Dollar nicht erlaubt. Diese Fakten sind privat, unternehmensspezifisch und ver\u00e4nderlich. Sie waren nie Teil der Trainingsdaten des Modells. Das Modell neigt dazu, Wissensl\u00fccken mit plausiblen, aber falschen Informationen zu f\u00fcllen \u2013 eine Halluzination <\/a>.<\/p>\n\n\n\n

Hier kommt Retrieval-Augmented Generation (RAG)<\/strong> ins Spiel <\/a><\/a>. RAG ist kein spezifisches Protokoll oder Werkzeug, sondern ein Systemmuster<\/strong>. Die Idee ist einfach und genial: Zwinge das Modell nicht, sich ver\u00e4nderliche Fakten zu merken. Stattdessen l\u00e4sst die Anwendung die relevanten Fakten in dem Moment abrufen, in dem sie ben\u00f6tigt werden.<\/p>\n\n\n\n

Der Ablauf eines RAG-Systems folgt einer klaren Pipeline <\/a><\/a>:<\/p>\n\n\n\n

    \n
  1. Ingestion<\/strong>: Dokumente wie Reiserichtlinien, pers\u00f6nliche Pr\u00e4ferenzen und Notizen werden aufbereitet, in sinnvolle Textabschnitte zerlegt und indexiert.<\/li>\n\n\n\n
  2. Indexing<\/strong>: Der Index kann auf Stichwortsuchen, semantischen Einbettungen (Vektorsuche) oder einer Kombination aus beidem basieren.<\/li>\n\n\n\n
  3. Retrieval<\/strong>: Bei einer Anfrage sucht das System in diesem Index nach den relevantesten Textpassagen.<\/li>\n\n\n\n
  4. Generation<\/strong>: Diese gefundenen Passagen werden in den Kontext des Modells eingef\u00fcgt, bevor es die Antwort generiert.<\/li>\n<\/ol>\n\n\n\n

    Atlas ruft also nicht das Ablaufdatum des Passworts aus dem Ged\u00e4chtnis ab, sondern liest eine autorisierte Kopie in dem Moment, in dem er sie braucht. Das macht die Antwort frisch und \u00fcberpr\u00fcfbar. RAG ist heute das Herzst\u00fcck vieler Dokumenten-Assistenten, Support-Bots und Unternehmenssuchwerkzeuge. Es erm\u00f6glicht es, LLMs mit firmeninternem Wissen zu f\u00fcttern, ohne sie daf\u00fcr teuer nachtrainieren zu m\u00fcssen <\/a>.<\/p>\n\n\n\n

    Allerdings l\u00f6st RAG nur das Problem des Wissens<\/strong>, nicht das der Handlungsf\u00e4higkeit<\/strong>. Ein Dokumentenindex kann keinen Live-Flugpreis abfragen, eine Buchung vornehmen oder den Kalender aktualisieren.<\/p>\n\n\n\n

    MCP: Die standardisierte Werkzeugkiste<\/h2>\n\n\n\n

    Die zweite Mauer, die Atlas einrennt, ist die des Handelns<\/strong>. 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.<\/p>\n\n\n\n

    Die naheliegende L\u00f6sung ist Function Calling<\/strong>. Das Modell schl\u00e4gt in seiner Antwort einen strukturierten Funktionsaufruf vor, etwa search_flights<\/code> mit den Parametern origin<\/code>, destination<\/code> und travel_dates<\/code>. Die Host-Anwendung validiert den Aufruf, f\u00fchrt den Code aus und gibt das Ergebnis zur\u00fcck an das Modell. Diese Schleife ist der grundlegende Motor vieler KI-Agenten <\/a>.<\/p>\n\n\n\n

    F\u00fcr jeden Dienst muss ein Entwickler jedoch einen individuellen Connector bauen: die API-Dokumentation lesen, das Datenformat mappen, Berechtigungen einrichten. Das f\u00fchrt zu einem wachsenden Berg an individuellem, schwer wartbarem Code.<\/p>\n\n\n\n

    An diesem Punkt kommt das Model Context Protocol (MCP)<\/strong> ins Spiel <\/a><\/a>. Anthropic f\u00fchrte es im November 2024 als offenen Standard ein <\/a>. MCP folgt einer Client-Host-Server-Architektur<\/strong> <\/a><\/a>:<\/p>\n\n\n\n