Aktuelles

Harness²: Googles KI-Agenten schreiben jetzt ihre eigene Bedienungsanleitung um

Die KI-Welt ist ein Blumenstrauß unglaublicher Überraschungen und jeden Tag kommt eine Blüte dazu. Oder so ähnlich. Bisher funktionierten KI-Agenten wie ein neuer Mitarbeiter, dem man am ersten Tag ein Handbuch gibt. Daran hält er sich dann bis zur Rente, ob er gerade eine Steuerakte prüft oder einen Server neu aufsetzt.

Google Research hat mit Harness² ein Open-Source-Framework veröffentlicht, mit dem Agenten dieses Handbuch für jede Aufgabe selbst überarbeiten. Am Modell selbst ändert sich dabei nichts. Das klingt nach Science-Fiction, ist aber eher solides Handwerk. Es gibt allerdings ein paar Haken, über die in den Jubelposts der Tech-Medien auffällig wenig steht.

Erst mal: Was ist eigentlich ein „Harness“?

Wer heute mit Agenten arbeitet, merkt schnell, dass das Sprachmodell nur der Motor ist. Ob daraus ein brauchbares Auto wird, entscheidet alles drumherum. Dazu gehören der Systemprompt, die Leitplanken, das Gedächtnis, die Anleitungen für Tools, Subagenten, Skills, Skripte und Plugins. Dieses ganze Geschirr nennt man Harness.

Harness² legt genau diese acht Bestandteile als editierbare Dateien offen. Bisher lief es meistens so: Ein Mensch baut das Harness einmal und bastelt es über Wochen zurecht. Danach arbeitet der Agent jede neue Aufgabe mit derselben Konfiguration ab, ob sie passt oder nicht. Wer schon einmal einen halben Tag an einer Tool-Beschreibung gefeilt hat, damit der Agent nicht zum dritten Mal das falsche Verzeichnis löscht, kennt das Problem.

Propose, Probe, Compose: So optimiert sich der Agent selbst

Das Verfahren arbeitet auf zwei Ebenen. Die erste nennt Google Propose-Probe-Compose und betrifft die einzelne Aufgabe:

• Der Agent erledigt die Aufgabe zunächst mit seinem Basis-Harness.
• Ein Editor-Modell schlägt danach zwei Änderungen vor. Die eine zielt auf allgemeine Schwächen wie schlechte Planung oder falsch eingesetzte Tools. Die andere ergänzt Fachwissen und Abläufe für genau diese Aufgabe.
• Beide Varianten laufen gegen dieselbe Aufgabe.
• Ein „Composer“ vergleicht die Ergebnisse. Er übernimmt nur die Änderungen, die sich im beobachteten Verhalten tatsächlich bewährt haben.

Die zweite Ebene sorgt dafür, dass der Agent nicht jedes Mal bei null anfängt. Nach jeder Aufgabe legt ein „Reflector“ das übernommene Harness und eine Lessons-learned-Datei ab. Aus dieser Bibliothek speisen sich die Vorschläge für spätere Aufgaben. Interessant ist dabei: Jede neue Aufgabe startet trotzdem wieder vom Basis-Harness aus. Es wächst also kein Konfigurationsmonster heran, das nach dreihundert Durchläufen niemand mehr versteht. Gelerntes fließt nur als Erfahrungswissen in die Vorschläge ein.

Wie viel Aufwand man treiben will, legt ein Budget fest. Im Parallelmodus werden mehrere Kandidaten gleichzeitig getestet. Im sequenziellen Modus folgen die Verfeinerungen aufeinander und gehen dadurch tiefer.

Bewertet wird ohne Lösungsblatt

Das ist der eigentlich spannende Teil, und er geht in der Hype-Kommunikation fast unter. Die meisten Verfahren zur Selbstverbesserung brauchen etwas, das „richtig“ und „falsch“ unterscheidet: Labels, Testfälle oder einen Verifier. Beim Programmieren funktioniert das noch, denn der Test ist grün oder rot. Ob ein juristisches Memo gelungen ist, sagt einem dagegen kein Unit-Test.

Harness² ist ausdrücklich für Aufgaben gebaut, die der Agent noch nie gesehen hat und für die es keine Musterlösung gibt. Statt gegen eine korrekte Antwort zu prüfen, vergleicht das System die Durchläufe untereinander. Gemessen wird also, welche Variante sich nachweislich besser verhalten hat, und nicht, welche „richtig“ ist. Ob dieser Vergleich auf Dauer verlässlich ist, wird sich zeigen. Der Ansatz passt aber deutlich besser zur echten Büroarbeit als die meisten Laborverfahren.

Die Zahlen - und wer sie gemessen hat

Getestet wurde auf drei Benchmarks mit Berufsbezug. Als ausführende Modelle dienten Gemini 3.5 Flash und GLM-5, jeweils in den Agenten-Umgebungen OpenCode und Codex. Das ergibt vier Kombinationen.

Benchmark	Inhalt	Ergebnis nach einem Optimierungsschritt
WorkBuddy-Bench	Büroarbeit, Web-Recherche, Programmierung (von Tencent)	bis zu +11,5 Punkte (GLM-5 mit OpenCode: von 64,2 auf 75,7)
LAB (Harvey)	juristische Aufgaben	bis zu +11,8 Prozentpunkte
JobBench	vollständige berufliche Aufgaben, etwa Unterlagen abgleichen und ein Memo dazu schreiben	Verbesserung in allen Setups; kleinster Zuwachs der gesamten Studie: +1,2 Punkte (GLM-5 mit Codex)

Ein einziger Schritt hat alle vier Kombinationen auf allen drei Benchmarks verbessert. Am stärksten haben die schwächeren Modelle profitiert. GLM-5 lag nach einem Durchgang auf WorkBuddy-Bench vor der unveränderten Gemini-3.5-Flash-Konfiguration. Auf diesem Benchmark kamen außerdem drei der vier Setups mit weniger Arbeitsschritten aus.

Jetzt der unvermeidliche Wermutstropfen: Alle Zahlen stammen von den Autoren selbst, eine unabhängige Überprüfung gibt es noch nicht. Auch die Vergleiche mit konkurrierenden Verfahren, etwa Stanfords Meta-Harness, hat das Harness²-Team selbst durchgeführt. Das muss nichts Schlechtes heißen, ist aber eben auch kein Gütesiegel.

Pikantes Detail: Der Lektor kommt von der Konkurrenz

Wer die Projektdetails liest, stößt auf eine hübsche Randnotiz. Als Editor-Modell, also als die Instanz, die die Verbesserungsvorschläge schreibt, ist standardmäßig Claude Opus 4.8 von Anthropic eingestellt. Googles Framework lässt Gemini-Agenten also von einem Modell der Konkurrenz redigieren. Man kann das als pragmatisch oder als ehrlich bezeichnen. Es zeigt jedenfalls, dass es in der Forschung offenbar eher ums Ergebnis geht als ums Logo. Und weil das Editor-Modell austauschbar ist, ist es am Ende eine Konfigurationsfrage.

Der Haken: Kosten, Sandbox und ein Agent, der seine eigenen Leitplanken umschreibt

Kostenlos ist die Selbstoptimierung nicht. Jeder Schritt bedeutet zusätzliche Durchläufe derselben Aufgabe: den Basislauf plus einen Testlauf pro Kandidat. Je höher das Budget, desto mehr Läufe. Das README warnt selbst vor den API-Kosten und empfiehlt, zunächst mit wenigen Aufgaben anzufangen. Wer das überliest, bekommt die Erkenntnis später per Rechnung.

Bei der Sicherheit wird es interessanter. Laut README hat der ausführende Agent standardmäßig uneingeschränkten Netzwerkzugriff, und Codex läuft mit deaktivierter Sandbox. Für ein Forschungswerkzeug ist das vertretbar, für den Produktivbetrieb klar nicht. Netzwerkbeschränkungen muss man selbst einrichten.

Dazu kommt eine grundsätzliche Frage. Zu den acht editierbaren Komponenten gehören auch die Guardrails. Ein Agent, der seine eigenen Leitplanken anpassen darf, braucht jemanden, der kontrolliert, was er geändert hat und warum. Harness² speichert übernommene Konfigurationen, Reflexionen und Lessons als Dateien, und das ist ein guter Anfang. Ein Prüfprozess entsteht dadurch aber noch nicht. Analysten weisen zu Recht darauf hin, dass eine Harness-Änderung im Zweifel genauso viel Risiko trägt wie ein Modell-Upgrade und genauso geprüft werden sollte.

Zum Rahmen: Das Projekt liegt in Version 0.1.0 vor, steht unter Apache-2.0-Lizenz und ist ausdrücklich als inoffizielles Google-Produkt gekennzeichnet. Der Code ist seit dem 6. Oktober auf GitHub, das Paper seit dem 9. Oktober auf arXiv. Vorausgesetzt werden Linux, Python 3.12 und der Paketmanager uv. Modellbasierte Läufe gehen über Vertex AI, eine lokale Demo läuft aber auch ohne Zugangsdaten.

Was das für Unternehmen bedeutet

Die meisten Firmen nutzen Sprachmodelle über eine API. An die Gewichte kommen sie nicht heran, Fine-Tuning ist teuer oder gar nicht vorgesehen. Das Harness ist dagegen der Teil, den man selbst in der Hand hat. Genau dort setzt Harness² an. Bestätigen sich die Ergebnisse, lässt sich ein Teil der mühsamen Prompt- und Skill-Bastelei automatisieren. In manchen Fällen bringt das so viel wie ein Wechsel auf ein größeres Modell.

Wer es ausprobieren will, sollte ein paar Dinge beachten:

• Nur in einer abgeschotteten Testumgebung laufen lassen, mit eigener Netzwerkbeschränkung und aktivierter Sandbox.
• Harness-Dateien versionieren, am besten in Git, damit jede Änderung als Diff nachvollziehbar bleibt.
• Änderungen an Guardrails nie automatisch übernehmen, sondern von einer verantwortlichen Person freigeben lassen.
• Budget und Aufgabenanzahl klein halten, bis klar ist, was ein Durchlauf tatsächlich kostet.
• Die Benchmark-Zahlen als Hinweis lesen, nicht als Versprechen. Entscheidend ist, was im eigenen Anwendungsfall herauskommt.

Und jetzt?

Harness² ist kein selbstbewusster Agent, der sich über Nacht zum Superhirn trainiert. Es ist ein sauber gedachtes Werkzeug, das die lästigste Handarbeit beim Agentenbau teilweise automatisiert, und zwar dort, wo es keine Musterlösung gibt. Das ist weniger spektakulär als die Schlagzeilen, aber deutlich nützlicher. Die nächsten Leistungssprünge bei KI-Agenten könnten also weniger aus noch größeren Modellen kommen als aus besseren Systemen drumherum. Bis dahin gilt allerdings die alte Admin-Weisheit: Wer einer Software erlaubt, ihre eigenen Regeln umzuschreiben, sollte zumindest mitlesen.

Quellen: Techstrong.ai, Pasquale Pillitteri

21.10.2026