A2A im Doppelpack: Zwei Hermes-Instanzen auf verschiedenen Rechnern zur Zusammenarbeit bringen

Ein Hermes auf einem Rechner kommt an seine Grenzen und möchte einen anderen Hermes auf einem anderen Rechner um Hilfe bitten – genau dafür ist A2A da. Aber welche Stolperfallen lauern bei der Bereitstellung? Echte Nutzer sind schon für dich drüber gestolpert.

Wann brauchst du überhaupt zwei Rechner?

Stell dir zuerst eine wichtige Frage: Brauchst du wirklich zwei Computer, oder willst du nur zwei Agenten zusammenarbeiten lassen?

Wenn beide Agenten auf derselben Maschine leben, reichen Delegation oder ein Kanban-Board völlig aus – wie im selben Büro, wo du einfach laut rufst und der Kollege am Nebenschreibtisch dich hört. Da brauchst du kein Telefon. A2A ist für „über Maschinen-/Prozess-/Framework-Grenzen hinweg“ gedacht: Dein Desktop-PC und dein Server laufen jeweils mit einem eigenen Hermes, mit eigenen Erinnerungen, Tools und Login-Zugangsdaten. Erst dann brauchst du die A2A-Brücke.

Erste Schritte

Schritt 1: A2A-Plattform auf beiden Rechnern aktivieren. Wähle bei der Hermes-Installation A2A aus oder setze in der Konfigurationsdatei gateway.platforms.a2a.enabled auf true. Der Standard-Port ist 9900. Dieser Schritt ist, als würdest du jedem Computer eine eigene Tür mit Zugangskontrolle nach außen einbauen.

Schritt 2: Token konfigurieren (Türschlüssel). Auf der Serverseite setzt du A2A_PEER_TOKENS oder A2A_BEARER_TOKEN. Wenn du nur lokal testest, kannst du auf ein Token verzichten, aber dann ist die Tür nur für 127.0.0.1 geöffnet – wie eine Zugangskarte, die nur an Bewohner des eigenen Gebäudes ausgegeben wird.

Schritt 3: Adresse freigeben. Für den Betrieb über mehrere Rechner musst du A2A_HOST setzen, z.B. auf 0.0.0.0 oder die LAN-IP. Damit verschiebst du die Tür vom „internen Flur“ an die „Straßenfront“, sodass der andere Rechner dich finden kann.

Schritt 4: Peers koppeln. Konfiguriere auf der Client-Seite a2a_agents oder nutze direkt a2a_discover("http://Serveradresse:9900"), um die Agent Card des Gegenübers zu sehen – quasi erstmal die Visitenkarte austauschen, um zu bestätigen, wer da ist und welche Fähigkeiten er hat.

Schritt 5: Verifizieren. Aktiviere das A2A-Toolset und schicke mit a2a_call eine einfache Aufgabe als Test. Achte auf das Timeout: Der Client hat standardmäßig 330 Sekunden, das Server-Antwortfenster liegt bei 300 Sekunden. Bei langen Aufgaben musst du das hochsetzen, sonst wird die Arbeit mitten drin abgebrochen. Danach kannst du in ~/.hermes/a2a_audit.jsonl das Audit-Log einsehen.

Praxisbeispiel 1: So sieht eine erfolgreiche Bereitstellung aus

Die offizielle Doku beschreibt ein ideales Szenario: Dein Desktop-Hermes übergibt eine Aufgabe an den Hermes auf dem Server – der Server hat mehr Rechenleistung, stabileres Netz und eine vollständigere Datenbank. Umgekehrt kann der Server-Hermes auch Aufgaben wie „schau mal in der lokalen Datei nach“ an den Desktop weiterreichen. Beide haben ihre eigenen Erinnerungen und Tools, machen ihre eigene Arbeit, entdecken gegenseitig ihre Fähigkeiten über die Agent Card, und die Konversation wird über contextId gesteuert, mit Multi-Turn-Unterstützung.

Das ist wie zwei Abteilungen in einer Firma: Die Marketingabteilung (Desktop) braucht einen Datenanalysebericht, schickt eine E-Mail an die Datenabteilung (Server), die Datenabteilung macht den Bericht und schickt ihn zurück. Beide führen ihre eigenen Akten, ohne sich gegenseitig zu stören.

Praxisbeispiel 2: Eine fehlgeschlagene Bereitstellung

In der Community gibt es einen echten Fall (#82910): Ein Nutzer hat auf zwei macOS-Rechnern einen Zwei-Knoten-Betrieb eingerichtet – ein nutzerorientiertes Gateway + einen Worker. Klingt ähnlich wie das Erfolgsbeispiel oben, aber am Ende ging es schief, und das Team hat die Bereitstellung wieder abgeschaltet.

Das Problem lag darin, dass die Rollen von „Koordinator“ und „Worker“ nicht klar getrennt waren. Der übergeordnete Agent (Koordinator) hat zu viel in seine eigene Session gepackt: Jeder Schritt des Workers, jedes Zwischenergebnis, jeder Denkprozess floss zurück in die Eltern-Session, was zu Kontextaufblähung führte – der Eltern-Agent wurde von einer Informationsflut überrollt und immer träger. Die trans-agenten Transkripte haben die Gesamtleistung ausgebremst, und bei komplexen Aufgaben wurden Wiederherstellungsschleifen ausgelöst, die das Ganze noch tiefer in den Sumpf zogen.

Die Lehre ist klar: Bei der A2A-Zusammenarbeit über Rechner hinweg musst du zuerst die Verantwortungsgrenzen designen – wer koordiniert, wer arbeitet, wessen Erinnerungen gehören wem. Stapel nicht alles in die Eltern-Session; der Worker sollte sein eigenes „Notizbuch“ haben.

Checkliste zur Vermeidung von Fallstricken

Identitätskollaps hinter Reverse Proxy (#80534/#80779): Wenn du nginx, K8s Ingress oder ein CDN als Reverse Proxy nutzt, teilen sich alle Peers dasselbe Bearer-Token, und alle Identitäten kollabieren auf die Proxy-Adresse. Die Lösung: Der Proxy muss X-Forwarded-For durchreichen, damit die echte Identität hinter dem vertrauenswürdigen Proxy abgeleitet werden kann. Das ist wie wenn die Rezeption im Gebäude Pakete annimmt – auf dem Paket muss der echte Empfänger stehen, sonst stapelt sich alles an der Rezeption.

Routing-Verweigerung bei mehreren Konfigurationsprofilen (#80884/#80956): Wenn du mit multiplex_profiles mehrere Konfigurationen betreibst, kann es passieren, dass eingehende A2A-Nachrichten, die an ein sekundäres Profil geroutet werden, von der Gateway-Autorisierungsschicht abgelehnt werden. Der Fix: Beim Start den unveränderlichen Adapter-Sicherheitskontext erfassen und für jedes Profil die eigenen Authentifizierungs-, Vertrauens-, Bindungs- und Agent-Card-Richtlinien beibehalten. Jede Tür braucht ihre eigene Zugangsregel, nicht eine gemeinsame für alle.

Timeout-Einstellungen: Standardmäßig 330 Sekunden Client vs. 300 Sekunden Server – bei langen Aufgaben unbedingt anpassen. Sonst ist es wie bei einem Ferngespräch: Bevor du ausgeredet hast, wird die Leitung gekappt.

Bounded-Worker-Modus (#82503): Das ist das offizielle Rezept gegen Kontextaufblähung. Nicht-Root-Served-A2A-Routen können konfigurierte Subprozesse oder versionierte RPC-Worker ausführen, mit begrenztem Output, Prozessbaum-Reaping, Abbruch und Exactly-Once-Terminierung – der Worker macht seine Arbeit und ist fertig, ohne den ganzen Prozess in die Eltern-Session zu kippen.

Was bedeutet das für dich als Nutzer?

Eine A2A-Zwei-Rechner-Bereitstellung ist nicht einfach „zwei Computer verbinden“. Es ist wie eine Filiale zu eröffnen: Schaufenster (Agent Card), Zugangskontrolle (Token), Arbeitsteilung (wer koordiniert, wer arbeitet), Lager (eigene Erinnerungen) – alles muss durchdacht sein. Erfolgreiche Bereitstellungen lassen beide Maschinen ihre Stärken ausspielen, fehlgeschlagene lassen den Koordinator in Informationen ertrinken.

Merke dir drei Dinge: Erstens klare Verantwortungsgrenzen definieren, dann über technische Details nachdenken; Reverse Proxy muss das Identitätsproblem lösen; lange Aufgaben brauchen angepasste Timeouts, komplexe Aufgaben den Bounded-Worker-Modus. Wenn du das beachtest, werden die beiden Hermes-Instanzen auf zwei Computern wirklich gute Kollegen – und nicht Teamplayer, die sich gegenseitig in den Abgrund ziehen.