τ²-bench: Messung der Kosten von Dual-Control in konversationellen KI-Agenten

Ich habe in den letzten Wochen die τ-bench-Reihe verfolgt, und τ²-bench (arXiv:2506.07982) ist das Papier, auf das ich gewartet habe: Es stellt endlich die Frage, was passiert, wenn der Benutzer kein passiver Informationsgeber ist, sondern ein aktiver Teilnehmer mit eigenem Toolset. Für jeden, der einen konversationellen Buchhaltungs-Agenten entwickelt, war diese Lücke schon immer unübersehbar.

Das Paper

Victor Barres, Honghua Dong, Soham Ray, Xujie Si und Karthik Narasimhan (Sierra AI und University of Toronto) führen τ²-bench als direkte Erweiterung der ursprünglichen τ-bench ein. Die Kernbeobachtung ist, dass bisherige Benchmarks für konversationelle KI-Agenten Single-Control sind: Nur der Agent kann Tools aufrufen; der Benutzer ist auf natürlichsprachliche Nachrichten beschränkt. Technischer Support in der realen Welt bricht mit dieser Annahme. Wenn ein Kundenservice-Mitarbeiter Ihnen sagt, Sie sollen den „Flugmodus ausschalten“, führen Sie einen Tool-Aufruf auf Ihrem eigenen Gerät aus, anstatt nur Ihre Präferenzen zu schildern.

Die Autoren modellieren dies als dezentralisierten, teilweise beobachtbaren Markov-Entscheidungsprozess (Dec-POMDP), bei dem sowohl der Agent als auch der Benutzersimulator über unterschiedliche Aktionsräume (Funktionsaufrufe und Nachrichten) über einen gemeinsamen, dynamischen Weltzustand verfügen. Die Seite des Agenten sieht wie ein Standard-CRM aus: Er kann Kundendatensätze einsehen, Roaming aktivieren oder eine SIM-Karte ersetzen. Die Benutzerseite ist ein simuliertes Telefon mit Lese-Tools (get_status_bar, get_sim_status) und Schreib-Tools (toggle_airplane_mode, toggle_data, reseat_sim_card). Der Benchmark wird mit einer neuen Telekom-Domain (114 Aufgaben, ausgewählt aus 2.285 programmatisch generierten Varianten) zusammen mit den verifizierten Domänen Einzelhandel (115 Aufgaben) und Fluggesellschaften (50 Aufgaben) aus der ursprünglichen τ-bench ausgeliefert.

Kernideen

• Dual-Control-Formalismus: Die Dec-POMDP-Repräsentation trennt sauber, was jeder Akteur beobachtet und welche Tools jeder aufrufen kann. Dies ist rigoroser als der Ad-hoc-Ansatz eines „Benutzers mit Telefon“, den man an ein bestehendes Single-Agent-Harness anflanschen könnte.
• Kompositioneller Aufgabengenerator: Aufgaben werden aus 15 atomaren Unteraufgabengruppen zusammengestellt, die drei Absichtstypen (service_issue, mobile_data_issue, mms_issue) mit expliziter Schwierigkeitsskalierung durch die Anzahl der erforderlichen Lösungsschritte abdecken.
• Leistung in der Telekom-Domain (pass¹): GPT-4.1 erreicht nur 34 %; o4-mini 42 %; Claude 3.7 Sonnet 49 %; GPT-4.1-mini rund 50 %. Alle Modelle schneiden hier wesentlich schlechter ab als im Einzelhandel oder bei Fluggesellschaften.
• Dual-Control-Penalty: Eine Ablationsstudie vergleicht den Default-Modus (Benutzer hat Tools) mit dem No-User-Modus (Agent steuert jedes Tool selbst). GPT-4.1 sinkt um 18 Prozentpunkte; o4-mini sinkt um 25 Punkte. Diese Lücke entspricht den Kosten der Koordination mit einem aktiven Benutzer, entkoppelt von der reinen logischen Schwierigkeit.
• Oracle-Plan-Lücke: Selbst wenn dem Agenten die vollständige Aktionssequenz im Voraus übergeben wird, erreicht die Leistung keine 100 %. Das zeigt uns, dass die Ausführung und die Benutzerkoordination zusätzliche Fehlerquellen zur Planung hinzufügen.
• Strukturierte Benutzer-Tools reduzieren Simulator-Rauschen dramatisch: Der Telekom-Benutzersimulator erzeugt nur 16 % Fehler (6 % kritisch), verglichen mit 40 % Fehlern (12 % kritisch) für den Einzelhandel in der ursprünglichen τ-bench. Die Verbesserung resultiert daraus, dass lose natürlichsprachliche Benutzer-Prompts durch eine eng begrenzte Tool-Schnittstelle ersetzt wurden, die den Gerätestatus verfolgt.

Was überzeugt – und was nicht

Das Dec-POMDP-Framework ist eine der sorgfältigsten Problemformulierungen, die ich bisher im Agenten-Benchmarking gesehen habe. Der programmatische Aufgabengenerator ist wirklich nützlich: Er liefert nachweislich korrekte Aufgaben und explizit steuerbare Komplexität, im Gegensatz zu den manuell erstellten Aufgabensammlungen, die die meisten Benchmarks plagen. Die Zuverlässigkeitszahlen des Benutzersimulators sind überzeugend – die Reduzierung kritischer Fehler von 12 % auf 6 % spielt eine große Rolle, wenn man seinem Evaluierungssignal vertrauen möchte.

Davon abgesehen ist die Telekom-Domain eng gefasst. Vier Kunden, neun Leitungen, fünf Tarife: Das ist ein kontrolliertes Labor, kein Unternehmenssystem. Die pass¹-Zahlen für gpt-4.1-mini und Claude 3.7 Sonnet (~50 %) erscheinen überraschend hoch, wenn man bedenkt, wie schwierig die Autoren die Domain beschreiben. Das lässt mich fragen, ob 114 Aufgaben ausreichen, um zu verhindern, dass Glückstreffer die Ergebnisse aufblähen. Die Autoren räumen ein, dass ihr Aufgabensatz eine Stichprobe ist. Ich finde auch die Analyse der Nutzer-Personas etwas dünn: Das Papier zeigt, dass die „Hard“-Persona (64-jähriger Rentner mit geringer Technikaffinität) schwieriger ist als die „Easy“-Persona, was wenig überrascht. Was ich gerne sehen würde, ist, ob sich die Art des Koordinationsfehlers unterscheidet – erzeugt eine schwierigere Persona mehr Denkfehler oder mehr Kommunikationsfehler?

Das Papier untersucht auch nicht, was passiert, wenn das Richtliniendokument des Agenten falsch oder unvollständig ist, was ein realistisches Szenario für Produktionsumgebungen darstellt. Jedes Ergebnis setzt voraus, dass der Agent akkurate Richtlinien erhält.

Warum das für Finanz-KI wichtig ist

Die in τ-bench, WorkArena und den meisten aufgabenorientierten Dialog-Benchmarks eingebettete Single-Control-Annahme lässt sich nur schlecht auf ein reales Beancount-Support-Szenario übertragen. Ein Benutzer, der einen Beancount-Agenten bittet, sein Ledger zu korrigieren, schildert nicht nur ein Problem – er editiert möglicherweise gleichzeitig die Datei in seinem Texteditor, führt bean-check aus oder lädt einen neuen CSV-Export von seiner Bank hoch. Das ist eine Dual-Control-Umgebung im exakten Sinne von τ²-bench.

Der Rückgang von 18–25 Prozentpunkten beim Wechsel vom No-User- zum Default-Modus ist die Zahl, auf die ich immer wieder zurückkommen werde. Sie legt nahe, dass selbst wenn wir einen Beancount-Agenten bauen würden, der nahezu perfekt in der autonomen Ledger-Manipulation ist, die Einführung eines aktiven Benutzers mit geteiltem Schreibzugriff die Erfolgsraten um etwa ein Viertel senken würde. Die sicheren Write-Back-Designs, die wir in Betracht gezogen haben (GuardAgent, ShieldAgent, verifizierbares MCP), wurden für Single-Control-Umgebungen entworfen; sie müssen überdacht werden, wenn der Benutzer ebenfalls ein Tool-aufrufender Agent in derselben Umgebung ist.

Die Verbesserung der Zuverlässigkeit des Benutzersimulators ist ebenfalls direkt umsetzbar. Wenn ich Offline-Evaluierungen eines Beancount-Agenten durchführen möchte, ohne menschliche Buchhalter zu rekrutieren, ist die enge Kopplung des simulierten Benutzers an eine deterministische Ledger-Umgebung – anstatt sich auf freies LLM-Rollenspiel zu verlassen – die richtige technische Entscheidung.

Was Sie als Nächstes lesen sollten

• τ-bench (Yao et al., arXiv:2406.12045): Die Basis, die hier erweitert wird – es lohnt sich, die ursprüngliche Aufgabenkonstruktion und das pass^k-Metrikdesign zu lesen, bevor man die τ²-bench-Ergebnisse interpretiert.
• ToolSandbox (Lu et al., arXiv:2408.04682): Führt zustandsbehaftete Tools für eine feinkörnige Agenten-Evaluierung ein; die relevanteste Architektur für den Entwurf eines Dual-Control-Beancount-Test-Harness.
• TheAgentCompany (Xu et al., arXiv:2412.14161): 175 Aufgaben innerhalb eines simulierten Softwareunternehmens mit echten internen Tools; der realistischste Benchmark für Unternehmensautomatisierung, der derzeit verfügbar ist, und das nächste Papier auf meiner Leseliste.