BenchmarksImplementierung 01 / 01

AgentLens - unser eigener Benchmark

Der Benchmark, den die Basics-Stufe fordert, gebaut: echte Agenten-Aufgaben in zwei echten Harnessen (Pi und Hermes), mehrfach je Modell, mit klickbarem Ausführungsprotokoll. Nicht ob ein Modell scheitert, sondern wo, wann und warum.

Implementierungen

Je ein Datenblatt zu einem System, das dieses Bauteil umsetzt - immer nach demselben Raster.

Auf der Basics-Stufe steht ein unbequemer Satz: Dein eigener Benchmark schlägt jede Rangliste. Wir nehmen ihn ernst - AgentLens ist dieser eigene Benchmark, gebaut auf genau dieser Plattform und gefüttert mit genau den Aufgaben, die hier auch Menschen ihren Agenten stellen.

Warum noch ein Benchmark?

Öffentliche Benchmarks liefern eine Zahl. Die Zahl beantwortet nicht, was in der Praxis entscheidet: Hat das Modell den Tool-Call gar nicht erst versucht und ihn nur beschrieben (einen Ghost-Call)? Hat der Parser einen syntaktisch kaputten Aufruf verworfen? Ist die Kette bei Schritt 4 gekippt - und was stand in Schritt 3? Wer ein mittelgroßes Modell für einen produktiven, lokalen Agenten-Stack auswählt, braucht diese Diagnose, keine Note.

AgentLens speichert deshalb zu jedem Lauf das vollständige Ausführungsprotokoll und bewertet auf Schritt-Ebene. Der Preis: mehr Speicher und ein Normalisierungs-Layer. Der Gewinn: Diagnose statt Leaderboard.

Die Methode in vier Sätzen

  1. Echte Aufgaben. Keine Needle-in-Haystack-Rätsel, sondern Arbeitsaufträge: Dateien anlegen und umbauen, ein Server-Log auswerten, eine Kundenliste bereinigen, einen Termin gegen drei Kalender diplomatisch platzieren, ein CRM aufräumen, ohne eine Notiz zu verlieren - zwei davon sind wörtlich die Parcours-Aufgaben dieser Plattform. Dazu Gedächtnis-Aufgaben über mehrere Gesprächs-Turns, mit Ablenkung dazwischen.
  2. Echte Harnesse. Jede Aufgabe läuft im vollständigen System aus Modell plus Agent-Harness - einmal unter PiExtern - Öffnet in neuem Tab, einmal unter dem Hermes-Agenten. Fehler entstehen in der ganzen Kette (Chat-Template, Decoding, Parser, Retry-Logik), also messen wir die ganze Kette. „Qwen unter Pi“ und „Qwen unter Hermes“ sind zwei verschiedene Ergebnisse - und dieser Unterschied ist eine der spannendsten Auswertungen.
  3. Mehrfach statt einmal. Jede Zelle (Aufgabe × Modell × Harness) läuft mehrfach. Wir zeigen getrennt, was ein Modell manchmal schafft und was es immer schafft - für Produktionsentscheidungen ist die Differenz die eigentliche Aussage.
  4. Deterministische Urteile. Bestanden ist, was der Prüf-Code am Endzustand nachmessen kann: Datei da, Kalender korrekt, kein Vermerk verloren. Kein LLM benotet ein LLM.

Scheitert ein Lauf, ordnet der Trace-Analyzer ihn einer Fehlerklasse zu - Ghost-Call, Parser-Verwurf, Endlosschleife, Fehler-Spirale nach einem Tool-Error, vergessene Instruktionen bei wachsendem Kontext, vorzeitiges „fertig!“. Ausfälle unserer Infrastruktur zählen dabei nie gegen das Modell.

Was du hier sehen kannst

Als Mitglied (kostenlos) siehst du ausgewählte Modelle in der Ergebnisübersicht und kannst einzelne Sitzungsprotokolle Schritt für Schritt durchklicken - jeder Tool-Call, jedes Ergebnis, jeder Fehlversuch.

Als Pro-Mitglied siehst du alles: die volle Vergleichsmatrix über alle Modelle und beide Harnesse, die Fehlerklassen-Fingerabdrücke, Harness-Deltas, Ausdauer-Kurven und jeden einzelnen Trace - plus die Empfehlungen, welche Bausteine aus Block II (Parser, Retry, Kontext-Verdichtung) die gefundenen Schwächen einer Kombination gezielt ausgleichen.

Neue Modelle stecken wir ein, sobald es sie gibt - die Endpunkte sind reine Konfiguration. Sobald Qwen 3.8 erscheint, läuft es hier gegen dieselben Aufgaben wie alle davor.

Zur Ergebnisübersicht