MoAI-ADK: Ein verifikationsgetriebenes Harness für Claude Code und der Factory Mode, der den Kontext auf Leader und Lanes aufteilt

Was es ist

MoAI-ADK ist ein quelloffenes Orchestrierungs-Harness für Agenten vom Team modu-ai. Es ist in Go geschrieben (Go 1.26 oder neuer) und steht unter der Apache-2.0-Lizenz. Das Release-Badge im Repository zeigt v3.1.3, und der Abschnitt What's New kündigt v3.2 mit einer Funktion namens Factory Mode an.

Das Projekt trainiert kein besseres Coding-Modell. Es legt um einen vorhandenen Coding-Agenten, vor allem Claude Code, eine äußere Struktur, damit sich dem erzeugten Code vertrauen lässt. Das Repository bietet außerdem Dokumentation auf Englisch, Koreanisch, Japanisch und Chinesisch, verweist auf ein Begleitbuch namens Practical Agentic Coding with Claude Code und zeigt CI-, CodeQL- und Codecov-Prüfungen.

Die Kernthese: drei Pflichten außerhalb des Modells

Das README beginnt mit einem Satz, der den ganzen Entwurf erklärt. Das Modell ist ein stochastischer Arbeiter, der Token für Token vorankommt. Von Runde zu Runde merkt es sich nicht, was es verbraucht hat und wie viel, es kann nicht beurteilen, ob das Ergebnis gut ist, und es weiß nicht, wie weit die letzte Sitzung gekommen ist. Ein Harness erzwingt alle drei Dinge von außen.

In der Ingenieurssprache sind das Budget, Qualität und Fortschritt. MoAI-ADK legt sie in die Hand deterministischen Codes, nicht des Modells. Das unterscheidet sich von der verbreiteten Gewohnheit, immer längere Prompts zu schreiben. Das Harness bittet das Modell nicht um gutes Verhalten. Es begrenzt und prüft das Modell.

Factory Mode: die Architektur

Der Factory Mode zielt auf das Kontextfenster. Eine Sitzung verbraucht ein Fenster. Eine lange SPEC füllt es, und jede spätere Aufgabe trägt alles Vorherige mit. Der Plan ist längst fertig, bleibt aber während der ganzen Prüfung im Fenster, und die Prüfung bleibt während des ganzen Abschlusstextes. Der übliche Ausweg ist /clear, aber das wirft nützlichen Kontext zusammen mit dem Ballast weg.

Der Factory Mode verteilt die Arbeit auf eine Leader-Sitzung und mehrere nummerierte Lane-Sitzungen. Der Leader beobachtet die Warteschlange und gibt Karten an freie Lanes. Eine Karte wechselt nicht bei jeder Stufe die Sitzung. Sie geht als Ganzes in eine Lane, und diese Lane führt sie in der eigenen Sitzung der Reihe nach durch plan, run und sync. Jede Stufe wird als Agent()-Subagent gestartet, und die Lane selbst orchestriert nur. Nichts ist unbegrenzt: Das Limit jeder Sitzung bleibt bestehen. Es ändert sich der Ort, an dem sich der Verlauf aufbaut. Der Verlauf einer Karte sammelt sich nur in der Lane, die sie besitzt. Dasselbe Budget reicht also weiter, und eine Lane leert ihren Kontext nach jeder Karte, bevor sie die nächste nimmt.

Ablauf im Betrieb

Der Einstieg nutzt zwei Optionen. moai cc -f (lange Form --factory) öffnet den Leader. moai cc -l (lange Form --lane) tritt der laufenden Fabrik als Lane bei. Keine der beiden nimmt einen Wert, und die Lane-Nummer wird automatisch vergeben. Die Kombination von -f und -l ist ein Fehler. Ein Wert hinter einer der Optionen, etwa moai cc -l lane-2, wird mit einer einzeiligen Meldung abgelehnt, die die richtige Form nennt. Der alte -k-Einstieg des Mehrsitzungs-Board-Modus ist entfernt, und moai cg endet mit einem Migrationshinweis, den man mit moai migrate cg vorab ansehen kann. Einen Befehl moai gpt gibt es nicht: GPT-Modelle laufen über moai codex, das keinen Leader-Einstieg hat und nur als Lane beitreten kann. Das Backend wird pro Lane gewählt. moai cc -l ist eine Claude-Lane, moai glm -l eine GLM-Lane, moai codex -l eine Codex-Lane. Die Dokumentation empfiehlt GLM für den Leader-Platz (moai glm -f), weil dieser Platz eine Warteschlange beobachtet und Karten trägt, statt Urteile zu fällen, und ein günstiges Modell beim Warten kaum kostet. Wenn ein Konto anfängt, 429-Fehler zu liefern, hilft es, die Lanes auf mehrere Konten zu verteilen. Der Text betont, dass diese Mischung nur ein Beispiel ist und ein einziges Backend für alle Sitzungen ebenso funktioniert. Um viele Karten gleichzeitig zu bearbeiten, führt man -l erneut aus. Eine Lane-Nummer wird nur übersprungen, solange eine lebende Sitzung sie hält. Der Anspruch einer toten Lane blockiert ihre Nummer nicht mehr, doch die automatische Vergabe nimmt immer die höchste lebende Nummer plus eins, füllt also nie eine Lücke in der Mitte. Die Lane-Zuordnung steht in ~/.moai/db/<project-key>/factory/factory.db. Ist das Basisverzeichnis ein temporäres Verzeichnis und gibt es keine absolute MOAI_HOME-Überschreibung, landet der Eintrag stattdessen unter <base>/.moai/db/<project-key>/factory/ im Projekt, dieselbe Ausnahme wie bei der Backlog-Warteschlange. Die alte Datei .moai/state/factory/workers.json wird einmal importiert und nur als Rollback-Beleg behalten.

Eine Lane führt höchstens 10 Agent()-Subagenten gleichzeitig aus, und Starts mit Schreibrechten werden in eigenen Worktrees isoliert. Die Empfehlung lautet: erst die erste Lane starten, prüfen, dass sie wirklich Ausgabe liefert, und erst dann die übrigen. Eine Karte wird nie auf mehrere Lanes verteilt. Ein Fabriklauf speichert außerdem die Prozessidentität der Sitzung, der er gehört. Ein Lauf, dessen Leader gestorben ist, wird beim Beitritt der nächsten Lane automatisch außer Dienst gestellt, damit der Beitritt nicht an AMBIGUOUS_FACTORY hängen bleibt. Auch der umgekehrte Fall ist abgedeckt: Tritt eine Lane bei, während der Lauf-Eintrag fehlt oder außer Dienst ist, aber eine lebende Leader-Sitzung existiert, prüft der Beitritt diesen Leader anhand der PID und eines Prozessstart-Fingerabdrucks.

Leistung und Kosten: Wo sind die Belege?

Der README-Auszug nennt keine Benchmark-Zahlen. Es gibt keinen Durchsatz, keinen Vergleich der Token-Kosten und keine Fehlerrate vorher und nachher.

Geboten wird ein struktureller Grund: Weil der Verlauf einer Karte nur in ihrer Lane liegt, reicht dasselbe Budget weiter. Der Mechanismus ist plausibel, sollte aber ohne veröffentlichte Messwerte als Hypothese gelesen werden, nicht als bewiesener Gewinn. Wer urteilen will, kann einige messbare Größen verfolgen: den mittleren Kontextverbrauch pro Karte, wie gut eine Lane ihr Fenster nach dem Leeren wiederverwendet, die Rate der 429-Fehler und den Koordinationsaufwand zwischen Leader und Lanes.

Folgen für Entwickler und Teams

Für Einzelentwickler bietet der Factory Mode einen parallelen Aufbau ohne eigenen Scheduler: mehrere Terminals öffnen und in jedem moai cc -l starten. Für Teams liegt der Zustand in SQLite-Dateien unter einem Projektschlüssel, was Prüfung und Wiederherstellung erleichtert.

Die Unterstützung mehrerer Backends erlaubt es, Anbieter nach Kosten und Kontingent zu mischen, statt auf einen zu setzen. Allgemeiner zeigt das Projekt eine Verschiebung im Feld: Der Wettbewerb wandert vom Modell selbst zur Prozess- und Prüfschicht um das Modell.

Grenzen und Ausblick

Erstens müssen Lanes von Hand gestartet werden, je ein Terminal, weil eine Sitzung keine andere starten kann. Das begrenzt die volle Automatisierung. Zweitens enthalten die öffentlichen Unterlagen keinen quantitativen Benchmark. Drittens zeigen die Prüfungen der Prozessidentität und der einmalige Import des alten Zustands, dass die Absturzwiederherstellung schon spürbare Komplexität trägt, die Nutzer verstehen sollten.

Viertens bedeutet die Regel, dass eine Karte nie geteilt wird, dass eine sehr große Einzelaufgabe das Fenster einer Lane weiterhin füllen kann. Sinnvolle nächste Schritte wären ein veröffentlichter Messbericht, mehr Backends und feinere Regeln zur Kartenteilung. Kurz: MoAI-ADK ist beobachtenswert. Vor dem Einsatz in der Produktion sollte man es selbst an einer kleinen Zahl echter Aufgaben messen.