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

Ein einzelner KI-Agent gerät bei größeren Workflows schnell ins Schleudern. Der Kontext läuft voll, Zwischenergebnisse vermischen sich, und ein Agent mit zu vielen Werkzeugen trifft eher riskante Entscheidungen. Die bessere Antwort ist oft nicht ein größeres Modell, sondern sauberere Orchestrierung: Rollen trennen, Eingaben strukturieren, Werkzeuge begrenzen und jeden Übergabepunkt prüfbar machen.

OpenClaw hilft in so einem Setup nicht als magischer Agentenschwarm, sondern als kontrollierte Schicht vor Modellen, Agent-Konfigurationen, Werkzeugen und Kanälen. Genau daraus entsteht ein nüchternes, aber nützliches Muster: OpenClaw regelt Modellzugang und Konfiguration, die eigentliche Multi-Agent-Logik baust du bewusst darüber.

Setup vor dem Start

Du brauchst:

• eine funktionierende OpenClaw-Installation,
• eingerichteten Modellzugang für mindestens ein nutzbares Modell,
• eine Shell in einem bewusst angelegten Projekt- oder Testverzeichnis,
• für das lokale Validierungsbeispiel python3.

Prüfe zuerst, welche Konfigurationsdatei aktiv ist und ob sie valide ist:

openclaw config file
openclaw config validate

Für nicht-interaktive Änderungen sind 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.

Rollen im Agenten-Team sauber schneiden

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

Conductor oder 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 die 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. Solche Zwischenschritte sind besonders nützlich, weil sie reproduzierbarer sind als freie Chat-Kommunikation.

Welche Aufgabe OpenClaw in diesem Muster übernimmt

OpenClaw ist in diesem Aufbau 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 ist dabei ein Punkt, den viele Teams zu spät merken: Ein JSON-Vertrag ist zuerst 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.

Ein minimaler Bridge-Schritt zum Nachbauen

Die folgenden Befehle starten noch keinen LLM-Agenten. Sie zeigen nur den reproduzierbaren Kern: Task-Vertrag schreiben, lokal validieren und erst danach einen nächsten Schritt erlauben. Führe sie in einem Testverzeichnis aus, nicht blind im Root eines produktiven Repositories.

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

Lege den Task-Vertrag ab:

cat > workflows/content-pipeline/tasks/research-task.json <<'JSON'
{
  "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
}
JSON

Ein bewusst einfacher Validator kann Pflichtfelder prüfen, bevor ein Agent oder nachgelagerter Schritt überhaupt starten darf:

cat > workflows/content-pipeline/validate_task.py <<'PY'
import json
import sys
from pathlib import Path

path = Path(sys.argv[1])
data = json.loads(path.read_text(encoding='utf-8'))
required = ['task_id', 'role', 'input', 'allowed_actions', 'forbidden_actions', 'output_schema', 'timeout_seconds']
missing = [key for key in required if key not in data]
if missing:
    raise SystemExit('missing required fields: ' + ', '.join(missing))
if data['role'] not in {'research', 'writing', 'review'}:
    raise SystemExit('unsupported role: ' + data['role'])
if not isinstance(data['allowed_actions'], list) or not isinstance(data['forbidden_actions'], list):
    raise SystemExit('allowed_actions and forbidden_actions must be lists')
if 'publish' in data['allowed_actions'] and data['role'] == 'research':
    raise SystemExit('research role must not publish')
print('task contract ok:', data['task_id'])
PY

python3 workflows/content-pipeline/validate_task.py workflows/content-pipeline/tasks/research-task.json

In einer echten Pipeline würde der Conductor nach diesem Schritt den passenden Agenten, einen CLI-Aufruf, einen CI-Job oder einen OpenClaw-nahen Arbeitsschritt starten. Der wichtige Punkt ist: Die Übergabe ist ein versioniertes Artefakt, nicht ein diffuser Chat-Verlauf.

Determinismus realistisch definieren

LLM-Ausgaben sind nie vollständig deterministisch. Du kannst die Umgebung aber deutlich 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.

Ein robuster Workflow in fünf Schritten

1. Arbeitsbereiche trennen

Lege pro Rolle eigene Eingabe-, Ausgabe- und Log-Verzeichnisse an. Wenn du dem Minimalbeispiel oben gefolgt bist, existieren diese Verzeichnisse bereits:

find workflows/content-pipeline -maxdepth 2 -type d | sort

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.

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 praktische OpenClaw-Seite lohnt außerdem der Blick auf das Tutorial zu Multi-Agent-Setups und Sub-Agents.

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.

Worauf es im Betrieb wirklich ankommt

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.