Pull Request mit zusammengeführtem Code
Alle Änderungen liegen gebündelt, nachvollziehbar und prüfbar im Repository bereit.
CLI-Agenten-Orchestrator
Onyx – Wie ein Orchestrator ein Team aus KI-Agenten dirigiert
Du gibst eine Aufgabe ein. Ein Planer zerlegt sie, mehrere KI-Agenten arbeiten parallel in eigenen Containern, ein Merge-Agent führt alles zusammen – und am Ende steht ein fertiges, geprüftes Ergebnis.
- Parallel
- Isoliert in Containern
- Gegengeprüft
Station 1 · Eingang
Alles beginnt mit einer Aufgabe
Eine Aufgabe kann direkt formuliert werden oder als GitHub-Issue ins Projekt kommen. Der Orchestrator sammelt beides an einer Stelle ein und legt es zur Bearbeitung ab – ein Eingang, mehrere Quellen.
- Aufgabenin eigenen Worten – so, wie man sie einem Kollegen erklären würde.
- GitHub-Issuesaus den Projekten, die der Orchestrator betreut.
- AufgabeLandingpage für ein Café bauen
- GitHub-Issue #42Login-Fehler auf Mobilgeräten
- AufgabePreisliste verständlich umschreiben
- GitHub-Issue #57Dunkles Farbschema ergänzen
Station 2 · Planung und Zerlegung
Ein Planer entscheidet: direkt oder zerlegen
Ein Sprachmodell als Planer liest die Aufgabe. Ist sie klein, geht sie direkt als eine Teilaufgabe an einen Agenten. Ist sie groß, wird sie zerlegt – in mehrere Teilaufgaben, die sich gegenseitig ergänzen.
- Agent
- Welcher Typ passt: „standard“ (baut) oder „browser“ (prüft).
- Repo
- Ein bestehendes Projekt, ein neues – oder keins.
- Modell und Effort
- Nur angegeben, wenn sie vom Standard abweichen.
- Abhängigkeiten (
after) - Was zuerst fertig sein muss. Alles ohne Abhängigkeit läuft parallel.
- Neue Aufgabe
- Kontaktseite ergänzenwartet
- 01 · Design und Seitenstrukturwartet
- 02 · Marktrecherchewartet
- 03 · Seite und Blog bauenwartet
- 04 · Im Browser prüfenwartet
- Ergebnis
- Merge-Agent → Ergebnis
Beispiel: „Café-Website mit Blog“ – wird in vier Teilaufgaben zerlegt.
Die Etiketten nennen den Agenten (standard oder browser), das Repo, Abweichungen bei Effort und die Abhängigkeit (after). Alle Angaben sind Beispiele.
Station 3 · Worker und Agenten-Container
Jede Teilaufgabe bekommt ihren eigenen Container
Ein Container ist eine abgeschottete Arbeitsumgebung, die für die Teilaufgabe hochfährt und danach wieder verschwindet. Gearbeitet wird auf einem eigenen Branch – einer parallelen Arbeitskopie. So kommen sich die Agenten nie in die Quere.
Es gibt zwei Varianten: standard baut – Code, Webseiten, Texte, Konfiguration. browser baut nichts: Er rendert Seiten wie ein echter Browser, macht Screenshots, klickt sich durch und prüft.
Beispielablauf zur Veranschaulichung. Bricht ein Worker ab (z. B. Absturz oder Zeitlimit), liest ein neuer Worker auftrag.md und status.md und macht genau dort weiter.
Animation: Ein Container startet, arbeitet eine Liste von Schritten ab, meldet das Ergebnis und fährt wieder herunter. Nach einem simulierten Abbruch setzt ein neuer Worker anhand der Datei status.md an derselben Stelle fort.
Station 4 · Warteschlange
Drei Prioritäten: hoch, niedrig, randzeit
Oft gibt es mehr Teilaufgaben als freie Plätze. Dann stellen sie sich in einer Warteschlange an – sortiert nach Priorität. Erst kommt hoch dran, dann niedrig.
Randzeit-Aufgaben haben keine Eile: Sie laufen bevorzugt in ruhigen Zeiten, wenn Kapazität frei ist und nichts Dringenderes wartet.
Spielwiese: Die Beispiel-Aufgaben und die zwei Plätze sind frei gewählt. Zum Ausprobieren eigene Aufgaben einreihen.
Station 5 · Kapazität und Speicher
Nur so viele Worker, wie der Server verträgt
Die Parallelität ist begrenzt: MAX_WORKERS legt fest, wie viele Worker gleichzeitig laufen dürfen. Zusätzlich startet ein neuer Worker nur, wenn genug Arbeitsspeicher frei ist – sonst würde der Rechner in die Knie gehen.
Passt beides, startet der Worker sofort. Sonst bleibt die Aufgabe in der Warteschlange, bis ein Platz oder genug Speicher frei wird.
Platz frei?Speicher reicht?
Ein neuer Worker möchte starten …
Beispielwerte: vier Plätze (MAX_WORKERS), roter Strich = Speichergrenze. Die echten Werte sind Konfiguration.
Station 6 · Abo-Limits
Ein Kontingent für alle
Der Orchestrator und alle Worker teilen sich ein gemeinsames Nutzungskontingent des Claude-Abos. Je mehr gleichzeitig arbeiten, desto schneller ist es aufgebraucht. Dagegen helfen drei Maßnahmen:
- Gestaffelter EffortNur so viel Denkaufwand wie nötig – einfache Teile bekommen weniger.
- Begrenzte ParallelitätNicht alles gleichzeitig, damit das Kontingent länger reicht.
- Pausieren und fortsetzenIst das Limit erreicht, ruht die Arbeit – nach dem Zurücksetzen geht es weiter.
- Orchestratorläuft
- Worker 1läuft
- Worker 2läuft
- Worker 3läuft
Beispielverlauf zur Veranschaulichung – die Prozentwerte und Zeiten sind nicht echt.
Station 7 · Merge-Agent
Aus vielen Branches wird ein Ergebnis
Sind alle Teilaufgaben fertig und gegengeprüft, übernimmt der Merge-Agent: Er führt alle Branches zusammen, löst Konflikte – etwa wenn zwei Agenten dieselbe Stelle angefasst haben – und räumt die Auftragsdateien auf.
- Alle Teile fertig und gegengeprüft
- Branches zusammenführen
- Konflikte lösen
- Auftragsdateien aufräumen
Station 8 · Ergebnisse
Am Ende steht etwas Greifbares
Kein Chat-Protokoll, sondern Ergebnisse, die man anfassen kann.
Ausgerollte Projekte
Webseiten und Anwendungen gehen – zum Beispiel über Coolify – live und sind unter eigener Adresse erreichbar.
Ergebnisbericht
Eine Zusammenfassung: was getan wurde, was geprüft wurde und welche Annahmen unterwegs getroffen wurden.
Alles zusammen · Live-Pipeline
Spiel eine Aufgabe ein und sieh zu
Ein Klick schickt eine Beispiel-Aufgabe durch die gesamte Pipeline – vom Eingang bis zum Ergebnis.
- EingangAufgabe kommt rein
- PlanungPlaner zerlegt
- WarteschlangeTeile reihen sich ein
- WorkerAgenten arbeiten parallel
- GegenprüfungBrowser-Agent prüft
- MergeBranches vereinen
- ErgebnisPull Request, Rollout
Bereit. Starte die Simulation mit dem Knopf oben.