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 im Folgenden, wie Sub-Agenten gestartet und gesteuert werden, wie die Kommunikation zwischen ihnen abläuft und welche Modelle sich für ein effizientes Kostenmanagement eignen. Zudem werfen wir einen Blick auf dauerhafte Installationen und bewährte Orchestrierungs-Muster aus der Praxis.

Praxisbeispiel: Sub-Agenten eignen sich ideal für parallele Aufgaben – etwa die gleichzeitige Recherche, Zusammenfassung und Erstellung einer Checkliste –, ohne dass der Haupt-Agent den Kontext verliert.

Vorteile der Multi-Agent-Orchestrierung

OpenClaw bietet zwei robuste Wege für diese Setups: Sub-Agenten für parallele Tasks und persistente Multi-Agent-Installationen. Der konkrete Nutzen liegt in drei Bereichen:

• Parallelisierung: Große Aufgaben lassen sich in kleine Sub-Tasks aufteilen und gleichzeitig ausführen.
• Spezialisierung: Jeder Agent wird auf ein spezifisches Modell oder Skill-Set optimiert.
• Fehlertoleranz: Scheitert ein Sub-Agent, arbeiten die restlichen Instanzen ungestört weiter.

Grundlegende Muster in OpenClaw

OpenClaw unterscheidet zwischen zwei Mustern für unterschiedliche Einsatzzwecke:

Persistente Agenten sind langlaufende Instanzen, die meist an einen bestimmten Kanal gebunden sind – beispielsweise ein Support-Agent für ein Team.

Sub-Agenten arbeiten als kurzlebige Hintergrund-Prozesse für spezifische Aufgaben und werden nach Abschluss automatisch archiviert.

Für eine dauerhafte Präsenz eignen sich persistente Agenten, für parallele Task-Verarbeitung greift man zu Sub-Agenten.

Sub-Agenten starten und steuern

Der direkteste Weg, einen Sub-Agenten zu initiieren, ist der Slash-Command /subagents. Laut OpenClaw-Dokumentation empfiehlt es sich, zunächst mit ein bis zwei Sub-Agenten zu starten, um Rate Limits zu vermeiden und das Debugging übersichtlich zu halten.

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

Dabei lassen sich auch spezifische Modelle und das gewünschte Thinking-Level definieren:

/subagents spawn research-agent "Analysiere GitHub-Trends" --model ds-v3-nx --thinking medium

Programmgesteuerte Orchestrierung mit sessions_spawn

Für den Start aus einem Workflow heraus ist sessions_spawn der Standard. Die wichtigsten Parameter umfassen den klaren Auftrag (task), einen lesbaren Namen für das Debugging (label), die Laufzeitumgebung (runtime, standardmäßig subagent) sowie das Modell und ein Timeout-Limit, um Endlosschleifen zu verhindern.

In Agenten-Skripten sieht die Einbindung des Tools wie folgt aus:

const subagent = await sessions_spawn({
  runtime: "subagent",
  agentId: "research-agent",
  task: "Finde 5 aktuelle Papers zu Multi-Agent-Coordination",
  model: "ds-v3-nx",
  label: "paper-research-001"
});

Ergebnisse verarbeiten mit sessions_yield

Nach dem Start mehrerer Sub-Agenten dient sessions_yield als Sammelpunkt. Der aktuelle Turn wird beendet und das System wartet, bis die Sub-Agenten ihre Resultate zurückmelden. Bei Bedarf lassen sich die Agenten in der Zwischenzeit über weitere Commands steuern, um Status und Logs zu prüfen oder Anweisungen zu präzisieren:

# Status prüfen
/subagents list

# Logs anzeigen  
/subagents log 2 [10] [tools]

# Nachricht senden
/subagents send 3 "Fokussiere dich auf KI-Agenten-Frameworks, nicht auf Chatbots."

Effizientes Kostenmanagement durch Modellauswahl

Da jeder Sub-Agent eigene Tokens verbraucht, ist eine gezielte Modellauswahl essenziell. Für rechenintensive Vorarbeiten wie Datenverarbeitung, Strukturierung oder Zusammenfassungen eignen sich günstigere Modelle (wie ds-v3-nx oder glm-nx). Der Haupt-Agent, der den finalen Schliff übernimmt, kann auf einem leistungsfähigeren Modell laufen.

# Günstiges Modell für Datenverarbeitung
/subagents spawn data-processor "Parse 100 JSON-Files" --model openrouter-nexus/qwen/qwen2.5-32b-instruct

# Leistungsstarkes Modell für komplexe Aufgaben  
/subagents spawn writer-agent "Schreibe Marketing-Text" --model openrouter-nexus/anthropic/claude-3-7-sonnet

Persistente Multi-Agent-Setups konfigurieren

Für dauerhafte Installationen werden persistente Agenten direkt in der OpenClaw-Konfiguration definiert. Jeder Agent erhält dabei einen vollständig isolierten Workspace mit eigenen Dateien und separatem Memory. Das verhindert Konflikte beim Dateizugriff und erhöht die Sicherheit.

agents:
  nexus:
    workspace: "./workspaces/nexus"
    soul: "nexus.md"
    channels:
      - "telegram:nexus"
  
  research-bot:
    workspace: "./workspaces/research"
    model: "ds-v3-nx"
    channels:
      - "discord:research-channel"

Bewährte Orchestrierungs-Muster

Je nach Anwendungsfall haben sich laut Praxisberichten verschiedene Muster etabliert:

• Fan-Out / Fan-In: Viele unabhängige Tasks werden parallel verarbeitet (z. B. die gleichzeitige Analyse von dutzenden Dokumenten durch eigene Sub-Agenten).
• Pipeline-Processing: Eine sequenzielle Verarbeitung durch spezialisierte Agenten (Recherche → Outline → Entwurf → Korrektur).
• Supervisor-Worker: Ein Haupt-Agent überwacht und steuert mehrere Worker-Agenten, die spezifische Teilaufgaben übernehmen.

Praxisbeispiel: Content-Pipeline

Eine typische Content-Erstellung nutzt oft ein Multi-Level-System. Ein Supervisor-Agent delegiert Themen an parallele Research-Agenten. Die Ergebnisse fließen an einen Outline-Agenten zur Strukturierung und schließlich an einen Writing-Agenten für den ersten Entwurf.

// Research parallelisieren
const researchTasks = topics.map(topic => 
  sessions_spawn({
    runtime: "subagent",
    agentId: "research-agent",
    task: `Recherchiere "${topic}"`,
    model: "ds-v3-nx"
  })
);

await Promise.all(researchTasks);

Typische Fehlerquellen und Monitoring

Beim Aufbau von Multi-Agent-Setups treten häufig ähnliche Herausforderungen auf. Zu viele gleichzeitige Sub-Agenten können API-Rate-Limits auslösen und Kosten in die Höhe treiben; hier hilft die Implementierung einer Queue mit Maximal-Parallelität. Fehlendes Error-Handling führt oft dazu, dass ein einzelner fehlgeschlagener Sub-Agent die gesamte Pipeline stoppt – Retry-Logiken und Fallbacks schaffen Abhilfe. Zudem sollte State-Sharing vermieden werden, indem eindeutige Workspace-Pfade und File-Locking genutzt werden.

Für das Monitoring empfiehlt sich ein detailliertes Logging. Über Commands wie /subagents list oder /subagents log 3 --follow lassen sich aktive Prozesse und Echtzeit-Logs direkt verfolgen.

Einstieg in die Praxis

Für den Start empfiehlt es sich, zunächst einen einfachen Sub-Agenten für repetitive Aufgaben zu initiieren:

/subagents spawn helper "Liste alle Dateien im aktuellen Verzeichnis auf"

Anschließend lassen sich Status und Logs prüfen, um das Verhalten nachzuvollziehen:

/subagents list
/subagents log 1

Sobald das Prinzip klar ist, kann ein zweiter Agent mit einem abweichenden Modell hinzugefügt und über /subagents send gezielt gesteuert werden.

Die schrittweise Skalierung von einfachen Experimenten hin zu komplexen Pipelines verwandelt eine Standard-Installation in ein effizientes Agenten-Orchester. Ein guter erster Anwendungsfall ist ein Proofreading-Agent, der Texte parallel zur eigentlichen Arbeit korrekturliest. So wird der praktische Nutzen der Parallelisierung sofort sichtbar.