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

Ein einzelner KI-Agent gerät bei großen Aufgaben leicht ins Schleudern: Der Kontext füllt sich, Zwischenergebnisse vermischen sich und eine Instanz mit vielen Werkzeugen kann mehr verändern als beabsichtigt. Ein Multi-Agent-Workflow hilft nur dann, wenn jede Übergabe enger gefasst ist als der ursprüngliche Auftrag.

OpenClaw bringt dafür mehrere Laufzeitbausteine mit. Subagents und getrennte ACP-Läufe können Arbeit im Hintergrund ausführen, Background Tasks machen solche Läufe beobachtbar und Task Flow hält mehrstufige Abläufe dauerhaft fest. Die fachlichen Grenzen entstehen dabei nicht automatisch. Du musst weiterhin entscheiden, wer welche Eingabe erhält, welche Werkzeuge verfügbar sind und wann ein Lauf abgebrochen wird.

Dieses Tutorial baut deshalb zuerst ein lokales Gate. Es startet noch keinen Agenten, prüft aber einen strukturierten Task-Vertrag und lässt sich später vor einen OpenClaw-Subagent, einen ACP-Lauf, einen CI-Job oder einen eigenen Task-Flow-Controller setzen.

Vor dem ersten Lauf

Für die Demo brauchst du eine funktionierende OpenClaw-Installation, ein nutzbares Modell, python3 und ein bewusst gewähltes Testverzeichnis. Beginne mit der aktiven Konfiguration:

openclaw config file
openclaw config validate

openclaw config file gibt den Pfad der aktiven Konfigurationsdatei aus. Bei einer gültigen Konfiguration endet openclaw config validate erfolgreich; für eine maschinenlesbare Prüfung kannst du openclaw config validate --json verwenden.

Wenn OPENCLAW_NIX_MODE=1 gesetzt ist, behandelt OpenClaw openclaw.json als unveränderlich. Lesende Befehle wie config file, config get, config schema und config validate funktionieren weiterhin, während Änderungen in die Nix-Quelle des Setups gehören.

Prüfe danach den Modellzugang:

openclaw models status
openclaw models list

openclaw models status zeigt die aufgelöste Primär- und Fallback-Konfiguration samt Authentifizierungsstatus. openclaw models list listet standardmäßig die konfigurierten Modelle. Falls du das Standardmodell bewusst ändern willst, lautet der dokumentierte Befehl:

openclaw models set <provider/model>

Ersetze den Platzhalter nur durch ein Modell, das in deiner Umgebung verfügbar und authentifiziert ist. Für die lokale Demo musst du das Standardmodell nicht ändern.

Wo OpenClaw aufhört

Drei Ebenen spielen für diesen Aufbau eine Rolle.

Agent- und Modellkonfiguration: agents.defaults enthält gemeinsame Vorgaben, während agents.list explizite Agenten mit stabilen IDs und möglichen Überschreibungen aufführt. Das Primärmodell liegt unter agents.defaults.model.primary, die geordnete Fallback-Liste unter agents.defaults.model.fallbacks.

Abgekoppelte Arbeit: Subagent-, ACP- und Automationsläufe können als Background Tasks erfasst werden. Diese Datensätze zeigen Zustände wie queued, running und ein terminales Ergebnis. Sie planen jedoch keinen Startzeitpunkt.

Task Flow: Plugin-Code kann einen verwalteten Flow steuern, der mehrere Schritte und deren Status dauerhaft verbindet. Für abgekoppelte ACP- oder Subagent-Läufe kann OpenClaw auch einen gespiegelten Ein-Task-Flow anlegen. Dieser Spiegel verbessert die Beobachtbarkeit, entwirft aber keine sichere Fachpipeline.

Das reicht noch nicht.

OpenClaw verwaltet Läufe und Zustände, doch aus einem unpräzisen Auftrag entsteht dadurch kein belastbarer Produktionsprozess. Die entscheidende Grenze bleibt der Vertrag zwischen zwei Schritten: Was darf der nächste Prozess lesen, ausführen und zurückgeben?

Konfigurationspfade verifizieren

Lies Schema und Ist-Zustand aus, bevor du agentenspezifische Werte änderst:

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 Pfade haben unterschiedliche Aufgaben. agents.defaults.model.primary setzt das Primärmodell, agents.defaults.model.fallbacks ordnet die Fallbacks und agents.defaults.models beschreibt den konfigurierten Modellkatalog samt Allowlist. Explizite Agenteneinträge stehen in agents.list.

agents.defaults.models ist keine vollständige Sicherheitsgrenze. Laut Modelldokumentation beschränkt ein Eintrag dort Modell-Overrides nicht automatisch; technische Werkzeugrechte und Laufzeitgrenzen müssen deshalb an den dafür vorgesehenen Stellen durchgesetzt werden.

Ändere außerdem nie blind agents.list[0]. Lies zuerst die Liste aus und prüfe die ID des Eintrags. Nach einer tatsächlichen Änderung folgt immer:

openclaw config validate

Rollen an der Übergabe trennen

Ein belastbarer Workflow braucht eine Instanz, die den nächsten Schritt freigibt. Dieser Conductor kann Plugin-Code, ein Skript, ein CI-Job oder ein manuell gestarteter Prozess sein. Seine wichtigste Aufgabe besteht nicht darin, möglichst viele Agenten parallel zu starten, sondern aus einem Auftrag einen prüfbaren Vertrag zu machen und nur validierte Ergebnisse weiterzureichen.

Ein Spezialist erhält anschließend ein enges Teilproblem, etwa Recherche oder Review. Ein deterministischer Bridge-Schritt prüft dessen JSON und überführt es bei Bedarf in das Eingabeformat der nächsten Rolle. Dafür ist kein weiterer LLM-Lauf nötig.

Ein konkretes Beispiel: Der Research-Schritt darf Quellen lesen und Claims extrahieren, aber weder veröffentlichen noch Produktionscode ändern. Der folgende Writing-Schritt bekommt später nur das validierte Rechercheartefakt – nicht den gesamten Chat und nicht jede Anweisung, die in einer Webseite gestanden haben könnte.

Einen Task-Vertrag anlegen

Der Vertrag beschreibt Rolle, Eingabe, erlaubte Aktionen und die erwartete Ausgabe:

{
  "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
}

Das JSON dokumentiert die beabsichtigten Grenzen. Es erzwingt sie nicht. Wenn die ausführende Instanz technisch Zugriff auf Publishing- oder Config-Werkzeuge besitzt, verhindert ein Eintrag in forbidden_actions keinen Tool-Aufruf. Harte Grenzen gehören in Tool-Policies, Sandboxes, getrennte Agentenprofile oder die Rechte des Betriebssystems und der CI-Umgebung.

Das lokale Vertrags-Gate bauen

Führe die nächsten Befehle in einem Testverzeichnis aus. Der Setup-Block bricht ab, falls dort bereits ein Eintrag namens mas-demo existiert, und überschreibt deshalb keinen früheren Versuch:

if [ -e mas-demo ]; then
  echo 'mas-demo already exists; choose another directory or inspect it first' >&2
  exit 1
fi

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 nun den Vertrag an:

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

Der Validator prüft anschließend nicht nur Pflichtfelder. Er lehnt auch leere IDs, doppelte oder widersprüchliche Aktionen, unbekannte Rollen und unbrauchbare Timeout-Werte ab:

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

ALLOWED_ROLES = {'research', 'writing', 'review'}
ALLOWED_SCHEMA_TYPES = {'array', 'object', 'string', 'number', 'boolean'}
REQUIRED = {
    'task_id',
    'role',
    'input',
    'allowed_actions',
    'forbidden_actions',
    'output_schema',
    'timeout_seconds',
}


def fail(message):
    raise SystemExit('invalid task contract: ' + message)


if len(sys.argv) != 2:
    fail('usage: validate_task.py PATH')

path = Path(sys.argv[1])
try:
    data = json.loads(path.read_text(encoding='utf-8'))
except OSError as error:
    fail('cannot read file: ' + str(error))
except json.JSONDecodeError as error:
    fail('invalid JSON: ' + str(error))

if not isinstance(data, dict):
    fail('top level must be an object')

missing = sorted(REQUIRED - data.keys())
if missing:
    fail('missing required fields: ' + ', '.join(missing))

task_id = data['task_id']
if not isinstance(task_id, str) or not task_id.strip():
    fail('task_id must be a non-empty string')

role = data['role']
if not isinstance(role, str) or role not in ALLOWED_ROLES:
    fail('unsupported role: ' + repr(role))

if not isinstance(data['input'], dict) or not data['input']:
    fail('input must be a non-empty object')

for key in ('allowed_actions', 'forbidden_actions'):
    value = data[key]
    if not isinstance(value, list):
        fail(key + ' must be a list')
    if not all(isinstance(item, str) and item.strip() for item in value):
        fail(key + ' must contain non-empty strings only')
    if len(value) != len(set(value)):
        fail(key + ' must not contain duplicates')

overlap = sorted(set(data['allowed_actions']) & set(data['forbidden_actions']))
if overlap:
    fail('actions listed as allowed and forbidden: ' + ', '.join(overlap))

schema = data['output_schema']
if not isinstance(schema, dict) or not schema:
    fail('output_schema must be a non-empty object')
for field, declared in schema.items():
    if not isinstance(field, str) or not field.strip():
        fail('output_schema field names must be non-empty strings')
    if declared not in ALLOWED_SCHEMA_TYPES:
        fail('unsupported output type for ' + field + ': ' + repr(declared))

timeout = data['timeout_seconds']
if isinstance(timeout, bool) or not isinstance(timeout, int):
    fail('timeout_seconds must be an integer')
if not 1 <= timeout <= 3600:
    fail('timeout_seconds must be between 1 and 3600')

if role == 'research' and 'publish' in data['allowed_actions']:
    fail('research role must not publish')

print('task contract ok:', task_id)
PY

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

Bei einem gültigen Vertrag erscheint:

task contract ok: research-2026-04-01-mas-001

Der Prozess endet mit Exit-Status 0. Bei einem Fehler beginnt die Meldung mit invalid task contract: und der Exit-Status ist ungleich 0.

Wichtig ist die Reichweite dieses Gates: Es prüft den Startauftrag, nicht das spätere Rechercheergebnis. Für outputs/research/report.json brauchst du ein zweites Schema oder einen eigenen Ergebnisvalidator. Sonst kann ein formal sauber gestarteter Agent weiterhin ein unbrauchbares Artefakt abliefern.

Das Gate vor einen Lauf setzen

Der Conductor führt zuerst den Validator aus. Nur bei Exit-Status 0 startet er den vorgesehenen OpenClaw-Subagent, ACP-Lauf, CI-Job oder Task-Flow-Schritt.

Nach der Recherche schreibt der Spezialist beispielsweise outputs/research/report.json. Der Writing-Schritt liest ausschließlich dieses validierte Artefakt. So wandern beiläufige Aussagen aus dem Recherche-Chat oder eingebettete Anweisungen einer Webseite nicht ungeprüft in den nächsten Steuerkontext.

Behandle externe Seiten, Issues, README-Dateien und Forenbeiträge als nicht vertrauenswürdige Eingaben. Ihr Inhalt gehört in klar markierte Datenfelder oder Zitate. Er darf nicht bestimmen, was der nächste Agent ausführt.

Modellkonfiguration kontrolliert ändern

Einen zusätzlichen Modell-Eintrag kannst du zunächst ohne Änderung prüfen:

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

Ersetze den Platzhalter durch eine verfügbare Provider-/Modell-ID. Entferne --dry-run erst, wenn die Vorschau das gewünschte Ergebnis zeigt. Danach folgen erneut:

openclaw config validate
openclaw models status

--merge erhält bestehende Einträge im Objekt. Ein erfolgreicher Katalogeintrag bestätigt allerdings weder gültige Zugangsdaten noch eine technische Beschränkung auf dieses Modell; dafür musst du den tatsächlichen Modellstatus und die getrennten Tool-Policies prüfen.

Zwei verschiedene Fallbacks

OpenClaw kann bei einem technischen Modellfehler auf Einträge aus agents.defaults.model.fallbacks ausweichen. Das beantwortet jedoch nicht die fachliche Frage, ob ein unvollständiges Ergebnis für den nächsten Schritt genügt.

Der Conductor braucht dafür eine eigene Regel: Er protokolliert Ursache und Task-ID, markiert das Teilresultat als unvollständig und startet nur bei vorgesehenen Fehlerarten einen neuen Versuch. Auch dieses Ergebnis muss wieder durch das Gate. Ein anderes Modell darf niemals eine fehlgeschlagene Rechte- oder Schemaprüfung umgehen.

Wenn der Ablauf stoppt

Die OpenClaw-Konfiguration ist ungültig

Lass dir den aktiven Pfad anzeigen und prüfe die fehlerhafte Stelle maschinenlesbar:

openclaw config file
openclaw config validate --json

Bei einem Nix-Setup änderst du die deklarative Nix-Quelle und nicht openclaw.json.

Kein Modell ist nutzbar

openclaw models status
openclaw models list

Richte danach die passende Provider-Authentifizierung ein. Der Multi-Agent-Lauf darf erst starten, wenn der Status den benötigten Modellzugang bestätigt.

mas-demo existiert bereits

Der Setup-Block bricht absichtlich ab. Wähle ein anderes Testverzeichnis oder untersuche den vorhandenen Ordner. Lösche ihn nicht ungeprüft, denn er kann Ergebnisse eines früheren Laufs enthalten.

Der Vertrag wird abgelehnt

Die Meldung hinter invalid task contract: nennt die verletzte Regel. Repariere das JSON und führe denselben Validator erneut aus. Das Gate zu lockern, nur damit der nächste Schritt startet, beseitigt den Fehler nicht.

Das Agentenergebnis ist unbrauchbar

Ein gültiger Startvertrag sagt nichts über die Qualität der Ausgabe. Prüfe das Ergebnis mit einem getrennten Schema, bevor Writing, Code-Änderung oder Publishing beginnen. Ohne dieses zweite Gate bleibt ausgerechnet die zentrale Übergabe ungeschützt.

Praxisbezug: Code Agent Orchestra

Addy Osmani beschreibt mit dem Code Agent Orchestra spezialisierte Coding-Agenten mit klaren Zuständigkeiten, Artefakten und Feedback-Schleifen. Entscheidend ist dabei nicht die Zahl parallel laufender Instanzen, sondern die Qualität ihrer Übergaben: Jede Rolle braucht eine abgegrenzte Aufgabe, und ein nachgelagerter Schritt muss das Ergebnis ablehnen können.

Für OpenClaw heißt das: Nutze Agent-Konfiguration, Subagents, Background Tasks und Task Flow passend zum gewünschten Laufmodell. Ergänze sie um Task-Verträge, technisch durchgesetzte Werkzeuggrenzen und Ergebnisvalidatoren. Ein automatisch erfasster Task oder gespiegelter Flow ist beobachtbar, aber noch keine sichere Fachpipeline.

Die Framework-Perspektive behandelt der Vergleich zwischen LangChain, CrewAI und AutoGen. Die praktische Konfigurationsseite vertieft der Artikel zur OpenClaw-Gateway-Konfiguration.

Mindestregeln für den Betrieb

Recherche- und Analyse-Rollen brauchen keine Deploy- oder Publishing-Rechte. Secrets gehören weder in den Task-Vertrag noch in Prompts und Ergebnisartefakte. Externe Quellen und LLM-Ausgaben bleiben bis zur Validierung nicht vertrauenswürdig.

Pro Übergabe solltest du mindestens Task-ID, verwendetes Modell, Ergebnis und Exit-Status protokollieren. Schreibende Rollen laufen in getrennten Arbeitsverzeichnissen oder Sandboxes; ihre Grenzen müssen technisch greifen und dürfen nicht nur im JSON stehen.

Konfigurationsänderungen werden zuerst als Vorschau geprüft und anschließend mit openclaw config validate validiert. Scheitert ein Vertrags-, Rechte- oder Ergebnis-Gate, darf auch ein Modell-Fallback den Folgeschritt nicht freigeben.

Worauf es ankommt

Ein Multi-Agent-System wird nicht durch die Anzahl seiner Agenten belastbar. Entscheidend ist die eine Frage an jeder Übergabe: Kann ein deterministischer Kontrollpunkt das Ergebnis ablehnen?

Dafür braucht der Schritt eine klar benannte Rolle, eine begrenzte Eingabe, technisch eingeschränkte Werkzeuge und eine validierte Ausgabe. Erst wenn dieses Gate erfolgreich ist, darf der nächste Agent oder Prozess übernehmen.