Wird der OpenClaw-Code immer schlechter, je mehr er geändert wird? Eine neue Studie namens EvoClaw zeigt: Die kontinuierliche Entwicklungserfolgsrate von Agents beträgt nur 13,37%.

Bis Ende 2025 hat sich die KI-Programmierung vollständig vom Hilfswerkzeug Copilot hin zur Agenten-Ära gewandelt, in der die Künstliche Intelligenz im Vordergrund steht und der Mensch die Überwachung übernimmt.

Wenn es darum geht, eine einfache Funktion zu schreiben oder einen isolierten Bug zu beheben, kann das aktuelle Spitzenmodell fast immer eine zufriedenstellende Lösung liefern.

Mit dem Aufstieg von OpenClaw Anfang 2026 hat sich der Agent jedoch von einer Einzeltask-Sitzung hin zu einem langfristig laufenden System entwickelt. Um von der einfachen Funktionalität und Benutzerfreundlichkeit zur endgültigen Substitution und Überholung des Menschen zu gelangen, muss die Künstliche Intelligenz alle Software-Schnittstellen, die mit der realen Welt interagieren, kontinuierlich und autonom anpassen und verbessern.

Das größte Hindernis für die Umsetzung dieser Vision liegt jedoch darin, dass die reale Softwareentwicklung nicht nur eine einmalige Codegenerierung ist, sondern ein anhaltender Wettlauf um Zeit und Komplexität. Der Codebestand wächst ständig mit den sich ändernden Anforderungen, und Probleme, die in der frühen Phase gelegt wurden, können Monate später zu systemischen Risiken werden. Kann die Künstliche Intelligenz bei einem solchen kontinuierlichen Entwicklungsprozess tatsächlich zuverlässig bleiben?

Kürzlich haben Deng Gangda von der USC, Chen Zhaoling von der UCR, Cong Le von Stanford, Wang Mengdi von Princeton, Tang Xiangru von Haven, Wang Xingyao von OpenHands und andere gemeinsam einen neuen, wichtigen Bewertungsstandard namens EvoClaw veröffentlicht. Das Forschungsteam hat die echten Code-Entwicklungsgeschichten aus Open-Source-Projekten extrahiert und sie zu einem Meilenstein-Abhängigkeitsgraph (Milestone DAG) rekonstruiert. Dieser Graph aggregiert die verstreuten Commits zu funktional zusammenhängenden Meilensteinen und erhält streng die zeitliche Abhängigkeit der Tasks.

Auf der Grundlage dieses neuen Standards hat die Forschung gezeigt, dass die Leistung der KI in echten Entwicklungsszenarien, in denen es um eine "kontinuierliche Entwicklung" geht, stark einbricht (von einem Score von > 80 % auf maximal knapp 40 %). Dies bedeutet, dass die KI immer noch einen deutlichen Abstand zu einer echten Eignung für die langfristige, kontinuierliche und autonome Softwareentwicklung hat.

Übersicht über die Gesamtleistung (y-Achse) und die Inferenzkosten (x-Achse) der verschiedenen Modellsysteme in EvoClaw

Programmierbewertung 2.0: Von der Einzeltask-Behebung zur kontinuierlichen Entwicklung

Warum überschätzen die bestehenden KI-Programmierbewertungen (z. B. SWE-bench) oft die reale Fähigkeit von Coding Agenten?

In den letzten Jahren lag der Schwerpunkt der Programmierbenchmarks hauptsächlich auf "Einzeltasks": Das Beheben eines Issues, das Abschluss eines großen PR und die Validierung der Ergebnisse in einem relativ statischen Codesnapshot. Diese Bewertungsart hat sicherlich ihren Wert, aber sie vernachlässigt natürlicherweise ein Schlüsselproblem: Die Softwareentwicklung ist nie eine Sammlung von Einzeltasks, sondern ein kontinuierlicher Entwicklungsprozess. Frühere Implementierungsentscheidungen beschränken den späteren Entwicklungsraum, und kleine Probleme aus der frühen Phase können sich in späteren Versionen vergrößern.

Die Studie weist darauf hin, dass die bestehenden Bewertungen die zeitliche Dimension der Softwareentwicklung oft übersehen, was dazu führt, dass die Bewertungen vieler KIs überhöht sind, aber in der Praxis ihre Schwächen schnell offenbaren.

EvoClaw hat bei der Bewertungsgestaltung einen entscheidenden Unterschied: Es verlangt, dass die KI mehrere voneinander abhängige Tasks in derselben Codebasis nacheinander ausführt. Abgesehen von der externen Aufgabenstellung muss die gesamte Entwicklung und Wartung von der KI autonom durchgeführt werden. Diese Designentscheidung, die "Dauerhaftigkeit der Entwicklungsumgebung" zu gewährleisten, zeigt direkt die Schwäche der KI in kontinuierlichen, autonomen Iterationsszenarien auf.

Vergleich der Bewertungsparadigmen zwischen Einzeltasks (z. B. SWE-bench) und kontinuierlicher Entwicklung (EvoClaw)

DeepCommit: Die Rekonstruktion von "Meilensteinen" in der Softwareentwicklung mit Agenten

Eine wichtige Frage ist, wie man die Entwicklungsgeschichte aus bestehenden Softwareprojekten extrahieren kann. Das Forschungsteam hat nicht einfach die vorhandenen Commit- und Release-Granularitäten zur Task-Segmentierung verwendet, sondern stattdessen die Ebene der Meilensteine (Milestones) eingeführt.

Der Grund ist einfach: Ein einzelner Commit ist oft zu fein aufgelöst und enthält viele unwichtige Änderungen, was es schwierig macht, ein vollständiges Entwicklungsziel darzustellen. Ein Release hingegen ist zu grob und komprimiert viele Zwischenabhängigkeiten und Entwicklungspfade.

Vergleich der drei Granularitäten Commit, Release und Milestone. Der Milestone erreicht ein Gleichgewicht zwischen semantischer Vollständigkeit und Beibehaltung von Abhängigkeiten.

Ein Milestone wird als "semantisch vollständige Funktionseinheit, die gleichzeitig die Abhängigkeiten in der Entwicklung beibehält" definiert und eignet sich daher besser als Task-Granularität für die Bewertung der Fähigkeiten der KI in Bezug auf die Codeentwicklung.

Basierend auf diesem Ansatz schlägt die Studie DeepCommit vor, ein Agenten-gesteuertes automatisches Pipeline-System, das die ursprünglich sehr verrauschte Git-Geschichte in einen verifizierbaren Milestone DAG umwandelt.

Erste Phase: Statische Analyse und Rauschunterdrückung (Vorverarbeitung)

Zunächst werden Änderungen, die nicht mit der Kernfunktion des Codes zusammenhängen (z. B. Dokumentation, CI/CD-Konfigurationen), herausgefiltert. Anschließend werden durch eine statische Analyse die Abhängigkeiten zwischen den Commits auf Codezeilen- und Symbolebene extrahiert, um die Grundlage für die spätere Graph-Konstruktion zu legen.

Zweite Phase: Agenten-gesteuerte DAG-Konstruktion

Der Large Language Model (LLM)-Agent fungiert als "Architekt" und rekonstruiert die Geschichte in vier Schritten: Zunächst werden die bahnbrechenden "Seed"-Commits identifiziert. Dann werden die semantisch verwandten Commits zusammengeführt und zu einem vollständigen Milestone vereinigt. Anschließend werden die Abhängigkeiten zwischen den Milestones abgeleitet. Schließlich werden die zu großen Milestones dynamisch aufgeteilt, um eine gleichmäßige Granularität zu gewährleisten.

Architekturdiagramm der DeepCommit-Pipeline, das zeigt, wie der Milestone DAG aus den ursprünglichen Commits extrahiert wird.

Dritte Phase: Agenten-gesteuerte Laufzeitanalyse und Validierung

Ein auf Papier konstruierter Graph hat nur bedingt Bedeutung. Die eigentliche Herausforderung besteht darin, die rekonstruierte Entwicklungsgeschichte in einer realen Umgebung auszuführen.

Da der neue Milestone DAG die ursprüngliche Git-Zeitlinie unterbricht, kann es passieren, dass beim Neuauftragen der Commits in der neuen topologischen Reihenfolge Schnittstelleninkompatibilitäten auftreten und die Kompilierung viele Fehler meldet. Wenn man die fehlerhaften Module einfach überspringt, sinkt die Testfallabdeckung drastisch, und die Bewertung verliert an Bedeutung.

Deshalb hat das Forschungsteam einen "iterativen Reparaturzyklus" entwickelt. Im Falle eines Kompilierungsfehlers analysiert der Agent die Fehlerprotokolle, ändert die Dockerfile dynamisch, um die Ausführbarkeit sicherzustellen. Noch wichtiger ist, dass er die ursprünglich fehlenden impliziten Abhängigkeiten in der ursprünglichen Milestone DAG ergänzt und die Reihenfolge der Milestones anpasst, um die Schnittstellenkonflikte endgültig zu beheben.

Durch kontinuierliche iterative Reparaturen wird schließlich sichergestellt, dass mindestens 85 % der ursprünglichen Testfälle erfasst werden können, um eine ausreichende Testbasis für die Bewertung zu schaffen.

Beispiel eines DeepCommit Milestone DAGs für den Release-Bereich von 1.5.2 bis 1.6.0 im scikit - learn - Repository

Es ist erwähnenswert, dass die Autoren der Studie den automatisch generierten Entwicklungsgraph von DeepCommit mit dem von menschlichen Experten manuell annotierten Graph verglichen haben. Das Ergebnis ist sehr interessant: Die menschlichen Experten neigen dazu, die Semantik von oben nach unten nach "strategischen Zielen" (z. B. Refactoring, Kompatibilität) zu segmentieren. DeepCommit zeigt jedoch eine völlig andere zugrunde liegende Logik - es basiert vollständig auf den tatsächlichen Abhängigkeiten auf Codeebene und reorganisiert das Skelett der Softwareentwicklung von unten nach oben mit einer topologischen Denkweise.

Dieses strenge automatisierte Pipeline-System hat erfolgreich sichergestellt, dass alle ausgewählten Milestone-Tasks 100 % der vorausgesetzten Abhängigkeiten annotiert haben und tatsächlich ausführbar sind.

EvoClaw: Die "kontinuierliche Entwicklung" in die Bewertung integrieren

Um sicherzustellen, dass die Bewertungsanforderungen klar definiert sind, hat der Autor mit Hilfe eines Agenten auf der Grundlage des korrekten Codes (Gold Patch) für jeden Milestone eine Softwareanforderungsspezifikation (SRS) rückwärts generiert und diese streng mit den Akzeptanztests abgestimmt. Anschließend wurden die SRS von menschlichen Experten einzeln überprüft, um sicherzustellen, dass keine Implementierungsdetails preisgegeben wurden, die Tasks absolut lösbar sind und alle instabilen Testfälle entfernt wurden.

Das resultierende EvoClaw-Datensatz umfasst fünf gängige Programmiersprachen. Für jedes Projekt wurde ein echter Entwicklungszyklus über mehrere Release-Bereiche (maximal 750 Tage) ausgewählt. Gleichzeitig wurden die Gesamtkosten in einem vertretbaren Rahmen gehalten. Beispielsweise kostet es etwa 500 US-Dollar, den Datensatz einmal vollständig mit Claude Opus 4.5 auszuführen.

Übersicht über den EvoClaw-Datensatz

Deshalb berücksichtigt EvoClaw nicht einfach nur die Einzelerfolgsrate, sondern fügt zusätzlich zwei Kernaspekte zur Bewertung der Agentenleistung hinzu:

Recall (Rekallrate): Misst die Vollständigkeit der Funktionsimplementierung. D. h., wie viele der Änderungen, die in der Zielaufgabe gefordert werden, hat der Agent tatsächlich umgesetzt?

Precision (Genauigkeit): Misst die Zuverlässigkeit der Modifikationsaktionen und quantifiziert, wie viel des bestehenden Codes der Agent "beschädigt", während er "neue Funktionen" implementiert.

Schließlich werden diese beiden Indikatoren durch eine F1 - Gewichtsmittelung