OpenClaw Tutorial Part 8: Multi-Agent-Setup & Sub-Agenten – Praxis-Guide zur Agenten-Orchestrierung

Die wahre Stärke von KI-Agenten entfaltet sich in der Zusammenarbeit. Während einzelne Agenten bereits mächtige Werkzeuge sind, löst erst ein Orchester aus spezialisierten KI-Assistenten komplexe Probleme, die für eine einzelne Instanz zu umfangreich wären.

In diesem achten Teil der OpenClaw-Serie geht es um Multi-Agent-Setups und Sub-Agenten für Automatisierungs-Workflows. Wir betrachten, wann kurzlebige Sub-Agenten sinnvoll sind, wie du sie kontrolliert einsetzt, wie du Kosten und Rate Limits im Griff behältst und worauf du bei dauerhaften Multi-Agent-Installationen achten musst.

Stand der Prüfung: 2026-05-08. Die offiziellen OpenClaw-Seiten zu Sub-agents und Multi-agent routing sind erreichbar. Früher genannte Einzelseiten zu sessions_spawn und sessions_yield liefern aktuell 404 und werden deshalb hier nicht mehr als stabile öffentliche Referenz verwendet.

Voraussetzungen

Bevor du Sub-Agenten produktiv verwendest, sollte deine OpenClaw-Installation grundsätzlich funktionieren:

openclaw models status
openclaw models list
openclaw config validate

Wichtig sind außerdem:

ein konfigurierter Standard-Agent oder ein klar ausgewählter Ziel-Agent,
ein funktionierender Modellanbieter,
bekannte Kosten- und Rate-Limit-Grenzen deines Providers,
ein sauberer Workspace ohne uncommitted Experimente, falls Agenten Dateien ändern dürfen.

Wenn du OpenClaw im Nix-Modus betreibst (OPENCLAW_NIX_MODE=1), sind schreibende openclaw config set-Operationen laut Dokumentation blockiert. Ändere dann die Nix-Quelle statt direkt openclaw.json.

Vorteile der Multi-Agent-Orchestrierung

OpenClaw unterstützt Multi-Agent-Szenarien über zwei unterschiedliche Muster:

Sub-Agenten: kurzlebige Worker für abgrenzbare Teilaufgaben.
Persistente Agenten: dauerhaft konfigurierte Agenten mit eigener Zuständigkeit, eigenem Kontext und typischerweise eigenen Kanal- oder Routing-Regeln.

Der praktische Nutzen liegt in drei Bereichen:

Parallelisierung: große Aufgaben lassen sich in kleine Sub-Tasks aufteilen und gleichzeitig bearbeiten.
Spezialisierung: einzelne Agenten können auf Recherche, Review, Zusammenfassung oder Dateiarbeit fokussiert werden.
Fehlertoleranz: ein fehlgeschlagener Worker muss nicht automatisch den kompletten Haupt-Workflow stoppen.

Grundlegende Muster in OpenClaw

Persistente Agenten sind langlaufende Einheiten. Sie eignen sich für wiederkehrende Rollen, zum Beispiel einen Support-Agenten für ein bestimmtes Team oder einen Recherche-Agenten für einen festen Kanal.

Sub-Agenten sind für begrenzte Aufgaben gedacht. Sie werden vom Haupt-Agenten oder aus einer laufenden Interaktion heraus gestartet, bearbeiten einen klaren Auftrag und liefern anschließend ein Ergebnis zurück.

Als Faustregel gilt:

Nutze persistente Agenten, wenn die Rolle dauerhaft existieren soll.
Nutze Sub-Agenten, wenn du eine konkrete Aufgabe parallel oder isoliert erledigen lassen willst.

Sub-Agenten kontrolliert starten

Der direkteste Einstieg ist der Sub-Agent-Befehl in der OpenClaw-Interaktion. Prüfe zuerst die tatsächlich verfügbare Syntax in deiner Installation, da Slash-Commands versionsabhängig erweitert werden können:

/subagents
/subagents help

Ein typischer Start sieht konzeptionell so aus:

/subagents spawn research-agent 'Recherchiere aktuelle Entwicklungen im Open-Source-Agenten-Ökosystem.'

Für den Anfang solltest du bewusst klein starten:

Starte genau einen Sub-Agenten.
Prüfe Status und Log.
Starte erst danach einen zweiten Worker.
Erhöhe Parallelität nur, wenn Rate Limits und Kosten kontrollierbar bleiben.

Beispiel für einen einfachen Testauftrag:

/subagents spawn helper 'Liste die wichtigsten offenen Punkte aus dem aktuellen Gespräch als kurze Checkliste auf.'

Danach prüfst du den Zustand:

/subagents list
/subagents log 1

Falls deine Version das Senden nachträglicher Hinweise unterstützt, kannst du einen laufenden Worker präzisieren:

/subagents send 1 'Fokussiere dich bitte auf Frameworks und ignoriere reine Chatbot-Produkte.'

Programmgesteuerte Orchestrierung: erst lokal prüfen, dann automatisieren

Ältere Beispiele nennen häufig Tool-Namen wie sessions_spawn oder sessions_yield. Die dafür früher verlinkten OpenClaw-Dokumentationsseiten sind aktuell nicht erreichbar. Deshalb sollte ein Tutorial diese Namen nicht mehr ungeprüft als stabile öffentliche API behandeln.

Wenn deine OpenClaw-Version solche Tools intern bereitstellt, prüfe vor der Automatisierung zwingend die lokale Tool-Beschreibung oder Help-Ausgabe. Entscheidend sind dabei:

Name des Tools,
erwartete Parameter,
Rückgabeformat,
Timeout-Verhalten,
Fehlerformat,
Abbruch- bzw. Cancel-Möglichkeit.

Für produktive Workflows gilt: Automatisiere erst, wenn du denselben Ablauf manuell mit /subagents reproduzieren kannst.

Ergebnisse zusammenführen

Ein gutes Multi-Agent-Setup braucht klare Rückgabeformate. Gib Sub-Agenten deshalb nicht nur eine Aufgabe, sondern auch ein erwartetes Ergebnisformat.

Schlechtes Prompting:

/subagents spawn research-agent 'Recherchiere Kubernetes-Agenten.'

Besser:

/subagents spawn research-agent 'Recherchiere Kubernetes-Agenten. Liefere maximal 8 Bulletpoints, jeweils mit Name, Zweck, Reifegrad und Risiko. Keine langen Erklärtexte.'

Der Haupt-Agent kann die Resultate anschließend vergleichen, deduplizieren und in ein finales Ergebnis überführen. Praktisch bewährt haben sich kurze, strukturierte Rückgaben statt langer Fließtexte.

Effizientes Kostenmanagement durch Modellauswahl

Jeder Sub-Agent verbraucht eigene Tokens. Parallelisierung beschleunigt Aufgaben, kann aber Kosten und Rate-Limit-Druck stark erhöhen.

OpenClaw verwendet Modell-Referenzen im Format provider/model. Prüfe verfügbare Modelle mit:

openclaw models status
openclaw models list

Das Setzen eines globalen Standardmodells erfolgt dokumentiert über:

openclaw models set provider/model

Setze das globale Modell aber nicht leichtfertig nur für einen Testlauf um. Für Sub-Agenten ist besser, sofern deine installierte /subagents-Syntax es unterstützt, pro Auftrag ein geeignetes Modell zu wählen.

Praktische Strategie:

günstigeres Modell für Vorarbeit, Extraktion und Zusammenfassung,
stärkeres Modell für finale Synthese, Architekturentscheidungen oder kritische Reviews,
harte Begrenzung der parallelen Worker,
kurze Ergebnisformate statt unkontrollierter Langantworten.

Persistente Multi-Agent-Setups konfigurieren

Dauerhafte Multi-Agent-Setups gehören in die OpenClaw-Konfiguration. Die Live-Dokumentation verweist auf openclaw.json und die openclaw config-Hilfsbefehle. Verwende deshalb nicht blind YAML-Beispiele aus älteren Artikeln, sondern prüfe das aktive Schema deiner Installation.

Nützliche Befehle:

openclaw config file
openclaw config schema
openclaw config get agents.list --json
openclaw config get agents.defaults.model --json
openclaw config validate

Die Dokumentation zeigt unter anderem Pfade wie agents.defaults.model, agents.defaults.models und agents.list[0]. Daraus folgt: Behandle persistente Agenten als strukturierte Konfiguration und validiere jede Änderung.

Sicherer Ablauf für Änderungen:

Aktive Config-Datei anzeigen:

openclaw config file

Schema ausgeben und passende Felder prüfen:

openclaw config schema

Bestehende Agentenliste lesen:

openclaw config get agents.list --json

Änderung in einer Kopie oder per Patch vorbereiten.
Trockenlauf bzw. Validierung ausführen:

openclaw config validate

Erst wenn die Validierung sauber ist, sollte der Agent produktiv an Kanäle oder Automationen gebunden werden.

Bewährte Orchestrierungs-Muster

Je nach Anwendungsfall haben sich drei Muster bewährt.

Fan-Out / Fan-In

Viele unabhängige Teilaufgaben werden parallel bearbeitet und anschließend zusammengeführt. Beispiel: zehn Dokumente werden von zehn Workern zusammengefasst; der Haupt-Agent erstellt daraus eine priorisierte Gesamtauswertung.

Achte dabei auf:

maximale Parallelität,
einheitliches Rückgabeformat,
Deduplizierung,
Quellen- oder Dateireferenzen pro Ergebnis.

Pipeline-Processing

Mehrere Agenten arbeiten nacheinander:

Recherche → Outline → Entwurf → Review → finale Fassung

Dieses Muster ist langsamer als reines Fan-Out, aber besser kontrollierbar. Es eignet sich besonders für Content-, Analyse- und Review-Prozesse.

Supervisor-Worker

Ein Haupt-Agent plant und überwacht mehrere Worker. Die Worker führen nur Teilaufgaben aus und treffen keine endgültigen Entscheidungen. Dieses Muster ist sinnvoll, wenn Qualitätssicherung wichtiger ist als maximale Geschwindigkeit.

Praxisbeispiel: Content-Pipeline

Eine robuste Content-Pipeline kann so aussehen:

Supervisor definiert Thema und Qualitätskriterien.
Zwei Research-Sub-Agenten recherchieren getrennte Perspektiven.
Ein Outline-Agent strukturiert die Ergebnisse.
Ein Writing-Agent erstellt einen Arbeitsentwurf.
Der Supervisor prüft Konsistenz, Quellenlage und Tonalität.

Beispielhafte Aufträge:

/subagents spawn research-agent 'Recherchiere technische Fakten zum Thema. Liefere 8 Bulletpoints mit Risiko-Hinweisen.'
/subagents spawn market-agent 'Recherchiere Zielgruppen- und Nutzenargumente. Liefere 8 Bulletpoints ohne Werbesprache.'

Danach sollte der Haupt-Agent die Ergebnisse nicht einfach zusammenkleben, sondern aktiv prüfen:

widersprechen sich Aussagen?
fehlen Quellen oder Annahmen?
sind Punkte doppelt?
ist ein Worker offensichtlich vom Auftrag abgewichen?

Typische Fehlerquellen und Monitoring

Häufige Probleme:

Zu viele parallele Sub-Agenten: führt zu Rate Limits und unkontrollierten Kosten.
Unklare Aufgaben: Worker liefern lange, schwer vergleichbare Antworten.
Kein Fehlerpfad: ein einzelner fehlgeschlagener Worker blockiert den Ablauf.
Unkontrollierte Dateizugriffe: mehrere Agenten schreiben in dieselben Dateien.
Zu starke Modelle für triviale Aufgaben: unnötig teuer.

Gegenmaßnahmen:

mit 1 bis 2 Sub-Agenten starten,
maximale Parallelität festlegen,
kurze strukturierte Rückgabeformate verlangen,
bei Dateiarbeit getrennte Pfade verwenden,
Logs direkt nach jedem Testlauf prüfen,
Konfigurationsänderungen immer mit openclaw config validate absichern.

Monitoring in der Interaktion:

/subagents list
/subagents log 1

Wenn deine Version Follow- oder Detailoptionen anbietet, nutze sie erst nach Blick in /subagents help, statt alte Syntax aus Blogposts zu übernehmen.

Sicherheit und Isolation

Multi-Agent-Setups erhöhen die Angriffs- und Fehlerfläche. Jeder zusätzliche Worker kann Werkzeuge ausführen, Dateien lesen oder Tokens verbrauchen, sofern seine Umgebung das erlaubt.

Praktische Sicherheitsregeln:

keine Secrets in Sub-Agent-Prompts kopieren,
Dateischreibrechte minimieren,
gefährliche Tools nur gezielt freigeben,
für Experimente separate Workspaces verwenden,
Logs nicht ungeprüft veröffentlichen,
Ergebnisse von Sub-Agenten wie untrusted Input behandeln.

Besonders wichtig: Ein Sub-Agent-Ergebnis ist kein Beweis. Der Haupt-Agent oder ein menschlicher Reviewer muss kritische Aussagen prüfen.

Einstieg in die Praxis

Starte mit einem ungefährlichen Test:

/subagents spawn helper 'Fasse diese Unterhaltung in fünf Bulletpoints zusammen und liste offene Entscheidungen separat.'

Prüfe danach:

/subagents list
/subagents log 1

Wenn das sauber funktioniert, teste einen zweiten Worker mit einer klar getrennten Aufgabe. Erst danach lohnt sich eine echte Pipeline.

Ein guter produktiver Anwendungsfall zum Einstieg ist ein Proofreading-Agent: Während du am Haupttext arbeitest, prüft ein Sub-Agent Rechtschreibung, Verständlichkeit und fehlende Übergänge. Der Nutzen der Parallelisierung wird sofort sichtbar, ohne dass du riskante Dateizugriffe oder komplexe Agentenketten brauchst.

Weiterlesen

Die Grundlagen zu Automationen stehen in Cron-Jobs, Heartbeats und Automationen.
Für spätere Praxis-Setups ergänzt Remote Nodes den Blick auf verteilte Agenten-Umgebungen.

Was daraus folgt

Sub-Agenten sind in OpenClaw ein praktisches Werkzeug für parallele, klar abgegrenzte Aufgaben. Der Schlüssel liegt nicht darin, möglichst viele Worker zu starten, sondern Aufgaben sauber zu schneiden, Rückgaben zu standardisieren und Kosten zu begrenzen.

Für dauerhafte Multi-Agent-Setups solltest du dich strikt an das aktuelle openclaw.json-Schema halten und jede Änderung validieren. Für programmgesteuerte Orchestrierung gilt: Erst die lokal verfügbare Tool-Schnittstelle prüfen, dann automatisieren. So bleibt dein Agenten-Orchester nachvollziehbar, bezahlbar und wartbar.