Google Harness²: Einrichtung, Benchmarks und echte Kosten

Zurück

Kevin Riedl

14 min Lesezeit · 16. Okt. 2026
Zuletzt geprüft 16. Oktober 2026

Weiter

Dein KI-Agent braucht vielleicht kein klügeres Modell. Vielleicht braucht er eine bessere Arbeitsweise.

Das ist die spannende Idee hinter Google Harness². Statt einen Agenten nur erneut versuchen zu lassen, verändert das Framework seine Anweisungen, Werkzeuge und wiederverwendbaren Abläufe. Es testet Alternativen und hält Erkenntnisse für spätere Aufgaben fest.

Das Potenzial ist real. Die Kurzfassung auf Social Media lässt jedoch Wichtiges aus. Harness² ist kein fertiger No-Code-Büroassistent. Bessere Benchmark-Ergebnisse garantieren keinen Produktivitätsgewinn. Und eine veränderbare Datei mit Sicherheitsregeln ist noch keine Sicherheitsgrenze.

Dieser Leitfaden trennt diese Fragen: Was hat Google veröffentlicht? Was bedeuten die Zahlen? Was kostet die Rekursion? Und wie lässt sich ein erster Test angehen, ohne einem experimentellen Agenten die Zugangsdaten des Unternehmens zu überlassen?

Quellenstand: 16. Oktober 2026. Die folgenden Befehle wurden anhand des fixierten Quellcodes geprüft, nicht als modellgestützte Experimente ausgeführt. Die Benchmark-Ergebnisse stammen von den Autoren, nicht aus Wavect-Messungen.

Was ist Google Harness²?

Google Harness², auch Harness2 geschrieben, ist ein Forschungsframework unter Apache-2.0. Es verbessert die Ausführungsumgebung eines KI-Agenten für unbekannte Aufgaben, während die Modellgewichte unverändert bleiben. Dazu verbindet es aufgabenbezogene Experimente mit einer dauerhaften Bibliothek, die spätere Verbesserungen unterstützt. Das offizielle Repository unterstützt OpenCode und Codex als ausführende Agentenumgebungen sowie drei Benchmark-Familien. Es weist ausdrücklich darauf hin, dass das Projekt kein offiziell unterstütztes Google-Produkt ist.

Ein Harness ist das Arbeitssystem um das Modell: Anweisungen, Werkzeuge, Gedächtnis und Ausführungslogik. Harness² verändert dieses System, nicht die trainierten Parameter des Modells. Laut Paketmetadaten trägt der geprüfte Code die Version 0.1.0 und unterstützt Python 3.12 oder 3.13.

„Open World“ beschreibt Aufgaben, die beim Entwurf des Harness noch nicht vorgesehen waren. Es bedeutet weder, dass uneingeschränkter Internetzugang notwendig ist, noch dass jede unbekannte Aufgabe lösbar oder jedes Ergebnis korrekt ist.

Die grundlegende Architektur erklärt unser Leitfaden zu KI-Agent-Harnesses. Hier geht es gezielt um Googles rekursiven Ansatz und die Entscheidung, ihn praktisch zu evaluieren.

Wie rekursives Harnessing funktioniert

Harness² verbindet zwei Schleifen. Der Methodenteil des Papers beschreibt für die aktuelle Aufgabe einen Schritt aus Propose, Probe, Compose: Änderungen vorschlagen, erproben und zusammenführen. Anschließend können daraus Erkenntnisse für spätere Aufgaben entstehen.

Zuerst zeigt ein Referenzdurchlauf, wie sich der ursprüngliche Harness verhält. Das System schlägt eine allgemeine Verbesserung vor, etwa eine bessere Werkzeugnutzung, und eine aufgabenspezifische, etwa ein geeigneteres Prüfverfahren. Beide Varianten bearbeiten dieselbe Aufgabe mit identischem ausführendem Modell und gleicher Umgebungskonfiguration. Aus den beobachteten Unterschieden wird ein überarbeiteter Harness zusammengestellt und ebenfalls ausgeführt.

Ein hypothetisches Beispiel ist der Abgleich zweier Tabellen. Eine Variante könnte die Arbeitsplanung verbessern. Die andere ergänzt ein wiederverwendbares Abgleichskript. Der Vergleich soll zeigen, welche Änderung das beobachtete Verhalten verbessert, statt nur einer überzeugenden Erklärung zu vertrauen. Das ist eine Illustration, keine getestete Harness²-Integration.

Die zweite Schleife speichert übernommene Harnesses und durch Beobachtungen gestützte Erkenntnisse, unter anderem in einer Datei namens EXPERIENCE.md. Sie fließen in spätere Vorschläge ein. Entscheidend: Jede neue Aufgabe startet trotzdem mit demselben ursprünglichen Ausführungsharness. Sie übernimmt nicht automatisch alle Änderungen der vorherigen Aufgabe. Fehlt ausreichende Evidenz, kann die Reflexion auf einen neuen Erfahrungseintrag verzichten.

Für Unternehmen ist das eine wichtige Unterscheidung. Hier entsteht Lernen durch dauerhaft gespeicherte Artefakte und bessere Konfiguration, nicht durch laufendes Modelltraining. Der Verhaltensvergleich ist auch keine unabhängige Richtigkeitsprüfung: Mehrere Durchläufe können denselben Denkfehler machen.

Die acht veränderbaren Komponenten

Unsere Regel für den Betrieb: Das System darf seine Arbeitsweise verbessern. Seine Befugnisse bleiben außerhalb des veränderbaren Harness. Eine Datei mit „Keine Kundendaten exportieren“ sollte nicht die einzige Exportkontrolle sein.

Was bedeuten die Ergebnisse von +11,5 und +4,5 Punkten?

Die häufig genannten Verbesserungen stehen tatsächlich in den Tabellen der Autoren. Es sind jedoch Maximalwerte aus unterschiedlichen Modell-Harness-Konfigurationen, kein universeller Leistungsschub. Die Hauptergebnisse und der Versuchsaufbau nennen Mittelwerte aus drei Durchläufen mit jeweils gemischter Aufgabenreihenfolge. Die folgenden Vergleiche nutzen einen Verbesserungsschritt, also k=1.

Die WorkBuddy-Zahl bedeutet nicht, dass jede Büroaufgabe um 11,5 Prozent besser wird. Für Gemini 3.5 Flash unter OpenCode steigt der dortige Mittelwert von 72,4 auf 77,5, also um 5,1 Punkte. Der konkrete Ausgangspunkt zählt.

Ein weiteres leicht übersehenes Detail: Als Standardeditor für den Harness verwendet das Hauptexperiment Claude Opus 4.8, auch wenn Gemini oder GLM-5 die Aufgabe ausführt. Vor und nach der Verbesserung wird dasselbe unveränderte Ausführungsmodell verglichen. Daraus folgt nicht, dass die gesamte Verbesserungskette ausschließlich dieses Modell nutzt. Das Paper untersucht separat auch Fälle mit identischem Ausführungsmodell und Editor.

Die Zeilen + Recursion zeigen zusätzliche Änderungen bei paralleler Rekursion mit k=5. Sie gehören nicht zum einfachen Ein-Schritt-Ergebnis. Auch Maximalwerte aus unterschiedlichen Zeilen dürfen nicht zu einer erfundenen Bestkonfiguration vermischt werden.

Die positive Schlussfolgerung ist enger und hilfreicher: Das Paper liefert Belege dafür, dass eine andere Arbeitsweise die Ergebnisse vorhandener Modelle in mehreren professionellen Benchmarks verbessern kann. Eure produktive Abnahmequote, Betriebskosten oder den nötigen menschlichen Prüfaufwand weist es damit nicht nach.

Was kostet der Betrieb von Harness²?

Die Lizenz ist nicht die Betriebsrechnung. Bei einem rekursiven Durchlauf zahlt man auch für die Erkundung von Alternativen, nicht nur für das ausgelieferte Ergebnis.

Das dokumentierte parallele Verfahren umfasst k Referenzdurchläufe, k allgemeine Varianten, k domänenspezifische Varianten und k Durchläufe mit zusammengesetztem Harness. Zusammen sind das 4k Ausführungsdurchläufe: vier bei k=1, zwanzig bei k=5. Diese Anzahl ist aus dem Algorithmus abgeleitet, keine gemessene Vervierfachung oder Verzwanzigfachung der Rechnung.

Editor, Zusammenführung, Reflexion, gegebenenfalls die abschließende Auswahl und die separate Bewertung verursachen zusätzlichen Aufwand. Tokenlängen, Caching, Modellpreise, Fehler und Wiederholungen bestimmen die tatsächlichen Kosten. Parallele Ausführung kann bei ausreichender Kapazität die Wartezeit verkürzen. Kostenlos werden die Aufrufe dadurch nicht.

Das Paper ignoriert diesen Punkt nicht. Seine Analyse des Rechenaufwands erfasst die vor der Auslieferung verbrauchten Tokens einschließlich Ausführung und Verbesserung. Unter den verglichenen Konfigurationen ergibt sich ein günstiges Verhältnis von Qualität und Rechenaufwand. Die Spalte mit Ausführungsschritten in den Haupttabellen ist aber keine vollständige Betriebskostenrechnung. Token-Effizienz im Benchmark ersetzt keinen Business Case in Euro.

Kosten pro abgenommenem Ergebnis messen

Für den unveränderten Harness und Harness² müssen dieselben unabhängig festgelegten Abnahmekriterien gelten:

Kosten pro abgenommenem Ergebnis = sämtliche Kosten für Ausführung, Verbesserungsmodelle, Bewertung, Infrastruktur und menschliche Prüfung der untersuchten Aufgabenmenge / unabhängig abgenommene Ergebnisse.

Jeden Kostenbestandteil nur einmal zählen. Wird kein Ergebnis abgenommen, darf kein endlicher Stückpreis ausgewiesen werden.

Hier erledigt die rekursive Variante mehr Aufgaben erfolgreich, ist pro abgenommenem Ergebnis aber teurer. Bei wertvolleren Ergebnissen oder kürzerer Durchlaufzeit kann sie sich trotzdem lohnen. Wichtig ist, diese Abwägung bewusst zu treffen, statt höhere Benchmark-Scores mit automatischer Ersparnis gleichzusetzen.

Ein allgemeineres Betriebsmodell bietet unser Artikel zu KI-Agent-Kosten pro Aktion. Im Harness²-Test bleibt die Frage: Kaufen zusätzliche Versuche ausreichend mehr brauchbare Arbeit?

Ist Harness² sicher für Unternehmenssysteme?

Nicht allein aufgrund der mitgelieferten Forschungsumgebung. Der Experimentleitfaden sagt ausdrücklich, dass die Veröffentlichung den Netzwerkzugang der ausführenden Agenten nicht einschränkt und Codex mit deaktivierter Sandbox läuft.

Außerdem dokumentiert er einen Validierungsdurchlauf, bei dem Codex ohne entsprechende Anweisung die öffentlich verfügbare Bewertungsrubrik seiner JobBench-Aufgabe heruntergeladen hat. Das ist eine konkrete Warnung für Reproduktionen. Es ist kein Beleg dafür, dass die ursprünglichen Hauptergebnisse des Papers kontaminiert sind.

Zwei Risiken müssen getrennt bleiben. Findet ein Benchmark-Agent seinen Lösungsschlüssel, leidet die Aussagekraft der Evaluation. Erreicht er echte Zugangsdaten, fremde Dateien oder externe Systeme, gefährdet er seine Umgebung. Ein zusätzlicher Satz in guardrails.md löst keines von beiden.

Für den ersten Test empfehlen wir eine isolierte, wegwerfbare Umgebung, synthetische oder bereinigte Dateien, eingeschränkte Modellzugänge, extern erzwungene Regeln für ausgehenden Netzwerkverkehr und ein Budget, das der Agent nicht erhöhen kann. Persönliche Cloud-Profile, Produktionsgeheimnisse, sensible Home-Verzeichnisse und ein uneingeschränkter Docker-Socket des Hosts gehören nicht in seine Umgebung.

Für Benchmarks brauchen Installation und Ausführung unterschiedliche Netzwerkregeln: Die Einrichtung lädt Abhängigkeiten herunter. Die spätere Ausführung darf dagegen keine öffentlichen Lösungen oder Bewertungskriterien abrufen. Prüft die Sperren praktisch, statt ihre Wirksamkeit aus einer Konfigurationsdatei abzuleiten.

Auch gespeicherte Erkenntnisse sollten vor der Wiederverwendung geprüft werden. Eine nach Fachgebieten geordnete Bibliothek ist nicht automatisch eine Grenze zwischen Kundendaten. Mandantentrennung, Aufbewahrung, Artefaktzugriff und Löschung müssen außerhalb des Ermessens des Modells liegen. Generierte Skripte, Plugins und Ergebnisse bleiben bis zur Prüfung nicht vertrauenswürdig.

Google Harness² ausprobieren, ohne sofort einen bezahlten Benchmark zu starten

Der Einrichtungsleitfaden empfiehlt Linux und Python 3.12 für Benchmarks. Modellgestützte Durchläufe brauchen zusätzlich Node.js ab Version 20, die Google Cloud CLI und Zugriff auf die konfigurierten Modelle. LAB benötigt Werkzeuge zur Dokumentverarbeitung, WorkBuddy zusätzlich Docker.

Das ist eine Einrichtung für Entwickler, keine No-Code-Registrierung. Auch ohne Programmierkenntnisse lässt sich eine Aufgabe definieren und ihr Nutzen beurteilen. Für Laufzeitumgebung, Zugangsdaten, Isolation und Fehlerbehandlung braucht es trotzdem einen Verantwortlichen.

Mit der Demonstration ohne Modellzugang beginnen

In einer isolierten Linux-Testumgebung lautet die anhand des Quellcodes geprüfte Befehlsfolge:

git clone https://github.com/google-research/harness2.git
cd harness2
git checkout 1cfe254e8d25b15f37048c3730134686abe60335
uv venv --python 3.12 .venv
source .venv/bin/activate
uv pip install -e '.[render]'
harness2-demo --output runs/demo --k 2

Damit wird der geprüfte Repository-Stand fixiert. Die Demonstration nutzt deterministische Editoren und echte Python-Ausführung, aber keine Modellzugangsdaten. Sie zeigt die Mechanik der Rekursion, nicht den Benchmark-Leistungsgewinn eines Sprachmodells. Die Installation der Umgebung und ihrer Abhängigkeiten benötigt weiterhin Netzwerkzugang.

Einen eng begrenzten modellgestützten Durchlauf vorbereiten

Erst fortfahren, wenn ein eingeschränktes Cloud-Projekt, die gewünschten Ausführungs-, Verbesserungs- und Bewertungsmodelle sowie die externen Schutzmaßnahmen eingerichtet sind. Die Standardeinstellungen reproduzieren nicht automatisch jede Konfiguration des Papers. Prüft .env.example; der dokumentierte Vertex-Weg nutzt Application Default Credentials.

Der Benchmark-Leitfaden trennt die Einrichtung von JobBench, LAB und WorkBuddy. Datensätze und Drittanbietercode behalten ihre eigenen Bedingungen. Insbesondere hat WorkBuddy eine eigene Lizenz mit territorialer Einschränkung. Diese vor dem Download prüfen; die Apache-Lizenz von Harness² setzt sie nicht außer Kraft.

Das folgende LAB-Beispiel wählt genau ein benanntes Fachgebiet und zeigt eine Vorschau für höchstens eine Aufgabe daraus:

export HARNESS2_RUNS_DIR=runs/lab-first-k1
harness2-setup lab
harness2-check --bench lab
harness2 --bench lab --k 1 --mode parallel --seed 42 \
  --only-domains antitrust-competition --max-tasks 1 \
  --workers 1 --dry-run

harness2-check prüft Abhängigkeiten, Zugangsdaten und Konfiguration ohne Modellaufruf. Es bestätigt nicht die Verfügbarkeit jedes ausgewählten Modells. --dry-run zeigt die Aufgabenauswahl ebenfalls ohne Modellaufrufe.

Die wichtige Grenze lautet --max-tasks: Sie gilt pro Fachgebiet, nicht für den gesamten Durchlauf. Für diesen ersten Versuch deshalb genau einen Wert mit --only-domains auswählen. --workers 1 begrenzt die gleichzeitig bearbeiteten Fachgebiete, nicht die gesamte API-Rechnung. Zusätzlich ein externes Ausgabenlimit verwenden.

Ohne --dry-run beginnt kostenpflichtige Modellarbeit. Diese Grenze bleibt sichtbar, wenn Ausführung und Bewertung getrennt werden:

harness2 --bench lab --k 1 --mode parallel --seed 42 \
  --only-domains antitrust-competition --max-tasks 1 --workers 1
harness2-judge --bench lab --k 1 --mode parallel --seed 42
harness2-report --bench lab --k 1 --mode parallel --seed 42

Bei Bewertung und Bericht müssen Benchmark, ausführende Umgebung, gegebenenfalls Teilmenge, Rekursionsbudget, Modus und Seed übereinstimmen. Der Seed mischt die Aufgaben, fixiert aber nicht das Modell-Sampling. Bei anderen Modellen oder einer geänderten Aufgabenauswahl ein neues Ausgabeverzeichnis verwenden. Die passende Bewertungsanweisung mit --bases bewertet Referenzdurchläufe; der Standardbericht behandelt die verbesserten Ergebnisse.

Diese Benchmark-Schnittstelle ist kein fertiger Anschluss an eure Büroprozesse. Eine echte Unternehmensaufgabe benötigt weiterhin einen passenden Adapter, Datenzugriff, Abnahmetests und operative Verantwortung.

Ein Pilot, der eine Einführung rechtfertigen kann

Vor einer Erhöhung von k zählt, ob die Verbesserung außerhalb der eigenen Reflexion des Systems nützlich ist. Anthropics Leitfaden zur Agenten-Evaluation unterscheidet zwischen einem Ausführungsprotokoll und dem tatsächlichen Ergebnis in der Umgebung. Genau darum geht es: Eine selbstbewusste Erfolgsmeldung ist weder eine abgeglichene Tabelle noch ein korrekt aktualisierter Datensatz.

Unsere vorgeschlagene Abnahmematrix verlangt deshalb mehr als eine funktionierende Demo:

Fehlgeschlagene Bewertungen bleiben in der Veröffentlichung unbewertet, statt als null gezählt zu werden. Diese Abdeckung ausdrücklich ausweisen. Ein Score nur für erfolgreich bewertete Aufgaben kann Betriebsfehler verdecken.

Prüft außerdem, wann Rekursion gar nicht laufen sollte. Ein günstiges deterministisches Skript kann eine stabile Transformation bereits zuverlässig erledigen. Zusätzliche Modellaufrufe für mehrdeutige, wertvolle Aufgaben aufzusparen, ist eine sinnvolle Pilothypothese, keine automatisch eingerichtete Funktion.

Wo Harness² in ein Wavect-Projekt passt

Harness² ist interessant, wenn wertvolle wiederkehrende Aufgaben zu unterschiedlich für ein einziges starres Verfahren sind, ihre Ergebnisse sich aber noch sinnvoll beurteilen lassen. Weniger überzeugend ist es bei bereits deterministischen Arbeiten, extrem knappen Latenzbudgets oder nicht akzeptablen Nebenwirkungen jedes weiteren Versuchs.

Unsere KI-Entwicklungsleistungen beginnen mit dem Ablauf und seinen Abnahmekriterien, nicht mit dem Versprechen, ein Framework werde sich selbst zuverlässig machen. Die Twinsoft-AI-Fallstudie liefert separaten Projektkontext. Sie ist keine Behauptung, dass Twinsoft Harness² verwendet. Mit unserer QA-Checkliste vor dem Launch lässt sich festlegen, welche Nachweise ein Pilot erbringen muss. Danach könnt ihr einen begrenzten Pilot mit Wavect besprechen.

Die hilfreiche kaufmännische Frage ist nicht: „Wie viele Agentenversuche haben wir gekauft?“ Sondern: „Welche unabhängig abgenommenen Ergebnisse haben diese Versuche ermöglicht, und zu welchen Gesamtkosten?“