OpenClaw Multi-Agent-Routing: Work, Privat und Experiment sauber trennen

Montag, 9 Uhr: Ich öffne den KI-Assistenten, um einem Kunden Code für eine Payment-API zu schreiben. Plötzlich sagt er: „Basierend auf Ihrer Elden-Ring-Boss-Strategie von gestern Abend schlage ich hier ebenfalls einen Roll-and-Slice-Ansatz vor …“

Ich war sprachlos.

Peinlicher: genau in einer Kundensitzung mit geteiltem Bildschirm. Die Stille auf der anderen Seite war spürbar.

Dann wurde klar: Der Assistent wird immer schlauer – aber Arbeit, Freizeit und Experimente liegen in einer Schublade ohne Trennwände. Alles vermischt – beim Suchen gräbt man sich durch, oft greift man ins Falsche.

Wenn Sie das kennen, hilft dieser Artikel. Ein Wochenende mit OpenClaw Multi-Agent-Routing: mehrere Assistenten – Arbeit getrennt, Privates privat, Experimente in der Sandbox.

Inhalt: warum nötig, wie konfigurieren, fünf Szenarien aus meiner Praxis.

Günstig „OpenClaw halten“: ArkClaw macht KI-Agents erschwinglich

OpenClaw („Hummer“) ist stark, Setup aber oft abschreckend. ByteDance Volcano Engine ArkClaw senkt die Hürde: ohne Server- und Token-Gefummel, ein Klick – 24/7 online, Browser, Skripte, Kalender.

Preis: ca. 9,9 ¥/Monat; mit Einladungscode ZLKUK54M (Registrierung) ca. 8,9 ¥. Entwickler: Coding Plan Pro kann kostenlos mitlaufen.

Warum KI-Assistenten „übergreifen“

Drei peinliche Momente mit einem Assistenten

Lange nutzte ich einen Assistenten für alles – bis Folgendes passierte:

Kontextvermischung
Sie optimieren eine Firmen-Datenbankabfrage, er erwähnt: „Wie bei Ihrem Python-Crawler-Skript letzte Woche – ähnliches Async …“ – das war ein Nebenprojekt, nichts für die Firma.

Datenschutz in der Demo
Sie zeigen einen Feature-Verlauf – in der Liste tauchen „Gehaltsverhandlung mit Chef“ und „Nebeneinkommen versteuern?“ auf. Wer das erlebt hat, versteht das Gefühl.

Experiment trifft Produktion
Batch-Umbenennung testen – er erinnert sich an ein Kundenprojekt-Verzeichnis und benennt Quellcode-Dateien um. Git rettete mich.

Ursache

Der Assistent ist nicht „schuld“ – er merkt sich alles und verknüpft Kontexte. Aber:

• Arbeit braucht Strenge und Datenschutz
• Privat braucht Lockerheit und persönliche Tipps
• Experimente brauchen Freiheit ohne Produktionsrisiko

Das gehört nicht in einen Topf.

Idee: Multi-Agent-Routing

OpenClaw gibt jedem Szenario ein eigenes „Zimmer“:

• Eigener Workspace: work-agent nur /work, personal-agent nur /personal – Dateisystem-Isolation
• Eigener Dialog: work-Agent weiß nichts von personal – und umgekehrt
• Eigene Rechte: Sandbox offline/read-only; Arbeit mit Firmen-Git; privat mit persönlicher Cloud

Technisch: Container-Isolation. Umgangssprachlich: mehrere unabhängige „Gehirne“.

2026 verlangen Enterprise-KI-Standards strikte Mandantentrennung. OpenClaws Docker-Sandbox geht weiter als reine „Chat-Gruppen“.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

OpenClaws Dreischicht-Isolation

Gateway, Brain, Skills verwirren zuerst – nach einmaligem Setup ist es klar.

Wie ein Paketdienst

• Gateway (Empfang): Telegram, Discord, Slack – Nachrichten kommen an, Routing zur richtigen Agent-ID
• Brain (Dispatch): Was soll passieren? Code, Recherche, Befehl – Aufgabenplan
• Skills (Ausführung): Arbeit im eigenen Docker-Container pro Agent

Drei Isolationsstufen

Session-Isolation (temporär)
Pro Dialog neuer Container, danach weg. Gut für „analysiere diese CSV“. Sauber, aber Umgebung jedes Mal neu.

Agent-Isolation (Dauerbetrieb)
Ein Container pro Agent, dauerhaft. work- und personal-agent bei mir so – mein Standard.

OS-Benutzer-Isolation (Maximum)
Verschiedene Systemnutzer pro Agent. Für Finanz/Medizin; für mich meist Overkill.

Test: In Agent A angelegte Dateien sind für Agent B ohne explizites Shared Volume nicht sichtbar. Beruhigend.

Fünf Szenarien aus der Praxis

Konkrete Setups zum Nachbauen.

Szenario 1: Arbeit vs. privat

Problem: Firmenprojekt und Blog-Code vermischt – fast Firmencode auf privatem GitHub.

Lösung:

• work-agent: D:\work, Firmen-GitLab-SSH, nur Arbeits-API-Keys
• personal-agent: D:\personal, privates GitHub

Details: separate .env, unterschiedliche WORKSPACE_PATH. Zwei Telegram-Bots: @my_work_bot und @my_personal_bot.

Szenario 2: Mehrere Kunden

Problem: Freelance, drei Kunden – Vorschläge für Kunde A im Stil von Kunde B.

Lösung: client-nike-agent, client-adidas-agent, client-puma-agent (fiktive Namen)

Details: eigene Verzeichnisse und Git-Repos; PROJECT_NAME in .env für Logs; API-Keys und DB-Configs strikt getrennt.

Szenario 3: Sicherheits-Sandbox

Problem: Batch-Skript testen ohne versehentliches Löschen.

Lösung: sandbox-agent mit harter Sandbox.

Details:

ENABLE_NETWORK=false  # offline
HOST_FILESYSTEM_MODE=readonly  # Host read-only
TEMP_STORAGE=true  # Änderungen temporär, Neustart = leer

Riskante Tests zuerst hier; Container neu = Host unberührt.

Szenario 4: Team vs. privat

Problem: Gemeinsamer Assistent, private Notizen für alle sichtbar.

Lösung:

• team-agent: Team-Repo/Docs auf NAS
• private-agent: lokale verschlüsselte Partition

Details: team in Gruppenchat, private nur per DM an mich.

Szenario 5: Multi-Modell-Vergleich

Problem: Claude, GPT-4, Llama vergleichen – ständiges Umschalten nervt.

Lösung: claude-agent, gpt-agent, llama-agent parallel

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

Details: je Agent anderer LLM_PROVIDER und API_KEY. Gleiche Frage an alle drei – Qualität, Speed, Kosten.

Beobachtung: Code → Claude stabil; Smalltalk → GPT-4 natürlich; sensible Daten → lokales Llama (langsamer, privat).

Tipps:

• Namen: Szenario-Zweck-Datum, z. B. client-nike-backend-20260201
• Wechsel: mehrere Telegram-Konten auf dem Handy
• RAM: seltene Agents per docker stop, bei Bedarf docker start

Erste work/personal-Agents einrichten

Voraussetzung: Docker und OpenClaw-Basis (sonst Quickstart-Doku).

Ziel: work + personal

Schritt 1: Config vorbereiten

cd openclaw
cp .env .env.work
cp .env .env.personal

Schritt 2: work-agent

.env.work anpassen:

AGENT_NAME=work-agent
WORKSPACE_PATH=/path/to/your/work/directory
TELEGRAM_BOT_TOKEN=your_work_bot_token
ALLOWED_USERS=your_telegram_user_id

Schritt 3: personal-agent

.env.personal:

AGENT_NAME=personal-agent
WORKSPACE_PATH=/path/to/your/personal/directory
TELEGRAM_BOT_TOKEN=your_personal_bot_token
CONTAINER_PORT=8001  # anderer Port

Schritt 4: Start

docker-compose --env-file .env.work up -d
docker-compose --env-file .env.personal up -d

Status: Running = ok.

Drei Isolationstests

Test 1 – Dateien
work: „Erstelle test.txt mit ‘work data’“. personal: „Liste Dateien“. → personal sieht test.txt nicht.

Test 2 – Dialog
work: „Projektcode ist ProjectX“. personal: „Mein Projektcode?“ → „Weiß ich nicht“.

Test 3 – Funktion
work: ENABLE_CODE_EXECUTION=true, personal: false → nur work führt Code aus.

Alle drei grün = Isolation aktiv.

Häufige Fehler:

• Port belegt → CONTAINER_PORT pro Agent unterschiedlich
• Bot antwortet nicht → Token und ALLOWED_USERS
• Dateirechte → WORKSPACE_PATH für Docker les-/schreibbar

Fortgeschritten: Performance und Sicherheit

Monate Nutzung – komprimierte Learnings.

Performance

Fünf Agents, Lüfter laut, ~8 GB RAM. Danach:

Limits in docker-compose.yml:

deploy:
  resources:
    limits:
      cpus: '0.5'
      memory: 512M

On-Demand:

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

# start-sandbox.sh
docker start sandbox-agent-container
# danach
docker stop sandbox-agent-container

Shared Image: ein OpenClaw-Basis-Image, unterschiedliche .env – ~1–2 GB für fünf Agents statt fünfmal voll.

Sicherheit

Least privilege: personal braucht kein /work → nicht mounten.

Secrets: nur Umgebungsvariablen, .gitignore für .env regelmäßig prüfen.

Audit:

docker logs work-agent-container --since 7d | grep ERROR

Troubleshooting

Start scheitert → docker logs <container>; oft Port oder Docker-Rechte.

Routing → Bot-Token, ALLOWED_USERS, Bot online testen.

Dateirechte → in docker-compose.yml: user: "${UID}:${GID}"

~90 % der Fälle stehen in den Logs.

Fazit

Warum: Ein Assistent vermischt Kontexte – Leaks und Effizienzverlust. Multi-Agent-Routing trennt physisch.

Wie: Mehrere Agents via .env, eigene Verzeichnisse, Bots, Rechte – work/personal in Minuten.

Praxis: Least privilege, on-demand stoppen, Logs prüfen.

Täglich im Einsatz: fokussierter bei der Arbeit, sicherere Experimente, ruhigere Demos.

Nächste Schritte:

1. Heute work/personal nach Tutorial
2. Fragen: OpenClaw GitHub Issues oder Discord
3. Artikel teilen, wenn „Übergreifen“ bekannt vorkommt

KI soll Ordnung schaffen, nicht Chaos. Multi-Agent-Routing ist Aufräumen – jeder Assistent seine Rolle.

Probieren Sie es – später danken Sie sich.