Multi-Agent-Orchestrierung
Viele Agents ausführen. Die Reihenfolge entscheidet ein Controller.
Manche Arbeit hat eine Reihenfolge, die sich vorab nicht aufschreiben lässt. Setzen Sie type: controller, deklarieren Sie, was am Ende des Laufs wahr sein muss, und Dagu lässt ein Modell den nächsten Agent-Schritt wählen, sobald Befunde zurückkommen. Jede Aktion bleibt ein gewöhnlicher Workflow-Schritt mit Logs, Retries, Freigaben und Audit-Historie.
# code-review.yaml
type: controller
llm:
provider: anthropic
model: claude-opus-5
system: |
Get top_n.py past both reviews. When a review fails, pass its finding
to revise, then ask that same reviewer again. A revision made for one
reviewer can break the other.
steps:
- name: review_simplicity
description: Judge simplicity. Prints PASS, or FAIL with what to change.
action: harness.run
with:
provider: opencode
prompt: Read top_n.py. Print "PASS" or "FAIL: <what to change>".
- name: review_correctness
description: Judge correctness. Prints PASS, or FAIL with the bug.
action: harness.run
with:
provider: codex
prompt: Read top_n.py. Print "PASS" or "FAIL: <the bug>".
- name: revise
description: Edit top_n.py to resolve one review finding.
action: dag.run
with: { dag: revise }
tasks:
- name: simplicity_passed
description: The latest simplicity review returned PASS on the current file.
- name: correctness_passed
description: The latest correctness review returned PASS on the current file.Abschlusskriterien deklarieren statt Schrittreihenfolge
Jede Aktion ist eine echte Agent-CLI: Claude, Codex, Gemini, OpenCode
Aufgaben enden als completed, skipped oder failed
Wartet der Lauf auf eine Antwort, bleibt kein Prozess stehen
At a glance
Controller-Workflows und Agent-Frameworks
Sie deklarieren die Abschlusskriterien. Der Lauf endet, wenn keine Aufgabe mehr offen ist.
Entweder erklärt sich das Modell selbst für fertig, oder jeder Pfad wird vorab gezeichnet und von Hand gepflegt.
Ein wartender Lauf beendet seinen Prozess und setzt in einem neuen fort.
Langes Warten bedeutet meist einen Prozess am Leben zu halten und einen State Store zu betreiben.
Zeitpläne, Queues, Retries, Artefakte und Audit-Historie kommen aus dem DAG-Lauf.
Pro Projekt neu gebaut oder an eine gehostete Control Plane abgegeben.
Die Menge der Schritte in der Workflow-Datei.
Alles, was die Tool-Definitionen zulassen.
In depth
Where each tool fits
Genau die Reihenfolge lässt sich nicht aufschreiben
Ein Graph kann auf einen Exit-Code verzweigen. Auf das, was ein Review tatsächlich gesagt hat, kann er nicht verzweigen. Ein Controller-Workflow hält die Aktionen fest und gibt nur die Reihenfolge ab.
- Schritte werden zum Katalog von Aktionen, damit entfällt jedes zu pflegende depends
- Eine tasks-Liste deklariert, was am Ende des Laufs wahr sein muss
- Der Controller trägt den Befund eines Agents in die Parameter des nächsten
Das Modell wählt die Reihenfolge, nie die Fähigkeiten
Der Controller wählt nur aus den Schritten, die Sie deklariert haben. Er kann keinen Schritt erfinden, kein eigenes Shell-Kommando schreiben und nichts erreichen, was die Datei nicht nennt. Der Wirkungsradius ist damit die Workflow-Definition.
- Jeden Agent auf dem Host oder in einer Container-Sandbox mit expliziten Mounts und Egress-Regeln ausführen
- Jeder Rolle ihren eigenen Provider und ihr Modell geben, damit kein Modell die eigene Arbeit bewertet
- Was sich bewährt hat, wandert in einen Sub-Workflow und ist keine Entscheidung mehr
Produktionskontrollen kommen aus dem Lauf, nicht aus einem Framework
Ein Controller-Lauf ist ein DAG-Lauf. Zeitpläne, Queues, Retries, Artefakte und Audit-Historie gelten unverändert, und die Grenzen für die Ausgaben eines Agents sind Engine-Einstellungen statt Prompt-Anweisungen.
- ask_user unterbricht den Lauf dauerhaft: der Prozess endet und der Worker-Slot wird frei
- Stunden später antwortet jemand, und der Lauf setzt in einem frischen Prozess fort
- Grenzen für Runden, Aktionsversuche und Rückfragen lassen den Lauf scheitern statt unbegrenzt Kosten zu erzeugen
Jeden Lauf im Nachhinein rekonstruieren
Ein Controller hat keine Abhängigkeitskanten. Der Lauf wird deshalb als Folge der tatsächlich getroffenen Entscheidungen dargestellt und nicht als Graph.
- Eine Entscheidungs-Timeline: eine Zeile je Runde, mit Versuchen, Dauer und Link auf den erzeugten Kindlauf
- Eine Aufgabenansicht mit der Begründung, warum der Controller jedes Ziel abgeschlossen hat
- Das vollständige Transkript, samt jedem Tool-Ergebnis, das das Modell gesehen hat
FAQ
Practical questions before adopting Dagu
Worin unterscheidet sich ein Controller-Workflow von einer Agent-Schleife?
Eine nackte Schleife überlässt dem Modell die Entscheidung, wann es fertig ist. Ein Controller behält die Schleife, holt sich aber die Abbruchbedingung zurück: Sie deklarieren die Aufgaben und was erledigt bedeutet, und der Lauf endet, wenn keine Aufgabe mehr offen ist.
Was passiert, wenn sich eine Aufgabe als überflüssig erweist?
Der Controller markiert sie als skipped und hält den Grund fest, und der Lauf bleibt erfolgreich. Skipped und failed sind getrennte Zustände, weil «es gab nichts zu tun» und «es ließ sich nicht tun» im Audit-Log verschiedene Ergebnisse sind.
Können verschiedene Schritte verschiedene Modelle nutzen?
Ja. Jeder Agent-Harness-Schritt nennt seinen eigenen Provider und sein Modell, und das Modell des Controllers wird getrennt konfiguriert. So kann ein günstiges Modell teure Spezialisten steuern oder zwei Provider können einander prüfen.
Wie verhindere ich unbegrenzte Kosten?
Die Grenzen setzt die Engine durch. Eine Aktion läuft höchstens fünfmal pro Lauf, ein Lauf stellt höchstens fünf Fragen, und das Rundenlimit liegt standardmäßig bei fünfzig und lässt sich senken. Wird eine Grenze erreicht, scheitert der Lauf und benennt, was offen geblieben ist.
Wann ist ein gewöhnlicher Graph weiterhin richtig?
Wenn Sie den Graphen zeichnen können, zeichnen Sie ihn. type: graph bleibt der Standard, weil er schneller, günstiger und reproduzierbar ist. Greifen Sie zum Controller nur, wenn die Reihenfolge wirklich davon abhängt, was frühere Schritte hervorgebracht haben.
Next step
Start with one workflow.
Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.