Google Harness2 macht die Selbstverbesserung von Agenten Open Source, doch Verifikation bleibt die Bewährungsprobe

Google hat Google Harness2 als Open Source veröffentlicht, nachdem das Unternehmen durch Änderungen an der umgebenden Software eines Agenten statt an seinem Modell Verbesserungen von bis zu 11,5 Punkten berichtet hatte. Genau diese Unterscheidung erzeugt die zentrale Spannung. Das Framework ermöglicht es einem Agenten, Prompts, Tools, Speicher und weitere Betriebsanweisungen zu überarbeiten, muss diese Überarbeitungen jedoch ohne bekannte richtige Antworten beurteilen.

Das von seinen Autoren Harness² genannte Projekt stammt von Forschenden, die mit Google Cloud AI Research und der Northwestern University verbunden sind. Sein Code erschien zusammen mit einer Forschungsarbeit vom 9. Oktober 2026 und steht unter der Apache-2.0-Lizenz. Die Veröffentlichung macht aus einer Forschungsmethode Software, die Entwickler prüfen, ausführen und verändern können.

Das Projekt stellt zudem eine vertraute Annahme über KI-Agenten infrage. Bessere Ergebnisse erfordern nicht immer ein neueres oder größeres Modell. Sie können durch Veränderungen am Harness entstehen, also an der Software und den Anweisungen, die ein Sprachmodell in ein handelndes System verwandeln.

Dieses Argument setzt starre Agenten-Frameworks unter Druck. OpenCode, Codex, Claude Code und ähnliche Systeme kombinieren Modelle mit Prompts, Tools, Speicher und Orchestrierung. Google Harness2 fragt, ob diese umgebenden Komponenten nach der Bereitstellung unverändert bleiben sollten.

Die Antwort ist mehr als für Benchmark-Ranglisten relevant. Ein selbsteditierender Harness kann sich an unbekannte Rechts-, Büro-, Web- und Programmieraufgaben anpassen. Er kann jedoch auch eine falsche Annahme bewahren, eine schwächere Überarbeitung wählen oder erheblich mehr Rechenleistung für eine Antwort aufwenden.

Google Harness2 verändert die Software um ein eingefrorenes Modell

Die Veröffentlichung verlagert rekursive Verbesserung vom Modelltraining in acht editierbare Teile der Agentenlaufzeit.

Ein KI-Agent ist mehr als das Sprachmodell, das seine Prompts beantwortet. Er hängt auch von Anweisungen, verfügbaren Tools, gespeichertem Kontext, Delegationsregeln und Software ab, die jede Aktion steuert. Zusammen bilden diese Komponenten den Agenten-Harness.

Google Harness2 legt acht Komponenten zur Überarbeitung offen: den System-Prompt, Leitplanken, Speicher, Tool-Anleitungen, Subagenten, Skills, Skripte und Middleware-Plugins. Jede Komponente wird als Datei dargestellt, die in die Laufzeit eingebunden ist. Die zugrunde liegenden Modellgewichte bleiben eingefroren.

Diese Trennung ist wichtig. Das Trainieren oder Fine-Tuning eines Modells erfordert spezialisierte Infrastruktur, aufbereitete Daten und einen separaten Bereitstellungsprozess. Das Bearbeiten eines Prompts, Skills oder einer Tool-Anweisung kann erfolgen, während der Agent an einer Aufgabe arbeitet.

Das Open-Source-Repository bündelt die Methode als Python-Projekt für Linux. Es unterstützt Python 3.12, parallele und sequenzielle Verfeinerung sowie Integrationen mit OpenCode- und Codex-Executors. Die enthaltene Demonstration verwendet deterministische Editoren und lokale Python-Ausführung, sodass Entwickler den Ablauf ohne Modellzugangsdaten prüfen können.

Modellgestützte Bewertungen erfordern mehr Infrastruktur. Das Repository nennt Node.js, Google-Cloud-Authentifizierung, Modellzugriff über Vertex AI sowie benchmark-spezifische Abhängigkeiten. WorkBuddy-Bench benötigt Docker, während der Rechts-Benchmark Werkzeuge zur Dokumentenverarbeitung erfordert.

Diese Einrichtung zeigt die derzeitige Zielgruppe des Projekts. Es handelt sich um Forschungssoftware für Teams, die bereit sind, kontrollierte Bewertungen durchzuführen, nicht um eine Verbraucherfunktion, die jeden Agenten unbemerkt aufwertet. Die Veröffentlichung liefert die Mechanik für Experimente, doch Anwender benötigen weiterhin Aufgaben, Ausführungsumgebungen, Prüfinstanzen und Betriebsgrenzen.

Das Framework startet jede eingehende Aufgabe mit einem gemeinsamen Basis-Harness. Es übernimmt nicht einfach die aktuellste aufgabenspezifische Konfiguration in die nächste Aufgabe. Stattdessen verfeinert es den aktuellen Harness vorübergehend und hält wiederverwendbare Erkenntnisse in einer separaten Verbesserungsbibliothek fest.

Diese Entscheidung begegnet einem häufigen Fehler adaptiver Systeme. Eine Anweisung, die bei der Vertragsanalyse hilft, kann einer Tabellenkalkulationsaufgabe schaden. Jede erfolgreiche Änderung unmittelbar anzusammeln, würde den Harness zunehmend spezialisieren und schwerer nachvollziehbar machen.

Harness² versucht stattdessen, Belege dafür zu bewahren, warum eine Änderung geholfen hat. Eine künftige Aufgabe kann auf diese Erfahrung zurückgreifen, ohne die gesamte frühere Ausführungskonfiguration zu übernehmen.

Das Projekt steht daher für zwei Formen von Software. Ein Harness erledigt die Arbeit, während ein weiterer das System verbessert, das diese Arbeit erledigt. Diese zweite Ebene ist der Grund, warum die Autoren die Methode als rekursives Agenten-Harnessing und nicht als gewöhnliche Prompt-Optimierung beschreiben.

Für Entwickler, die Agentenanweisungen bereits manuell pflegen, formalisiert die Veröffentlichung einen vertrauten Arbeitsablauf. Teams untersuchen Fehler, überarbeiten Anweisungen, führen Aufgaben erneut aus und bewahren nützliche Techniken. Google Harness2 überträgt einen Großteil dieser Schleife an Agenten und hält die daraus entstehenden Änderungen als strukturierte Artefakte fest.

Wie Google Harness2 einen Agenten ohne richtige Antworten verfeinert

Sein Kernmechanismus vergleicht Verhalten unter abgestimmten Bedingungen, statt einen perfekten Verifizierer die richtige Ausgabe bestimmen zu lassen.

Das Framework nennt seinen zentralen Prozess auf Aufgabenebene Propose-Probe-Compose. Ein Proposer untersucht zunächst die ursprüngliche Ausführung und schlägt gezielte Änderungen am Harness vor. Ein Probe führt dieselbe Aufgabe mit diesen Kandidaten erneut aus. Anschließend kombiniert ein Composer Änderungen, die durch Unterschiede zwischen den resultierenden Trajektorien gestützt werden.

Eine Trajektorie ist die aufgezeichnete Abfolge von Modellantworten, Tool-Aufrufen, Beobachtungen und erzeugten Dateien. Sie liefert dem System mehr Belege als allein eine endgültige Antwort. Der Editor kann erkennen, ob eine Überarbeitung fehlende Eingaben gefunden, ein geeignetes Tool aufgerufen oder ein Dokument vor der Abgabe geprüft hat.

Das System unterteilt Vorschläge in zwei Bereiche. Ein Invariant-Editor konzentriert sich auf allgemeines Ausführungsverhalten, etwa auf das Prüfen von Ergebnissen nach ihrem Schreiben. Ein Domain-Editor konzentriert sich auf aufgabenspezifisches Wissen, Formate oder Verfahren.

Diese Trennung verringert die Wahrscheinlichkeit, dass jedes Problem dieselbe allgemeine Lösung erhält. Sie ermöglicht dem Composer außerdem, eine breit nützliche Prozessregel mit spezialisierter Anleitung zu verbinden, wenn beide hilfreiche Verhaltensänderungen bewirken.

Entscheidend ist, dass der Online-Prozess keinen Zugriff auf den Lösungsschlüssel des Benchmarks erhält. Die Forschungsarbeit beschreibt ein Open-World-Szenario, in dem Aufgaben eintreffen, nachdem der Harness entworfen wurde. Während der Ausführung steht möglicherweise kein zuverlässiger Ground-Truth-Verifizierer zur Verfügung.

Statt einen Kandidaten für richtig zu erklären, sucht das System nach Kontrasten. Angenommen, der Basisagent übersieht mehrere Quelldateien. Eine Überarbeitung inventarisiert jede Eingabe, während eine andere Anleitung zum Abgleich von Tabellenkalkulationen ergänzt. Ihre Trajektorien zeigen, ob diese Eingriffe den Prozess des Agenten verändert haben.

Der Composer verwendet diese Belege, um einen weiteren Harness zu erstellen und die Aufgabe erneut auszuführen. Der Ansatz beseitigt die Beurteilung nicht. Er verlagert sie vom Vergleich einer Ausgabe mit einer bekannten Antwort zum Vergleich beobachtbaren Verhaltens über mehrere Ausführungen hinweg.

Entwickler können zusätzlichen Rechenaufwand zur Testzeit auf zwei Arten einsetzen. Parallele Rekursion untersucht mehrere Kandidatenüberarbeitungen gleichzeitig und kombiniert anschließend die Belege aus diesen Versuchen. Sequenzielle Rekursion wendet nach jeder vorherigen Überarbeitung eine weitere Verfeinerung an.

Die Variable k steuert dieses Explorationsbudget. Ein größerer Wert gibt dem System mehr Gelegenheiten, Änderungen zu finden und zu testen, doch jede Gelegenheit erhöht die Anzahl der Modellaufrufe, die Tool-Nutzung und die Ausführungszeit.

Nach Abschluss der Aufgabe aktualisiert eine zweite Rekursionsebene den Harness für kontinuierliche Verbesserung. Ein Reflector speichert den übernommenen Harness und eine Erfahrungsdatei, die Eingriff, Belege und Ergebnis beschreibt. Spätere Vorschläge können diese Bibliothek konsultieren.

Dieses Design macht Erfahrung übertragbarer als einen fertigen Prompt. Eine gespeicherte Erkenntnis könnte besagen, dass Aufgaben zur Dokumenterstellung davon profitieren, fertige Dateien erneut zu öffnen und erforderliche Abschnitte zu prüfen. Dieser Prozess kann domänenübergreifend gelten, selbst wenn die konkreten Dokumente unterschiedlich sind.

Die Unterscheidung verbindet das Framework auch mit alltäglicher Wissensarbeit. Ein Agent muss möglicherweise Besprechungsnotizen, Tabellenkalkulationen, Richtlinien und Projektdokumente zusammenführen, bevor er ein Entscheidungsmemo erstellt. Der schwierige Teil besteht häufig darin, Aussagen über Quellen hinweg nachzuverfolgen, nicht darin, flüssigen Text zu erzeugen.

Teams können diese Belastung bereits durch den Aufbau einer durchsuchbaren Wissensdatenbank verringern. Harness² erweitert die Idee auf die Ausführungspolitik: Der Agent kann für eine bestimmte Aufgabe überarbeiten, wie er dieses Material sammelt, prüft und verwendet.

Der Mechanismus bleibt jedoch experimentell. Verhaltenskontrast ist ein Beleg, keine Wahrheit. Zwei Kandidaten können dieselbe falsche Prämisse teilen, und eine überzeugende Trajektorie kann dennoch zu einem schlechten Arbeitsergebnis führen.

Die Benchmark-Zugewinne setzen starre Agenten-Harnesses unter Druck

Die berichteten Ergebnisse legen nahe, dass das Harness-Design die Leistung ebenso stark verändern kann wie ein Modellwechsel, besonders bei schwächeren Ausgangssystemen.

Die Forschenden bewerteten Harness² anhand von drei professionellen Benchmarks. WorkBuddy-Bench umfasst Programmier-, Web- und Büroaufgaben. JobBench testet professionelle Arbeit, während Harvey’s Legal Agent Benchmark die Leistung bei Rechtsaufgaben misst.

Die Tests umfassten vier Kombinationen aus zwei Modellen und zwei Ausgangs-Harnesses. Die Modelle waren Gemini 3.5 Flash und GLM-5. Die anfänglichen Ausführungs-Harnesses waren OpenCode und Codex, während Claude Opus 4.8 in den Hauptexperimenten als Standard-Editor diente.

Nach Angaben der Autoren verbesserte ein einzelner Verfeinerungsschritt jede getestete Modell- und Harness-Kombination über alle drei Benchmarks hinweg. Die größten berichteten Zugewinne erreichten 11,5 Punkte bei WorkBuddy-Bench, 4,5 Punkte bei JobBench und 11,8 Prozentpunkte bei der Teilbestehensrate des Rechts-Benchmarks.

Die größte Veränderung bei WorkBuddy-Bench zeigte sich mit GLM-5 unter OpenCode. Sein Durchschnittswert stieg nach einem Schritt von 64,2 auf 75,7. Gemini 3.5 Flash unter OpenCode stieg von 72,4 auf 77,5.

Diese Zahlen stützen eine praktische Schlussfolgerung. Der Harness kann einen Teil der Lücke zwischen Modellen schließen, indem er Ausführungsverhalten korrigiert, das die reine Modellfähigkeit nicht löst.

Die Ergebnisse variierten je nach Konfiguration. GLM-5 unter Codex gewann bei JobBench lediglich 1,2 Punkte und stieg von 23,6 auf 24,8. Gemini unter OpenCode verbesserte sich beim selben Benchmark um 4,5 Punkte.

Diese Variation ist wichtiger als die höchste Schlagzeilenzahl. Die Methode erzielte nicht bei jedem Modell, Harness und jeder Aufgabe eine einheitliche Verbesserung. Ihr Wert hing vom Ausgangssystem und der Domäne ab.

Die Forschenden erhöhten außerdem das Rekursionsbudget. Mit Gemini unter OpenCode steigerte der Wechsel von einem Verfeinerungsschritt zu paralleler Rekursion bei k=5 die WorkBuddy-Bench-Leistung weiter. Programmierung erreichte 80,8, Web 81,7 und Büro 83,4.

Die Arbeit berichtet, dass sowohl parallele als auch sequenzielle Werte stiegen, als das Budget in ausgewählten WorkBuddy-Bench-Domänen von eins auf fünf erhöht wurde. Konkurrenzmethoden zeigten in diesen Tests geringere oder weniger konsistente Veränderungen.

Mehr Exploration war nicht die ganze Erklärung. In einer Ablationsstudie verringerte das Entfernen der Verbesserungsbibliothek die durchschnittliche WorkBuddy-Bench-Leistung um 3,1 Punkte. Das Entfernen bereichsspezifischer Editorrollen kostete 2,9 Punkte, während das Überspringen der Komposition 1,6 Punkte kostete.

JobBench zeigte ein ähnliches Muster. Das Entfernen der Bibliothek verringerte den Wert um 1,8 Punkte, generische Editoren verloren 3,7 Punkte und das Weglassen der Komposition 1,9 Punkte. Diese Ergebnisse deuten darauf hin, dass bewahrte Erfahrung, spezialisierte Vorschläge und evidenzbasierte Kombination jeweils beitrugen.

Eine JobBench-Fallstudie veranschaulicht den Mechanismus. Der Basisagent konnte Informationen aus Quelldateien nicht zusammenführen und öffnete seine endgültige Ausgabe nicht erneut zur Überprüfung. Sein Wert lag bei 43,1.

Eine vorgeschlagene Intervention verlangte eine Bestandsaufnahme aller Eingaben und eine explizite Quellennachverfolgung. Eine weitere ergänzte Fachanweisungen zur Abstimmung von Zeitplan, Veranstaltungsort, Personal und Budget. Der Composer übernahm alle vier durch diese Interventionen eingeführten Änderungen, und der erneute Durchlauf erreichte 77,8.

Dieses Beispiel stärkt das Argument für die Verbesserung des Agent Harness, weil der Fehler prozedural war. Dem Modell fehlten weder grundlegende Sprachfähigkeiten noch der Zugriff auf die Dateien. Es fehlte ihm eine zuverlässige Arbeitsmethode.

Unveränderte Harnesses erzielten in verschiedenen Bereichen weiterhin unterschiedliche Ergebnisse. Der Vergleich der Studie ergab, dass Claude Code unter den festen Systemen bei Code- und Office-Aufgaben führte, während Codex bei Web-Aufgaben vorne lag. Kein unverändertes Harness führte überall.

Ausgehend von OpenCode mit einem größeren Rekursionsbudget übertraf Harness² die stärkste feste Alternative um 4,6 Punkte bei Code, 5,8 bei Web und 4,9 bei Office. Die Autoren weisen ausdrücklich darauf hin, dass dieses adaptive Ergebnis zusätzliche Rechenleistung zur Testzeit nutzte.

Der Wettbewerbsdruck richtet sich daher gegen den Ansatz fester Harnesses, nicht gegen ein bestimmtes Produkt. Ein Anbieter kann sein Modell verbessern, doch Nutzer erhalten möglicherweise weiterhin uneinheitliche Ergebnisse, wenn die umgebenden Anweisungen und Tools sich nicht anpassen können.

Selbstverbessernde Agent Harnesses benötigen weiterhin unabhängige Kontrollen

Harness² kann den Prozess eines Agenten verbessern, doch die eigenen Belege zeigen, dass rekursive Änderungen mitunter schlechteres Verhalten auswählen oder eine falsche Annahme verbreiten.

Die Benchmark-Ergebnisse stammen von den Autoren des Projekts und belegen noch keine Produktionszuverlässigkeit über unabhängige Bereitstellungen hinweg. Die Studie berichtet Mittelwerte aus drei Durchläufen, was bei der Messung von Variabilität hilft, aber keine externe Replikation ersetzt.

Die Methode verbraucht zudem zusätzliche Rechenleistung, bevor sie ihre endgültige Ausgabe liefert. Jeder Vorschlag, Probe, jede Komposition und jeder erneute Durchlauf beansprucht Tokens und Ausführungszeit. Parallele Verarbeitung kann die verstrichene Zeit verringern, wenn Kapazität verfügbar ist, beseitigt jedoch nicht die zugrunde liegenden Ressourcenkosten.

Die Studie ordnet evaluierte Konfigurationen auf einer empirischen Compute-Performance-Grenzlinie für JobBench und WorkBuddy-Bench ein. Dieses Ergebnis bedeutet, dass die gemessenen Verbesserungen im Vergleich zu getesteten Alternativen vorteilhaft ausfielen. Es bedeutet nicht, dass Rekursion für jede Produktionslast wirtschaftlich sein wird.

Eine Aufgabe mit geringem Wert rechtfertigt möglicherweise nicht mehrere Modellausführungen. Ein Rechtsgutachten oder eine operative Entscheidung könnte mehr Kontrolle rechtfertigen, doch diese Bereiche verlangen auch strengere Kontrollen, als ein Benchmark-Runner bietet.

Die wichtigste Warnung stammt aus der eigenen Fehleranalyse der Autoren. Sie untersuchten neun Verschlechterungen und ordneten sie Fehlern bei der Kandidatenauswahl, gemeinsamen falschen Prämissen sowie Unsicherheit bei Bewertung oder Ausführung zu.

In einem Coding-Beispiel wählte das Framework eine Ausgabe mit einem Wert von 55 gegenüber einer Alternative mit 95. Bei einer Rechtsaufgabe verringerte eine engere Überarbeitung die Abdeckung und senkte den Wert von 54 auf 26.

Andere Fehler begannen mit einer falschen Annahme, die von mehreren Kandidaten geteilt wurde. Diese Fehler führten zu Verlusten zwischen 2 und 11 Punkten. Wenn jede vorgeschlagene Änderung dieselbe falsche Prämisse akzeptiert, legt der Vergleich ihres Verhaltens den ursprünglichen Fehler nicht offen.

Die Studie nennt auch fehlende Entscheidungen von Bewertungsinstanzen und gewöhnliche Schwankungen zwischen Durchläufen als Zuordnungsprobleme. Ein veränderter Wert kann die Änderung, stochastische Ausführung oder Bewertungsrauschen widerspiegeln. Mehr Proben helfen, erhöhen aber die Kosten.

Die Repository-Aktivität hat zudem Implementierungsrisiken sichtbar gemacht. Ein offenes Problem zur Cache-Identität berichtet, dass fortgesetzte Experimente frühere Ausgaben wiederverwenden können, nachdem sich Aufgabenanweisungen oder Quelldateien ändern, während Aufgabenkennungen konstant bleiben.

Der Autor des Issues reproduzierte das Verhalten ohne Modellaufrufe und stellte fest, dass Eingabeinhalte in Teilen der gespeicherten Laufidentität fehlen. Der Bericht quantifiziert keine Auswirkungen auf veröffentlichte Benchmark-Werte, und zum Zeitpunkt der Prüfung war keine Lösung durch Maintainer angehängt.

Dennoch veranschaulicht das Issue die umfassendere operative Herausforderung. Ein rekursives System benötigt eine zuverlässige Herkunftsnachverfolgung für Aufgaben, Quellmaterial, Harness-Revisionen, zwischengespeicherte Ausgaben und Bewertungseinstellungen. Andernfalls kann eine scheinbare Verbesserung auf veralteten Belegen beruhen.

Sicherheit schafft eine weitere Sorge. Die acht bearbeitbaren Komponenten umfassen Guardrails, Skripte, Plugins und Tool-Anweisungen. Diese Dateien können beeinflussen, worauf ein Agent zugreift und welche Aktionen er ausführt.

Ein autonomer Editor sollte keine uneingeschränkte Befugnis erhalten, Zugriffskontrollen zu schwächen, ungeprüfte Skripte auszuführen oder sensible Aufgabendetails dauerhaft zu speichern. Der Produktionseinsatz benötigt Berechtigungen auf Komponentenebene, unveränderliche Sicherheitsgrenzen, Audit-Logs und Rollback.

Auch persistente Erfahrung verdient ähnliche Vorsicht. Eine nützliche Erkenntnis aus einem Kundenfall, einer Abteilung oder einer Rechtsangelegenheit kann vertrauliche Informationen offenlegen, wenn sie für einen anderen Fall abgerufen wird. Eine Verbesserungsbibliothek benötigt daher Datenisolation und Aufbewahrungsrichtlinien, nicht nur semantische Relevanz.

Teams sollten zudem Leistungsoptimierung von Sicherheitsvalidierung unterscheiden. Ein Benchmark-Wert belohnt die Aufgabenerledigung unter seinem Evaluator. Er misst nicht automatisch Datenschutz, Autorisierung, faktische Genauigkeit oder Widerstandsfähigkeit gegen bösartige Eingaben.

Google Harness2 selbst zeigt, warum diese Unterscheidung wichtig ist. Sein Composer kann einen verhaltensmäßig überzeugenden Kandidaten bevorzugen, der objektiv schwächer ist. Das Fehlen einer Ground Truth ist das Problem, das das Framework adressiert, bleibt jedoch eine Grenze, die das Framework nicht beseitigen kann.

Ein sinnvolles Produktionsdesign würde dem System erlauben, risikoärmere Anleitungen zu ändern, während Kernrichtlinien geschützt bleiben. Prompt-Formulierungen und Workflow-Checklisten könnten bearbeitbar sein. Regeln für Zugangsdaten, Netzwerkgrenzen, Genehmigungsschranken und Grenzen für destruktive Aktionen sollten außerhalb der Befugnis des Agenten bleiben.

Menschliche Prüfung bleibt auch für vorgeschlagene Änderungen wertvoll, die aufgabenübergreifend bestehen bleiben. Das Framework kann Belege erzeugen, die erläutern, warum eine Änderung übernommen wurde. Betreiber können diese Aufzeichnung nutzen, um die Änderung zu genehmigen, abzulehnen oder einzuschränken, bevor sie in eine gemeinsame Bibliothek aufgenommen wird.

Rekursive Agent Harnesses verändern die Roadmap des Agent Engineering

Der nächste Test besteht darin, ob Organisationen die Gewinne reproduzieren können, während sie Rechenaufwand, Regressionen und persistenten Speicher kontrollieren.

Das erste zu beobachtende Signal ist eine unabhängige Replikation der Benchmarks. Das Repository stellt Code, Konfigurationen, Prompts und Evaluierungsbefehle bereit und gibt externen Teams damit einen praktischen Ausgangspunkt. Reproduktionen sollten sowohl Endwerte als auch den gesamten Modellverbrauch berichten.

Eine erfolgreiche Replikation über verschiedene Anbieter hinweg würde die zentrale Behauptung stärken. Sie würde zeigen, dass adaptives Harnessing nicht eng an die getesteten Modelle, den Editor oder die Google Cloud-Umgebung gebunden ist.

Ein Ausbleiben der Reproduktion der Gewinne würde den Anspruch auf Allgemeingültigkeit schwächen. Forschende müssten ermitteln, ob der Unterschied aus Modellverhalten, Benchmark-Versionen, Ausführungsumgebungen oder Bewertungseinstellungen entstand.

Das zweite Signal ist die Leistung auf realen Aufgabenströmen statt auf isolierten Benchmark-Durchläufen. Rekursion auf Harness-Ebene verspricht kumulativen Nutzen, weil Erkenntnisse aus früheren Aufgaben spätere Vorschläge leiten.

Die Studie liefert erste Hinweise auf einen solchen Transfer. Eine auf JobBench aufgebaute Erfahrungsbibliothek verbesserte die Ein-Schritt-Verfeinerung auf WorkBuddy-Bench um 0,6 Punkte bei Code, 0,5 bei Web und 2,9 bei Office.

Diese Gewinne sind geringer als die stärksten Ergebnisse auf Aufgabenebene, und eine Analyse nutzte Erfahrungen aus späteren Aufgaben rückblickend. Eine Live-Bereitstellung sollte zeigen, dass nützliche Erkenntnisse sich in chronologischer Reihenfolge ansammeln, ohne zukünftige Informationen zu importieren.

Betreiber sollten Regressionsraten neben der durchschnittlichen Leistung messen. Sie sollten außerdem Interventionshäufigkeit, Latenz, Modellverbrauch und den Anteil persistenter Änderungen verfolgen, die eine menschliche Prüfung bestehen.

Das dritte Signal ist eine stärkere Ebene für Verifikation und Governance. Die Autoren empfehlen Proben, die gemeinsame Annahmen herausfordern, wiederholte Ausführung zur Trennung von Änderungen und Variabilität sowie bessere Auswahlmethoden, die Abdeckung und Präzision ausbalancieren.

Repository-Korrekturen können einen weiteren Indikator liefern. Inhaltsbewusste Cache-Identitäten, festgeschriebene Benchmark-Revisionen und zuverlässige Invalidierung würden Experimente leichter reproduzierbar machen. Klare Sicherheitsgrenzen für bearbeitbare Komponenten würden Bereitstellungen sicherer machen.

Das breitere Forschungsfeld wird auch alternative Formen der Harness-Anpassung testen. Meta-Harness sucht vor der Bereitstellung nach Konfigurationen. ReasoningBank ruft nützliche Reasoning-Erfahrung ab, während das Harness unverändert bleibt. Harness Scaling überarbeitet ein Harness für einzelne Aufgaben.

Harness² kombiniert Online-Aufgabenanpassung mit einem persistenten Verbesserungsmechanismus. Diese Kombination ist sein wichtigstes Unterscheidungsmerkmal, bündelt aber auch Risiken. Eine schlechte Revision auf Aufgabenebene beeinflusst ein Ergebnis, während eine schlechte beibehaltene Erkenntnis spätere Aufgaben beeinflussen kann.

Für Entwickler lautet die praktische Botschaft nicht, dass jeder Agent sich sofort selbst umschreiben sollte. Sie lautet, dass Prompts, Speicher, Tools und Orchestrierung als zusammenhängendes System evaluiert werden sollten.

Teams können mit begrenzten Experimenten beginnen. Sie können repräsentative Aufgaben auswählen, ein unveränderliches Basis-Harness bewahren, Revisionen nur in einer Sandbox zulassen und die Ausgabequalität mit dem gesamten Rechenaufwand vergleichen. Jede persistente Änderung sollte nachvollziehbar und reversibel bleiben.

Wissensarbeiter sollten sich dafür interessieren, weil die Harness-Qualität das sichtbare Agentenverhalten prägt. Ein Modell kann unzuverlässig erscheinen, wenn seine Tool-Anweisungen schwach sind, sein Speicher verrauscht ist oder sein Workflow keine Überprüfung umfasst. Umgekehrt kann ein besseres Verfahren Ergebnisse verbessern, ohne das Modell zu ändern.

Die offene Veröffentlichung macht diese Hypothesen überprüfbar. Sie gibt Forschenden eine gemeinsame Implementierung, um zu untersuchen, wie Agenten Fehler diagnostizieren, Betriebsanweisungen überarbeiten und Erfahrungen bewahren.

Google Harness2 verschiebt die Debatte über Selbstverbesserung letztlich von abstrakter Modellintelligenz zu überprüfbaren Softwareartefakten. Das ist eine nützliche Verschiebung, weil Teams Dateien prüfen, Revisionen nachverfolgen und Ausführungen messen können.

Sie löst nicht die schwierigste Frage: Wer überprüft den Verbesserer, wenn kein Lösungsschlüssel existiert? Das Framework ersetzt blindes Bearbeiten durch strukturierte Verhaltensbelege, doch Belege können weiterhin in die Irre führen.

Achten Sie in den nächsten Monaten auf unabhängige Replikationen, Live-Ergebnisse über mehrere Aufgaben hinweg und strengere Kontrollen rund um bearbeitbare Komponenten. Diese Signale werden bestimmen, ob rekursives Agent Harnessing zu einer zuverlässigen Engineering-Schicht wird oder ein vielversprechender Forschungsworkflow bleibt.

Für Teams, die KI-Agenten jetzt evaluieren, ist die unmittelbare Maßnahme einfach. Testen Sie das Modell und sein Harness getrennt, dokumentieren Sie jede Änderung und verlangen Sie klare Belege, bevor Sie eine automatisierte Revision beibehalten. Google Harness2 bietet einen konkreten Rahmen für dieses Experiment, während die berichteten Fehler zeigen, warum Aufsicht weiterhin wichtig ist.