Zum Inhalt springen

Multi-Agent Routing: So verwaltest du mehrere isolierte Agenten

Du kennst das Problem: Du baust einen Agenten für deine Arbeit und einen für private Projekte. Plötzlich vermischen sich die Kontexte, der Agent nutzt die falschen API-Keys oder erinnert sich an Chats, die eigentlich in den anderen Bereich gehören. Es ist anstrengend, ständig manuell zwischen Instanzen zu wechseln oder Angst vor Datenlecks zwischen verschiedenen Projekten zu haben.

Wenn du mehrere Aufgaben gleichzeitig automatisierst, brauchst du eine klare Trennung. Ein einziger Gateway sollte in der Lage sein, verschiedene “Gehirne” zu steuern, ohne dass diese sich gegenseitig in die Quere kommen.

  • OpenClaw Gateway Instanz
  • Eine openclaw.json Konfigurationsdatei
  • Mindestens einen aktiven Channel (z. B. WhatsApp oder Telegram)
  • Zugriff auf das CLI Tool openclaw

Standardmäßig läuft OpenClaw im Single-Agent-Mode mit der ID main. Um einen neuen, isolierten Agenten hinzuzufügen, nutzt du den Agent Wizard. Das ist der schnellste Weg, um die Verzeichnisse und Bindings korrekt zu erstellen.

  1. Erstelle einen neuen Agenten:
    Terminal-Fenster
    openclaw agents add work
  2. Folge den Anweisungen im Wizard, um die Bindings für deine Nachrichten zu definieren.
  3. Überprüfe dein Setup:
    Terminal-Fenster
    openclaw agents list --bindings

Ein Agent in OpenClaw ist ein vollständig abgegrenztes System. Jeder Agent besitzt eigene Ressourcen, damit keine Konflikte entstehen:

  • Workspace: Ein eigener Ordner für Dateien, AGENTS.md, SOUL.md und lokale Notizen.
  • State Directory (agentDir): Hier liegen Auth-Profile, die Model Registry und die agentenspezifische Konfiguration.
  • Session Store: Der Chat-Verlauf wird unter ~/.openclaw/agents/<agentId>/sessions gespeichert.
  • Auth Profiles: Zugangsdaten werden pro Agent verwaltet und liegen in auth-profiles.json.

Wichtig: Nutze niemals dasselbe agentDir für verschiedene Agenten. Das führt zu Kollisionen bei der Authentifizierung und den Sessions. Wenn du Credentials teilen willst, kopiere die auth-profiles.json manuell in das agentDir des anderen Agenten.

Die Weiterleitung (Routing) erfolgt über bindings. Diese Regeln sind deterministisch – die spezifischste Regel gewinnt immer. Die Reihenfolge der Prüfung sieht so aus:

  1. peer match (exakte ID für DM, Gruppe oder Channel)
  2. guildId (für Discord)
  3. teamId (für Slack)
  4. accountId match für einen spezifischen Account innerhalb eines Channels
  5. Channel-Level match (z. B. alle Nachrichten eines Channels)
  6. Fallback auf den Default-Agenten

In diesem Szenario routest du zwei verschiedene Telefonnummern auf zwei unterschiedliche Agenten-Persönlichkeiten.

{
agents: {
list: [
{
id: "home",
default: true,
name: "Home",
workspace: "~/.openclaw/workspace-home",
agentDir: "~/.openclaw/agents/home/agent",
},
{
id: "work",
name: "Work",
workspace: "~/.openclaw/workspace-work",
agentDir: "~/.openclaw/agents/work/agent",
},
],
},
bindings: [
{ agentId: "home", match: { channel: "whatsapp", accountId: "personal" } },
{ agentId: "work", match: { channel: "whatsapp", accountId: "biz" } },
],
channels: {
whatsapp: {
accounts: {
personal: {},
biz: {},
},
},
},
}

Beispiel: Ein Kanal, verschiedene Agenten je nach Kontakt

Abschnitt betitelt „Beispiel: Ein Kanal, verschiedene Agenten je nach Kontakt“

Du kannst auch innerhalb eines einzigen WhatsApp-Accounts entscheiden, wer antwortet. Private DMs gehen an den Standard-Agenten, aber eine spezifische Nummer wird an einen Experten-Agenten (z. B. mit Claude Opus) geleitet.

{
agents: {
list: [
{
id: "chat",
name: "Everyday",
workspace: "~/.openclaw/workspace-chat",
model: "anthropic/claude-sonnet-4-5",
},
{
id: "opus",
name: "Deep Work",
workspace: "~/.openclaw/workspace-opus",
model: "anthropic/claude-opus-4-6",
},
],
},
bindings: [
{
agentId: "opus",
match: { channel: "whatsapp", peer: { kind: "direct", id: "+15551234567" } },
},
{ agentId: "chat", match: { channel: "whatsapp" } },
],
}

Seit Version v2026.1.6 kannst du für jeden Agenten einzeln festlegen, welche Tools er nutzen darf und ob er in einer Sandbox laufen soll. Das bietet dir folgende Vorteile:

  1. Security Isolation: Schränke Tools für weniger vertrauenswürdige Agenten ein.
  2. Resource Control: Nutze Container nur für bestimmte Agenten.
  3. Flexible Policies: Unterschiedliche Berechtigungen je nach Einsatzzweck.
  4. Daten-Sicherheit: Verhindere Schreibzugriffe in sensiblen Workspaces.

Hier ein Beispiel für eine strikte Familien-Bot-Konfiguration:

{
id: "family",
workspace: "~/.openclaw/workspace-family",
sandbox: {
mode: "all",
scope: "agent",
docker: {
setupCommand: "apt-get update && apt-get install -y git curl",
},
},
tools: {
allow: ["read"],
deny: ["exec", "write", "edit", "apply_patch"],
},
}

Problem: Authentifizierungs-Fehler oder Session-Mix-up. Dies passiert meistens, wenn mehrere Agenten auf dasselbe Verzeichnis zugreifen.

  • Lösung: Prüfe deine openclaw.json. Jeder Agent in agents.list muss ein eindeutiges agentDir und einen eigenen workspace haben. Kopiere niemals den gesamten Ordnerinhalt während der Laufzeit von einem Agenten zum anderen.

Problem: Nachrichten kommen beim falschen Agenten an. Die Routing-Regeln werden von oben nach unten geprüft, wobei spezifische IDs Vorrang haben.

  • Lösung: Stelle sicher, dass peer-spezifische Bindings in der Liste oberhalb von allgemeinen Channel-Bindings stehen.

AI Setup Assistant

OpenClaw

OpenClaw Expert

Noch festgefahren?

Wenn diese Seite nicht hilft, frage OpenClaw Expert nach Schritt-fuer-Schritt-Loesungen.