tau2-bench: Werkzeug-Agenten im Dialog mit simulierten Nutzern bewerten

Welches Problem der Benchmark adressiert

Ein Agent, der Werkzeuge aufruft, lässt sich nicht mit einer einzelnen Frage und einer einzelnen Antwort prüfen. In echten Kundenservice-Fällen verläuft das Gespräch über mehrere Runden, der Nutzer ändert zwischendurch sein Anliegen, und am Ende zählt, ob genau die richtigen Aktionen ausgeführt wurden. tau2-bench setzt an dieser Stelle an: Das Repository beschreibt sich selbst als Simulationsframework zur Bewertung von Kundenservice-Agenten über mehrere Domänen. Jede Domäne bringt vier Dinge mit, nämlich eine policy, die der Agent einhalten muss, eine Menge von tools, eine Menge von tasks und optional user tools für den Nutzer-Simulator. Damit ist die Zielgruppe klar umrissen: Entwickler, die einen Agenten gegen feste Regeln und messbare Aktionsfolgen stellen wollen, sowie Forschende, die Modelle in mehrrundigen Dialogen vergleichen. Wer dagegen eine Bibliothek sucht, mit der sich ein Agent produktiv betreiben lässt, findet hier nichts, denn der Zweck ist die Auswertung, nicht der Betrieb.

Agent, Nutzer-Simulator und Auswertung als getrennte Rollen

Das Framework trennt drei Beteiligte. Der Agent sieht die Domänenpolitik und die Werkzeuge, der Nutzer-Simulator spielt die Gegenseite und kann in manchen Domänen eigene Werkzeuge nutzen, und die Auswertung prüft anschließend die entstandene Trajektorie. Die Bewertung stützt sich laut der Dokumentation auf evaluation_criteria.actions, also eine erwartete Liste von Aktionen, und auf reward_basis, das die Belohnung steuert. Diese Konstruktion ist der eigentliche Kern des Projekts. Sie erlaubt es, einen Dialog nicht nur danach zu beurteilen, ob die Antwort höflich klingt, sondern danach, ob die richtigen Werkzeugaufrufe in der richtigen Reihenfolge stattgefunden haben. Das Orchestrierungsmodul unterstützt dabei zwei Betriebsarten: halbduplex, also rundenbasiert, und vollduplex, also mit gleichzeitiger Audioübertragung. Beide Modi laufen über dieselbe Domänenbeschreibung, was bedeutet, dass dieselbe Aufgabe einmal als Text und einmal als Sprachdialog gestellt werden kann. Der Preis dieser Trennung ist, dass die Qualität jeder Messung an der Qualität der Aufgabenstellung hängt, und genau dort hat das Projekt zuletzt nachgebessert.

Die fünf Domänen und was sie unterscheiden

Zur Auswahl stehen mock, airline, retail, telecom und banking_knowledge. Die ersten vier sind textorientiert und decken klassische Buchungs- und Servicedialoge ab. banking_knowledge geht darüber hinaus: Diese Domäne arbeitet mit einer Retrieval-Pipeline, Dokumentensuche, Embeddings und einer agentischen, shell-basierten Suche. Sie ist damit die einzige Domäne, in der der Agent nicht nur Werkzeuge aufruft, sondern Wissen aus Dokumenten ziehen muss, und sie benötigt ein eigenes Extra bei der Installation. mock dient offenbar als schlanke Vorlage, airline, retail und telecom bilden den Kern der ursprünglichen Aufgabenstellung. Wer seinen eigenen Anwendungsfall prüfen will, muss also zuerst entscheiden, ob er in eine dieser Domänen passt. Ein Bestellsystem für Fertigungsteile oder ein internes Ticketsystem lässt sich nicht einfach als sechste Domäne anhängen, ohne die Datenformate für policy, tools und tasks selbst zu bauen.

Installation und erster Lauf

Die Installation erfolgt über uv, nicht mehr über pip install -e ., wie die Upgrade-Notiz ausdrücklich festhält. Das Repository wird geklont, dann folgt uv sync für den Kern, der die Textdomänen airline, retail, telecom und mock abdeckt. Weitere Fähigkeiten kommen über Extras hinzu: uv sync --extra voice für Audio, uv sync --extra knowledge für die Retrieval-Domäne, uv sync --extra gym für die gymnasium-Schnittstelle zum Reinforcement Learning und uv sync --extra dev für pytest, ruff und pre-commit. Verlangt wird Python in der Spanne >=3.12, <3.14, zuvor war >=3.10 ausreichend. Für den Sprachmodus nennt die Anleitung Systemabhängigkeiten, auf macOS brew install portaudio ffmpeg. Zugangsdaten kommen in eine .env-Datei, die aus .env.example kopiert wird; die Anbindung läuft über LiteLLM, sodass laut README jeder unterstützte Anbieter funktioniert. Ein Lauf sieht dann so aus: tau2 run --domain airline --agent-llm gpt-4.1 --user-llm gpt-4.1 --num-trials 1 --num-tasks 5. Die Ergebnisse landen in data/simulations/ und lassen sich mit tau2 view durchsehen. Wer sich zuerst orientieren will, ruft tau2 intro auf. Bemerkenswert ist, dass Agent und Nutzer-Simulator getrennt konfiguriert werden. Damit lässt sich ein starkes Modell gegen einen schwachen Simulator stellen, was die Messung verzerren kann, ohne dass es auf den ersten Blick sichtbar wird.

Versionswechsel und die Vergleichbarkeitsfalle

Die Release-Historie zeigt, wie stark die Ergebnisse an der Version hängen. Version 1.0.1 vom Juli 2026 korrigiert Fehler in banking_knowledge-Aufgaben, und die Release-Notiz ist ungewöhnlich deutlich: Ergebnisse, die mit tau2-bench < 1.0.1 erzeugt wurden, sind nicht mit >= 1.0.1 vergleichbar, betroffene Leaderboard-Einreichungen wurden neu bewertet. Alte Ergebnisdateien lassen sich mit tau2 evaluate-trajs --fresh-tasks neu auswerten, und wer das Verhalten vor der Korrektur reproduzieren will, pinnt den Tag pre-v1.0.1. Andere Domänen sind laut Notiz nicht betroffen. Das ist ehrliche Kommunikation, aber es ist auch eine Warnung an jeden, der Zahlen aus verschiedenen Zeitpunkten nebeneinanderlegt. Version 1.0.0 vom März 2026 brachte Sprachmodus, Wissensdomäne und mehr als 75 Aufgabenkorrekturen, die auf einer Analyse von SABER (Cuadron et al., 2025) beruhen und falsche Erwartungsaktionen, mehrdeutige Anweisungen und unmögliche Bedingungen in airline, retail und banking bereinigt haben. Wer heute eine Baseline erhebt, sollte sie gegen 1.0.1 oder neuer erheben und das im Ergebnis festhalten.

Grenzen: wann der Benchmark das Falsche misst

Die erste Einschränkung ist struktureller Natur. Ein Benchmark mit festen Aufgaben belohnt Anpassung an diese Aufgaben. Wer ein Modell oder einen Prompt so lange verändert, bis airline und retail bessere Werte liefern, optimiert auf die Aufgabenverteilung, nicht auf den eigenen Anwendungsfall. Die zweite Einschränkung betrifft die Rollentrennung: Der Nutzer-Simulator ist selbst ein Sprachmodell. Ein Simulator, der zu kooperativ antwortet, macht Aufgaben leichter, ein zu widerspenstiger macht sie unlösbar. Die Dokumentation beschreibt user tools für den Simulator, aber die Materialbasis hier erlaubt keine Aussage darüber, wie stark die Simulatorqualität das Ergebnis verschiebt. Drittens der Sprachmodus: Vollduplex-Audio mit realtime-Anbietern ist aufwendig, verlangt Systempakete und bindet die Bewertung an die Audioqualität der Anbieter. Wer nur die Werkzeuglogik prüfen will, für den ist der Textmodus der günstigere Weg. Und schließlich ist der Benchmark kein Ersatz für Tests am eigenen System: Er simuliert, er integriert nichts.

Was tau2-bench von Aufzeichnungs- und Auswertungswerkzeugen unterscheidet

Eine naheliegende Alternative ist der Ansatz, echte oder nachgestellte Dialoge aufzuzeichnen und nachträglich zu bewerten. Solche Werkzeuge beurteilen, was tatsächlich passiert ist. tau2-bench geht den umgekehrten Weg: Es erzeugt die Dialoge selbst, mit einem Nutzer-Simulator und einer vorgegebenen Werkzeugumgebung, und kennt deshalb die Soll-Aktionsliste von Anfang an. Der Unterschied in der Praxis liegt in der Wiederholbarkeit. Ein aufgezeichneter Dialog lässt sich nur einmal bewerten, eine Aufgabe in tau2-bench beliebig oft, gesteuert über --num-trials. Der Preis dafür ist Realitätsnähe. Ein aufgezeichneter Verlauf enthält die Eigenheiten echter Nutzer, der Simulator nur die, die ihm das Modell zuschreibt. Für Regressionsmessungen an einem Agenten ist die Wiederholbarkeit wertvoller, für die Frage, ob ein System mit echten Anrufern zurechtkommt, die Aufzeichnung.

Wartung, Abhängigkeiten und Lizenz

Das Repository steht unter der MIT-Lizenz, was die Verwendung und Weitergabe mit wenigen Bedingungen erlaubt; wer den Code einbettet, sollte die Lizenzbedingungen selbst prüfen, da dieser Text keine Rechtsberatung ist. Der Wartungsaufwand liegt weniger im Projekt als in seinem Umfeld. Die Anbindung an Modellanbieter läuft über LiteLLM, das heißt, ein Anbieterwechsel oder eine geänderte Modellkennung kann einen Lauf unbrauchbar machen, ohne dass sich am Benchmark etwas geändert hat. Der Sprachmodus hängt zusätzlich an den realtime-Schnittstellen von OpenAI, Gemini und xAI, die sich unabhängig voneinander bewegen. Und die Versionshistorie zeigt, dass Aufgabenkorrekturen die Ergebnisse verschieben können, wie im Fall von 1.0.1. Wer den Benchmark über Monate einsetzt, sollte deshalb die Version im Ergebnis festhalten, die Aufgabenkorrekturen im Auge behalten und bei einem Sprung auf eine neue Version eine kleine Stichprobe mit tau2 evaluate-trajs --fresh-tasks neu auswerten, bevor alte und neue Zahlen in derselben Tabelle landen.

Redaktionelles Fazit

tau2-bench passt für Teams, die einen Werkzeug-Agenten gegen feste Domänenpolitiken und auswertbare Aktionslisten messen wollen, und für alle, die einen Nutzer-Simulator mit halb- oder vollduplexfähigem Modell brauchen. Wer einen produktionsreifen Agentenrahmen sucht, ist hier falsch, denn das Repository liefert Simulation und Auswertung, keine Laufzeitumgebung. Vor dem ersten Lauf ist zu klären, ob die eigene Fragestellung überhaupt eine der fünf Domänen trifft, ob der Rechner die Extras voice oder knowledge installieren kann und ob die Ergebnisse gegen Version 1.0.1 oder neuer erhoben werden, weil ältere banking_knowledge-Werte nicht vergleichbar sind.

Offizielle Quellen

1. License: MIT
2. Project website
3. README
4. Releases
5. sierra-research/tau2-bench on GitHub