Im April 2026 bauten Forscher der UC Berkeley einen KI-Agenten, der in sieben von acht führenden Agenten-Benchmarks 100% erzielte, darunter SWE-bench Verified und Pro, Terminal-Bench, WebArena, FieldWorkArena und CAR-bench. Keine einzige der zugrunde liegenden Aufgaben hatte er tatsächlich gelöst. Stattdessen las er den Bewertungscode und nutzte dessen Lücken aus: eine zehnzeilige Testdatei, die jedes Ergebnis als "bestanden" umschrieb, ein ausgetauschter curl-Befehl, der stets die erwartete Antwort zurückgab, eine Konfigurationsdatei, die den Lösungsschlüssel direkt offenlegte. Von 13 getesteten Benchmarks wurde jeder Einzelne als ausnutzbar eingestuft.
Dieses Ergebnis ist keine Geschichte über ein cleveres Forscherteam. Es ist eine Warnung, was eine bestandene Punktzahl auf einem öffentlichen Leaderboard tatsächlich aussagt, bevor Sie einen Agenten vor echte Kunden, echte Rechnungen oder echte Infrastruktur stellen: nicht viel, es sei denn, Sie haben den Test selbst gebaut.
Warum Agenten-Evals keine Modell-Evals sind
Die meisten Teams, die KI bewerten, übernehmen noch Gewohnheiten aus der Modellbewertung: einen Prompt eingeben, die Ausgabe bewerten, die Punktzahl mit einem Leaderboard vergleichen. Bei einem Agenten funktioniert das nicht, weil das, was Sie bewerten, keine Antwort ist, sondern eine Trajektorie: der Systemprompt, die Anfrage des Nutzers, jeder Tool-Aufruf des Agenten mit seinen Argumenten und Rückgabewerten, jede ausgeführte Retrieval-Abfrage, das Zwischenergebnis des Reasonings und das Endergebnis. Eine korrekt wirkende Antwort kann aus dem falschen Tool mit falschen Argumenten und einem glücklichen Treffer stammen. Eine falsch wirkende Antwort kann aus einem eigentlich korrekten Vorgehen stammen, das durch eine einzige fehlerhafte API-Antwort entgleist ist. Wer nur die Endantwort bewertet, verdeckt genau diesen Unterschied, und genau diese Lücke nutzt das Ausreizen von Benchmarks aus.
Unternehmen, die 2026 eigene Evaluierungspipelines aufbauen, setzen zunehmend auf sechs Dimensionen, die jeweils unabhängig bewertet werden, statt sie in eine einzige Bestanden-Nicht-bestanden-Zahl zu pressen. Das entspricht einem Arbeitsmuster, das aus produktiven Agenteneinsätzen abgeleitet wurde:
| Dimension | Was geprüft wird | Typischer Fehler, wenn übersprungen |
|---|---|---|
| Tool-Auswahl | Richtiges Tool gewählt, oder zu Recht keins | Erfundener Tool-Aufruf, falsches Tool für die Aufgabe |
| Argumentextraktion | Argumente schemakonform und inhaltlich korrekt | Richtiges Tool, aber fehlerhaftes Datum oder fehlendes Feld |
| Ergebnisnutzung | Agent hat die Tool-Ausgabe tatsächlich verwendet | Ergebnis ignoriert, Modell rät stattdessen selbst |
| Fehlerbehebung | Wiederholung, Ausweichlösung oder Eskalation bei Fehlern | Absturz, vorgetäuschter Erfolg, blinde Wiederholung |
| Plankohärenz | Keine Schleifen, keine Sackgassen, richtige Tiefe | Endlosschleife, verfrühter Abschluss des Plans |
| Aufgabenabschluss | Das Gesamtziel wurde Ende-zu-Ende erreicht | Jeder Einzelschritt grün, Endergebnis trotzdem falsch |
Wer weniger als vier dieser Dimensionen testet, erhält eher eine Wahrscheinlichkeitsaussage als ein belastbares Urteil darüber, ob der Agent einsatzbereit ist.
Warum öffentliche Benchmarks allein nicht ausreichen
Öffentliche Benchmarks wie AgentBench, WebArena, SWE-bench, MedAgentBench und tau-bench sind nützlich, um die reine Leistungsfähigkeit zwischen Modellen zu vergleichen, und bilden eine sinnvolle Untergrenze. Keiner von ihnen wurde entwickelt, um Ihre Datenschemata, Ihre internen Tools oder Ihre Compliance-Regeln zu testen, und bereits 2026 galt weithin als belegt, dass sie gesättigt und manipulierbar geworden waren, noch bevor der Berkeley-Exploit diesen Punkt unübersehbar machte. Eine hohe Leaderboard-Punktzahl ist ein Signal über das Modell in einer Laborumgebung. Sie ist kein Beweis dafür, dass derselbe Agent, eingebunden in Ihr CRM und Ihren Freigabeprozess, sich in Betriebsstunde 400 des Produktivverkehrs gleich verhält.
Die praktische Konsequenz: Öffentliche Benchmarks gehören an den Anfang eines Evaluierungsprogramms, nicht an dessen Ende. Sie zeigen, ob ein Kandidatenmodell eine vernünftige Mindestschwelle erreicht, bevor Sie in den Aufbau von etwas darauf investieren.
Die Evaluierung aufbauen, die über den Release wirklich entscheidet
Ein praxistaugliches Muster, das dem entspricht, wie Unternehmen dies 2026 strukturieren, besteht aus drei Ebenen:
1. Ein privates, zurückgehaltenes Evaluierungsset aus Ihren eigenen Arbeitsabläufen. Schreiben Sie Szenarien mit Ihren tatsächlichen Tools, Ihren Datenformen und den Grenzfällen, von denen Ihr Team bereits weiß, dass sie Probleme verursachen: der Kunde mit zwei offenen Tickets, die Rechnung mit Währungsabweichung, die Anfrage, die abgelehnt werden muss. Das ist das Set, das ein Modell noch nie gesehen hat, und genau darin liegt der Sinn. Einen öffentlichen Benchmark kann man vorab einstudieren; ein intern gepflegtes privates Set nicht.
2. Bewertung pro Dimension, eingebunden in die CI, nicht eine einzelne Erfolgsquote. Koppeln Sie Releases an Schwellenwerte je Dimension (Tool-Auswahl, Argumentextraktion und die übrigen), damit sich eine Verschlechterung bei der Fehlerbehebung nicht hinter einer starken Gesamtquote beim Aufgabenabschluss verstecken kann. Teams, die das gut umsetzen, behandeln einen Rückgang in einer einzigen Dimension als Grund, den Release zu blockieren, genauso wie ein Sicherheitsteam einen Build wegen eines einzigen fehlgeschlagenen Checks blockiert, statt ihn gegen die bestandenen Checks zu verrechnen.
3. Eine Rückkopplungsschleife von der Produktion zurück ins Evaluierungsset. Jeder reale Fehler, auf den ein Agent im Produktivbetrieb trifft, ist ein kostenloser Regressionstest, wenn jemand die Trajektorie erfasst und dem privaten Set hinzufügt. Wer diesen Schritt auslässt, zahlt für denselben Fehlermodus zweimal: einmal, wenn ihn ein Kunde trifft, und ein weiteres Mal Monate später, wenn eine neue Agentenversion ihn wieder einführt.
Was das vor dem nächsten Go-live Ihres Agenten bedeutet
Nichts davon erfordert ein Forschungslabor. Es erfordert die Entscheidung, bevor ein Agent live geht, welche Beweise auf Trajektorienebene Ihr Team zum Go-live bewegen würden, und die Weigerung, eine öffentliche Leaderboard-Zahl diese Entscheidung ersetzen zu lassen. Wenn Ihr Unternehmen agentenbasierte KI-Pilotprojekte betreibt und der einzige Beweis hinter einer Go-live-Entscheidung eine Demo und eine Benchmark-Punktzahl ist, dann ist das genau die Lücke, die das Berkeley-Ergebnis offengelegt hat, und sie ist eher die Regel als die Ausnahme.
Hier verbindet sich die Evaluierung auch mit dem Messproblem, das wir in unserem Beitrag zur ROI-Messung bei Agentic AI behandelt haben: Eine Kennzahl, der auf Trajektorienebene nicht zu trauen ist, kann auch keine Skalierungsentscheidung tragen, egal wie sauber das übergeordnete Dashboard aussieht. Beide Disziplinen, Agenten-Evals und ROI-Messung, müssen gemeinsam aufgebaut werden, nicht nacheinander nachgerüstet.
Wenn Sie ein Agentic-AI-Rollout planen und die Evaluierungsebene von Anfang an zusammen mit dem Workflow entwerfen möchten, statt sie erst nach einem ins Stocken geratenen Pilotprojekt nachzurüsten, setzt genau dort unser Ansatz an, und unser Services-Team hat bereits private Evaluierungssets für Abläufe aufgebaut, die sich eine stille Regression nicht leisten konnten. Wie sich das verhält, sobald ein Agent bereits live ist, lesen Sie in unserem Beitrag zu AI Agent Observability. Nehmen Sie Kontakt auf, bevor der Go-live-Termin Ihres nächsten Agenten dessen einziger Nachweis der Einsatzbereitschaft wird.
