Dein Agent-Eval-Maßstab ist veraltet — EVA-Bench 2.0 setzt einen neuen

ServiceNow AI hat gerade EVA-Bench 2.0 veröffentlicht — ein öffentliches Agent-Evaluation-Dataset mit 121 Tools, 3 Domains und 213 Szenarien. Wer dieses Jahr einen Agent-Pilot abgenickt hat, sollte aufhorchen: Der Benchmark, den dein Team wahrscheinlich nutzt — irgendeine Kombination aus internen Demos und Bauchgefühl — hat jetzt einen Namen, und der lautet "nicht ausreichend." Unsere Einschätzung: EVA-Bench 2.0 ist das erste externe Artefakt, das konkret genug ist, um eine echte Diskussion über Production-Readiness zu verankern. Wer seine eigene Eval-Oberfläche noch nicht definiert hat, dem hat sie gerade jemand anderes definiert.

Was sich diese Woche im Agent-Benchmarking verändert hat

EVA-Bench 2.0, von ServiceNow AI auf Hugging Face veröffentlicht, erweitert das ursprüngliche EVA-Bench um ein strukturiertes Dataset, das Agents über realistische Multi-Tool-Workflows testet. Der Benchmark ist in 3 klar abgegrenzte Domains unterteilt — jede repräsentiert eine Klasse von Enterprise-Workloads — und deckt 121 Tools mit 213 verschiedenen Szenarien ab, die gezielt Failure-Modi aufdecken, die Single-Tool-Evals systematisch übersehen.

Die Design-Philosophie dahinter ist bewusst gewählt. Statt zu testen, ob ein Modell eine einzelne API korrekt aufruft, verkettet EVA-Bench 2.0 Tool-Use über realistische Sequenzen — genau dort, wo produktive Agents tatsächlich scheitern. Ein Szenario kann erfordern, dass ein Agent eine Knowledge Base abfragt, ein Ticketing-System gegenprüft und einen strukturierten Output schreibt — in Reihenfolge, mit State zwischen den Schritten. Das ist ein fundamental anderer Test als "hat das Modell den richtigen Funktionsnamen gewählt."

Das Dataset ist öffentlich, auf Reproduzierbarkeit ausgelegt und MIT-lizenziert. Dein Engineering-Team kann es heute pullen, eigene Modelle dagegen laufen lassen und Zahlen generieren, die zumindest mit dem vergleichbar sind, was andere berichten. Das allein stellt die meisten internen Eval-Rigs in den Schatten, die wir bei Unternehmen gesehen haben, die ihren ersten Agent in die Produktion bringen.

Warum dein aktueller Eval-Prozess das wahrscheinlich nicht überlebt

Die meisten Agent-Pilots, die wir 2026 auditieren, haben dieselbe Evaluierungsarchitektur: eine Reihe handgefertigter Happy-Path-Demos, ein paar Edge Cases, die jemand im Team in einem Slack-Thread hatte, und eine implizite Messlatte nach dem Motto "der PM hat's nach dem Donnerstags-Review abgenickt." Dieser Prozess findet die Bugs, die dein Team ohnehin schon kannte. Er findet nicht die Failure-Modi, die entstehen, wenn ein Agent auf Tool-Kombinationen trifft, die er noch nie gesehen hat — oder wenn ein API-Call im 4. Schritt ein Schema zurückgibt, das dein Prompt nie antizipiert hat.

Die 121-Tool-Oberfläche von EVA-Bench 2.0 ist bedeutsam, weil sie eine Frage erzwingt, die die meisten Teams noch nie formal gestellt haben: Wie viele Tools berührt dein Agent tatsächlich in der Produktion — und hast du das Verhalten über alle bedeutsamen Kombinationen hinweg evaluiert? Bei einem Customer-Support-Agent, der ein CRM, eine Knowledge Base, ein Ticketing-System und eine E-Mail-API anspricht, ist die kombinatorische Oberfläche groß. Das Regressionsrisiko bei jedem Modell-Upgrade ist real. Ohne strukturiertes Eval merkst du eine Regression erst, wenn ein Kunde dich darauf hinweist.

Da ist auch noch der Vendor-Selection-Aspekt. Wer Third-Party-Agent-Frameworks oder Foundation Models für den nächsten Build evaluiert, bekommt mit EVA-Bench 2.0 ein gemeinsames Vokabular, um vergleichbare Zahlen von Anbietern einzufordern. "Wie performt euer Modell auf EVA-Bench 2.0 Domain 2" ist eine belastbarere Procurement-Frage als "können Sie uns eine Demo zeigen, die wie unser Use Case aussieht."

Jetzt ein Domani AI Architecture Audit buchen →

Der Montags-Schritt hängt davon ab, wo dein Agent im Lifecycle steht

Die richtige Reaktion auf EVA-Bench 2.0 ist nicht "den vollständigen Benchmark auf alles laufen lassen." Sie ist diagnostisch. Beantworte zunächst 5 Fragen zu deinem aktuellen Agent:

• Wie viele verschiedene Tools ruft er in der Produktion auf? Wenn es mehr als 5 sind, hast du mit ziemlicher Sicherheit unentdeckte Failure-Modi in Multi-Step-Sequenzen.
• Hast du eine schriftliche Eval-Suite, getrennt von deinen Demo-Skripten? Wenn Demo und Eval dasselbe Artefakt sind, hast du kein Eval.
• Hast du das Verhalten nach dem letzten Modell-Versions-Bump getestet? Die meisten Teams haben seit dem initialen Build keinen strukturierten Regressionstest mehr durchgeführt.
• Was ist deine Fehler-Taxonomie? Kannst du Failures nach Typ kategorisieren — falsche Tool-Auswahl, schlechte Parameter-Extraktion, halluzinierter Output — oder weißt du nur, dass etwas schiefgelaufen ist?
• Hast du ein Domain-Mapping? EVA-Benchs 3-Domain-Struktur ist eine nützliche Forcing Function: Kannst du den Workload deines Agents einer kohärenten Domain zuordnen, oder sprawlt er über Kontexte, für die er nie konzipiert wurde?

Wenn du 3 oder mehr Fragen mit "nein" oder "weiß ich nicht" beantwortet hast, ist der Montags-Schritt klar: Scope einen strukturierten Eval-Sprint, bevor du das nächste Mal in die Produktion pushst. Pull das EVA-Bench 2.0 Dataset von Hugging Face, identifiziere, welche der 3 Domains am ehesten zur Tool-Oberfläche deines Agents passt, und lasse dein aktuelles Modell gegen die relevante Szenario-Teilmenge laufen. Du wirst nicht alles abdecken — aber du hast eine dokumentierte Baseline. Das ist mehr, als die meisten Teams, die heute Agents ausliefern, vorweisen können.

Wer noch früher im Cycle ist und gerade evaluiert, ob man eine Agent-Capability bauen oder kaufen soll: Nutze EVA-Bench 2.0 als RFP-Gerüst. Fordere jeden Modell- oder Framework-Anbieter auf, domain-spezifische Scores vorzulegen. Wer das nicht kann, gibt damit bereits ein Signal.

Was das kostet — und was der Verzicht noch mehr kostet

Einen Teil von EVA-Bench 2.0 zu betreiben ist nicht umsonst. Ein strukturierter Eval-Sprint — relevante Szenarien scopen, den Agent für loggbare Outputs instrumentieren, Failure-Modi analysieren — kostet je nach aktuellem Observability-Setup 2 bis 4 Wochen Engineering-Zeit. Wer heute keine Eval-Infrastruktur hat, muss die erste Woche damit rechnen, den Harness zu bauen, bevor eine einzige nützliche Zahl entsteht.

Die Alternativkosten sind schwerer zu beziffern, aber im Nachhinein leicht zu erkennen: ein Modell-Upgrade, das leise einen kritischen Workflow regressiert; ein Production-Incident, der auf einen Tool-Chaining-Fehler zurückgeht, den deine Demo nie berührt hat; eine Procurement-Entscheidung, die vertretbar wirkte, bis die Zahlen eines Anbieters sich als Cherry-Picking auf einem Benchmark herausstellten, der nicht zu deinem Stack passt. EVA-Bench 2.0 eliminiert diese Risiken nicht — kein Benchmark tut das. Aber es gibt dir einen gemeinsamen externen Standard, gegen den du Druck aufbauen kannst. Das ist eine andere Kategorie von Absicherung als "es hat funktioniert, als wir's dem Board gezeigt haben."