Blog

Die RockBot Band - Ein Multi-Agenten-KI-System

Rockford Lhotka

Rockford Lhotka

Aktualisiert April 9, 2026
8 Minuten


In den letzten Monaten habe ich eine Reihe von Open-Source-Projekten entwickelt, die jeweils ein bestimmtes Problem im Bereich der KI-Agenten lösen. Einzeln sind sie nützlich. Zusammen bilden sie die Grundlage für den Aufbau echter Agentensysteme, die in Produktionsumgebungen wie Kubernetes oder Azure laufen.

Ich möchte einen Schritt zurücktreten und darüber sprechen, wie diese Projekte zusammenpassen, denn das große Ganze ist wichtiger als jede einzelne Komponente.

Die Projekte

Hier ist die Aufstellung:

  • RockBot - Ein Framework für die Entwicklung von Agenten und Multi-Agenten-Systemen, das Cloud-nativ und verwaltbar sein soll. Stellen Sie es sich als Laufzeit und Architektur für Agenten vor, die über einen Nachrichtenbus mit vollständiger Isolierung und Trennung von Belangen kommunizieren.
  • mcp-aggregator - Ein Gateway, das zwischen Ihren Agenten (oder jedem LLM-Client) und all Ihren MCP-Servern sitzt. Agenten interagieren mit MCP-Servern, ohne große Mengen an Kontextspeicher zu verbrauchen und ohne Anmeldeinformationen oder Verbindungsdetails für jeden Server zu benötigen.
  • calendar-mcp - Ein MCP-Server, der Zugriff auf mehrere M365-, outlook.com- und Gmail-E-Mail- und -Kalenderkonten bietet. Nicht nur auf einen Kalender - auf alle. Ihr Arbeitskalender, Kundenkalender, persönliche und Familienkalender. Ein echtes Bild Ihres tatsächlichen Lebens.
  • agentregistry - Eine Agentenregistrierung für die dynamische Erkennung von A2A- und ACP-Agenten sowie MCP-Servern. Unterstützt sowohl persistente als auch ephemere Instanzen (z.B. Container mit KEDA-Skalierung) und die Kommunikation von Agent zu Agent über HTTP und Queued Messaging.
  • researchagent - Ein Agent, der auf dem RockBot-Framework aufbaut und für die Durchführung von Forschungsaufgaben konzipiert ist, deren Ergebnisse an den aufrufenden RockBot-Agenten zurückfließen.

Jede von ihnen adressiert eine Lücke, auf die ich beim Aufbau von Agentensystemen immer wieder gestoßen bin. Lassen Sie mich erklären, wie sie zusammenhängen.

Der Agent Runtime: RockBot

Alles beginnt mit RockBot. Es bietet die grundlegende Architektur: Agenten als isolierte Prozesse, die über einen Nachrichtenbus (in der Produktion RabbitMQ) kommunizieren. Kein gemeinsamer Speicher, kein LLM-generierter Code, der in Ihrem Host-Prozess läuft, keine Möglichkeit für einen kompromittierten Agenten, auf den Status eines anderen Agenten zuzugreifen.

Ich habe in Einführung in RockBot ausführlich über das Design von RockBot geschrieben, aber der wichtigste Punkt ist, dass RockBot von Grund auf für den Einsatz in Containern konzipiert wurde. Das Framework unterstützt sowohl zustandsbehaftete als auch zustandslose Agenten - der Zustand kann im Agentenprozess, in Nachrichten oder in externen Speichern gespeichert werden, je nach den Bedürfnissen des Agenten. Die Skalierung ist für zustandslose Worker horizontal und die Registry versteht den Unterschied. Dies ist wichtig, wenn Sie Agenten zusammenstellen - die Laufzeitumgebung muss die Cloud-native Bereitstellung unterstützen, nicht dagegen ankämpfen.

Ein persönlicher Agent: RockBot Agent

Das RockBot Framework ist die Grundlage, aber der RockBot Agent selbst ist ein konkretes Beispiel dafür, was Sie damit aufbauen können. Es ist ein persönlicher und professioneller Agent, der Ihnen hilft, Ihr Leben zu managen - Terminplanung, Recherche, Informationsbeschaffung, Aufgabenkoordination und mehr.

Im Gegensatz zu den zustandslosen Worker-Agenten, die sich starten, eine Aufgabe erledigen und wieder verschwinden, ist der RockBot-Agent von vornherein zustandsorientiert. Er verfügt über ein dauerhaftes Gedächtnis über Sie: Ihre Vorlieben, Ihre Projekte, Ihre Kontakte, Ihren Kommunikationsstil. Er merkt sich, worüber Sie letzte Woche gesprochen haben und baut darauf auf. Das ist für einen persönlichen Agenten unerlässlich - Sie wollen sich nicht bei jedem Gespräch neu vorstellen.

Der Agent verwendet Markdown-basierte Profildateien (Seele, Direktiven und Stil), um seine Identität und sein Verhalten zu definieren, und er verfügt über ein mehrschichtiges Speichersystem mit Kurzzeit-, Langzeit- und Arbeitsspeicher. Wenn er etwas tun muss, das über seine eigenen Fähigkeiten hinausgeht - ein Thema recherchieren, Ihren Kalender überprüfen, mit externen Systemen interagieren - delegiert er über den Nachrichtenbus und den mcp-aggregator an andere Agenten und Tools. Der RockBot-Agent ist der Knotenpunkt, der alles andere aus der Sicht des Benutzers zusammenhält.

Tool-Zugriff ohne den Bloat: mcp-aggregator

Agenten brauchen Werkzeuge. MCP (Model Context Protocol) ist der aufkommende Standard, um KI-Systemen Zugang zu externen Fähigkeiten zu geben. Aber wenn Sie einem Agenten naiverweise direkten Zugang zu einem Dutzend MCP-Servern gewähren, passieren zwei Dinge: Das Kontextfenster Ihres Agenten füllt sich mit Tool-Beschreibungen, die er vielleicht nie benutzen wird, und jeder Agent benötigt Anmeldedaten für jeden Server.

mcp-aggregator löst beide Probleme. Er fungiert als ein einziges Gateway, mit dem sich Ihr Agent verbindet. Der Aggregator kennt alle verfügbaren MCP-Server, liefert kurze Zusammenfassungen und lädt nur bei Bedarf die vollständigen Details des Tools. Die Berechtigungsnachweise befinden sich im Aggregator, nicht in jedem Agenten.

Ich habe dies in MCP Aggregator behandelt, aber der Teil, den ich hier hervorheben möchte, ist, wie dies in die Cloud-native Geschichte passt. In einer containerisierten Umgebung konfigurieren Sie den Aggregator einmal und jeder Agent im Cluster kann ihn nutzen. Fügen Sie einen neuen MCP-Server hinzu? Registrieren Sie ihn beim Aggregator und jeder Agent kann ihn sofort erkennen. Kein erneutes Deployment, keine Konfigurationsänderungen bei Dutzenden von Agenteninstanzen.

Eine echte Übersicht über Ihren Zeitplan: calendar-mcp

Die meisten Kalenderintegrationen bieten Ihnen Zugriff auf einen einzigen Kalender. Das ist in Ordnung, wenn Sie nur einen haben, aber die meisten Berufstätigen jonglieren mit mehreren Konten - beruflich (M365), privat (outlook.com oder Gmail), vielleicht einem gemeinsamen Familienkalender, Kundenkalendern und so weiter.

calendar-mcp ist ein MCP-Server, der alle diese Daten zusammenfasst. Wenn Ihr Agent etwas planen oder Ihre Verfügbarkeit prüfen muss, sieht er das komplette Bild. Nicht nur Ihren Arbeitskalender, sondern auch den Zahnarzttermin in Ihrem persönlichen Kalender und die Schulveranstaltung in Ihrem Familienkalender.

Dies ist die Art von Tool, die viel leistungsfähiger wird, wenn der Zugriff über den Aggregator erfolgt. Der Agent muss sich nicht um OAuth-Token für drei verschiedene E-Mail-Anbieter kümmern. Er fragt den Aggregator nach Kalender-Tools, der Aggregator leitet an calendar-mcp weiter, und calendar-mcp kümmert sich um die Komplexität mit mehreren Konten.

Suche nach Agenten und Servern: agentregistry

In einem statischen System können Sie fest programmieren, welche Agenten existieren und wo sie zu finden sind. In einer dynamischen Cloud-Umgebung fällt das schnell auseinander. Container drehen sich auf und ab. KEDA skaliert die Agenten auf Null, wenn sie inaktiv sind, und wieder hoch, wenn es Arbeit gibt. Neue Agenten werden eingesetzt. Alte Agenten werden ausgemustert.

agentregistry bietet eine dynamische Erkennung für das gesamte Ökosystem. Sie weiß Bescheid:

  • A2A-Agenten - Agenten, die über das Agent-to-Agent-Protokoll von Google kommunizieren
  • ACP-Agenten - Agenten, die das Agent Communication Protocol verwenden
  • MCP-Server - in der Umgebung verfügbare Toolserver
  • Persistente Instanzen - ständig laufende Dienste, einschließlich zustandsabhängiger Agenten wie dem RockBot-Agenten, die ein Langzeitgedächtnis haben
  • Ephemere Instanzen - zustandslose Container, die auf Null skalieren und bei Bedarf hochgefahren werden (über KEDA oder ähnliches)
  • Mehrere Transportwege - HTTP für synchrone Kommunikation, Queued Messaging (wie RabbitMQ) für asynchrone Agent-to-Agent-Arbeit

Dies ist der Klebstoff, der ein Multiagentensystem dynamisch und nicht statisch macht. Wenn RockBot eine Forschungsaufgabe delegieren muss, braucht es keine fest kodierte Adresse. Er fragt die Registrierung ab, findet einen verfügbaren Forschungsagenten und sendet die Aufgabe - unabhängig davon, ob dieser Agent bereits läuft oder erst hochgefahren werden muss.

Spezialisierte Agenten: researchagent

Der Researchagent ist ein konkretes Beispiel dafür, wie dies alles zusammenkommt. Er basiert auf dem RockBot-Framework und ist ein spezialisierter Agent, der Recherchen durchführt - Websuche, Dokumentenanalyse, Informationssynthese - und strukturierte Ergebnisse an den aufrufenden Agenten zurückgibt.

In der Praxis fragt ein Benutzer den RockBot-Agenten etwas, das eine Recherche erfordert. RockBot erkennt den Bedarf, fragt die Agentenregistrierung ab, um einen Forschungsagenten zu finden, delegiert die Aufgabe über den Nachrichtenbus und erhält die Ergebnisse zurück. Der Recherche-Agent verwendet mcp-aggregator, um auf alle benötigten Tools zuzugreifen - Websuche, Dokumentenspeicher, APIs - ohne eigene MCP-Serverkonfigurationen zu haben.

Wie alles zusammenpasst

Hier ist der Ablauf in einem realistischen Szenario:

  1. Ein Benutzer bittet seinen RockBot-Agenten, einen guten Termin für ein Treffen mit einem Kunden in der nächsten Woche zu finden und Hintergrundinformationen über die jüngsten Projekte des Kunden vorzubereiten.
  2. RockBot prüft die Verfügbarkeit, indem es die Kalender-Tools über mcp-aggregator aufruft, das an calendar-mcp weiterleitet. Calendar-mcp prüft den Arbeitskalender des Benutzers, den persönlichen Kalender und den gemeinsamen Kalender des Kunden.
  3. RockBot delegiert die Hintergrundrecherche an einen Forschungsagenten, der über die Agentenregistrierung gefunden wird. Die Registrierung weiß, dass ein Forschungsagent verfügbar ist (oder veranlasst, dass einer über KEDA gestartet wird).
  4. Der Researchagent verwendet mcp-aggregator, um auf Web-Suchwerkzeuge, die interne Wissensdatenbank des Unternehmens und das CRM zuzugreifen - und das alles, ohne direkte Zugangsdaten zu einem dieser Bereiche zu haben.
  5. Die Ergebnisse fließen über den Nachrichtenbus zurück. RockBot fasst die Verfügbarkeit des Kalenders und die Rechercheergebnisse zusammen und präsentiert dem Benutzer vorgeschlagene Besprechungszeiten und ein Briefing-Dokument.

Kein einzelnes Projekt kann all dies leisten. Aber zusammen bieten sie die komplette Infrastruktur: eine Agentenlaufzeit mit angemessener Isolierung, zentralem Zugriff auf Tools, Integration von realen Kalendern, dynamischer Agentenerkennung und spezialisierter Agentendelegation.

Warum das wichtig ist

Das KI-Agenten-Ökosystem ist noch jung, und die meisten Frameworks behandeln die Bereitstellung als nachträglichen Gedanken. Sie funktionieren hervorragend auf dem Laptop eines Entwicklers, haben aber keine Lösungen für mandantenfähige Umgebungen, dynamische Skalierung, Berechtigungsverwaltung oder die Koordination zwischen Agenten in der Produktion.

Das ist die Lücke, die ich zu schließen versuche. Nicht durch den Aufbau eines monolithischen Frameworks, das alles kann, sondern durch den Aufbau fokussierter Komponenten, die etablierten Prinzipien verteilter Systeme folgen und sich auf natürliche Weise zusammensetzen.

Diese Projekte sind alle Open Source und stehen unter der MIT-Lizenz:

Wenn Sie darüber nachdenken, Agentensysteme zu entwickeln, die in echten Produktionsumgebungen laufen müssen, würde ich mich freuen, wenn Sie einen Blick darauf werfen. Eröffnen Sie ein Problem, stellen Sie Fragen oder tragen Sie bei. Die Teile sind vorhanden - jetzt geht es darum, sie besser zu machen.

Verfasst von

Rockford Lhotka

Hello, I’m Rocky Lhotka, software architect, open source contributor, author, and speaker. I am VP of Strategy for Xebia-Microsoft Services USA and Chief Software Architect at Marimer LLC. Find me at; Mastodon: @rockylhotka@fosstodon.org GitHub: rockfordlhotka Link tree: Rockford Lhotka

Contact

Let’s discuss how we can support your journey.