Erstellung eines LLM-Agent-Newsrooms mit A2A-Protokoll und MCP in Elasticsearch: Teil 1

Agent Builder ist ab sofort als technische Vorschau verfügbar. Starten Sie mit einer Elastic Cloud-Testversion und lesen Sie die Dokumentation zum Agent Builder hier.

Einleitung

Die derzeitigen LLM-gestützten Systeme entwickeln sich rasant über Einzelmodellanwendungen hinaus zu komplexen Netzwerken, in denen spezialisierte Agenten zusammenarbeiten, um Aufgaben zu bewältigen, die mit modernen Computern bisher für unmöglich gehalten wurden. Mit zunehmender Komplexität dieser Systeme rückt die Infrastruktur, die die Kommunikation der Agenten und den Zugriff auf Werkzeuge ermöglicht, in den Mittelpunkt der Entwicklung. Zur Erfüllung dieser Anforderungen haben sich zwei komplementäre Ansätze herausgebildet: Agent2Agent (A2A) -Protokolle für die Koordination mehrerer Agenten und das Model Context Protocol (MCP) für den standardisierten Zugriff auf Werkzeuge und Ressourcen.

Das Verständnis dafür, wann man die einzelnen Elemente harmonisch miteinander und wann man sie ohne die anderen einsetzt, kann die Skalierbarkeit, Wartbarkeit und Effektivität Ihrer Anwendungen erheblich beeinflussen. Dieser Artikel untersucht die Konzepte und Implementierungen von A2A am praktischen Beispiel einer digitalen Nachrichtenredaktion, in der spezialisierte LLM-Agenten zusammenarbeiten, um Nachrichtenartikel zu recherchieren, zu schreiben, zu bearbeiten und zu veröffentlichen.

Ein zugehöriges Repository finden Sie hier, und konkrete Beispiele für A2A in der Praxis werden wir gegen Ende des Artikels in Abschnitt 5 untersuchen.

Voraussetzungen

Das Repository besteht aus Python-basierten Implementierungen der A2A-Agenten. Flask stellt einen API-Server sowie einen benutzerdefinierten Python-Messaging-Dienst namens Event Hub bereit, der Nachrichten für die Protokollierung und UI-Aktualisierungen weiterleitet. Schließlich wird eine React-Benutzeroberfläche für die eigenständige Nutzung der Newsroom-Funktionen bereitgestellt. Alles ist zur einfacheren Implementierung in einem Docker-Image enthalten. Wenn Sie die Dienste direkt auf Ihrem Rechner ausführen möchten, sollten Sie sicherstellen, dass die folgenden Technologien installiert sind:

Sprachen und Laufzeiten

• Python 13.12 – Kern-Backend-Sprache
• Node.js 18+ - Optionale React-Benutzeroberfläche

Kern-Frameworks und SDKs:

• A2A SDK 0.3.8 – Agentenkoordination und -kommunikation
• Anthropic SDK - Claude-Integration für die KI-Generierung
• Uvicorn – ASGI-Server zum Ausführen von Agenten
• FastMCP 2.12.5+ - MCP-Server-Implementierung
• React 18.2 – Frontend-UI-Framework

Daten & Suche

• Elasticsearch 9.1.1+ - Artikelindexierung und -suche

Docker-Bereitstellung (optional, aber empfohlen)

• Docker 28.5.1+

Abschnitt 1: Was ist Agent2Agent (A2A)?

Definition und Kernkonzepte

Offizielle Spezifikation: https://a2a-protocol.org/latest/specification/

Ursprung und Evolution

Das Konzept der Agent2Agent-Kommunikation bzw. von Multiagentensystemen hat seine Wurzeln in der Forschung zu verteilten Systemen, Microservices und Multiagentensystemen, die Jahrzehnte zurückreicht. Frühe Arbeiten im Bereich der verteilten künstlichen Intelligenz legten den Grundstein für Agenten, die verhandeln, koordinieren und zusammenarbeiten können. Diese frühen Systeme dienten der Durchführung groß angelegter sozialer Simulationen, der akademischen Forschung und dem Management von Stromnetzen.

Mit der Verfügbarkeit von LLM und den gesunkenen Betriebskosten wurden Multiagentensysteme auch für den „Prosumer“-Markt zugänglich, unterstützt von Google und der breiteren KI-Forschungsgemeinschaft. Die Einführung des A2A-Protokolls, die heute als Agent2Agent-Systeme bekannt ist, hat sich zu einem modernen Standard entwickelt, der speziell für das Zeitalter mehrerer großer Sprachmodelle konzipiert wurde, die ihre Bemühungen und Aufgaben koordinieren.

Das A2A-Protokoll gewährleistet eine reibungslose Kommunikation und Koordination zwischen den Agenten, indem es einheitliche Standards und Prinzipien an den Interaktionspunkten anwendet, an denen LLMs sich verbinden und kommunizieren. Diese Standardisierung ermöglicht es Agenten verschiedener Entwickler – die unterschiedliche zugrunde liegende Modelle verwenden – effektiv zusammenzuarbeiten.

Kommunikationsprotokolle sind nicht neu und haben sich in nahezu jeder digitalen Transaktion im Internet fest etabliert. Wenn Sie https://www.elastic.co/search-labs eingegeben haben Wenn Sie einen Browser verwenden, um diesen Artikel zu erreichen, ist die Wahrscheinlichkeit hoch, dass alle TCP/IP-, HTTP-Transport- und DNS-Lookup-Protokolle ausgeführt wurden, um ein konsistentes Browsererlebnis für uns zu gewährleisten.

Hauptmerkmale

A2A-Systeme basieren auf mehreren grundlegenden Prinzipien, um eine reibungslose Kommunikation zu gewährleisten. Aufbauend auf diesen Prinzipien wird sichergestellt, dass verschiedene Agenten, die auf unterschiedlichen LLMs, Frameworks und Programmiersprachen basieren, nahtlos miteinander interagieren.

Hier sind die vier Hauptprinzipien:

• Nachrichtenübermittlung: Agenten kommunizieren über strukturierte Nachrichten mit klar definierten Eigenschaften und Formaten.
• Koordination: Agenten orchestrieren komplexe Arbeitsabläufe, indem sie Aufgaben untereinander delegieren und Abhängigkeiten verwalten, ohne andere Agenten zu blockieren.
• Spezialisierung: Jeder Agent konzentriert sich auf einen bestimmten Bereich oder eine bestimmte Fähigkeit, wird Experte auf seinem Gebiet und bietet Aufgabenerledigung basierend auf diesen Fähigkeiten an.
• Verteilter Zustand: Zustand und Wissen sind auf mehrere Agenten verteilt und nicht zentralisiert. Die Agenten können sich gegenseitig über den Fortschritt des Aufgabenstatus und Teilergebnisse (Artefakte) informieren.

Die Redaktion: Ein laufendes Beispiel

Stellen Sie sich eine digitale Nachrichtenredaktion vor, die von KI-Agenten gesteuert wird, von denen jeder auf einen anderen Aspekt des Journalismus spezialisiert ist:

• Nachrichtenchef (Koordinator/Kunde): Vergibt Artikel und überwacht den Arbeitsablauf.
• Reporteragent: Verfasst Artikel auf Grundlage von Recherchen und Interviews.
• Rechercheagent: Sammelt Fakten, Statistiken und Hintergrundinformationen.
• Archivagent: Durchsucht historische Artikel und identifiziert Trends mithilfe von Elasticsearch.
• Redaktionsassistent: Überprüft Artikel auf Qualität, Stil und Suchmaschinenoptimierung.
• Verlagsagent: Veröffentlicht freigegebene Artikel über CI/CD auf der Blog-Plattform.

Diese Akteure arbeiten nicht isoliert; wenn der Nachrichtenchef einen Artikel über die Einführung erneuerbarer Energien in Auftrag gibt, benötigt der Reporter den Rechercheur, um Statistiken zu sammeln, den Redakteur, um den Entwurf zu überprüfen, und den Verleger, um den endgültigen Artikel zu veröffentlichen. Diese Koordination erfolgt über A2A-Protokolle.

Abschnitt 2: A2A-Architektur verstehen

Kundenbetreuer- und Fernbetreuerrollen

In der A2A-Architektur übernehmen Agenten zwei Hauptrollen. Der Kundenbetreuer ist dafür verantwortlich, Aufgaben zu formulieren und an andere Betreuer im System zu kommunizieren. Es identifiziert Remote-Agenten und deren Fähigkeiten und nutzt diese Informationen, um fundierte Entscheidungen über die Aufgabenverteilung zu treffen. Der Kundenbetreuer koordiniert den gesamten Arbeitsablauf und sorgt dafür, dass die Aufgaben ordnungsgemäß verteilt werden und das System seine Ziele erreicht.

Der Remote Agent hingegen erledigt Aufgaben, die ihm von Clients übertragen werden. Es stellt Informationen bereit oder ergreift konkrete Maßnahmen als Reaktion auf Anfragen, initiiert aber keine Aktionen selbstständig. Remote-Agenten können bei Bedarf auch mit anderen Remote-Agenten kommunizieren, um ihre zugewiesenen Aufgaben zu erfüllen, wodurch ein kollaboratives Netzwerk spezialisierter Kompetenzen entsteht.

In unserer Redaktion fungiert der Nachrichtenchef als Ansprechpartner für den Kunden, während Reporter, Rechercheur, Redakteur und Verleger als externe Mitarbeiter Anfragen bearbeiten und sich untereinander abstimmen.

Kernfunktionen für A2A

A2A-Protokolle definieren verschiedene Funktionen, die die Zusammenarbeit mehrerer Agenten ermöglichen:

1. Entdeckung

A2A-Server müssen ihre Fähigkeiten bekanntgeben, damit Clients wissen, wann und wie sie diese für bestimmte Aufgaben nutzen können. Dies geschieht mithilfe von Agentenkarten – JSON-Dokumenten, die die Fähigkeiten, Eingaben und Ausgaben eines Agenten beschreiben. Agentenkarten werden über einheitliche, bekannte Endpunkte (wie den empfohlenen /.well-known/agent-card.json -Endpunkt) bereitgestellt, sodass Clients die Fähigkeiten eines Agenten ermitteln und abfragen können, bevor sie die Zusammenarbeit initiieren.

Nachfolgend sehen Sie eine Beispiel-Agentenkarte für den benutzerdefinierten Archivagenten von Elastic, „Archie Archivist“. Beachten Sie, dass Softwareanbieter wie Elastic ihre A2A-Agenten hosten und eine URL für den Zugriff bereitstellen:

Diese Agentenkarte offenbart mehrere wichtige Aspekte des Archivagenten von Elastic. Der Agent stellt sich als „Archie Archivist“ vor und gibt seinen Zweck klar an: die Suche nach historischen Nachrichtendokumenten in einem Elasticsearch-Index. Die Karte gibt den Anbieter (Elastic) und die Protokollversion (0.3.0) an und gewährleistet so die Kompatibilität mit anderen A2A-kompatiblen Agenten. Am wichtigsten ist jedoch, dass das skills -Array die spezifischen Fähigkeiten auflistet, die dieser Agent bietet, darunter leistungsstarke Suchfunktionen und intelligente Indexerkundung. Jede Fähigkeit definiert, welche Eingabe- und Ausgabemodi sie unterstützt, sodass Clients genau verstehen, wie sie mit diesem Agenten kommunizieren können. Dieser Agent basiert auf dem Agent Builder-Service von Elastic, der eine Reihe nativer, LLM-gestützter Tools und API-Endpunkte bereitstellt, um mit Ihrem Datenspeicher zu kommunizieren und nicht nur Daten daraus abzurufen. Zugriff auf A2A-Agenten in Elasticsearch finden Sie hier.

2. Verhandlung

Kunden und Agenten müssen sich auf Kommunikationsmethoden einigen – egal ob die Interaktion per Text, Formular, iFrames oder sogar Audio/Video erfolgt –, um eine ordnungsgemäße Benutzerinteraktion und einen reibungslosen Datenaustausch zu gewährleisten. Diese Aushandlung findet zu Beginn der Zusammenarbeit der Agenten statt und legt die Protokolle fest, die ihre Interaktion während des gesamten Arbeitsablaufs regeln. Ein Mitarbeiter im telefonischen Kundenservice könnte beispielsweise die Kommunikation über Audiostreams aushandeln, während ein Mitarbeiter im Datenanalyse-Bereich strukturiertes JSON bevorzugen könnte. Der Verhandlungsprozess stellt sicher, dass beide Parteien Informationen effektiv in einem Format austauschen können, das ihren Fähigkeiten und den Anforderungen der jeweiligen Aufgabe entspricht.

Die im obigen JSON-Ausschnitt aufgeführten Funktionen verfügen alle über Eingabe- und Ausgabeschemata; diese legen fest, wie andere Agenten mit diesem Agenten interagieren sollen.

3. Aufgaben- und Zustandsmanagement

Kunden und Agenten benötigen Mechanismen, um während der gesamten Aufgabenausführung über Aufgabenstatus, Änderungen und Abhängigkeiten zu kommunizieren. Dies umfasst die Verwaltung des gesamten Lebenszyklus einer Aufgabe von der Erstellung und Zuweisung bis hin zu Fortschrittsaktualisierungen und Statusänderungen. Typische Status sind: ausstehend, in Bearbeitung, abgeschlossen oder fehlgeschlagen. Das System muss außerdem Abhängigkeiten zwischen Aufgaben verfolgen, um sicherzustellen, dass die erforderlichen Vorarbeiten abgeschlossen sind, bevor die abhängigen Aufgaben beginnen. Fehlerbehandlung und Wiederholungslogik sind ebenfalls wesentliche Bestandteile, die es dem System ermöglichen, sich nach Fehlern reibungslos zu erholen und weiterhin Fortschritte in Richtung des Hauptziels zu erzielen.

Beispiel einer Aufgabenmeldung:

Diese Beispiel-Aufgabennachricht veranschaulicht mehrere wichtige Aspekte der A2A-Kommunikation.

• Die Nachrichtenstruktur umfasst Metadaten wie eine eindeutige Nachrichtenkennung, die Art der gesendeten Nachricht, die Kennung von Absender und Empfänger sowie einen Zeitstempel zur Nachverfolgung und Fehlerbehebung.
• Die Nutzlast enthält die eigentlichen Aufgabeninformationen, in denen angegeben wird, welche Funktion auf dem Remote-Agenten aufgerufen wird, und die notwendigen Parameter zur Ausführung dieser Funktion bereitgestellt werden.
• Der Abschnitt „Kontext“ liefert zusätzliche Informationen, die dem empfangenden Agenten helfen, den übergeordneten Arbeitsablauf zu verstehen, einschließlich Fristen und Prioritätsstufen, die Aufschluss darüber geben, wie der Agent seine Ressourcen einsetzen und seine Arbeit planen sollte.

4. Zusammenarbeit

Kunden und Agenten müssen eine dynamische, aber dennoch strukturierte Interaktion unterstützen, die es den Agenten ermöglicht, Klärungen, Informationen oder Teilaktionen vom Kunden, anderen Agenten oder Benutzern anzufordern. Dadurch entsteht eine kollaborative Umgebung, in der Agenten bei unklaren Anfangsanweisungen Nachfragen stellen, zusätzlichen Kontext anfordern können, um bessere Entscheidungen zu treffen, Teilaufgaben an andere Agenten mit besser geeigneter Expertise delegieren und Zwischenergebnisse zur Rückmeldung liefern können, bevor sie mit der Gesamtaufgabe fortfahren. Diese multidirektionale Kommunikation stellt sicher, dass die Agenten nicht isoliert arbeiten, sondern in einen fortlaufenden Dialog eingebunden sind, der zu besseren Ergebnissen führt.

Verteilte Peer-to-Peer-Kommunikation

A2A ermöglicht verteilte Kommunikation, bei der Agenten von verschiedenen Organisationen gehostet werden können, wobei einige Agenten intern verwaltet werden, während andere von Drittanbietern bereitgestellt werden. Diese Agenten können auf verschiedenen Infrastrukturen ausgeführt werden – potenziell über mehrere Cloud-Anbieter oder lokale Rechenzentren hinweg. Sie verwenden möglicherweise unterschiedliche zugrunde liegende LLMs, wobei einige Agenten auf GPT-Modellen, andere auf Claude und wieder andere auf Open-Source-Alternativen basieren. Agenten könnten sogar über verschiedene geografische Regionen hinweg operieren, um den Anforderungen der Datensouveränität nachzukommen oder die Latenz zu reduzieren. Trotz dieser Vielfalt stimmen alle Agenten einem gemeinsamen Kommunikationsprotokoll für den Informationsaustausch zu, wodurch die Interoperabilität unabhängig von Implementierungsdetails gewährleistet wird. Diese verteilte Architektur bietet Flexibilität beim Aufbau und der Bereitstellung von Systemen und ermöglicht es Organisationen, die besten Agenten und Infrastrukturen für ihre spezifischen Bedürfnisse zu kombinieren.

Dies ist die endgültige Architektur der Newsroom-Anwendung:

Abschnitt 3: Modellkontextprotokoll (MCP)

Definition und Zweck

Das Model Context Protocol (MCP) ist ein von Anthropic entwickeltes standardisiertes Protokoll, das dazu dient, ein einzelnes LLM mit benutzerdefinierten Werkzeugen, Ressourcen und Eingabeaufforderungen sowie anderen ergänzenden Codebasiserweiterungen zu erweitern und zu stärken. MCP bietet eine universelle Schnittstelle zwischen Sprachmodellen und den externen Ressourcen, die sie benötigen, um Aufgaben effektiv zu erledigen. Dieser Artikel beschreibt den aktuellen Stand von MCP anhand von Anwendungsbeispielen, aufkommenden Trends und der Implementierung von Elastic.

Kernkonzepte des MCP

MCP arbeitet mit einer Client-Server-Architektur und besteht aus drei Hauptkomponenten:

• Clients: Anwendungen (wie Claude Desktop oder kundenspezifische KI-Anwendungen), die sich mit MCP-Servern verbinden, um auf deren Funktionen zuzugreifen.
• Server: Anwendungen, die Ressourcen, Werkzeuge und Eingabeaufforderungen für Sprachmodelle bereitstellen. Jeder Server ist darauf spezialisiert, Zugriff auf bestimmte Funktionen oder Datenquellen zu bieten.
  • Tools: Benutzerdefinierte Funktionen, die Modelle aufrufen können, um Aktionen auszuführen, wie z. B. Datenbanken zu durchsuchen, externe APIs aufzurufen oder Datentransformationen durchzuführen.
  • Ressourcen: Datenquellen, aus denen Modelle lesen können, die dynamische oder statische Daten liefern und über URI-Muster aufgerufen werden (ähnlich wie REST-Routen).
  • Eingabeaufforderungen: Wiederverwendbare Eingabeaufforderungsvorlagen mit Variablen, die das Modell bei der Erfüllung spezifischer Aufgaben unterstützen.

Anfrage-Antwort-Muster

MCP folgt einem bekannten Anfrage-Antwort-Interaktionsmuster, ähnlich wie REST-APIs. Der Client (LLM) fordert eine Ressource an oder ruft ein Tool auf. Anschließend verarbeitet der MCP-Server die Anfrage und gibt das Ergebnis zurück, das der LLM zur Fortsetzung seiner Aufgabe verwendet. Dieses zentralisierte Modell mit peripheren Servern bietet im Vergleich zur Peer-to-Peer-Agentenkommunikation ein einfacheres Integrationsmuster.

MCP im Newsroom

In unserem Beispiel aus der Nachrichtenredaktion nutzen einzelne Mitarbeiter MCP-Server, um auf die benötigten Tools und Daten zuzugreifen:

• Der Forscheragent verwendet:
  • News API MCP Server (Zugriff auf Nachrichtendatenbanken)
  • Faktencheck-Server von MCP (Überprüfung von Behauptungen anhand vertrauenswürdiger Quellen)
  • Akademische Datenbank MCP-Server (wissenschaftliche Artikel und Forschungsergebnisse)
• Reporteragent verwendet:
  • Styleguide MCP Server (Schreibstandards für Redaktionen)
  • Template MCP Server (Artikelvorlagen und -formate)
  • Bildbibliothek MCP-Server (Stockfotos und Grafiken)
• Redaktionsagenten verwenden:
  • Grammatikprüfung MCP-Server (Tools zur Sprachqualitätsprüfung)
  • Plagiatserkennungsserver MCP (Originalitätsprüfung)
  • SEO-Analyse MCP-Server (Überschriften- und Keyword-Optimierung)
• Verlagsagenten verwenden:
  • CMS MCP Server (API für Content-Management-Systeme)
  • CI/CD MCP-Server (Bereitstellungspipeline)
  • Analytics MCP Server (Tracking und Monitoring)

Abschnitt 4: Architekturvergleich

Wann sollte man A2A verwenden?

Die A2A-Architektur ist besonders geeignet für Szenarien, die eine echte Zusammenarbeit mehrerer Agenten erfordern. Mehrstufige Arbeitsabläufe, die eine Koordination erfordern, profitieren stark von A2A, insbesondere wenn Aufgaben mehrere sequentielle oder parallele Schritte umfassen, Arbeitsabläufe Iteration und Verfeinerung erfordern und Prozesse Kontrollpunkte und Validierungsanforderungen haben. In unserem Beispiel aus der Nachrichtenredaktion sieht der Arbeitsablauf vor, dass der Reporter den Artikel schreibt, ihn aber gegebenenfalls an den Rechercheur zurückgeben muss, wenn das Vertrauen in bestimmte Fakten gering ist, bevor er ihn an den Redakteur und schließlich an den Verleger weiterleitet.

Domänenspezifische Spezialisierung über mehrere Bereiche hinweg ist ein weiterer wichtiger Anwendungsfall für A2A. Wenn mehrere Experten aus verschiedenen Bereichen benötigt werden, um eine größere Aufgabe zu bewältigen, wobei jeder Experte über fundiertes Fachwissen und spezialisierte Denkfähigkeiten für unterschiedliche Aspekte verfügt, bietet A2A den Koordinierungsrahmen, der für die Herstellung dieser Verbindungen erforderlich ist. Die Redaktion ist dafür ein perfektes Beispiel: Der Rechercheur ist auf die Informationsbeschaffung spezialisiert, der Reporter auf das Schreiben und der Redakteur auf die Qualitätskontrolle – jeder mit einem besonderen Fachgebiet.

Die Notwendigkeit eines autonomen Agentenverhaltens macht A2A besonders wertvoll. Agenten, die selbstständig Entscheidungen treffen können, proaktives Verhalten auf der Grundlage sich ändernder Bedingungen zeigen und sich dynamisch an die Workflow-Anforderungen anpassen können, sind in einer A2A-Architektur besonders erfolgreich. Die horizontale Skalierung spezialisierter Funktionen ist ein weiterer entscheidender Vorteil – anstatt eines einzigen Alleskönners arbeiten mehrere spezialisierte Agenten koordiniert zusammen, und mehrere Instanzen desselben Agenten können Teilaufgaben asynchron bearbeiten. Bei Eilmeldungen in unserer Redaktion arbeiten beispielsweise mehrere Reporter gleichzeitig an verschiedenen Aspekten derselben Geschichte.

Schließlich eignen sich Aufgaben, die eine echte Zusammenarbeit mehrerer Agenten erfordern, ideal für A2A. Dies umfasst LLM-als-Jury-Bewertungsmechanismen , Konsensfindungs- und Abstimmungssysteme sowie kollaborative Problemlösungsansätze, bei denen mehrere Perspektiven erforderlich sind, um das beste Ergebnis zu erzielen.

Wann sollte MCP verwendet werden?

Das Model Context Protocol eignet sich ideal zur Erweiterung der Fähigkeiten eines einzelnen KI-Modells. Wenn ein einzelnes KI-Modell Zugriff auf mehrere Tools und Datenquellen benötigt, bietet MCP die perfekte Lösung mit zentralisierter Datenverarbeitung in Verbindung mit verteilten Tools und unkomplizierter Tool-Integration. In unserem Beispiel aus der Nachrichtenredaktion benötigt der Rechercheagent (ein Modell) Zugriff auf mehrere Datenquellen, darunter die News-API, Faktencheck-Dienste und akademische Datenbanken – der Zugriff erfolgt über standardisierte MCP-Server.

Die Integration standardisierter Werkzeuge gewinnt dann an Bedeutung, wenn die breite Weitergabe und Wiederverwendbarkeit von Werkzeugintegrationen wichtig ist. MCP glänzt hier mit seinem Ökosystem aus vorkonfigurierten MCP-Servern, die die Entwicklungszeit für gängige Integrationen erheblich reduzieren. Wenn Einfachheit und Wartbarkeit gefordert sind, sind die Anfrage-Antwort-Muster von MCP den Entwicklern vertraut, leichter zu verstehen und zu debuggen als verteilte Systeme und weisen eine geringere betriebliche Komplexität auf.

Schließlich wird MCP häufig von Softwareanbietern angeboten, um die Fernkommunikation mit ihren Systemen zu vereinfachen. Diese vom Anbieter bereitgestellten MCP-Server reduzieren die Einarbeitungs- und Entwicklungszeit erheblich und bieten gleichzeitig eine standardisierte Schnittstelle zu proprietären Systemen, wodurch die Integration wesentlich einfacher wird als die Entwicklung kundenspezifischer APIs.

Wann man beides verwendet (A2A ❤️'s MCP)

Viele hochentwickelte Systeme profitieren von der Kombination von A2A und MCP, wie in der A2A-Dokumentation zur MCP-Integration beschrieben. Systeme, die sowohl Koordination als auch Standardisierung erfordern, sind ideale Kandidaten für einen hybriden Ansatz. A2A übernimmt die Agentenkoordination und Workflow-Orchestrierung, während MCP den einzelnen Agenten Zugriff auf die Tools ermöglicht. In unserem Beispiel aus der Redaktion koordinieren sich die Mitarbeiter über A2A; der Arbeitsablauf verläuft dabei vom Reporter über den Rechercheur zum Redakteur und schließlich zum Verleger. Allerdings nutzt jeder Agent MCP-Server für seine spezialisierten Tools, wodurch eine klare architektonische Trennung entsteht.

Mehrere spezialisierte Agenten, die jeweils MCP für den Werkzeugzugriff nutzen, stellen ein gängiges Muster dar, bei dem es eine Agentenkoordinierungsschicht gibt, die von A2A verwaltet wird, und eine Werkzeugzugriffsschicht, die von MCP verwaltet wird. Durch diese klare Trennung der Zuständigkeiten werden die Systeme leichter verständlich und wartungsfreundlicher.

Die Vorteile der Kombination beider Ansätze sind beträchtlich. Sie profitieren von den organisatorischen Vorteilen von Multiagentensystemen, einschließlich Spezialisierung, Autonomie und Parallelverarbeitung, und genießen gleichzeitig die Vorteile von MCP in Bezug auf Standardisierung und Ökosystem, wie z. B. Werkzeugintegration und Ressourcenzugriff. Zwischen Agentenkoordination (A2A) und Ressourcenzugriff (MCP) besteht eine klare Trennung, und vor allem ist A2A für kleinere Aufgaben wie den API-Zugriff allein nicht erforderlich – MCP erledigt diese effizient ohne den Aufwand einer Multi-Agenten-Orchestrierung.

Häufig gestellte Fragen: A2A vs. MCP – Anwendungsfälle

Fazit

Dies ist der erste von zwei Teilen, die die Implementierung von A2A-basierten Agenten behandeln, die durch MCP-Server unterstützt werden, um Support und externen Zugriff auf Daten und Tools zu ermöglichen. Im nächsten Abschnitt wird der konkrete Code untersucht, um zu demonstrieren, wie die einzelnen Elemente zusammenarbeiten, um die Abläufe in einer Online-Nachrichtenredaktion nachzubilden. Obwohl beide Frameworks für sich genommen äußerst leistungsfähig und flexibel sind, werden Sie erst im Zusammenspiel sehen, wie sehr sie sich ergänzen.