Die zweite Hälfte der Agent-Bewertung: Warum brauchen wir ein "lebendes" Benchmark?

【Einführung】Claw-Eval-Live stellt das Konzept eines „lebenden“ Benchmarks vor. Durch die Sammlung von Signalen und die Auswahl von Aufgaben wird sichergestellt, dass die Bewertungsinhalte den tatsächlichen Problemen von Unternehmen folgen, anstatt auf einem festen Fragenpool basieren. Die Bewertung betrachtet nicht nur das Ergebnis, sondern verfolgt auch den Ausführungsprozess, von der Datenabfrage bis zur Statusänderung, um die echten Fähigkeiten des Agenten umfassend zu überprüfen.

Heutige KI-Agenten sehen immer mehr wie „arbeitsfähige digitale Angestellte“ aus: Sie können APIs aufrufen, Datenbanken durchsuchen, E-Mails schreiben, Code ändern, Termine planen und Berichte erstellen. Das wirkliche Problem liegt jedoch nicht darin, ob sie „sprechen können“, sondern in zwei realeren Fragen: Hat der Agent tatsächlich die Aufgabe erledigt? Und repräsentieren die Aufgaben, mit denen wir ihn testen, noch die wichtigsten Workflows der realen Welt?

Claw-Eval beantwortet die erste Frage, Claw-Eval-Live die zweite. Das erste Projekt löst das Problem, wie man sicherstellt, dass der Agent eine Aufgabe tatsächlich erledigt hat. Das zweite befasst sich damit, wie der Fragenpool eines Benchmarks den aktuellen Anforderungen gerecht wird. Dieser Artikel möchte genau diese fortschreitende Bewertungslogik darstellen. In gewisser Weise ist dies auch das Zeichen für die „zweite Halbzeit“ des Agent-Benchmarks: Es geht nicht mehr nur darum, wer besser antworten kann, sondern wer näher an der realen Welt ist.

Link zur Studie: https://arxiv.org/abs/2604.28139

Link zur Studie: https://arxiv.org/pdf/2604.06132

Sind Sie sicher, dass der Agent die Aufgabe tatsächlich erledigt hat?

Vor Claw-Eval war die gängige Methode zur Agentenbewertung, dem Agenten eine Aufgabe zu geben, das Endergebnis zu betrachten und zu entscheiden, ob es richtig ist. Wurde die Datei erstellt? Bestanden die Tests? Passt die Antwort? Dann gilt die Aufgabe als bestanden.

Das klingt vernünftig, aber für Agenten hat diese Art der Bewertung zwei fatale Probleme.

Erstens: Es wird nur auf das Ergebnis geachtet, nicht auf die Aktionen. Das Modell liefert einen schönen Bericht, aber hat es wirklich die richtigen Datenquellen abgefragt? Hat es die richtigen APIs aufgerufen? Oder hat es einfach eine Antwort „erfunden“, die richtig aussieht? Neuere Studien haben gezeigt, dass fortschrittliche Modelle aktiv nach Bewertungs-Kürzungen suchen, um die erwartete Ausführungsroute zu umgehen und die Endprüfung direkt zu bestehen. Eine Bewertung, die nur auf das Ergebnis abzielt, bietet genau diese Möglichkeit.

Zweitens: Es spiegelt schwer die realen Implementierungsanforderungen wider. Ein wirklich einsetzbarer Agent muss nicht nur die Aufgabe erledigen, sondern auch vermeiden, Dinge zu tun, die er nicht sollte, und in einer Umgebung mit API-Timeouts und Servicefehlern stabil funktionieren. Mit anderen Worten: Die Bewertung darf nicht nur darauf abzielen, ob die Aufgabe „erledigt werden kann“, sondern auch, ob sie „sicher und robust erledigt wird“. Claw-Eval integriert auch Multimodalität und mehrrunde Dialoge in einen einheitlichen Bewertungsrahmen. Sein wichtigster Beitrag besteht jedoch darin, die Agentenbewertung von der „Nur-Ergebnis-Bewertung“ zur „Aktions-Bewertung“ zu bringen.

Claw-Eval macht den Ausführungsprozess des Agenten zu überprüfbaren Beweisen

Claw-Eval umfasst 300 manuell überprüfte Aufgaben, die drei Gruppen abdecken: allgemeine Service-Orchestrierung, Multimodalitätssicht und -generierung sowie mehrrunde Fachdialoge. Insgesamt werden 2.159 unabhängig überprüfbare Bewertungsregeln definiert.

Der Kerngedanke lässt sich in einem Satz zusammenfassen: Der Ausführungsprozess des Agenten wird zu überprüfbaren Beweisen. Jede Bewertung findet in einer isolierten Umgebung statt und gliedert sich in drei Phasen: Setup, Ausführung und Beurteilung. Während der Ausführung des Agenten sind die Bewertungsskripte und die Musterlösungen im Container nicht sichtbar. Die eigentliche Bewertung basiert nicht nur auf der endgültigen Ausgabe, sondern auf drei unabhängigen Beweissträngen: der Ausführungstrajektorie, den Server-Audit-Logs und der Umgebungs-Snapshot nach der Ausführung.

Auf dieser Grundlage integriert Claw-Eval die Vollständigkeit, Sicherheit, Robustheit und multimodalen Aufgaben in einen einheitlichen Bewertungsrahmen.

Die wichtigste Erkenntnis von Claw-Eval ist recht einfach: Ohne die Betrachtung des Prozesses wird die Agentenbewertung systematisch zu Gunsten des Modells ausgelegt.

Das Team führte ein strenges Kontrollexperiment durch: Ein einfaches LLM-Judge erhielt die vollständigen Dialoge und den Quellcode der Bewertungsskripte, fehlten aber die Server-Audit-Logs und der Umgebungs-Snapshot. Das Ergebnis war, dass es immer noch 44 % der Sicherheitsverletzungen und 13 % der Robustheitsprobleme übersah. Dies bedeutet, dass die „Nur-Ergebnis-Bewertung“ für Agenten nicht nur unpräzise ist, sondern auch das Modell systematisch überschätzt.

Claw-Eval zeigt natürlich noch viel mehr, wie etwa, dass der Fehler-Einsatz die Zuverlässigkeit erheblich senkt (Pass^3 kann um bis zu 24 Prozentpunkte einbrechen) und dass es keinen einheitlichen Sieger in Bezug auf Multimodalität und mehrrunde Dialoge gibt. Für diesen Artikel ist jedoch die wichtigste Schlussfolgerung die folgende: Der Agent-Benchmark darf nicht nur auf die Antworten abzielen, sondern auch auf die Aktionen.

Wenn jedoch die Frage, wie man bewertet, geklärt ist, taucht ein neues, realeres Problem auf: Selbst wenn die Bewertung vertrauenswürdig ist, kann es sein, dass der Benchmark, den wir verwenden, sich langsam von den aktuellen Anforderungen entfernt. In diesem Fall ist eine genaue Bewertung möglicherweise nicht zielführend.

Genau dieses Problem will Claw-Eval-Live lösen.

„Genau bewerten“ reicht nicht aus, Benchmarks können veraltet werden

Ab hier geht es nicht nur darum, wie man bewertet, sondern auch, was man bewertet. Dies ist der Punkt, an dem Claw-Eval-Live wirklich ins Spiel kommt.

Claw-Eval löst das Problem, ob die Bewertung vertrauenswürdig ist. Aber wie fast alle anderen Benchmarks hat es eine grundlegende Einschränkung:

Die Aufgabenmenge ist festgelegt.

Die 300 Aufgaben sind am Veröffentlichungstag festgelegt. Unabhängig davon, wie sich die Tool-Ekosysteme ändern, wie sich die Schwerpunkte der Unternehmensworkflows verschieben oder welche Aufgaben die Benutzer lieber automatisieren möchten (von der Tagesberichtserstellung zur Quersystemabstimmung) – die Aufgabenverteilung im Benchmark ändert sich nicht.

In der traditionellen NLP-Bewertung ist dies kein großes Problem, da Aufgaben wie „einen Text übersetzen“ oder „eine Frage beantworten“ relativ stabil sind. In der Agentenbewertung wird dieses Problem jedoch dramatisch vergrößert. Agenten müssen nicht mit abstrakten Sprachaufgaben, sondern mit konkreten Workflows umgehen. Und Workflows ändern sich ständig – die Tool-Stacks werden weiterentwickelt, die Unternehmensprobleme verschieben sich, einige Automatisierungsszenarien entstehen neu, während andere aus dem Mittelpunkt rücken.

Ein Benchmark kann technisch vollständig reproduzierbar sein, aber die Aufgabenkombination, die er misst, kann sich langsam von den Aufgaben entfernen, die die Benutzer aktuell am liebsten vom Agenten automatisiert hätten.

Diese Abweichung kommt nicht von der „Veraltung“ einer bestimmten Aufgabe, sondern von der Aufgabenmischung selbst. Die heißesten Automatisierungsanforderungen vor sechs Monaten sind wahrscheinlich nicht die gleichen wie heute.

Genau dieses Problem will Claw-Eval-Live lösen.

Wie sieht ein „lebender“ Benchmark aus?

Wenn man von einem „lebenden Benchmark“ hört, denkt man zuerst wahrscheinlich: Dann ändert sich der Benchmark ständig, und es ist unmöglich, Vergleiche anzustellen.

Die Antwort von Claw-Eval-Live lautet nicht „lass den Benchmark ständig ändern“, sondern:

Jede Veröffentlichung soll eine Momentaufnahme der realen Welt sein.

Der Kern ist ein zweischichtiges Design:

Signalschicht (Signal Layer) – Bei der Erstellung einer neuen Veröffentlichung wird nicht von einem Team ermittelt, was getestet werden soll, sondern es werden öffentliche Workflow-Anforderungssignale wie die Top-500 beliebtesten Skills auf ClawHub betrachtet, um zu sehen, welche Workflows derzeit wichtiger sind. Hier ist zu betonen, dass diese Signale keine automatischen Aufgabengeber sind und auch keine genaue Messung der realen Anforderungen darstellen. Sie sind lediglich eine öffentliche, überprüfbare Vorinformation, die dem Benchmark hilft, zu entscheiden, welche Workflows in dieser Veröffentlichung stärker berücksichtigt werden sollen.

Veröffentlichungsschicht (Release Layer) – Der tatsächlich veröffentlichte Benchmark ist immer noch eine feste, zeitgestempelte Momentaufnahme. Die Aufgabendefinition, die Ausführungsumgebung, die Datenvorlagen und die Bewertungsskripte sind alle festgelegt. Die Modelle können stabil verglichen werden, und die Ergebnisse sind akademisch reproduzierbar.

Die beiden Schichten sind durch eine fünfstufige Pipeline verbunden:

Signal-Sammlung: Erfassung eines zeitgestempelten Momentaufnahme der ClawHub Top-500, wobei jedes Signal seine Quelle und Metadaten enthält

Modus-Clustering: Zusammenführung von fragmentierten Skill-Namen zu stabilen Workflow-Mustern – Es wird nicht nach den Oberflächennamen der Skills unterschieden, sondern nach den zugrunde liegenden Benutzerzielen, den betroffenen Objekten und der Ausführungsumgebung

Familien-Weighting: Bestimmung der Zielgewichte für jede Aufgabenfamilie basierend auf der Stärke der upstream-Signale. Workflows mit stärkeren Signalen haben einen höheren Anteil in der Veröffentlichung.

Sampling und Auswahl: Entwicklung der gewichteten Muster zu ausführbaren Aufgabenkandidaten. Nach einem Testlauf werden nur die Kandidaten beibehalten, die ausführbar, reproduzierbar und in der Lage sind, signifikante Punktunterschiede zu erzeugen – von 178 generierten Kandidaten auf 157 reduziert

Optimierte Auswahl für Differenzierung: Auswahl von 105 öffentlichen Aufgaben aus den 157 Kandidaten mithilfe von gemischt-ganzzahliger linearer Programmierung (MILP), wobei drei Einschränkungen optimiert werden: Veröffentlichungsgröße, Familienabdeckung und Ranglistendifferenzierung

Die MILP zielt nicht darauf ab, „Vielfalt“ mechanisch zu maximieren, sondern macht drei Dinge explizit: Die Größe der öffentlichen Veröffentlichung, die Mindestabdeckung jeder Familie und die Fähigkeit, die Modelle wirklich voneinander zu trennen. Durch die Umwandlung dieser ursprünglich unscharfen Entscheidungen in überprüfbare Einschränkungen macht Claw-Eval-Live den Veröffentlichungsprozess selbst transparent.

Die Größe der aktuellen öffentlichen Veröffentlichung: 105 Aufgaben, 22 Aufgabenfamilien, 13 führende Modelle. Die Aufgaben werden in zwei Ausführungsumgebungen aufgeteilt: 87 dienstgestützte Geschäftsprozesse (umfassen 18 kontrollierte Dienste wie CRM, E-Mail, Kalender, Finanzen, Ticketsysteme) und 18 lokale Arbeitsbereichsreparaturaufgaben (Terminal-Betrieb, Umgebungsreparatur, Konfigurationsdebugging).

Jede Aufgabe ist nicht nur eine Anweisung, sondern eine vollständige ausführbare Bewertungseinheit: Aufgabenbeschreibung (task.yaml), Tool-Schnittstellen, Datenvorlagen und ein eigenes Bewertungsskript (grader.py). Die Bewertung basiert auf den Beweisprinzipien von Claw-Eval – in der gesamten Veröffentlichung sind die drei häufigsten Arten von deterministischen Beweisen: Datenabfrage (ob die richtigen Tools und Datenquellen aufgerufen wurden), Datengenauigkeit (ob Entitäten und Werte mit der Ground Truth übereinstimmen), Aktionenüberprüfung (ob die erforderlichen Statusänderungen tatsächlich stattgefunden haben). Erst wenn diese deterministischen Prüfungen nicht alle semantischen Aspekte abdecken können (z. B. Berichtsqualität, Zusammenfassungskohärenz), wird ein strukturiertes LLM-Judge eingeführt.

Von der Projektentwicklung her sind die beiden Arbeiten aufeinander aufbauend:

Claw-Eval löst das Problem der „vertrauenswürdigen Bewertung“ – es zeigt uns, was der Agent tatsächlich getan hat.

Claw-Eval-Live löst das Problem, dass der Fragenpool den aktuellen Anforderungen entspricht – es bringt den Benchmark von einem festen Fragenpool zu einer Momentaufnahme der aktuell relevantesten Workflows.

Was sehen wir, wenn der Benchmark der realen Welt näher kommt?

Die Ergebnisse der 13 führenden Modelle in der aktuellen Veröffentlichung sind direkt und ern