ThinkingBox prüft, ob KI-Agenten ihre Arbeit wirklich erledigen

Von /

Ein Support-Agent meldet, eine Reklamation sei erledigt. Tatsächlich hat er das Ticket im falschen Status geschlossen, obwohl die Sendung noch beim Paketdienst festhängt. Wer nur die Antwort des Agenten oder seine Werkzeugaufrufe liest, übersieht den Fehler womöglich. Entscheidend ist, was nach dem Durchlauf im Geschäftssystem steht.

Genau dort setzt ThinkingBox an. Microsoft hatte die Testumgebung und den zugehörigen Benchmark bereits im August vorgestellt. In einem gemeinsamen Beitrag mit Hugging Face vom 3. Oktober erläutert das Team nun die Anbindung an OpenEnv und neue Auswertungen wiederholter Agentenläufe. Der Benchmark lässt sich damit über eine standardisierte Umgebung ansprechen; die ausführbaren Testfälle stammen weiterhin aus Microsofts gesondertem Daten-Repository. Microsofts frühere Projektvorstellung macht die zeitliche Einordnung deutlich: Neu ist nicht die Grundidee des Benchmarks, sondern vor allem sein jetzt dokumentierter Zugang über OpenEnv und die aktuelle Analyse.

Ein korrekter Werkzeugaufruf genügt nicht

ThinkingBox-Bench umfasst 507 synthetisch rekonstruierte Geschäftsaufgaben aus Bereichen wie Handel, Reise, Autoversicherung, Neobank und IT-Support. Ein Test beschreibt den anfänglichen Zustand von Datensätzen, das Anliegen eines simulierten Nutzers, die verfügbaren MCP-Werkzeuge und den Zustand, der am Ende erreicht werden soll. Der Nutzer kann Angaben, etwa eine Buchungsnummer, erst auf Nachfrage liefern. Für jeden Versuch startet die Umgebung eine eigene Sitzung mit frisch initialisierten Daten; so kann ein früherer Lauf den nächsten nicht beeinflussen. Microsoft beschreibt den Aufbau hier.

Nach dem Durchlauf vergleicht die Auswertung die tatsächlich geänderten Datensätze und weitere Nebenwirkungen mit dem erwarteten Ergebnis. Sie schreibt dem Agenten dabei nicht vor, in welcher Reihenfolge er Werkzeuge benutzen muss. Bei 477 Aufgaben reichen Zustandsprüfungen aus; bei weiteren 30 kommen eng gefasste Bewertungen der Antwort hinzu, etwa wenn ein erforderlicher Hinweis nicht als Datenbankfeld vorliegt. Das ist für Entwickler wichtig: Ein erfolgreich aufgerufenes Werkzeug kann trotzdem den falschen Datensatz ändern oder eine zusätzlich benötigte Aktion auslassen. Die technische Einordnung im gemeinsamen Beitrag unterscheidet deshalb ausdrücklich zwischen Ablauf und Ergebnis.

Die OpenEnv-Dokumentation zu ThinkingBox beschreibt einen Adapter mit einer Reset-/Step-Schnittstelle, der nach einer abgeschlossenen Episode ein binäres Testergebnis liefert. Er ist derzeit auf Evaluierung ausgelegt, nicht als fertige Trainingslösung. Für einen eigenen Lauf genügen die veröffentlichten Testdaten allein nicht: Der ausführbare Benchmark benötigt auch das ThinkingBox-Framework, die extern gestarteten Dienste und konfigurierte Modell-Endpunkte. Die aktuelle Dokumentationsseite bezieht sich auf den Hauptentwicklungszweig von OpenEnv, für den sie eine Installation aus dem Quellcode nennt.

Einmal richtig ist noch nicht zuverlässig

Ein einzelner erfolgreicher Lauf sagt wenig darüber aus, ob ein Agent dieselbe Aufgabe beim nächsten Mal wieder bewältigt. Die Autoren führten deshalb jede Aufgabe wiederholt aus. Ihre Auswertung trennt drei Fragen: Wie hoch ist die Erfolgsquote einzelner Versuche? Bei wie vielen Aufgaben gelingt innerhalb von 20 Versuchen wenigstens einer? Und bei wie vielen gelingen tatsächlich alle 20 beobachteten Versuche? Der zweite Wert beschreibt Reichweite, der dritte die beobachtete Konstanz. Er ist keine Zusage, dass ein Agent außerhalb des Tests immer korrekt arbeitet. Die Definitionen und Resultate stehen im aktuellen Projektbeitrag.

Die Unterschiede sind beträchtlich. In den dort berichteten Versuchen bewältigte Kimi-K3 insgesamt 476 der 507 Aufgaben mindestens einmal, aber nur 68 Aufgaben in allen 20 Durchläufen. Claude Opus 5.5 erreichte bei 241 Aufgaben alle 20 Erfolge. Zugleich lag seine durchschnittliche Erfolgsquote pro Versuch bei 67,16 Prozent. Diese Zahlen stammen aus der Untersuchung der Projektbeteiligten, nicht aus einer unabhängigen Vergleichsmessung. Auch die Aufgaben sind künstlich nachgebildete Geschäftsprozesse; reale Berechtigungen, Ausfälle und Unternehmensregeln können andere Ergebnisse hervorbringen. Quelle: Microsoft und Hugging Face.

Das begleitende Paper, zuletzt am 1. Oktober überarbeitet, verwendet zusätzlich eine statistisch abgeleitete Wiederholungsmetrik. Sie sollte nicht mit der im Blogbeitrag ausgewiesenen Zahl der Aufgaben verwechselt werden, die in den tatsächlich aufgezeichneten 20 Läufen ausnahmslos bestanden wurden. Wer Agentenmodelle vergleichen will, muss deshalb nicht nur den Prozentwert, sondern auch seine Definition und den Versuchsaufbau lesen.

Was Unternehmen daraus ableiten können

Für produktive Agenten ist der Benchmark weniger eine Einkaufsliste für Modelle als ein Muster für eigene Tests. Ein Unternehmen kann beispielsweise nach einem Testlauf prüfen, ob eine Bestellung wirklich erstattet wurde, ob das richtige Kundenkonto betroffen ist und ob kein zweites Ticket versehentlich geschlossen wurde. Wiederholte Durchläufe zeigen dann, wie oft derselbe Ablauf gelingt. Gerade bei Änderungen, die sich schwer rückgängig machen lassen, sollten Systeme den tatsächlichen Zustand kontrollieren und gegebenenfalls einen Menschen einbeziehen, statt sich auf die Erfolgsmeldung des Modells zu verlassen.

ThinkingBox macht dafür Code und ausführbare Testfälle zugänglich; die OpenEnv-Anbindung erleichtert den Anschluss an bestehende Evaluierungsabläufe. Aus den Ergebnissen folgt jedoch weder, dass ein Modell in jeder Unternehmensumgebung gleich abschneidet, noch dass 20 erfolgreiche Wiederholungen eine Fehlerquote von null beweisen. Der praktische Fortschritt liegt darin, den richtigen Maßstab anzulegen: Nicht die überzeugendste Antwort zählt, sondern der überprüfbare Zustand, den der Agent hinterlässt.

Quellen

Nach oben scrollen