Multi-Agent-Systeme: Wenn KIs zusammenarbeiten — Teil 4 der Serie 'KI-Agenten in der Praxis'

Ein einzelner KI-Agent stößt bei komplexen Workflows schnell an Grenzen. Der Kontext wird voll, Zwischenergebnisse vermischen sich und ein Agent mit zu vielen Werkzeugen trifft schneller riskante Entscheidungen. Die Lösung ist nicht automatisch ein größeres Modell, sondern eine saubere Orchestrierung: Rollen trennen, Eingaben strukturieren, Werkzeuge begrenzen und jeden Übergabepunkt prüfbar machen.

Wichtig ist dabei die präzise Einordnung von OpenClaw. Nach dem Stand der offiziellen Dokumentation vom 10. Mai 2026 ist OpenClaw primär ein selbst gehostetes Gateway zu AI-Coding-Agenten mit Konfigurations-, Modell-, Channel-, Plugin- und Automationsfunktionen. Die Dokumentation belegt unter anderem openclaw config, openclaw models, Agent-Defaults, Modell-Fallbacks und Agent-Konfigurationspfade. Sie belegt aber nicht, dass OpenClaw selbst ein vollständiger nativer Multi-Agent-Scheduler mit frei spawnbaren „Sub-Agents“ ist. In diesem Tutorial verwenden wir OpenClaw deshalb als Gateway- und Konfigurationsschicht und modellieren die eigentliche Multi-Agent-Orchestrierung explizit über Rollen, Task-Verträge, getrennte Arbeitsbereiche und Logs.

Voraussetzungen

Du brauchst eine funktionierende OpenClaw-Installation mit eingerichtetem Modellzugang. Prüfe zuerst, welche Konfigurationsdatei aktiv ist und ob sie valide ist:

openclaw config file
openclaw config validate

Für nicht-interaktive Änderungen ist openclaw config get|set|patch|unset|schema|validate dokumentiert. Wenn du OpenClaw in einem Nix-basierten Setup mit OPENCLAW_NIX_MODE=1 betreibst, behandelt OpenClaw openclaw.json als unveränderlich. In diesem Fall dürfen Agenten oder Skripte die generierte Konfigurationsdatei nicht direkt beschreiben; ändere stattdessen die Nix-Quelle deines Setups.

Prüfe außerdem den aktuellen Modellstatus:

openclaw models status
openclaw models list

Wenn du das Standardmodell bewusst ändern willst, nutzt du laut Dokumentation:

openclaw models set <provider/model>

Ersetze <provider/model> durch ein Modell, das in deiner Umgebung authentifiziert und verfügbar ist.

Rollenverteilung im Agenten-Team

Ein Multi-Agent-Workflow wird stabiler, wenn jede Rolle nur eine klar begrenzte Aufgabe bekommt.

Conductor bzw. Orchestrator: Diese Instanz nimmt die Hauptaufgabe entgegen, zerlegt sie in Arbeitspakete und entscheidet, welcher Spezialist welche Aufgabe erhält. In einem einfachen Setup kann das ein Skript, ein CI-Job, ein Task-Runner oder ein manuell ausgelöster Prozess sein. Der Conductor sollte nicht selbst alle Detailarbeit erledigen, sondern Aufgaben vergeben, Ergebnisse validieren und Fallbacks auslösen.

Spezialisten: Jeder Spezialist arbeitet an einem engen Teilproblem: Recherche, Code-Änderung, Testausführung, Review, Dokumentation oder Veröffentlichungsvorbereitung. Für jeden Spezialisten definierst du Eingaben, erlaubte Werkzeuge, Arbeitsverzeichnis, Modellwahl und erwartetes Ausgabeformat.

Bridge-Schritte: Nicht jede Übergabe braucht einen weiteren LLM-Agenten. Oft reicht ein deterministisches Skript, das JSON prüft, Felder normalisiert oder Markdown aus einem validierten Report erzeugt. Bridge-Schritte sind besonders nützlich, weil sie reproduzierbarer sind als freie Chat-Kommunikation.

Was OpenClaw in diesem Muster übernimmt

OpenClaw ist in diesem Aufbau nicht der magische „Agenten-Schwarm“, sondern die kontrollierte Zugriffsschicht zu Modellen, Agent-Konfigurationen, Werkzeugen und Kanälen. Die offiziellen Docs beschreiben unter anderem:

• agents.defaults.model.primary beziehungsweise agents.defaults.model als primäre Modellwahl,
• agents.defaults.model.fallbacks als geordnete Fallback-Liste,
• agents.defaults.models als Allowlist beziehungsweise Katalog sichtbarer Modelle,
• openclaw models status, openclaw models list und openclaw models set,
• openclaw config schema, openclaw config get, openclaw config set und openclaw config validate.

Bevor du agentenspezifische Pfade änderst, prüfe immer die aktive Schema-Version:

openclaw config schema > openclaw.schema.json
openclaw config get agents.defaults.model --json
openclaw config get agents.defaults.models --json
openclaw config get agents.list --json

Die Dokumentation nennt beispielsweise Konfigurationspfade unter agents.defaults.* und agents.list[...]. Indexbasierte Änderungen an agents.list[0] solltest du aber nur vornehmen, wenn du vorher geprüft hast, welcher Agent an diesem Index tatsächlich liegt. Danach immer validieren:

openclaw config validate

Strukturierte Delegation statt Prompt-Ketten

Die wichtigste Regel lautet: Übergib keine unklaren Chat-Verläufe, sondern strukturierte Task-Verträge. Ein Task-Vertrag beschreibt mindestens Eingabe, Rolle, erlaubte Werkzeuge, Ausgabeformat und Abbruchbedingungen.

Beispiel für eine Recherche-Aufgabe:

{
  "task_id": "research-2026-04-01-mas-001",
  "role": "research",
  "input": {
    "topic": "Multi-Agent-Orchestrierung für Coding-Workflows",
    "urls": [
      "https://addyosmani.com/blog/code-agent-orchestra/",
      "https://docs.openclaw.ai/concepts/models.md"
    ]
  },
  "allowed_actions": [
    "read_url",
    "summarize",
    "extract_claims"
  ],
  "forbidden_actions": [
    "publish",
    "write_production_code",
    "modify_config"
  ],
  "output_schema": {
    "claims": "array",
    "sources": "array",
    "uncertainties": "array"
  },
  "timeout_seconds": 600
}

Der Conductor speichert diesen Vertrag, startet den passenden Arbeitsschritt und akzeptiert das Ergebnis nur, wenn es dem erwarteten Schema entspricht. Scheitert die Validierung, wird kein nachgelagerter Schreib- oder Publishing-Schritt ausgeführt. Wichtig: Ein solcher JSON-Vertrag ist erst einmal nur ein Vertrag. Er erzwingt keine Rechte, solange der ausführende Agent technisch weiterhin alle Werkzeuge nutzen kann. Die harten Grenzen müssen deshalb zusätzlich in der Laufzeitumgebung liegen: getrennte Agent-Profile, eingeschränkte Tool-Listen, separate Arbeitsverzeichnisse, CI-Regeln oder Betriebssystemrechte.

Determinismus realistisch definieren

LLM-Ausgaben sind nie vollständig deterministisch. Du kannst aber die Umgebung reproduzierbarer machen:

1. Modell und Fallbacks bewusst setzen oder dokumentieren.
2. Tool-Zugriffe pro Rolle begrenzen.
3. Eingaben als Dateien oder JSON-Artefakte versionieren.
4. Ausgaben gegen Schemas prüfen.
5. Jede Übergabe mit Task-ID, Modell, Zeitstempel und Status loggen.
6. Fallbacks nur auf validierte Zwischenergebnisse anwenden.

Wenn du Modell-Allowlisten in OpenClaw pflegst, nutze dokumentierte Config-Kommandos. Ein Beispiel aus der offiziellen Config-Dokumentation ist das Setzen von agents.defaults.models mit JSON:

openclaw config set agents.defaults.models '{"<provider/model>":{}}' --strict-json --merge
openclaw config validate

Ersetze <provider/model> durch einen Modellnamen, der in deiner Umgebung wirklich verfügbar ist. openclaw models status zeigt dir, welche Default- und Fallback-Konfiguration aktuell aufgelöst wird.

Schritt-für-Schritt: ein robuster Workflow

1. Arbeitsbereiche trennen

Lege pro Rolle eigene Eingabe-, Ausgabe- und Log-Verzeichnisse an:

mkdir -p workflows/content-pipeline/tasks
mkdir -p workflows/content-pipeline/outputs/research
mkdir -p workflows/content-pipeline/outputs/writing
mkdir -p workflows/content-pipeline/outputs/review
mkdir -p workflows/content-pipeline/logs

Diese Trennung ersetzt keine echte Sandbox, verhindert aber viele versehentliche Vermischungen von Artefakten. Für produktive Schreibzugriffe solltest du zusätzlich Betriebssystemrechte, Container, separate Repositories oder CI-Policies nutzen. Führe die Beispielbefehle außerdem nur in einem bewusst angelegten Projekt- oder Testverzeichnis aus, nicht blind im Root eines produktiven Repositories.

2. Rollenvertrag schreiben

Definiere je Rolle, was erlaubt und verboten ist. Ein Research-Schritt braucht keine Publishing-Rechte. Ein Review-Schritt braucht normalerweise Lesezugriff auf Diff, Quellen und Tests, aber keinen Zugriff auf Secrets.

3. OpenClaw-Konfiguration prüfen

Vor einem Lauf sollten mindestens diese Checks erfolgreich sein:

openclaw config validate
openclaw models status

Wenn du modell- oder agentspezifische Konfigurationen änderst, prüfe vorher Schema und Ist-Zustand:

openclaw config schema > openclaw.schema.json
openclaw config get agents.defaults.model --json
openclaw config get agents.defaults.models --json

4. Ergebnisse nur strukturiert weitergeben

Der Research-Schritt schreibt beispielsweise outputs/research/report.json. Der Writing-Schritt liest nur diese Datei und nicht den kompletten Chat-Verlauf. Ein Bridge-Skript kann vorher prüfen, ob alle Pflichtfelder vorhanden sind. Behandle dabei nicht nur die Antwort des Agenten als untrusted input, sondern auch die gelesenen Quellen selbst: Webseiten, Issues, README-Dateien oder Forenposts können Prompt-Injection enthalten und versuchen, dem Recherche-Agenten neue Anweisungen unterzuschieben. Solche Inhalte gehören in zitierte Datenfelder, nicht in den System- oder Steuerkontext des nächsten Schritts.

5. Fallbacks kontrolliert auslösen

Ein Fallback darf nicht bedeuten: „Nimm irgendein anderes Modell und mache weiter.“ Besser ist:

• Fehlerursache loggen,
• unvollständiges Ergebnis markieren,
• optional denselben Task mit anderem Modell oder engerem Prompt wiederholen,
• Ausgabe erneut validieren,
• erst danach den nächsten Schritt starten.

Die OpenClaw-Dokumentation beschreibt Modell-Fallbacks in der Modellkonfiguration. Für Workflow-Fallbacks brauchst du zusätzlich eigene Orchestrierungslogik im Conductor.

Praxisbezug: Code Agent Orchestra

Addy Osmani beschreibt im Konzept des „Code Agent Orchestra“, warum parallele oder spezialisierte Coding-Agenten nur dann zuverlässig werden, wenn Zuständigkeiten, Artefakte und Feedback-Schleifen klar sind. Genau das ist der Kern dieses Musters: Nicht viele Agenten sind automatisch besser, sondern sauber begrenzte Agenten mit überprüfbaren Übergaben.

In OpenClaw-nahen Setups bedeutet das: Nutze OpenClaw für Modellzugang, Konfigurationsprüfung, Agent-Defaults und Gateway-Funktionen. Baue die Multi-Agent-Logik darüber bewusst und explizit, statt implizit anzunehmen, dass ein Tool automatisch sichere Sub-Agent-Isolation liefert.

Wer die Microsoft-Perspektive auf standardisierte Orchestrierung vertiefen möchte, findet im Beitrag zum Microsoft Agent Framework RC den nächsten Baustein. Für die konzeptionelle Grundlage lohnt außerdem der Blick auf den Überblick zu Multi-Agenten-Systemen.

Sicherheitsregeln für Multi-Agent-Workflows

• Gib Schreib-, Deploy- und Publishing-Rechte nie an Recherche- oder Analyse-Rollen.
• Leite Secrets nicht über Task-JSON oder Agenten-Prompts weiter.
• Validiere OpenClaw-Konfigurationen nach jeder Änderung mit openclaw config validate.
• Protokolliere Modell, Task-ID, Input-Dateien, Output-Dateien und Exit-Status.
• Behandle LLM-Ausgaben und externe Recherchequellen als untrusted input, bis Schema-, Quellen- und Plausibilitätschecks abgeschlossen sind.
• Leite Inhalte aus Webseiten, Issues oder Foren nicht ungefiltert als Anweisungen an andere Agenten weiter.
• Erzwinge Tool-Grenzen technisch über Agent-Konfiguration, Laufzeit, CI oder Betriebssystemrechte; ein forbidden_actions-Feld im Task-JSON ist allein nur Dokumentation.
• Nutze getrennte Arbeitsverzeichnisse oder Sandboxes, wenn Agenten Dateien verändern dürfen.

Was daraus folgt

Multi-Agenten-Systeme werden dann nützlich, wenn Rollen, Datenübergaben und Grenzen explizit modelliert sind. OpenClaw kann dabei eine wichtige Gateway- und Konfigurationsschicht sein, ersetzt aber nicht automatisch die Orchestrierungslogik, Validierung und Rechtekontrolle deines Workflows.

Der Fortschritt liegt nicht darin, möglichst viele Agenten zu starten. Der Fortschritt liegt darin, jeden Schritt prüfbar zu machen: klare Rolle, begrenzte Werkzeuge, strukturierte Eingabe, validierte Ausgabe, nachvollziehbares Log und definierter Fallback.