Der selbstlernende Governor

Die Autonomous Delivery Engine lernt, welches Agent-Profil und Modell für eine gegebene Aufgabe zu verwenden ist, und auditiert dieses Lernen fortlaufend auf Qualitätsregressionen. Diese Seite erklärt das geschichtete Lernmodell (L0–L2) und was der L3-Governor darüber hinaus tut. Die wichtigste Eigenschaft, die es zu verstehen gilt, steht am Ende: Der Governor wendet niemals automatisch eine Konfigurationsänderung an — jede Änderung ist an die Zustimmung des Workspace-Owners gebunden.

Die Lernschichten (L0–L2)

Das Auswahllernen ist geschichtet, sodass ein Kaltstart sicher ist und das datengetriebene Signal die Auswahl erst dann steuert, wenn es vertrauenswürdig ist.

L0 — die statische Heuristik

An der Basis bewertet SupaCloud Kandidaten-Profile und -Modelle mit einer statischen Heuristik über die Aufgabe: Schweregrad, Aufwand, Budget-Spielraum und Capability-Passung. Ein brandneuer Workspace ohne Historie läuft vollständig auf L0. Diese Schicht ist bei Sicherheit und Budget stets maßgeblich — die darüberliegenden gelernten Schichten können ihren Score nur anstoßen, niemals ein hartes Budget- oder Sicherheitssignal überschreiben.

L1 — das Reward-Signal

Jeder abgeschlossene Run verdient einen skalaren Reward in [-1, 1]: eine gewichtete Mischung aus schwer zu manipulierenden Ergebnissignalen — bestandene Tests und Builds, ein erstellter oder gemergter Pull Request, die Zustimmung eines unabhängigen LLM-Richters — abzüglich einer Kostenstrafe. Die Gewichtung ist bewusst widerstandsfähig gegen Reward-Hacking: Eine Coding-Aufgabe, die null Dateien geändert hat, wird gedeckelt, das Test-/Build-Signal zählt nur, wenn echte Arbeit (ein PR) geleistet wurde, und ein teurer Run, der nichts erreicht hat, erzielt netto einen negativen Wert. Dieser Reward ist das überwachte Signal, aus dem die nächste Schicht lernt.

L2 — der kontextuelle Bandit

Ein kontextueller Bandit aggregiert Rewards zu segmentierten Statistiken (segmentiert nach Aufgabentyp, Schweregrad und Aufwand) und stößt den L0-Heuristik-Score in Richtung des Arms mit dem besseren gelernten Reward an. Zwei Schutzmechanismen halten ihn ehrlich:

Der Anstoß ist begrenzt — er kann den Heuristik-Score nur um eine kleine Spanne anpassen, sodass er eine knappe Entscheidung kippt, statt die Heuristik zu überschreiben.
Ein Segment muss genügend Stichproben sammeln (eine Mindest-Signifikanz-Schranke), bevor sein gelernter Reward die Auswahl überhaupt steuert; darunter bleibt die Auswahl heuristikdominiert. Der Kaltstart wird daher nie von Rauschen getrieben.

Der L3-Governor

Der Governor sitzt über dem Lernsubstrat und steuert es. Er läuft nach einem periodischen Zeitplan (getrieben vom Tick des Schedulers — keine dauerhaft laufende Schleife) und hat vier Aufgaben.

Golden-Set-Audit

Jeder Workspace kann ein Golden-Set kuratieren — eine Menge repräsentativer (Aufgabentyp, Fixture, Erwartung)-Fälle, die der Governor erneut abspielt und bewertet, um Qualitätsregressionen zu erkennen. Das periodische Audit aggregiert die Ergebnisse des jüngsten Fensters pro Profil und erzeugt einen selbstbeschreibenden Qualitätsbericht.

Kappa-kalibrierter Richter

Der maßgebliche Qualitäts-Score des Audits kann von einem LLM-Richter stammen — aber nur dann, wenn diesem Richter vertraut wird. Der Governor misst die Übereinstimmung des Richters mit Ground-Truth-Signalen (gemergte PRs, bestandene Builds) als Cohens Kappa über ein Kalibrierungsfenster. Dem Richter wird nur vertraut, wenn:

genügend gelabelte Kalibrierungsstichproben vorhanden sind, um Kappa überhaupt zu schätzen, und
Kappa die Vertrauensschwelle erreicht (die übliche Grenze für „substanzielle Übereinstimmung“).

Wenn der Richter unkalibriert ist — zu wenige Stichproben oder Kappa unter der Schwelle — misstraut ihm der Governor und fällt auf die deterministischen Ergebnismetriken zurück (Reward- und Erfolgsraten-Aggregate), die ein schmeichelnder Richter nicht manipulieren kann. Die gewählte Verdikt-Quelle wird im Bericht festgehalten, sodass jedes Audit angibt, ob es dem Richter vertraut hat oder zurückgefallen ist.

Drift-Einfrieren

Für jedes kürzlich aktive Profil vergleicht der Governor dessen jüngste Reward-Verteilung mit dessen Baseline-Verteilung mittels eines Zwei-Stichproben-Kolmogorow-Smirnow-Tests. Der KS-Test wird verwendet (statt eines einfachen Mittelwertvergleichs), weil er eine Änderung in der Form der Verteilung erkennt — zum Beispiel ein Profil, das im Mittel noch gut abschneidet, aber einen dicken Ausläufer fehlgeschlagener Runs entwickelt hat.

Bei einer statistisch signifikanten Regression — einer Verschiebung in die schlechtere Richtung mit genügend Stichproben auf beiden Seiten — tut der Governor Folgendes:

Er friert die gelernte Auswahl des Profils ein. Während des Einfrierens wird der Bandit-Anstoß für dieses Profil unterdrückt und die Auswahl fällt auf die statische Heuristik zurück, sodass ein regressierendes Profil nicht weiter von veraltetem gelerntem Reward gesteuert werden kann;
er löst ein Audit-Ereignis aus (das Signal, das die Operator-Konsole und das Governor-Dashboard lesen);
er öffnet einen owner-gebundenen Remediation-Vorschlag (siehe unten).

Das Einfrieren ist umkehrbar und wird nur aufgehoben, wenn ein Owner eine Remediation genehmigt. Ein bereits eingefrorenes Profil löst keine doppelten Alarme aus.

Owner-gebundene Vorschläge

Der Governor bearbeitet ein Profil nie von sich aus. Stattdessen erhebt er Vorschläge, die ein Owner prüft und entscheidet:

Ein Profilversions-Vorschlag trägt eine konkrete, prüfbare Kandidaten-Konfiguration — typischerweise die letzte als gut bekannte frühere Version des Profils (Rücknahme der Änderung, die der Regression vorausging) oder die aktuelle Konfiguration, die der Owner bearbeiten kann. Bei Genehmigung wird der Kandidat über den normalen validierten Writer als neue Agent-Profil-Version materialisiert (versioniert, als Snapshot gesichert und auditiert), und das Drift-Einfrieren wird aufgehoben, sodass die gelernte Auswahl von der korrigierten Baseline aus wieder aufgenommen wird. Bei Ablehnung wird der Vorschlag geschlossen und das Einfrieren bleibt bestehen, bis es anderweitig aufgehoben wird.
Ein Skill-Induktions-Vorschlag schürft aus der Reflexion eines erfolgreichen Runs — den Lektionen, die der Agent in seiner Abschlussfassung festgehalten hat — einen verallgemeinerbaren Skill und erhebt ihn als Entwurf. Bei Genehmigung wird er als Skill-Capability veröffentlicht, die das Laufzeit-Skill-Retrieval dann verwenden kann; bei Ablehnung wird er geschlossen. Ein Entwurf ist für das Laufzeit-Retrieval konstruktionsbedingt unsichtbar, sodass ein nicht genehmigter Vorschlag niemals einen live laufenden Agenten erreicht.

Nichts wird automatisch angewendet

Das ist die definierende Garantie des Governors: Der Governor diagnostiziert und schlägt vor, wendet aber niemals eine Konfigurationsänderung ohne die Zustimmung des Owners an.

Das Lernen in L0–L2 justiert ausschließlich einen begrenzten Anstoß an der Auswahlbewertung — es schreibt nie die Konfiguration eines Profils um.
Eine per Drift erkannte Regression friert die gelernte Auswahl ein (ein sicherer, umkehrbarer Rückfall auf die Heuristik) und schlägt eine Remediation vor — sie ändert das Profil nicht.
Eine Profilversionsänderung und ein neuer induzierter Skill materialisieren beide nur bei ausdrücklicher Owner-Zustimmung, über dieselben validierten, auditierten Writer, die ein Owner von Hand verwenden würde.

Jede Governor-Aktion — ein Einfrieren, ein Audit-Bericht, eine Vorschlagsentscheidung — wird im Audit-Protokoll festgehalten, sodass die autonome Schleife vollständig nachvollziehbar ist.

Siehe auch

Die Delivery-Engine betreiben — die Operator-Konsole, die Dispatch-Metriken und der Kill-Switch.
Die vollständige Designbegründung findet sich in ADR 0045.