Der Entwickler-Blog von Google veröffentlichte am 2. September einen Beitrag zum Thema Harness-Engineering, Autorin ist Shir Meir Lador. Der Artikel definiert Harness recht nüchtern: die Gesamtheit aller deterministischen Komponenten, die das Sprachmodell umhüllen – Orchestrierungsschicht, Ausführungs-Sandbox, Zustandsspeicherung und Validierungswerkzeuge zählen alle dazu.
Zum Einstieg steht ein Kontrastwert: In einem experimentellen internen Produkt von OpenAI lag der Anteil von Hand geschriebenen Codes bei null Zeilen – drei Ingenieure bauten allein mit modellgeneriertem Code eine interne Beta-Version und brachten sie live. Die Autorin nutzt das Beispiel, um zu zeigen: Das eigentliche Problem liegt nicht in der Fähigkeit des Modells, sondern in der Struktur, die es innerhalb eines kontrollierbaren Prozesses hält.
Zügel, Scheuklappen und Rennbahn
Der Artikel bemüht einen Pferderennen-Vergleich: Das Modell ist das Pferd, der Harness sind Rennbahn, Scheuklappen und Zügel – zuständig dafür, dass es in eine Richtung läuft.
"The harness is composed of all the deterministic components that wrap the LLM."
Der Harness besteht aus sämtlichen deterministischen Komponenten, die das Sprachmodell umschließen.
Diese Definition verschiebt einen Teil der Arbeit, die bislang unter "Prompt Engineering" lief. Um das Modellverhalten einzugrenzen, gibt es nur zwei Wege: in den Prompt schreiben oder in den umgebenden Code schreiben. Ersteres verlässt sich auf die Selbstdisziplin des Modells – bei einem Modellwechsel muss neu nachjustiert werden; Letzteres ist eine harte Grenze, die auch über Modellgenerationen hinweg gilt. Im vergangenen Jahr haben die meisten Teams, die Agent-Produkte gebaut haben, beides ausprobiert – und für beides Lehrgeld gezahlt. Der Prompt-Satz "Testdateien nicht verändern" – spätestens in der dreißigsten Runde eines langen Kontexts fängt das Modell an, ihn selektiv zu übersehen.
Drei Design-Prinzipien
Strikte Grenzen. Den Agenten in eine Sandbox sperren, ihm keine Chance geben, Produktionsdaten anzufassen. In der Demo des Artikels darf der Agent nur innerhalb des Verzeichnisses ./sandbox Dateien schreiben; Operationen außerhalb dieser Grenze werden gar nicht erst ausgeführt.
Reparaturschleife. Fehler sollten nicht direkt an Menschen weitergereicht werden. Schlägt ein Test fehl, spielt der Harness das saubere Log an das Modell zurück, damit es sich selbst korrigiert. ADK 2.0 setzt hier auf einen graphenbasierten Workflow – der Validierungsschritt ist selbst ein Routing-Knoten im Graphen; ein fehlgeschlagener Lauf leitet den Kontrollfluss automatisch zurück zum Generierungsknoten, ohne dass man Retry-Logik von Hand in den Orchestrierungscode schreiben müsste.
Schrittweise entdeckbare Repo-Struktur. Keine tausende Zeilen lange Anleitungsdatei schreiben und dem Agenten auf einmal vor die Nase setzen. Stattdessen das Repository so organisieren, dass sich der Agent Schicht für Schicht hineingraben und Kontext bei Bedarf selbst entdecken kann.
Das begleitende Antigravity SDK kümmert sich um die lokale Umgebungsseite: Es steckt Workspace-Grenzen ab und stellt gleichzeitig persistentes Gedächtnis bereit. Zusammen decken die beiden Werkzeuge zwei Fragen ab: "Wo läuft der Agent?" und "Wie kommt er zurück, wenn etwas schiefgeht?"
Die Fünf-Runden-Grenze und der Schalter dahinter
Die selbstheilende Schleife der Demo durchläuft einen vollständigen Zyklus: Der Agent schreibt Code in einer eingeschränkten Sandbox, führt automatisch Tests aus, der Test schlägt fehl, das Log wird zurückgespielt, der Agent korrigiert, dann wird erneut getestet. Die Obergrenze liegt bei fünf Runden; ist sie erreicht, bricht der Harness ab – die Autorin nennt das einen Kill Switch.
Diese Fünf ist die praktisch nützlichste Zahl im gesamten Artikel. Das typische Fehlermuster einer selbstheilenden Schleife: Das Modell springt zwischen zwei fehlerhaften Zuständen hin und her, verbrennt in jeder Runde Token, ohne zu konvergieren. Eine harte Obergrenze zu setzen heißt, im Voraus einzugestehen, dass das Modell manchmal nicht weiterkommt – und das Problem früher an einen Menschen zurückzugeben. Ohne diesen Schalter kann eine entgleiste Schleife über Nacht unbeaufsichtigt das gesamte Budget verbrennen.
Verglichen mit den Agenten-Frameworks, die in der ersten Jahreshälfte populär waren, ist die Schwerpunktverschiebung deutlich sichtbar. Frühe Frameworks drehten sich vor allem um Orchestrierung – wie man mehrere Agenten verkettet, Arbeit aufteilt, Nachrichten weiterreicht. Heute geht es um Validierung und Grenzen: Wo läuft die Ausführung, wie fließen Fehler zurück, wann wird gestoppt. Ersteres löst die Frage "Läuft es überhaupt?", Letzteres die Frage "Kann man es auf einem echten Projekt laufen lassen, ohne Angst zu haben?"
Für Teams, die nicht genau auf Googles Stack setzen, sind ADK 2.0 und das Antigravity SDK als konkrete Werkzeuge nicht zwingend brauchbar – die drei Prinzipien lassen sich aber eins zu eins übernehmen. Sandbox, Reparaturschleife, schrittweise entdeckbarer Kontext: Um diese drei Punkte kommt kein selbst gebauter Coding-Agent herum. Der einzige Unterschied ist, ob man sie von Anfang an mitdenkt – oder erst nachrüstet, nachdem der Agent einmal die Testdateien gelöscht hat.
Quellen: Googles Entwickler-Blog, CocoLoop, Projektdokumentation zu ADK und Antigravity SDK; Harness-Definition, die drei Design-Prinzipien und die Fünf-Runden-Grenze wurden mit dem Originalartikel abgeglichen, die Angaben zu null Zeilen handgeschriebenem Code und drei Ingenieuren stammen aus dessen Darstellung.