ThinkingBox bewertet KI‑Agenten anhand von Datenbank‑Ergebnissen und wiederholter Zuverlässigkeit

4. Oktober 2026 – Microsoft‑Forscher haben ThinkingBox auf Hugging Face veröffentlicht und damit einen neuen Weg eingeführt, große Sprachmodelle (LLM‑Agenten) zu bewerten, die mit externen Werkzeugen interagieren. Im Gegensatz zu früheren Benchmarks, die eine korrekte natürlichsprachliche Antwort oder einen syntaktisch gültigen Tool‑Aufruf belohnten, misst ThinkingBox den endgültigen Backend‑Zustand und die Nebenwirkungen, nachdem ein Agent einen Geschäfts‑Workflow ausgeführt hat. Der Benchmark umfasst 507 verschiedene, zustandsbehaftete Geschäftsprozesse – etwa Auftragserfassung, Bestands‑Update oder Kunden‑Datensatz‑Änderung – die jeweils 20‑mal in isolierten Microsoft Copilot (MCP)‑Tool‑Sitzungen durchgeführt werden. Durch die Konzentration auf die tatsächlichen Datenbank‑Ergebnisse soll die Suite Zuverlässigkeitsprobleme sichtbar machen, die erst nach wiederholtem, real‑weltlichem Einsatz auftreten.

Wie ThinkingBox funktioniert

Jeder der 507 Workflows ist als Sequenz von Tool‑Aufrufen kodiert, die eine relationale Datenbank manipulieren. Der Benchmark führt für jeden Durchlauf eine vollständige Isolation der MCP‑Tool‑Umgebung durch, sodass keine Kontamination zwischen den Läufen Fehler verbergen kann. Nachdem der Agent einen Durchlauf abgeschlossen hat, prüft ThinkingBox den finalen Datenbank‑Snapshot und vergleicht ihn mit einer Ground‑Truth‑Spezifikation, die erwartete Zeilen, Spaltenwerte und Nebenwirkungen wie Audit‑Logs aufzählt. Das Bewertungsschema berücksichtigt nicht, ob der Agent eine flüssige textuelle Zusammenfassung erzeugt hat; es zeichnet ausschließlich auf, ob der Backend‑Zustand mit der Spezifikation übereinstimmt, ob unbeabsichtigte Änderungen aufgetreten sind und ob ein Tool einen Fehler gemeldet hat.

Die Evaluation umfasste 12 öffentlich verfügbare LLM‑Agenten, von Open‑Source‑Modellen bis hin zu kommerziellen Angeboten. Insgesamt wurden 121 680 gültige Versuche generiert – das Produkt aus 507 Workflows, 20 Wiederholungen und den 12 Modellen. Davon scheiterten 79 853 Versuche bereits in der ausführbaren‑Check‑Phase, weil der Agent entweder keinen erforderlichen Tool‑Aufruf tätigte oder einen Aufruf erzeugte, der nicht geparst werden konnte. Bemerkenswert ist, dass 67,24 % dieser fehlgeschlagenen Versuche dennoch ohne einen finalen Tool‑Fehler endeten, weil mindestens ein zustandsverändernder Tool‑Aufruf vor dem Abbruch erfolgt war. Dieses Muster verdeutlicht die Diskrepanz zwischen dem scheinbaren Erfolg eines Agenten und den verborgenen Inkonsistenzen, die in der Datenbank verbleiben.

Wesentliche Ergebnisse

Wenn ein Versuch den ausführbaren Check nicht bestand, erfasste der Benchmark drei Abweichungs‑Kategorien. Falsche Feldwerte traten in 77,61 % der fehlgeschlagenen Versuche auf, was zeigt, dass Agenten häufig falsche Daten schreiben, selbst wenn ein Tool‑Aufruf erfolgreich war. Unbeabsichtigte Effekte – Aktionen, die Teile der Datenbank veränderten, die im Workflow nicht spezifiziert waren – wurden in 43,30 % der Fehlversuche beobachtet, während fehlende Effekte – erwartete Änderungen, die nie realisiert wurden – in 25,36 % der Fälle auftraten. Die Prozentsätze überschneiden sich, weil ein einzelner Lauf mehrere Fehlertypen gleichzeitig aufweisen kann. Diese Zahlen demonstrieren, dass die Mehrheit der tool‑gesteuerten Fehlfunktionen die Datenbank dennoch in einem inkonsistenten oder nur teilweise korrekten Zustand zurücklässt.

Die Leistung variierte stark zwischen den Modellen. Claude Opus 5.5 erreichte die höchste pass@1‑Rate und bestand 67,16 % der 121 680 Versuche beim ersten Versuch. Kimi‑K3 zeigte ein anderes Profil: Es löste 93,89 % der Aufgaben mindestens einmal über die 20 Wiederholungen hinweg, jedoch nur 13,41 % der Durchläufe in allen 20 Wiederholungen erfolgreich. Dieser Kontrast unterstreicht die Bedeutung, Zuverlässigkeit über wiederholte Ausführungen zu messen, anstatt nur einen einzelnen Best‑Case‑Durchlauf zu betrachten. Die übrigen Modelle lagen zwischen diesen Extremen, viele erzielten pass@1‑Raten unter 50 % und wiesen erhebliche Schwankungen zwischen den Wiederholungen auf.

Einschränkungen des Benchmarks

ThinkingBox ist bewusst auf einen kuratierten Satz von Geschäfts‑Workflows beschränkt, und die Autoren betonen, dass die Zahlen nicht jede Produktions‑Situation abbilden, der ein Unternehmen begegnen könnte. Der Benchmark isoliert jeden Versuch in einer frischen MCP‑Sitzung, wodurch der Einfluss von langfristiger Zustandsakkumulation, Caching oder abteilungsübergreifenden Abhängigkeiten, die in Live‑Systemen existieren, entfernt wird. Darüber hinaus konzentriert sich die Bewertung auf relationale Datenbank‑Ergebnisse; Agenten, die mit Nicht‑SQL‑Diensten, Dateisystemen oder externen APIs interagieren, werden nicht berücksichtigt. Schließlich behandelt die Metrik jede Abweichung von der Ground‑Truth‑Spezifikation als Fehlschlag, selbst wenn die Abweichung in einem konkreten Geschäftskontext harmlos sein könnte.

• 79 853 Versuche scheiterten am ausführbaren Check von insgesamt 121 680 Versuchen.
• 67,24 % der fehlgeschlagenen Versuche endeten sauber ohne einen finalen Tool‑Fehler.
• 77,61 % der Fehlversuche berichteten falsche Feldwerte in der Datenbank.
• 43,30 % der Fehlversuche erzeugten unbeabsichtigte Nebenwirkungen.
• 25,36 % der Fehlversuche ließen erwartete Effekte ausfallen.
• Claude Opus 5.5 führte mit 67,16 % Erfolg die höchste pass@1‑Rate an.
• Kimi‑K3 löste 93,89 % der Aufgaben mindestens einmal, jedoch nur 13,41 % in allen 20 Durchläufen.

Die praktischen Implikationen sind sofort für Entwickler, die KI‑gesteuerte Automatisierung bauen. Indem ThinkingBox aufzeigt, wie oft Agenten stillschweigend falsche Daten schreiben oder erforderliche Updates verpassen, fördert es einen Wandel von „funktioniert der Tool‑Aufruf?“ zu „ist die Datenbank am Ende korrekt?“. Teams können den Benchmark nun nutzen, um Robustheitstests zu priorisieren, kompensierende Transaktionen hinzuzufügen oder Prompt‑Designs zu überarbeiten, die ein idempotentes Verhalten besser erzwingen. Die Daten geben den Anbietern zudem ein konkretes Ziel vor: die Wiederholbarkeit über mehrere Durchläufe zu verbessern, nicht nur eine hohe Einzeldurchlauf‑Pass‑Rate zu erreichen. Während Unternehmen LLM‑Agenten für kritische Back‑Office‑Aufgaben einsetzen, wird die Fähigkeit, zu zertifizieren, dass die zugrunde liegenden Daten vertrauenswürdig bleiben, zu einem klaren Wettbewerbs‑Differenzierungsmerkmal.

Für die Zukunft planen Microsoft und die breitere Forschungsgemeinschaft, ThinkingBox um weitere Workflow‑Kategorien, umfangreichere Nebenwirkungs‑Verfolgung und die Integration in Continuous‑Integration‑Pipelines zu erweitern. Der Benchmark ist bereits auf Hugging Face verfügbar, sodass jeder die gleichen 507 Workflows gegen eigene Agenten ausführen und die Ergebnisse mit dem veröffentlichten Basis‑Benchmark vergleichen kann. Durch die offene und wiederholbare, ergebnis‑fokussierte Evaluation ist ThinkingBox dabei, die Art und Weise zu verändern, wie die Branche die Zuverlässigkeit von KI‑Agenten misst – und verlagert das Gespräch von oberflächlicher Korrektheit hin zu der tieferen Frage, ob die Datenbank – die ultimative Quelle der Wahrheit – das beabsichtigte Geschäftsergebnis widerspiegelt.