ClawHosters
von Daniel Samer
6 Min. Lesezeit
Du willst einen Slack-Bot, der im Büro den Kundensupport abwickelt, und gleichzeitig einen Telegram-Assistenten für deine privaten Aufgaben. Zwei Agenten, zwei Personas, zwei komplett verschiedene Jobs. Wenn du so einen Multi Agent Workflow auf einem eigenen Server einrichten willst, bedeutet das: agentDir-Konfigurationen schreiben, Binding-Regeln von Hand anlegen und Tool-Berechtigungen in JSON-Dateien festlegen. Auf ClawHosters startest du einfach zwei Instanzen über das Dashboard. Fertig.
Aber vielleicht willst du beide Agenten wirklich auf einem Server betreiben. Oder du brauchst Agenten, die miteinander kommunizieren. Schauen wir uns an, wie OpenClaw das handhabt und welcher Ansatz wann sinnvoll ist.
Wie OpenClaw Multi-Agent tatsächlich funktioniert
Das Gateway ist der Kern jedes OpenClaw Multi Agent Setups. Ein einzelner Gateway-Prozess kann mehrere Agenten über die agents.list-Konfiguration betreiben. Jeder Agent bekommt sein eigenes Workspace-Verzeichnis, seinen eigenen Conversation-Speicher, seinen eigenen Auth-Kontext und seinen eigenen Session Store.
Bindings leiten eingehende Nachrichten an den richtigen Agenten weiter. Wenn du ein Slack-Binding auf Agent A und ein Telegram-Binding auf Agent B zeigst, landen Nachrichten von jeder Plattform automatisch beim richtigen Agenten. Die Routing-Logik folgt dem Prinzip "spezifischste Regel gewinnt". Ein Peer-Level-Binding (bestimmter Nutzer) schlägt ein Channel-Level-Binding, und das schlägt wiederum den Default.
Ein Fehler, über den viele stolpern: Verwende niemals das gleiche agentDir für zwei Agenten. Ich habe erlebt, wie das zu Session-Kollisionen geführt hat. Agent A antwortet plötzlich mit der Persönlichkeit von Agent B. Die Memory Stores überlappen sich, Auth-Tokens geraten durcheinander, und du debuggst stundenlang. Verzeichnisse immer getrennt halten.
Vier Patterns für mehrere Agenten
| Pattern | Funktionsweise | Ideal für | Nachteil |
|---|---|---|---|
| Bindings-basiert | Ein Gateway, mehrere Agenten, Routing über Bindings | Verschiedene Personas auf einem Server | Geteilte Ressourcen, Config-Komplexität |
| Sub-Agenten | Hauptagent startet Worker-Agenten während einer Konversation | Parallele Tasks innerhalb eines Workflows | Schwieriger zu debuggen, Token-Kosten steigen |
| Separate Instanzen | Jeder Agent bekommt einen eigenen VPS | Maximale Isolation, unabhängiges Skalieren | Höhere Kosten pro Agent |
| Lobster Pipeline | YAML-definierte Schrittfolgen mit JSON-Piping | Deterministische Abläufe wie Code-Reviews | Weniger flexibel bei spontanen Aufgaben |
Der Bindings-Ansatz ist wahrscheinlich das Richtige, wenn du zwei oder vier Agenten betreibst, die nicht miteinander interagieren müssen. Sub-Agenten sind nützlich für Dinge wie Code-Review-Pipelines, bei denen ein Agent Code schreibt und ein anderer ihn im selben Thread prüft. Separate Instanzen, also das, was ClawHosters bietet, geben dir Isolation auf Infrastruktur-Ebene statt nur auf Config-Ebene.
Lobster: Deterministische Pipelines, die wirklich funktionieren
Hier wird es interessant. Die Lobster Workflow Engine geht einen anderen Weg als klassische Agent-Orchestrierung. Statt ein LLM entscheiden zu lassen, welcher Agent als nächstes drankommt (was öfter schiefgeht, als man denkt), nutzt Lobster YAML-definierte Schrittfolgen.
Du definierst eine Pipeline. Schritt eins: Programmierer schreibt Code. Schritt zwei: Reviewer prüft. Schritt drei: Tester lässt Tests laufen. Jeder Schritt übergibt JSON-Daten an den nächsten. Wenn ein Schritt menschliche Freigabe braucht, pausiert Lobster mit einem resumeToken und wartet.
Ein Entwickler hat auf der DEV Community dokumentiert, wie er 12 gleichzeitige Agent-Sessions über vier Projekte hinweg mit diesem Pattern betrieben hat. Die zentrale Erkenntnis aus dem Beitrag: LLMs sind unzuverlässige Router. Sie halluzinieren Tool-Calls, überspringen Schritte und verlieren bei komplexer Verzweigungslogik den Faden. Deterministische Pipelines lassen den Code die Reihenfolge steuern, während LLMs das tun, was sie wirklich gut können: Text generieren und über Probleme nachdenken.
Token-Kosten lassen sich mit klugem Model-Routing um 70 bis 80 Prozent senken. Opus für den Orchestrator, der über Architektur nachdenken muss. Haiku oder Sonnet für Sub-Agenten, die einfachere Aufgaben wie Formatierung oder Checks erledigen. Der Community-Konsens liegt bei maximal 5 KB für Bootstrap-Dateien und einem globalen Budget von 200K Tokens pro Pipeline-Durchlauf.
Sicherheit: Der Teil, über den niemand gerne spricht
Mehrere OpenClaw-Agenten zu betreiben bedeutet, die Angriffsfläche zu vervielfachen. Jeder Agent braucht seine eigene Tool Allow/Deny List. Die Deny List gewinnt immer. Das ist die richtige Designentscheidung.
Microsofts Security-Team hat eine Analyse veröffentlicht, die das als "Dual Supply Chain Risk" bezeichnet. Dein Agent vertraut dem LLM-Provider, und das LLM vertraut den Tools, die du ihm gegeben hast. Wenn eine der beiden Verbindungen bricht, hast du ein Problem. Und ehrlich gesagt: GitHub Issue #10004 im OpenClaw-Repo listet fünf offene Isolation-Lücken, die noch nicht gepatcht sind. Lohnt sich, das vor einem sensitiven Deploy zu lesen.
Genau hier helfen separate VPS-Instanzen. Auf ClawHosters läuft jede Instanz auf einem eigenen Server mit eigenen Firewall-Regeln. Ein kompromittierter Agent kann nicht auf die Daten eines anderen Agenten zugreifen, weil es kein geteiltes Dateisystem gibt, keinen geteilten Prozessraum, nichts. Unser Security Hardening Guide beschreibt das vollständige Bild.
Das Dashboard übernimmt auch Auto-Updates, einschließlich Sicherheitspatches. Wer selbst hostet, muss diese Updates eigenständig einspielen. Bei OpenClaws mehr als 180.000 GitHub-Stars und dem Umfang an Community-Beiträgen sind das eine Menge Commits, die man verfolgen muss.
Wenn du Token-Kosten um 77 Prozent senken willst, während du Multi-Agent-Setups betreibst, ist Model-Routing vermutlich der größte Hebel. Details findest du in der Dokumentation, oder du testest deine Pipeline in einer kostenlosen Testversion, bevor du dich festlegst.
