A2A mit bestehenden Agenten-Frameworks integrieren: Eine Hermes-Agent-Demonstration

Warum A2A für die Agenten-Orchestrierung wichtig ist

Das Agent2Agent-Protokoll (A2A) ist ein offener Standard, den Google im April 2025 für die Kommunikation zwischen Agenten vorstellte. Es definiert, wie ein KI-Agent die Fähigkeiten eines anderen Agenten entdeckt, ihm eine Aufgabe sendet, Streaming-Ausgabe empfängt und die Aufgabe über ihren Lebenszyklus verfolgt — alles über JSON-RPC 2.0, ohne vorauszusetzen, dass beide Agenten dasselbe Framework, denselben Modellanbieter oder dieselbe Deployment-Topologie teilen.

A2A füllt eine Lücke, die MCP nicht abdeckt. MCP verbindet einen Agenten mit Werkzeugen und Datenquellen — es ist ein Werkzeugaufruf-Protokoll. A2A verbindet Agenten mit Agenten. Ein Agent, der eine spezialisierte Fähigkeit benötigt (Preislogik, Katalogsuche, RFQ-Verarbeitung), kann die Arbeit an einen Remote-Agenten delegieren, der diese Fähigkeit über einen A2A-Endpunkt bereitstellt, das Ergebnis als A2A-Aufgabe erhalten und seinen eigenen Workflow fortsetzen. Die beiden Protokolle sind komplementär: MCP gibt einem Agenten Hände; A2A gibt ihm Kollegen.

Die A2A-Spezifikation definiert drei Kernprimitive:

• Agent Card — ein JSON-Dokument unter /.well-known/agent-card.json, das die Identität, Fähigkeiten, Skills und den Service-Endpunkt des Agenten beschreibt. So entdecken Agenten einander.
• Task — die Arbeitseinheit. Ein Client sendet eine Aufgabe über message/send (nicht-streamend) oder message/stream (streamend). Die Aufgabe durchläuft Zustände: submitted, working, input-required, completed, failed, canceled.
• Artifact — strukturierte Ausgabe, die während der Aufgabenausführung erzeugt und dem Client gestreamt wird, sobald sie verfügbar ist.

Für B2B-Deployments ist der Wert konkret: Anstatt einen monolithischen Agenten zu bauen, der alles erledigt, komponiert man spezialisierte Agenten, die jeweils eine Domäne besitzen — und sie koordinieren sich über ein Protokoll, nicht über gemeinsamen Speicher oder hartkodierte Funktionsaufrufe.

Das Integrationsproblem

Die meisten bestehenden Agenten-Frameworks sprechen kein A2A. Sie haben ihre eigenen nativen API-Oberflächen, ihre eigenen Aufgabenmodelle, ihre eigenen Streaming-Mechanismen. Hermes Agent (von Nous Research) stellt eine OpenAI-kompatible API-Schnittstelle unter /v1/chat/completions und ein laufbasiertes SSE-Streaming-Interface unter /v1/runs und /v1/runs/{id}/events bereit. OpenClaw bedient eine OpenResponses-kompatible API unter POST /v1/responses. LangGraph hat ein eigenes Graph-Ausführungsmodell. CrewAI hat einen eigenen Crew-Dispatch.

Keines dieser Frameworks wird seine Interna umschreiben, um A2A zu unterstützen. Noch sollten sie — ihre nativen APIs bedienen ihre eigenen Ökosysteme gut. Die Frage ist: Können sie an einem A2A-Agentennetzwerk teilnehmen, ohne ihren Code zu ändern?

Die Antwort ist eine Brückenschicht — eine Komponente, die zwischen dem A2A-Protokoll und der nativen API des Frameworks sitzt. Die Brücke implementiert die A2A-JSON-RPC-Oberfläche auf der einen Seite (Agent Card, Aufgaben-Lebenszyklus, Streaming) und übersetzt auf der anderen Seite in die nativen Aufrufe des Frameworks. Das Framework weiß nicht, dass es über A2A aufgerufen wird. Der A2A-Client weiß nicht, welches Framework die Aufgabe ausführt.

Dieser Artikel führt durch das Brückenmuster am Beispiel von Hermes Agent. Dasselbe Muster gilt für OpenClaw und andere Frameworks — der Brücken-Handler ist das einzige Bauteil, das sich ändert.

Die Brückenarchitektur

Eine funktionierende Referenzimplementierung dieses Musters ist der a2a_daemon_engine — ein A2A-Protokoll-Daemon, der als Gateway-Modul läuft und die Ausführung an einsteckbare Handler weiterleitet. Die Architektur ist:

A2A Client (beliebiger Agent oder Anwendung)
  │
  POST /{endpoint_id}/a2a  (message/send | message/stream)
  │
  ▼
Gateway (Auth, Routing, SSE-Client-Verwaltung)
  │
  ▼
A2A Daemon Executor
  │
  resolve_agent(uuid) → Datenbank-Lookup
  load_agent_handler()  ← datengesteuertes, metadatenbasiertes Routing
  │
  ├── HermesAgentHandler
  │     → POST /v1/runs → GET /v1/runs/{id}/events → SSE-Streaming
  │     → POST /v1/chat/completions (nicht-streamend)
  │
  └── [AnyFrameworkHandler]  ← selbes Interface, andere Übersetzung
        → native API des Frameworks

Die Brücke hat drei Schichten:

1. A2A-Protokollschicht — übernimmt JSON-RPC-Dispatch, Agent-Card-Auslieferung, Aufgaben-Zustandsmaschine und das A2A-SDK-EventQueue. Dies ist frameworkagnostisch. Es ist bei jeder Integration identisch.

2. Gateway-Transportschicht — übernimmt HTTP, Authentifizierung, SSE-Client-Lebenszyklus und Routing. Ebenfalls frameworkagnostisch. Das Gateway besitzt die Leitung; die Brücke besitzt die Übersetzung.

3. Framework-Handler — der einzige frameworkspezifische Code. Er implementiert ein ask_model()-Interface: A2A-Nachrichtenteile und Kontext akzeptieren, die native API des Frameworks aufrufen, die Antwort zurück in A2A-Nachrichtenteile konvertieren und (bei Streaming) Token-Deltas an den SSE-Kanal weiterleiten.

Ein neues Framework hinzuzufügen bedeutet, eine Handler-Klasse zu schreiben. Alles andere — die Protokolloberfläche, das Gateway-Dispatch, das SSE-Management, die Aufgabenpersistenz — ist gemeinsame Infrastruktur.

Demonstration: Die Hermes-Agent-Brücke

Der HermesAgentHandler ist das ausgearbeitete Beispiel. Er brückt A2A-Aufgabensemantik zum Hermes-Agent-API-Server. Der Handler unterstützt zwei Ausführungsmodi:

Nicht-streamend: message/send mit message_response

Der Handler ruft POST /v1/chat/completions auf dem Hermes-API-Server auf — die OpenAI-kompatible Schnittstelle. Die Anfrage trägt die konvertierten A2A-Nachrichtenteile als Chat-Completion-Payload. Hermes verarbeitet die Anfrage (Modellinferenz, Werkzeugaufrufe, Agenten-Reasoning) und gibt eine einzelne Antwort zurück. Der Handler konvertiert die Antwort in eine A2A-Message mit ROLE_AGENT und emittiert sie an das SDK-EventQueue.

Der Client erhält eine einzelne JSON-RPC-Antwort mit dem vollständigen Agenten-Text. Keine Zwischenstatusereignisse, keine Streaming-Chunks — die Anfrage blockiert, bis Hermes abgeschlossen ist.

Streamend: message/send mit task_execution und stream: true

Der Handler ruft POST /v1/runs auf, um einen Lauf zu erzeugen, und öffnet dann eine SSE-Verbindung zu GET /v1/runs/{id}/events. Hermes streamt Ereignisse, sobald sie eintreten: Token-Deltas, Reasoning-Metadaten, Werkzeugaufruf-/Ergebnis-Benachrichtigungen, Genehmigungsanforderungen und Lebenszyklusereignisse (run.created, run.completed, run.failed).

Der Handler führt eine Drain-Schleife in einem Hintergrund-Thread. Jedes message.delta-Ereignis wird an den SSE-Manager des Gateways weitergeleitet, um es in Echtzeit an verbundene Clients auszuliefern. Der Handler akkumuliert Token in einem einzelnen Puffer. Wenn run.completed eintrifft, wird der akkumulierte Text als einzelne A2A-Message an das SDK-EventQueue emittiert, und ein COMPLETED-Statusereignis wird ausschließlich an SSE weitergeleitet.

Dieses Zwei-Pfade-Design — SSE für Echtzeit-Chunks, SDK-EventQueue für die endgültige akkumulierte Nachricht — ist eine Reaktion auf eine Einschränkung im A2A-SDK v2, die unten erläutert wird.

Human-in-the-Loop-Genehmigung über Agentengrenzen hinweg

Hermes unterstützt Human-in-the-Loop-Genehmigungstore — wenn ein Agent die Erlaubnis benötigt, eine sensible Aktion auszuführen, pausiert er und emittiert eine Genehmigungsanforderung. Die Brücke übersetzt dies in den A2A-INPUT_REQUIRED-Zustand, der dem aufrufenden Agenten (oder menschlichen Bediener) signalisiert, dass eine Eingabe erforderlich ist. Die Antwort kommt über POST /v1/runs/{id}/approval zurück, und der Lauf wird fortgesetzt.

Hier zeigt das Brückenmuster seinen Wert. A2A definiert INPUT_REQUIRED als Zustand erster Klasse. Hermes hat seinen eigenen Genehmigungsmechanismus. Die Brücke bildet das eine auf das andere ab, und der aufrufende Agent — der selbst ein A2A-Client sein kann, der auf einem völlig anderen Framework läuft — sieht eine Standardprotokoll-Zustandsüberführung, kein Hermes-spezifisches Detail. Eine Agenten-Delegationskette kann einen Schritt enthalten, der eine menschliche Genehmigung erfordert (eine Kaufautorisierung, eine Datenzugriffsentscheidung, eine Angebotsgenehmigung), und das A2A-Protokoll trägt dieses Tor transparent über Frameworkgrenzen hinweg.

A2A-Zustandsabbildung

A2A definiert eine Aufgaben-Zustandsmaschine: submitted → working → input-required | completed | failed | canceled. Jedes Framework hat sein eigenes Ereignisvokabular. Die Brücke bildet zwischen ihnen ab.

Die Hermes-Ereignis-zu-Zustand-Abbildung:

Hermes-SSE-Ereignis	A2A-Aufgabenstatus	Brückenaktion
run.created	WORKING	run_id für Abbruch-Unterstützung registrieren
message.delta	WORKING	Token akkumulieren; pro-Chunk an SSE emittieren
reasoning.available	WORKING	Reasoning-Metadaten — keine Token-Emission
tool.call / tool.result	WORKING	Nur Werkzeugausführungs-Metadaten
approval.required	INPUT_REQUIRED	Genehmigungs-Chunk emittieren; pending_approval speichern
run.completed	COMPLETED	Stream-Ereignis setzen; endgültigen Text akkumulieren
run.failed	FAILED	Fehler-Chunk emittieren; FAILED-Zustand setzen
POST /v1/runs/{id}/stop	CANCELED	Externer Abbruch über tasks/cancel
POST /v1/runs/{id}/approval	(setzt Lauf fort)	Über operation="approval_response" aufgelöst

Diese Tabelle ist das Herz der Brücke. Jede Framework-Integration erzeugt eine äquivalente Tabelle — die nativen Ereignisse des Frameworks links, die A2A-Zustände rechts, die Brückenaktionen in der Mitte. Das Dokument HERMES_INTEGRATION.md in der Referenzimplementierung zeichnet das genaue Hermes-Ereignisformat, die Konfigurationsschlüssel und die End-to-End-Ablaufdetails auf.

Die A2A-SDK-v2-Einschränkung und das Zwei-Pfade-Fix

Das A2A-SDK v2 (a2a-sdk==1.0.2) legt der on_message_send-Pfad zwei Einschränkungen auf, die jede Brückenimplementierung geprägt haben:

1. Nur eine einzelne Message. Das Emitieren mehrerer Message-Objekte an das SDK-EventQueue löst InvalidAgentResponseError: Multiple Message objects received. aus.
2. Kein TaskStatusUpdateEvent. Statusereignisse lösen InvalidAgentResponseError: Received TaskStatusUpdateEvent in message mode. aus.

Eine naive Brücke würde ein Message pro Token-Delta emittieren — das natürliche Streaming-Muster. Das SDK lehnt dies ab. Es lehnt auch Statusereignisse (WORKING, COMPLETED) auf dem message/send-Pfad ab.

Die Lösung ist ein Zwei-Pfade-Ausgabekanal:

• SSE (gateway-verwaltet): Token-Chunks werden in Echtzeit an SSE weitergeleitet. Verbundene Clients sehen Streaming-Ausgabe, sobald sie eintrifft. Statusereignisse (WORKING, COMPLETED, FAILED) gehen ebenfalls ausschließlich an SSE.
• SDK-EventQueue: Nach Abschluss des Streams wird eine einzelne akkumulierte Message, die den vollständigen Antworttext enthält, an das SDK-EventQueue emittiert. Dies ist, was die JSON-RPC-message/send-Antwort zurückgibt.

Der Client erhält Echtzeit-Streaming über SSE und eine saubere Einzelnachrichten-JSON-RPC-Antwort über das SDK. Beide Kanäle funktionieren; keiner verletzt die SDK-Einschränkungen. Dieses Muster ist frameworkunabhängig — es gilt, ob das Backend Hermes, OpenClaw oder ein beliebiger zukünftiger Handler ist.

Das Muster auf OpenClaw anwenden

OpenClaws Gateway-API stellt eine andere native Oberfläche bereit als Hermes, aber das Brückenmuster ist identisch. Ein OpenClawHandler würde dasselbe ask_model()-Interface implementieren und A2A-Aufgabensemantik in OpenClaw-Gateway-Aufrufe übersetzen:

• Nicht-streamend bildet auf POST /v1/responses ab, wobei die A2A-Nachrichtenteile in OpenResponses-Eingabeelemente konvertiert werden. Die Antwort wird zurück in eine A2A-Message konvertiert.
• Streaming bildet auf POST /v1/responses mit stream: true ab, konsumiert den SSE-Ereignisstrom und leitet Token-Deltas an den A2A-SSE-Kanal weiter. Das OpenResponses-Streaming-Format verwendet response.output_text.delta für Token-Chunks und response.completed für den Abschluss — andere Ereignisnamen, dieselbe Brückenstruktur.
• Agentenauswahl verwendet das model-Feld (openclaw/<agentId>) oder den x-openclaw-agent-id-Header, abgebildet aus A2A-Agenten-Metadaten.
• Sitzungskontinuität nutzt OpenClaws previous_response_id- oder user-Feld für stabiles Session-Routing, was sich natürlich auf A2A-Aufgabenpersistenz abbilden lässt.

Die Zustandsabbildungstabelle für OpenClaw sähe so aus:

OpenClaw-Ereignis	A2A-Aufgabenstatus	Brückenaktion
response.created	WORKING	Response-ID registrieren
response.output_text.delta	WORKING	Token akkumulieren; an SSE emittieren
response.completed	COMPLETED	Endgültigen Text akkumulieren; Message emittieren
response.failed	FAILED	Fehler emittieren; FAILED setzen

Dieselben Spalten, dieselbe Struktur, andere Ereignisnamen. Der Brücken-Handler ist das einzige Bauteil, das sich zwischen Frameworks ändert.

Konfiguration: metadatengesteuertes Routing

Das Agenten-Routing ist metadatengesteuert, nicht umgebungsvariablengesteuert. Jeder Agenteneintrag in der Datenbank trägt seine Handler-Konfiguration in einer metadata-JSON-Spalte. Für einen Hermes-gestützten Agenten:

{
  "module_name": "a2a_daemon_engine.handlers.a2a_hermes_handler",
  "class_name": "HermesAgentHandler",
  "hermes_api_url": "http://127.0.0.1:8642",
  "hermes_api_key": "hermes-local-key",
  "hermes_model": "hermes-agent",
  "hermes_timeout": 300.0
}

Für einen OpenClaw-gestützten Agenten würde der Metadateneintrag auf den OpenClaw-Handler verweisen:

{
  "module_name": "a2a_daemon_engine.handlers.a2a_openclaw_handler",
  "class_name": "OpenClawHandler",
  "openclaw_api_url": "http://127.0.0.1:3000",
  "openclaw_api_key": "openclaw-key",
  "openclaw_agent_id": "pricing-agent",
  "openclaw_timeout": 300.0
}

Die Konfigurationsauflösung folgt einer Prioritätskette: Agent-Metadaten (DB) → Setting-Dict → Config-Standardwerte (Umgebungsvariablen). Pro-Agent-Overrides haben Vorrang vor globalen Standards. Zwei Agenten können auf verschiedene Frameworks verweisen — einer auf Hermes für reasoning-intensive Aufgaben, ein anderer auf OpenClaw für Workflow-Orchestrierungs-Aufgaben — und die A2A-Protokolloberfläche sieht für den aufrufenden Agenten identisch aus.

Was dies ermöglicht

Das Brückenmuster bietet drei Fähigkeiten, die von Grund auf neu zusammenzustellen schwierig ist:

1. Agent-zu-Agent-Delegation mit Streaming. A2A-Client-Agenten können Aufgaben an einen Hermes-gestützten Agenten senden und Echtzeit-Token-Streaming über SSE empfangen. Der aufrufende Agent muss nicht wissen, dass der Remote-Agent Hermes ausführt — er sieht einen A2A-Endpunkt mit einer Agent Card und einer JSON-RPC-Schnittstelle.

2. Human-in-the-Loop-Genehmigung über Agentengrenzen hinweg. Framework-native Genehmigungstore (Hermes-Genehmigungsanforderungen, OpenClaw-Bedienergenehmigungen) bilden auf A2A-INPUT_REQUIRED-Zustände ab. Eine Agenten-Delegationskette kann einen Schritt enthalten, der eine menschliche Genehmigung erfordert, und das A2A-Protokoll trägt diese Zustandsüberführung zurück zum ursprünglichen Agenten oder Bediener — unabhängig davon, auf welchem Framework jeder Agent in der Kette läuft.

3. Multi-Framework-Routing über ein Gateway. Dasselbe Gateway, derselbe Executor, dieselbe A2A-Protokolloberfläche bedient Handler für verschiedene Frameworks. Ein neues Framework hinzuzufügen bedeutet, eine Handler-Klasse zu schreiben und einen Agenteneintrag einzufügen — kein neues Deployment, keine neue Protokollimplementierung.

Die Referenzimplementierung unterstützt außerdem AWS-Lambda-Dispatch für serverloses A2A, experimentelles gRPC-Transport mit bidirektionalem Streaming und duale Backend-Persistenz (DynamoDB oder PostgreSQL) mit Multi-Tenant-Isolation über zusammengesetzte Partitionsschlüssel. Das a2a_daemon_engine-Repository und sein Hermes-Integrationsleitfaden enthalten die vollständige Implementierung, die Konfigurationsreferenz und die Zustandsabbildungsdetails.

---

Ein mittelständischer Distributor braucht Angebots-Agenten, die mit Katalog-Agenten sprechen, die mit Bestands-Agenten sprechen — jeder durch ein anderes Framework gestützt, jeder von einem anderen Team betreut. A2A gibt diesen Agenten ein gemeinsames Protokoll. Eine Brückenschicht ermöglicht es Hermes Agent, OpenClaw und jedem anderen Framework, teilzunehmen, ohne seine Interna umzuschreiben. Der a2a_daemon_engine ist eine funktionierende Referenzimplementierung dieses Brückenmusters, demonstriert mit Hermes Agent.

Angebot für ein abgegrenztes Build anfordern

Einwöchige Discovery. Sie erhalten ein Systeminventar, eine Workflow-Karte und einen festen Umfang — ob Sie mit uns bauen oder nicht.