Googles EnvHarness nutzt ein Modell doppelt
Googles neues Framework baut Trainingsumgebungen um die Schwächen eines Agenten herum. Auf beiden Seiten läuft dabei dasselbe Modell.
Trainingsumgebungen für KI-Agenten sind teuer zu bauen und danach statisch. Der Agent wird besser, die Umgebung bleibt gleich, und irgendwann lernt er dort nichts mehr. Google Cloud AI Research hat dafür ein Framework veröffentlicht, das einen anderen Weg geht als die verbreitete Antwort "dann generieren wir eben mehr Umgebungen": EnvHarness legt eine programmierbare Schicht um eine bestehende Umgebung und baut sie um die konkreten Schwächen des Agenten herum um. Der Code steht unter Apache-2.0 auf GitHub, das Paper ist seit dem 20.08.2026 online.
Der Name ist bewusst gewählt. Wir haben über Harness Engineering schon ausführlich geschrieben: die Software-Schicht um ein Modell herum, die Tools, Kontext und Ausführungsschleifen beisteuert. EnvHarness macht dasselbe am anderen Ende der Interaktion, auf der Seite der Umgebung.
Drei Bausteine, die Umgebung selbst bleibt unangetastet
Das Framework kennt drei Komponenten. Ein Stage verändert den Startzustand. In einer ALFWorld-Aufgabe soll der Agent etwa eine saubere Tasse auf einen Schreibtisch stellen, und normalerweise liegt die Tasse sichtbar herum. Legt der Stage sie in eine geschlossene Schublade, muss der Agent erst suchen. Ein Contract greift in die Interaktion ein, filtert Aktionen oder kürzt Beschreibungen, sodass der Agent Informationen über mehrere Schritte zusammentragen muss. Eine Chain hängt Aufgaben aneinander, was längere Trajektorien erzwingt, in denen der Agent seine Ziele und sein Schrittbudget im Blick behalten muss.
Den Umbau übernimmt nicht der Mensch, sondern EnvRigger. Der läuft in einer Schleife aus Beobachten, Diagnostizieren, Schreiben und Validieren: Agent mehrfach laufen lassen, in den erfolgreichen und gescheiterten Durchläufen nach wiederkehrenden Fehlermustern suchen, passende Komponenten bauen, dann mit frischen Durchläufen prüfen, ob die Aufgabe noch lösbar und nicht zu leicht ist. Reicht das nicht, wird nachgebessert, bis zu fünf Runden.
Das praktische Beispiel aus dem Paper: Ein Coding-Agent reicht Patches ein, ohne vorher die Tests laufen zu lassen. EnvRigger baut daraufhin eine Regel, die das vorzeitige Einreichen abfängt und eine Warnung zurückgibt. Entscheidend ist, was dabei nicht passiert. Das Repository und die von Menschen geschriebenen Unit-Tests bleiben unberührt. Der Contract blockiert von außen, aber über Erfolg oder Misserfolg entscheiden weiter die Original-Tests.
Die Zahlen: Über fünf Benchmarks aus vier Domänen bringt EnvHarness laut Paper bis zu 9,0 Punkte auf zurückgehaltenen Aufgaben, bei 9,8 Prozent weniger Ausführungsschritten. Auf SWE-bench Verified liegt es 2,46 Punkte über dem eigens dafür gebauten SWE-smith und braucht 5,11 Schritte weniger pro Episode. Interessanter als die Einzelwerte ist die Skalierungskurve: Bei 300 Umgebungen kommt der Agent von 47,67 auf 54,79 Prozent, ein Plus von 7,12 Punkten, und die Kurve steigt weiter. Derselbe Aufwand in Original-Umgebungen landet bei 52,13, in generierten bei 50,37. In der zugehörigen Kurve flachen beide früher ab.
Die Stelle, an der es interessant wird
Im Abschnitt zum Versuchsaufbau steht ein Satz, der leicht zu überlesen ist:
"Importantly, EnvRigger and the policy agent utilize the same model backbone on each benchmark: Gemini-3.1-Flash-Lite for ALFWorld and WebArena, and Gemini-3.5-Flash elsewhere, ensuring that performance gains do not stem from distilling a stronger external model."
Das ist methodisch sauber gedacht. Wenn der Designer ein stärkeres Modell wäre, könnte man die Verbesserungen als Destillation abtun. Gleiches Modell auf beiden Seiten schließt das aus. Nur beschreibt derselbe Satz auch ein Setup, in dem Prüfer und Prüfling dasselbe Modell sind. Und der Informationsfluss zwischen beiden ist kein theoretischer: EnvRigger behandelt den Agenten als Blackbox und liest seine Trajektorien, also vom Agenten selbst erzeugten Text, Shell-Befehle, Zwischennotizen, Patches. Daraus leitet er ab, wie die Umgebung umgebaut wird.
Der Kanal ist dabei breiter, als es zunächst klingt. Was EnvRigger als Contract ableitet, ist laut Anhang C.3 Python-Quelltext, den das Framework kompiliert und pro Episode in einem eigenen Subprozess ausführt. Der Weg führt dort also von agentenerzeugtem Text über eine Diagnose zu generiertem Code, der dann läuft. Für die anderen beiden Komponenten gilt das nicht: Ein Stage speichert laut Anhang nichts weiter als die Aktionsliste selbst, eine Chain ist reine Kompositionslogik.
Was das über Absprachen zwischen Modellen aussagt und was nicht, haben wir getrennt aufgeschrieben. Kurz: Der Mechanismus für gemeinsame Interessen fehlt hier, weil EnvRigger geprompted und nicht trainiert wird und es keinen gemeinsamen Reward gibt. Was bleibt, ist die Konstellation. Die Forschungslage dazu steht in Derselbe Modellkopf auf beiden Seiten.
Was das für die Praxis heißt
Die gute Nachricht steckt im Design von EnvHarness selbst. Der menschgeschriebene Verifier wird weder generiert noch verändert. EnvRigger liest seine Urteile durchaus, die Validierung hängt an den Erfolgsraten aus fünf Durchläufen, aber umschreiben kann er ihn nicht. Genau das ist die Sicherung, und die Autoren betonen sie zu Recht als Vorteil gegenüber Pipelines, die komplette Umgebungen samt Bewertung generieren.
Auffällig ist trotzdem, worüber der Limitations-Anhang spricht und worüber nicht. Genannt werden die Kosten der Design-Schleife, die Voraussetzung einer zurücksetzbaren Umgebung und die rein sequenzielle Komposition von Chains. Absprachen, Reward Hacking oder Prompt Injection über den Trajektorien-Kanal kommen nicht vor. In den Future Directions stehen dagegen ausdrücklich Komponenten, die "several agents in a shared environment" platzieren, also genau die Konstellation, in der solche Fragen scharf werden.
Wer EnvHarness ausprobiert, sollte deshalb zwei Dinge beachten. Erstens die Grenze, die das Paper selbst zieht: Die Diagnose-Schleife braucht eine zurücksetzbare Umgebung. In Systemen mit irreversiblen Nebenwirkungen hat sie nichts zu suchen, also weder an einer Produktionsdatenbank noch an echten Kundenkonten. Zweitens die Frage, die es nicht zieht: Wer den Designer mit demselben Modell betreibt, das er trainiert, sollte wenigstens wissen, dass er das tut.
Wie solche Trainingsschleifen überhaupt gebaut sind, wo sie sich schließen und wo nicht, steht in Wenn KI die nächste KI trainiert.