Jay von 凹非寺
Quantum Bit | WeChat-Konto QbitAI
Googles neue RSI-Ergebnisse sind jetzt Open Source.
Sie trägt den NamenHarness²und ermöglicht es großen Modellen, sich während der Ausführung selbst External-Code, System-Prompts, Toolchains und Skill-Bibliotheken zu modifizieren.
Ja, RSI auf der Harness-Ebene.
Die Ergebnisse sind ebenfalls sehr beeindruckend.
Ein mit diesem RSI-ausgerichteten GLM-5 ausgestattetes Modell stieg im Büro-Benchmark WorkBuddy-Bench direkt um11,5 Punkte——
und überholte damit sofort das native Gemini 3.5 Flash.
Kurz gesagt: ein absolut verrücktes Cheat-Tool – egal welches Modell es aufsetzt, die Benchmark-Werte schießen direkt nach oben.
Das Projekt ist mittlerweile vollständig als Open Source veröffentlicht und unterstützt bereits OpenCode und Codex.
Warum „sich selbst verändern“ oft scheitert
Um Agents intelligenter zu machen, hat die Branche in der Vergangenheit zahlreiche Ansätze zur rekursiven Selbstverbesserung (Recursive Self-Improvement, kurz RSI) verfolgt.
Die Idee klingt wunderbar: Die KI schreibt selbst Code, ändert selbst Prompts und optimiert selbst das System. Doch sobald sie in die echte, offene Welt entlassen wird, scheitern sie fast ausnahmslos.
Warum?
Im Wesentlichen scheitert es an zwei Todsünden:
Es gibt keine Standardantwort.
Im Labor gibt es beim Lösen von Aufgaben Unit-Tests und eine Ground Truth, die einem sagt, ob etwas richtig ist. In realen Arbeitsszenarien – etwa beim Schreiben eines Businessplans oder bei der Prüfung eines Rechtvertrags – gibt es online niemanden, der einem eine Bewertung gibt.
Wenn die KI eine Version ihres Prompts ändert, woher soll sie dann wissen, ob sie dadurch intelligenter geworden ist oder einfach Unsinn produziert?
Überanpassung an Einzelaufgaben.
Man hat mühsam das Scaffold für eine bestimmte Aufgabe umgebaut – und schon besteht die nächste Aufgabe darin, einen Web-Crawler zu schreiben, und alle vorher geänderten Regeln werden zur Belastung.
Wird das veränderte Scaffold einfach auf die nächste Aufgabe übertragen, gerät das System schnell in eine Rauschspirale und wird mit jeder Änderung dümmer.
Das Harness², das das Google-Team diesmal vorgestellt hat, zielt genau auf diese beiden Todsünden ab.
Sie haben einezweistufige rekursive Architektur。
aufgebaut. Zweistufige Rekursion: Die linke Hand macht Experimente, die rechte Hand macht sich Notizen
Das „Quadrat“ im Namen Harness² steht für zwei ineinander verschachtelte rekursive Schleifen:Aufgabenebene-Rekursion（Task-level） undVerbesserungsebene-Rekursion（Harnessing-level）.
Die erste Ebene:Aufgabenebene-Rekursion: Kontrollexperimente durchführen, ohne eine Standardantwort zu haben.
Angesichts der vorliegenden neuen Aufgabe lässt das System zunächst mit dem initialen Scaffold eine Referenz-Trajektorie erstellen. Ob das Ergebnis dieser Version korrekt ist, bleibt vorerst offen; entscheidend ist zu sehen, welche Mängel das Modell während der Ausführung offenlegt.
Unmittelbar danach startet es einen Mechanismus namensPropose–Probe–Compose（Vorschlagen-Erkunden-Kombinieren） :
Propose（Vorschlagen）：
Eine eigene Editor-Rolle unterbreitet auf Grundlage der soeben erstellten Trajektorie zwei Änderungsvorschläge.
Ein davon ist das „generische Mängel-Repair“ (Invariant), das speziell branchenübergreifende allgemeine Fehler aufspürt, etwa chaotische Planung, Endlosschleifen bei Tool-Aufrufen und Context-Explosionen;
das andere ist das „domänenspezifische Repair“ (Domain), das gezielt auf das spezifische Wissen und die Constraints des jeweiligen Geschäfts ausgerichtet ist.
Probe (Erkundung)：
Die beiden modifizierten Kandidaten-Scaffolds werden zurück in dieselbe Aufgabe gegeben und jeweils einmal ausgeführt.
Es macht nichts, wenn es keinen Richter gibt: Das System erfasst ihre Ausführungs-Traces und vergleicht sie verhaltensbezogen mit der Referenz-Trace (Behavioral Contrast). Dabei wird geprüft, ob die Änderung den gerade hängengebliebenen Schritt tatsächlich gelöst hat und ob dadurch neue logische Verschlechterungen entstanden sind.
Compose (Synthese)：
Der Synthesizer legt alle Ausführungsnachweise nebeneinander, wählt diejenigen Änderungen aus, die durch verhaltensbasierte Belege tatsächlich als wirksam nachgewiesen sind, und führt sie in den endgültigen Ausführungs-Scaffold zusammen.
Das ist noch nicht alles. Es unterstützt auch parallele Skalierung (Parallel Recursion): $k$ Kandidatenlösungen werden auf einmal parallel erkundet, um in einem breiteren Suchraum die beste Variante zu synthetisieren.
Beeindruckend.
Die zweite Ebene,Rekursion auf Verbesserungsebene: die Erfahrung aus der Scaffold-Optimierung als Metakompetenz verdichten.
Bei vielen Systemen endet der Lebenszyklus, sobald die aktuelle Aufgabe abgeschlossen und das Ergebnis übergeben ist.
Aber das eigentlich Beeindruckende an Harness² kommt erst jetzt —
die gesamte Debugging-Aufzeichnung (Referenz-Trace, Kandidatenänderungen, Vergleichsnachweise, Syntheseentscheidungen) wird an das Reflexionsmodul (Experience Reflector) übergeben.
Nachdem das Reflexionsmodul die Rückschau abgeschlossen hat, schreibt es ein EXPERIENCE.md, in dem klar festgehalten wird, warum diesmal so geändert wurde, unter welchen Bedingungen die Änderung wirkte und welche Folgen sie hatte. Gespeichert wird das in derBibliothek für kontinuierliche Verbesserungserfahrung(Harness Improvement Library).
Wenn die nächste neue Aufgabe hereinkommt:
Die Ausführungsseite erhält weiterhin einen völlig sauberen Basis-Scaffold.
Aber das für die Scaffold-Anpassung zuständige „Verbesserungsgehirn“ hält bereits ein dickes Handbuch mit historischen Erfahrungen in der Hand. In der Vorschlags- und Synthesephase kann es direkt nach wirksamen Komponenten und Stolperfallen-Leitfäden aus ähnlichen früheren Szenarien suchen.
Verbessert wird nicht nur der aktuelle Scaffold, sondern vor allem die künftige Fähigkeit, Scaffolds zu verbessern.
Damit wird die punktuelle Flickarbeit einer einzelnen Aufgabe in eine kognitive Ressource für lebenslanges Lernen verwandelt.
Benchmark-Ergebnisse aus der Praxis
So elegant der Mechanismus auch beschrieben wird — letztlich müssen echte Daten aus dem Feld sprechen.
Das Team hat sich direkt drei äußerst gewichtige, anspruchsvolle berufliche Benchmarks vorgenommen:
WorkBuddy-Bench: deckt drei hochkomplexe Büro-Workflows ab — Code, Web und Office-Suite;
JobBench: langfristige, komplexe, professionelle End-to-End-Job-Aufgaben;
LAB: der von Harvey veröffentlichte Spitzен-Benchmark für juristische Agenten.
Als Basismodell wurdeGemini 3.5 FlashundGLM-5, als Scaffold wählte man das branchenweit verbreitete Open-Source-OpenCodeundCodex。
Das Ergebnis ist äußerst übertrieben.
Im WorkBuddy-Bench-Test mit nur einer einzelnen Harness²-Verbesserung ($k=1$):
GLM-5 erreichte unter OpenCode einen Gesamtsprung von 64.2 auf 75.7, ein Anstieg um 11.5 Punkte；unter Codex stieg der Wert ebenfalls von 64.4 auf 75.3.
Gemini 3.5 FlashUnter OpenCode wurde eine Steigerung von 72.4 auf 77.5 erzielt, unter Codex eine Steigerung von 74.5 auf 77.5.
Schauen Sie sich diese Daten an:
das optimierte Gerüst-konfigurierte GLM-5 (75,7 Punkte / 75,3 Punkte),hat damit direkt das unveränderte Original mit dem Standard-Scaffolding, Gemini 3.5 Flash (72,4 Punkte / 74,5 Punkte), überholt。
Auch bei JobBench, einem End-to-End-Benchmark für Berufsaufgaben, führt die Verbesserung eines einzelnen Schrittes zu einer umfassenden Steigerung; Gemini 3.5 Flash legte um4,5 Punkte, GLM-5 stieg um3.6 Punkte; beim gesetzlichen Benchmark LAB wurde die Teilbestehensquote von GLM-5 direkt deutlich angehoben11,8 Prozentpunkte。
Wenn man das Parallelitätsbudget auf $k=5$ erhöht (5 gleichzeitige Kandidatenpfade), steigt die Leistung weiter an: Bei WorkBuddy-Bench eine zusätzliche Steigerung von bis zu3,9 Punkte, JobBench steigt erneut um4.2 Punkte, die LAB-Quote steigt weiter6,7 Prozentpunkte。
Noch eindrucksvoller ist der domänenübergreifende Transfer-Test des Erfahrungsrepertoires.
Das Team nahm die durch die Ausführung von Aufgaben auf JobBench aufgebaute Erfahrungsbibliothek, zog sie einfach ab und steckte sie direkt an WorkBuddy-Bench – und das ganz ohne zusätzliche Sondierungen führte das zu schmerzfreien Punktzugewinnen von Code +0,6, Web +0,5 und Büro +2,9.
In den vergangenen zwei Jahren setzten die Erwartungen an die KI fast vollständig auf das „Scaling der Basismodelle“; man meinte stets, man müsse nur auf die nächste Generation GPT, die nächste Generation Gemini warten, und schon würden die Probleme der eigenen Anwendungen sich von selbst lösen.
Doch die Realität hat allen Praktikern einen Eimer kaltes Wasser überschüttet: Die Basismodelle werden immer teurer, der Grenznutzen lässt nach, und die Long-Tail-Bugs in den realen Einsatzszenarien scheinen endlos zu sein.
Wie groß man dem Modell auch das Kontextfenster macht, bei der abrechnungsübergreifenden Verarbeitung mehrerer Dateien wird es trotzdem faul; wie hoch man ihm auch die Benchmark-Punktzahl gibt, es öffnet nach dem Schreiben eines Berichts trotzdem nicht von sich aus die Datei, um das Format zu prüfen.
Solche Dinge lassen sich durch vortrainierte Parameter nie ausreichend mitfüttern.
Was es braucht, ist ein System, das sich während der Laufzeit selbst wahrnimmt, selbst repariert und sich kontinuierlich weiterentwickelt:Runtime-Kognitions-Engineering。
Früher, wenn wir Scaffolding aufbauten, saßen Ingenieure vor dem Computer und schrieben Prompt für Prompt von Hand, konfigurierten Werkzeuge und flickten Pipelines – bis zum Umfallen und trotzdem überall undicht.
Jetzt hat Harness² einen neuen Weg bewiesen:
Gibt die Macht der Regelsetzung an die Agenten selbst zurück.
Autoren der Arbeit
Zum Schluss sprechen wir, wie üblich, über die Autoren der Arbeit.
Insgesamt 9 Personen, und der Anteil chinesischer Forschender ist mit 78 % extrem hoch ...
Da der Artikel begrenzt lang ist, stellen wir hier drei Personen in Reihenfolge vor.
Ruiyao Xu, Erstautor und korrespondierender Autor der Arbeit.
Er ist Doktorand am Department of Statistics and Data Science der Northwestern University in den USA; sein Betreuer ist Kaize Ding.
Seine wichtigsten Forschungsrichtungen umfassen große Sprachmodelle, Graph-Machine-Learning, Anomalieerkennung und KI-Agent-Systeme.
Diese Arbeit ist das Ergebnis seines Praktikums bei Google.
Yanfei Chen, Senior Research Engineer bei Google Cloud AI Research.
Er schloss sein Bachelorstudium an der Peking University mit den Hauptfächern Elektrotechnik und Wirtschaftswissenschaften ab und erhielt 2018 einen Ph.D. in Industrial Engineering von der University of Pittsburgh in den USA.
Danach arbeitete er als Research Engineer beim Machine-Learning-Unternehmen Qeexo und stieg 2020 bei Google ein, wo er an Projekten wie Vertex AI Search und Gemini Enterprise Deep Research mitwirkte; seine Forschungsschwerpunkte sind große Sprachmodell-Agenten, Retrieval-Augmented Generation und Tool Learning.
Zhongying CuiZhu, auch bekannt als Zoey CuiZhu, Research Engineer bei Google Cloud AI Research.
Sie erhielt 2019 einen Ph.D. in Elektrotechnik von der Stanford University und forscht hauptsächlich an allgemeinen Agenten, verifizierbaren Agenten sowie der Qualitätsbewertung von Agenten.
Referenzlink:
[1] https://arxiv.org/html/2610.14224v1