Leistungssteigerung um 76% ohne Modellabhängigkeit? Karpathys 700-Loop-Experiment enthüllt den größten Irrtum über Agenten

„Der größte Irrtum in der heutigen KI-Branche besteht darin, dass alle Agenten dazu drängen, so schnell wie möglich zu arbeiten, anstatt zuerst die zugrunde liegenden Modelle und Systemmechanismen gründlich zu verstehen und zu beherrschen.“

Dies ist die Ansicht von Andrej Karpathy, ehemaliger Mitbegründer von OpenAI und derzeitiger Pre-Training-Forscher bei Anthropic, die er im letzten Jahr in dem Podcast „AGI ist noch ein Jahrzehnt entfernt“ äußerte.

Er ging direkt auf den Punkt und warnte die Branche davor, den Fokus auf die Modellarchitektur zu verstärken. „Auch OpenAI ist in den frühen Jahren in ähnliche Fallen getappt. Als die grundlegenden Fähigkeiten noch nicht ausgereift waren, eilten wir Agenten dazu, komplexe Aufgaben zu erledigen, und verschwendeten am Ende fünf Jahre vergeblich.“

Diese Aussage ist auch heute noch nicht veraltet.

Im vergangenen Jahr sind Agenten zu dem überfülltesten Bereich im KI-Bereich geworden. Alle verbinden Modelle, schließen Tools an und stapeln Workflows, als ob ein Agent, der wirklich selbstständig arbeiten kann, automatisch entsteht, wenn man nur noch ein paar weitere Fähigkeitsebenen hinzufügt.

Aber genau hier liegt das Problem: Viele Agenten scheitern nicht daran, dass das „Modell nicht klug genug ist“, sondern an einem grundlegenderen, langweiligeren und entscheidenderen Systemingenieurwesen außerhalb des Modells.

Kürzlich zeigte das Experiment „Don't Train the Model, Evolve the Harness“ des Hugging Face-Maschineningenieurs Joel Niklaus:

Mit demselben DeepSeek-v4-pro, ohne die Modellgewichte zu ändern und nur den Ausführungsmechanismus außerhalb des Modells zu optimieren, kann die Leistung des Agenten bei professionellen Aufgaben erheblich verbessert werden (der pooled Score stieg von 3,5 % auf 80,1 %).

Das Open-Source-Projekt AutoResearch (Loop Cycle) von Karpathy, das 90.000 Sterne erhalten hat, zeigt ferner, dass der wahre Wert von KI nicht darin liegt, einmalig eine Antwort zu generieren, sondern in dem Zyklus von „Vorschlagen von Änderungen, Durchführen von Experimenten, automatischer Bewertung und Beibehalten von Fortschritten“.

Einmal richtig zu antworten hängt vom Modell selbst ab, während kontinuierliche Iteration von der kombinierten Fähigkeit des Modells und des externen Ausführungssystems abhängt.

Nur die „Hülle“ optimieren – kann die Leistung dann sprunghaft steigen?

Wenn Sie noch hart an Prompt-Wörtern arbeiten oder sich darüber beschweren, dass Open-Source-Modelle nicht klug genug sind, könnte dieses kürzliche Experiment von Hugging Face Ihre Vorstellungen auf den Kopf stellen.

Um herauszufinden, wo genau der Engpass der Agentenleistung liegt, verwendete Niklaus das Open-Source-Modell DeepSeek-V4-Pro und führte Experimente an spezifischen rechtlichen Agenten-Benchmark-Tests durch.

Aufgabenleistung von DeepSeek-V4-Pro unter dem ursprünglichen LAB-Harness. Die Unterschiede zwischen verschiedenen rechtlichen Praxisfeldern und Aufgaben sind deutlich, was zeigt, dass die Modellleistung zuerst durch den externen Ausführungsmechanismus beeinflusst wird und nicht nur durch die Fähigkeiten des reinen Modells.

Niklaus tat etwas äußerst Zurückhaltendes: Er fror die Gewichte des Modells vollständig ein, d. h. es erfolgte keine Feinabstimmung oder Fortbildung. Die einzige Variable war der Code und die Ausführungslogik, die das Modell umhüllen – das sogenannte Agent Harness (externer Ausführungsmechanismus).

Es ist zum Lachen und zum Weinen zugleich: In den ersten Tests erreichte das Modell unter einigen externen Mechanismen sogar einen Wert von 0 %. Das Forschungsteam fand die Wahrheit heraus: Der rechtliche Denkprozess des Modells war tatsächlich vollständig korrekt, aber es speicherte das Ergebnis immer unter einem falschen Dateinamen, sodass das Testprogramm das Ergebnis überhaupt nicht lesen konnte.

Das bedeutet, dass der 0-Punkte-Wert niemals die Intelligenz des Modells misst, sondern prüft, ob das Harness wirksam ist.

Da das Problem also in der „Hülle“ liegt – um wie viel kann die Leistung verbessert werden, wenn man sie nur optimiert?

Die Experimentaldaten liefern eine äußerst beeindruckende Antwort. Bei demselben DeepSeek-V4-Pro, denselben Aufgaben und demselben Bewerter schwankte der pooled Score (Gesamtwertung) dramatisch zwischen 3,5 % und 80,1 %, nur weil fünf verschiedene externe Ausführungsmechanismen verwendet wurden:

Von 3,5 % bei mini-swe-agent, 23,2 % bei Goose und 45,4 % bei Pi bis hin zu 63,4 % beim ursprünglichen LAB-Harness.

Vergleich der Leistung verschiedener externer Ausführungsmechanismen bei Held-Out-Testaufgaben mit einem Schwankungsbereich von bis zu 76 Punkten.

Nach etwa 22 Runden automatischer Code-Iterationsoptimierung stieg der pooled Score bei 100 Held-Out-Testaufgaben schließlich von 63,4 % beim ursprünglichen LAB-Harness auf 80,1 % (ein Anstieg um 16,7 Prozentpunkte), und die All-Pass-Rate stieg von 0 % auf 5,0 %.

Dieses Open-Source-Modell, dessen Gewichte überhaupt nicht verändert wurden, erreichte durch die Optimierung des Harness eine Leistung, die mit der des branchenführenden Closed-Source-Modells Claude Sonnet 4.6 gleichzieht – und die Betriebskosten betrugen nur 1/7 des ursprünglichen Werts.

Entscheidender ist, dass dieses optimierte Harness, wenn es auf das kleinere Modell derselben Familie, DeepSeek-V4-Flash, übertragen wird, immer noch eine Verbesserung um 14,4 Punkte bewirkt.

Dies beweist: Der Ausführungsmechanismus auf Codeebene ist viel leichter zu konsolidieren und auf andere Modelle zu übertragen als die Feinabstimmung von Prompt-Wörtern.

Also, was genau ist ein Harness?

Akshay, ehemaliger Ingenieur bei Lightning AI und Mitbegründer von DailyDoseOfDS, hat es so analysiert:

Ein ursprüngliches LLM ist nur eine CPU ohne Arbeitsspeicher oder Festplatte; wenn es nicht das Modell selbst ist, dann ist es das Harness – es ist das Betriebssystem, das den Arbeitsspeicher, die Ein-/Ausgabe und die Treiber verwaltet.

Er ist der Ansicht, dass ein produktionsreifes Harness 12 Kernkomponenten enthalten sollte, die alle Aspekte abdecken – von der Prozessorchestrierung, dem Tool-Aufruf, dem hierarchischen Speicher bis hin zur Kontextverwaltung und Fehlerbehandlung.

Zum Beispiel das häufige Problem des „Kontextverfalls“: Wenn das Modell wichtige Informationen in der Mitte des Kontextfensters platziert, sinkt die Leistung direkt um mehr als 30 %.

Ein ausgereiftes Harness verfügt bereits über eine vollständige ingenieurmäßige Methode, um dieses Problem zu lösen – Komprimieren des Verlaufs, Ausblenden alter Ausgaben, dynamisches Abrufen und Proxy-Zusammenfassung. Der Kern liegt darin, die besten Ergebnisse mit der minimalen Anzahl an Tokens hoher Informationsdichte zu erzielen.

Auf Basis der oben genannten Experimente zog Niklaus eine zentrale Schlussfolgerung:

Was Benchmarks messen, ist niemals das reine Modell, sondern die kombinierte Fähigkeit von „Modell + Harness“. Die größten Leistungsverbesserungen stammen oft von einfachen automatisierten Schritten wie der Dateiverwaltung, anstatt viele Tokens für die Änderung von Prompt-Wörtern zu verschwenden.

Bedeutet das also, dass wir in Zukunft keine Modelle mehr trainieren müssen, sondern nur noch Harness stapeln brauchen?

Die Antwort ist nicht so einfach. Die durch das Harness erzielte Verbesserung hat schließlich Grenzen, und die verbleibende Lücke muss durch die grundlegenden Fähigkeiten des Modells geschlossen werden. Aber das Kernproblem im Moment ist: Die meisten Menschen haben noch nicht einmal ein ausreichend funktionsfähiges Harness gebaut, und eilen schon dazu, größere Modelle zu stapeln.

Wenn Sie nicht einmal wissen, ob Fehler in Ihren Testtools vorliegen, werden Sie niemals feststellen können, ob der Leistungsengpass im Modell selbst oder in Ihrem lückenhaften externen Code liegt.

700 automatische Iterationen – die Leistung steigt um das 5-fache

Da der externe Ausführungsmechanismus außerhalb des Modells so wichtig ist – wie baut man konkret einen Agenten, der sich kontinuierlich weiterentwickeln kann?

Der KI-Forscher Codila hat das 90.000-Sterne-Projekt AutoResearch von Karpathy weiter verfeinert und die 630 Zeilen Open-Source-Code zu einer fünfstufigen „Loop-Engineering“-Methodik verdichtet.

Diese Methodik hat derzeit auf X über 2 Millionen Aufrufe erhalten, weil sie einen zentralen Schmerzpunkt trifft: Erwarten Sie nicht, dass der Agent es beim ersten Mal richtig macht – sondern nähern Sie sich der optimalen Lösung durch kostengünstiges, kontinuierliches Ausprobieren und Irren.

Die Logik dieses Zyklus scheint sehr einfach zu sein:

1. Auf Basis eines feinabgestimmten Modells erstellen Sie ein Dokument, das dem Agenten mitteilt, welche Richtungen er erkunden und welche Einschränkungen er einhalten soll.
2. Dem Agenten ist es nur erlaubt, das Trainingsskript zu ändern; die Bewertungs- und Bewertungsskripte sind gesperrt und können nicht geändert werden. Denn das verhindert, dass der Agent die Standards willkürlich senkt, um eine höhere Punktzahl zu erhalten.
3. Lassen Sie den Agenten in folgendem Zyklus laufen: Änderungen vorschlagen → Trainieren → Bewerten → Gute Verbesserungen behalten, schlechte verbessern oder verwerfen

Karpathy ließ sein Modell, das er mit 20 Jahren Erfahrung manuell angepasst hatte, zwei Tage lang laufen – und das Ergebnis war erstaunlich:

Der Agent führte automatisch 700 Experimente durch und fand 20 Code-Verbesserungen, die er selbst übersehen hatte. Zum Beispiel ein fehlender skalarer Multiplikator im Aufmerksamkeitsmechanismus, der dazu führte, dass die Aufmerksamkeit zu stark auf mehrere „Köpfe“ verteilt wurde. Solche feinen Optimierungen, die enorme Geduld erfordern, machen Menschen nach