Einführung von RockBot: Ein Cloud-natives KI-Agenten-Framework

Ich habe an einem neuen Projekt namens RockBot gearbeitet, einem Framework zum Aufbau von Agenten- und Multi-Agenten-KI-Systemen, bei denen Agenten und Benutzer-Proxys ausschließlich über einen Nachrichtenbus in einer Cloud-nativen Architektur kommunizieren.

Ich möchte darüber sprechen, warum ich es gebaut habe, welche Probleme es löst und wie es funktioniert.

Hier nicht geschrieben-Syndrom

OpenClaw hat die Welt im Sturm erobert, als es auf den Markt kam, und es ist wirklich erstaunlich. Ich fand es sehr inspirierend, aber all die (angeblichen) Sicherheitsprobleme haben mich zögern lassen, es wirklich zu benutzen, geschweige denn, mich damit zu beschäftigen.

nanobot wurde von OpenClaw inspiriert und scheint sich mehr auf Sicherheit und Isolierung zu konzentrieren. Ich habe eine Instanz von nanobot eingerichtet und betreibe sie seit einiger Zeit, aber sie funktioniert bei mir nicht. Viele aufgehängte Konversationen.

Da nanobot weniger als 4000 Zeilen Code umfasst, dachte ich mir: "Wie schwer kann es sein, so etwas selbst zu entwickeln?" Ich habe umfangreiche Erfahrung im Aufbau verteilter Systeme und dachte, ich könnte dieses Wissen nutzen, um ein robusteres und sichereres Agenten-Framework zu entwickeln.

Das Problem der meisten KI-Agenten-Frameworks

Die meisten KI-Agenten-Frameworks führen heute LLM-generierten Code im selben Prozess wie die Host-Anwendung aus. Das klingt praktisch, führt aber zu ernsthaften Problemen:

Als ich anfing, über die Entwicklung autonomer Agenten nachzudenken, fühlten sich diese Probleme grundlegend an. Keine Macken, die es zu umgehen gilt, sondern architektonische Fehler, die auf der Entwurfsebene gelöst werden müssen.

Vielleicht liegt es daran, dass ich meine Karriere im Bereich der Unternehmenssoftware aufgebaut habe und mich dabei speziell auf verteilte Systeme konzentriert habe. Ich möchte etwas, das zwar nicht perfekt ist, aber zumindest den architektonischen Prinzipien folgt, die sich bei groß angelegter, produktionsfähiger Software bewährt haben. Das bedeutet Trennung von Belangen, Isolierung der Ausführung, geringste Privilegien und Cloud-natives Design.

Die Nachrichtenbus-Architektur

RockBot basiert auf einer zentralen Idee: Agenten kommunizieren ausschließlich über einen Nachrichtenbus. Es gibt keinen gemeinsam genutzten Speicher, keine direkten Methodenaufrufe zwischen Agenten und keinen LLM-generierten Code, der prozessintern mit dem Host läuft.

Jeder Agent ist ein isolierter Prozess, der:

Der Nachrichtenbus wird in der Produktion von RabbitMQ unterstützt, das jedoch bei Bedarf gegen andere Implementierungen ausgetauscht werden kann. Es ist einfach genug, eine RabbitMQ-Instanz in Docker Desktop für die lokale Entwicklung zu betreiben.

Das ist keine neue Idee. Ereignisgesteuerte Architekturen gibt es schon seit Jahrzehnten. Neu ist die konsequente Anwendung auf KI-Agentensysteme, bei denen die Isolationseigenschaften noch wichtiger sind als bei herkömmlicher Software.

Vier Design-Ziele

RockBot ist auf vier grundlegende Ziele ausgerichtet:

Trennung der Anliegen: Jede Verantwortung hat einen klaren Eigentümer und klar definierte Grenzen. Agenten sind für die Argumentation zuständig. Der Nachrichtenbus übernimmt die Weiterleitung. Werkzeugbrücken übernehmen die Ausführung. LLM-Anbieter übernehmen die Inferenz. Keine dieser Schichten greift in die Domäne der anderen ein - sie kommunizieren nur über typisierte Nachrichten. Dadurch ist jede Schicht unabhängig testbar, austauschbar und verständlich.

Isolierung der Ausführung: LLM-generierter Code wird nie im selben Prozess wie der Host ausgeführt. Agenten werden in separaten Prozessen ohne gemeinsamen Speicher ausgeführt. Skripte werden in ephemeren Kubernetes-Containern ausgeführt, die nach Gebrauch verworfen werden. Ein kompromittierter oder entlaufener Agent kann nicht auf den Host zugreifen, seine Geheimnisse lesen oder andere Agenten beeinflussen. Ausfälle sind von vornherein ausgeschlossen.

Das Prinzip der geringsten Privilegien: Jede Komponente weiß nur das, was sie für ihre Arbeit benötigt. Agenten empfangen nur die an sie gerichteten Nachrichten. Tool-Bridges stellen nur die Tools zur Verfügung, für die sie explizit konfiguriert sind. Skripte werden in Containern ausgeführt, die keinen Netzwerkzugriff, keine dauerhafte Speicherung und keine Anmeldedaten haben. Keine Komponente sammelt Fähigkeiten an, die über ihre unmittelbare Aufgabe hinausgehen.

Von vornherein Cloud-nativ: Außerhalb des Kernagenten selbst sind die Worker zustandslos - der Status befindet sich in Nachrichten oder externen Speichern, niemals im Prozessspeicher. Die Komponenten skalieren unabhängig voneinander. Der Nachrichtenbus bietet Gegendruck, Warteschlangen für tote Buchstaben und Haltbarkeit, so dass das System auch unter Last stabil bleibt. Die Konfiguration kommt aus der Umgebung, die Geheimnisse aus Kubernetes Secrets und die Beobachtbarkeit durch OpenTelemetry.

Kernkomponenten

Das Framework besteht aus verschiedenen Paketen. Hier sind einige der wichtigsten:

RockBot.Messaging.Abstraktionen: Transport-agnostische Verträge (IMessagePublisher, IMessageSubscriber, MessageEnvelope)
RockBot.Messaging.RabbitMQ: RabbitMQ-Anbieter mit Topic-Exchanges und Dead-Letter-Queues
RockBot.Messaging.InProcess: In-Memory-Bus für lokale Entwicklung und Tests
RockBot.Host: Agent-Host-Laufzeit - empfängt Nachrichten und sendet sie durch die Handler-Pipeline
RockBot.Llm LLM Integration über Microsoft.Extensions.AI
RockBot.Tools / RockBot.Tools.Mcp: Werkzeugaufruf - REST und MCP (Model Context Protocol)
RockBot.Scripts.Container: Ephemere Skriptausführung in isolierten Kubernetes-Containern
RockBot.A2A: Agent-zu-Agent-Aufgabendelegation über den Nachrichtenbus
RockBot.Cli: Einheitliche Host-Anwendung - führt Agenten als gehostete Dienste aus

Die Abstraktionsschicht ist absichtlich dünn. Wenn Sie RabbitMQ gegen einen anderen Message Broker austauschen möchten, implementieren Sie einen neuen Anbieter für dieselben Verträge und nichts anderes ändert sich.

Agent-Profile

Was mir an diesem Design besonders gefällt, ist die Art und Weise, wie die Agenten konfiguriert werden. Jeder Agent erhält drei Markdown-Dateien:

Diese Dateien sind für Menschen lesbar, versionskontrolliert und werden zur Laufzeit in die Systemsteuerung des Agenten eingefügt. Das bedeutet, dass Sie das Verhalten eines Agenten anpassen können, ohne den Code zu berühren, indem Sie einfach seine Profildateien bearbeiten. Das bedeutet auch, dass Ihre Agentenkonfiguration zusammen mit Ihrem Code in der Versionskontrolle liegt und vom gesamten Team überprüft und kontrolliert werden kann.

Brücken zur Welt

RockBot unterstützt das Model Context Protocol (MCP) zur Integration von Tools. Legen Sie eine mcp.json-Datei neben RockBot.Cli, und die MCP-Bridge wird automatisch verfügbare Tools erkennen und registrieren. Das bedeutet, dass Sie jeden MCP-kompatiblen Toolserver einbinden können, ohne Glue-Code schreiben zu müssen.

Dies ist besonders nützlich, weil das MCP-Ökosystem schnell wächst. Wenn ein Tool über einen MCP-Server verfügt, kann RockBot ihn nutzen.

Die MCP-Bridge schützt den Agenten davor, Details über alle MCP-Server, die möglicherweise registriert sind, kennen zu müssen. Sie verwaltet und stellt eine Liste der verfügbaren MCP-Server zur Verfügung und liefert die Details zu den Tools nur bei Bedarf. Auf diese Weise wird das Kontextfenster des Agenten nicht mit Informationen über Tools überfrachtet, die er möglicherweise nie verwendet, während er sie bei Bedarf dennoch zur Verfügung hat.

RockBot unterstützt auch die Suche und das Browsen im Internet und ermöglicht es dem Agenten, nach Webinhalten zu suchen und diese zu lesen. Normalerweise werden diese Inhalte in den durchsuchbaren Arbeitsspeicher zurückgezogen, so dass der Agent darüber nachdenken kann, ohne wiederholt auf das Internet zuzugreifen.

Und es gibt Unterstützung für die Ausführung beliebiger Python-Skripte in isolierten Containern. Dadurch können Agenten komplexe Berechnungen, Datenverarbeitung oder Interaktionen mit externen Systemen durchführen, ohne die Sicherheit des Hosts zu gefährden.

Speicher und Staat

Der Agent selbst verfügt auf mehreren Ebenen über einen persistenten Speicher:

Fertigkeiten

Der Agent kann seine eigenen Skills verwalten: Markdown-Dateien mit Anweisungen, wie der Agent das tun kann, was er tun muss. Ich habe festgestellt, dass es oft sehr vorteilhaft ist, für jeden MCP-Server oder jeden Arbeitsablauf, den der Agent ausführen muss, einen Skill zu haben. Auf diese Weise kann der Agent im Laufe der Zeit lernen, wie man die Tools verwendet, und er hat einen klaren Ort, an dem er die Anweisungen nachschlagen kann, wie etwas zu tun ist.

Benutzer-Interaktion

Derzeit gibt es zwei Proxys: ein CLI-Tool zum Testen und eine Blazor-Web-UI für die tatsächliche Nutzung.

Das Konzept des Benutzer-Proxys ist erweiterbar, so dass es durchaus möglich ist, alle möglichen anderen Benutzeroberflächen zu erstellen.

Ein Benutzer-Proxy kommuniziert mit dem Agenten über RabbitMQ-Nachrichten, genau wie jeder andere Agent oder jede andere Komponente. Das bedeutet, dass die Benutzeroberfläche vollständig von den Überlegungen des Agenten und der Ausführung des Tools entkoppelt ist. Die Benutzeroberfläche kann ausgetauscht, unabhängig skaliert und sogar auf einem anderen Rechner oder in einer anderen Umgebung ausgeführt werden, ohne dass die Kernlogik des Agenten beeinträchtigt wird.

Was kommt als Nächstes?

Das Projekt befindet sich noch im Anfangsstadium. Die Kernarchitektur ist vorhanden, die RabbitMQ- und prozessinternen Transporte funktionieren, die LLM-Integration erfolgt über Microsoft.Extensions.AI und die Blazor Server-Benutzeroberfläche ist funktionsfähig. Es gibt noch viel mehr zu bauen, und das Design ist absichtlich erweiterbar.

Wenn Sie sich für Multi-Agenten-KI-Systeme interessieren und Wert auf Sicherheit, Isolierung und Cloud-native Bereitstellung legen, würde ich mich freuen, wenn Sie einen Blick darauf werfen. Das Repository finden Sie unter https://github.com/MarimerLLC/rockbot. Beiträge sind willkommen - eröffnen Sie einfach ein Thema, bevor Sie mit der Arbeit beginnen, damit wir den Ansatz diskutieren können.

Der Bereich der KI-Agenten entwickelt sich schnell. Mein Ziel mit RockBot ist es, etwas zu schaffen, das es ermöglicht, seriöse, produktionsreife Agentensysteme zu entwickeln, ohne die Sicherheit und die architektonischen Prinzipien zu opfern, die Software im Laufe der Zeit nachhaltig machen.

Lesen Sie den nächsten Beitrag aus der Serie: Wie RockBot sich erinnert: Der Einbau einer Speicherarchitektur in einen KI-Agenten →.