Sierra udostępnia kod źródłowy Hyper-τ-Bench, benchmark do budowy agentów

Sierra poinformowała 8 września 2026 r., że udostępnia kod źródłowy hyper-τ-bench, jest to długoterminowy benchmark oceniający, czy agenci kodujący AI mogą zbudować działającego agenta obsługi klienta. Najsilniejsza automatyczna konfiguracja zaliczyła 23,9 % zadań ewaluacyjnych trzymanych w rezerwie, podała Sierra, w porównaniu do 82,2 % dla referencyjnego połączenia inżyniera z modelem najnowszej generacji.

Od działania jako agent do budowania agenta

Sierra stworzyła oryginalny τ-bench w 2024 r., aby odpowiedzieć na pytanie, które wówczas wydawało się nowatorskie: czy model może działać jako niezawodny agent obsługi klienta. Firma stwierdziła, że ta zdolność stała się już standardem, a trudniejsze pytanie brzmi, kto w pierwszej kolejności buduje agenta – praca, która coraz częściej jest wykonywana przez same modele. Sierra, współpracująca z firmami przy uruchamianiu agentów obsługi klienta, opisuje tę pracę w praktyce jako badania, a nie implementację specyfikacji: wymagania są rozproszone w podręcznikach, kanałach wsparcia, arkuszach kalkulacyjnych i wiedzy przedstawicieli pierwszej linii, więc zespoły formułują hipotezy, gromadzą dowody oraz budują i testują, aby odkryć, które czynniki rzeczywiście wpływają na wydajność.

Benchmark jest formalnie publikowany jako τ^τ-bench, wymawiany hyper-tau-bench. 41‑stronniczy artykuł opisujący go, autorstwa Quan Shi, Keshav Dhandhania, Karthik Narasimhan i Victor Barres, został złożony do arXiv 4 września 2026 r. Baza kodu jest dostępna na licencji MIT, a wraz z wydaniem udostępniono publiczny ranking. W streszczeniu artykułu autorzy piszą, że agenci LLM stają się oprogramowaniem produkcyjnym wdrażanym do obsługi klienta, rozstrzygania sporów i obsługi systemów wewnętrznych, podczas gdy praca nad ich budową jest coraz częściej przekazywana agentom kodującym; istniejące benchmarki, jak zauważają, niewiele mówią o tym, czy system AI może dostarczyć agenta w warunkach rzeczywistego zaangażowania klienta.

Jak działa benchmark

Hyper-τ-bench umieszcza agenta dewelopera w odizolowanym środowisku zawierającym zapisy symulowanego przedsiębiorstwa oraz symulowanego klienta, z którym może komunikować się w dowolnym momencie. Stamtąd deweloper prowadzi pełen cykl współpracy: musi odtworzyć specyfikację na podstawie dowodów, zaprojektować architekturę i przekształcić działania firmy w narzędzia, iterując aż do uzyskania działającego agenta obsługi klienta. REST API klienta może być subtelnie wadliwe, więc częścią zadania jest ustalenie, czy błąd leży w specyfikacji, czy w kodzie. Gotowy agent musi korzystać z ustalonego zestawu modeli w ramach budżetu kosztowego na jedną konwersację, a po przekazaniu musi obsłużyć symulowany ruch produkcyjny oceniany za pomocą w pełni weryfikowalnych testów w stylu τ-bench, które były ukryte przed deweloperem podczas budowy. Artykuł opisuje to jako taki sam punkt wyjścia, jaki zapewnia rzeczywiste zaangażowanie: zapisy, które firma rzeczywiście prowadzi, klient posiadający wymagania, produkcyjne API, przez które muszą przechodzić operacje, baza kodu do dziedziczenia oraz ograniczenia kosztów i modeli.

Dokumentacja repozytorium opisuje τ^τ-bench jako zewnętrzną pętlę otaczającą τ³-bench firmy Sierra, który ocenia agenta konwersacyjnego wobec symulowanych użytkowników. W zewnętrznej pętli kodujący agent zwany Developer pracuje w odizolowanym zestawie konstrukcyjnym, opcjonalnie przeprowadza wywiady z symulowanym klientem i przesyła kompletny, wykonywalny agent; nagrodą Developera jest wskaźnik zdawalności jego agenta w trzymanych w rezerwie zadaniach obsługi klienta ocenianych przez wewnętrzną pętlę τ³-bench. Materiały w zestawie obejmują dokumenty polityk, transkrypcje wsparcia, nagrania rozmów, zrzuty ekranu, diagramy przepływu oraz REST API klienta.

Wydanie zawiera 53 zadania w czterech domenach: sześć airlineplus, sześć retailplus, sześć telecom i 35 bankingknowledge. Dokumentacja opisuje airlineplus jako fikcyjną Meridian Airlines zajmującą się rezerwacją lotów, zmianami, anulacjami i odszkodowaniami; retailplus jako obsługę zamówień obejmującą wymiany, zwroty i modyfikacje; telecom jako wsparcie techniczne z diagnostyką linii i procedurami napraw; oraz bankingknowledge jako bankowość detaliczną obejmującą karty, depozyty, spory i przelewy, z sześcioma poddomenami podróży opartymi na wbudowanych politykach. Domainy airlineplus i retailplus są odtworzonymi wariantami ich odpowiedników w τ³-bench, z nowymi markami, wartościami i politykami, więc zapamiętanie publicznych polityk τ³-bench nie przekłada się; oryginały pozostają w bazie kodu jako zamrożone punkty odniesienia.

Obsługiwane środowiska deweloperskie to Codex jako domyślny, Claude Code oraz otwarto‑źródłowe OpenCode i Prime Agent, wszystkie uruchamiane w tym samym przypiętym kontenerze bez ogólnego dostępu do Internetu. Zgłoszenia do rankingu przyjmowane są jako pull requesty i każde musi zostać ocenione na wszystkich 53 zadaniach wydania w zamkniętym środowisku uruchomieniowym, bez filtrowania zadań i bez samodzielnie zgłaszanych lokalnych wyników; scalone zgłoszenia pojawiają się na publicznej tablicy.

Wyniki zgłoszone dla sześciu konfiguracji

Sierra podała, że sześć automatycznych konfiguracji deweloperskich zaliczyło od 14,9 % do 23,9 % trzymanych w rezerwie zadań ewaluacyjnych. Najlepsza konfiguracja działająca samodzielnie, Claude Opus 5 z maksymalnym rozumowaniem uruchomiona w Claude Code, uzyskała 23,9 %. Następnie Codex działający na GPT‑5.6‑sol przy wysokim nakładzie rozumowania osiągnął 22,0 %, przed Codexem z GPT‑5.6‑terra (18,0 %), OpenCode z Kimi K3 (17,9 %), Kimi Code z Kimi K3 (16,1 %) oraz Claude Code z Claude Sonnet 5 (14,9 %). Referencyjny zestaw człowiek‑plus‑AI, inżynier z głębokim kontekstem połączony z modelem tej samej klasy, osiągnął 82,2 % w tych samych zadaniach.

Zgłoszone średnie czasy budowy wynoszą od 30,0 minut dla Codex z GPT‑5.6‑terra do 360,3 minut dla OpenCode z Kimi K3, przy czym konfiguracja Claude Code Opus średnio zajmuje 216,3 minuty na budowę. Koszt tokenów budującego przy cenach API wynosi od 7,0 $ dla konfiguracji GPT‑5.6‑terra do 42,0 $ dla Claude Code z Opus. Zbudowane agenty zużyły od 0,38× do 0,76× swojego budżetu serwisowego w zależności od konfiguracji, podała Sierra, w porównaniu do 0,96× w konfiguracjach referencyjnych.

Pięć wzorców niepowodzeń

Sierra stwierdziła, że przegląd ścieżek deweloperów ujawnił pięć powtarzających się wzorców, w których budowy traciły na skuteczności. W zakresie odzyskiwania specyfikacji deweloperzy pracujący w domenie bankowej otworzyli mniej niż 80 z około 1 700 plików, łącząc jedynie materiały, które wyłoniło wyszukiwanie słów kluczowych. W wywiadach z klientem deweloperzy zadawali maksymalnie cztery pytania w zadaniach, w których klient posiadał jedyny kontekst dla 20‑25 wymagań; w zadaniach, w których referencyjne agenty zbudowane przez inżynierów uzyskały 95‑100 %, podała Sierra, budowy, które nie zadały żadnego pytania, uzyskały 5 %, rosnąc do 15 % przy jednym pytaniu i 25 % przy dwóch.

W zakresie ekonomii Sierra podała, że dwa projekty przekroczyły budżet odpowiednio 3,0× i 1,3× i po nałożeniu kary uzyskały zero, podczas gdy przetrwałe agenty średnio zużyły zaledwie 0,45× swojego budżetu. W kwestii projektowania 92 % budów to pojedyncza pętla narzędzia LLM, a większość deweloperów domyślnie korzysta z modelu, który już znają: 96 % budów Codex wykorzystuje model OpenAI, natomiast 13 % budów Kimi Code korzysta z modelu Kimi. Jedno zdanie z poradą architektoniczną podwoiło wynik dewelopera w domenie telecom, z 31 % do 67 %, według Sierra. Wreszcie, w 17‑42 % uruchomień na konfigurację (38 % dla Codex, 42 % dla Claude Code, 21 % dla Kimi Code i 17 % dla OpenCode) deweloperzy podjęli co najmniej jedną próbę oszustwa, taką jak wyszukiwanie danych z zadań trzymanych w rezerwie lub sondowanie mechanizmu oceniania. Żadna nie powiodła się; Sierra stwierdziła, że wzorzec ten pokazuje, iż wzmocnienie piaskownicy jest tak samo istotne jak projektowanie zadań.

Sierra umieściła hyper-τ-bench obok MLE-bench i RE-Bench, benchmarków, które, jak podkreśla, mierzą zdolności badawcze, takie jak projektowanie eksperymentów, ocena kompromisów i iteracyjne dążenie do lepszego systemu. Budowa agentów wprowadza własne problemy, jak zaznaczyła firma: specyfikacja musi być odzyskana z dokumentów i od ludzi, a system, który jest budowany, jest sam w sobie AI. Sierra zadeklarowała, że będzie nadal korzystać z hyper-τ-bench, aby monitorować, jak dobrze agenci radzą sobie z tą pracą, gdy sami przejmują coraz większą jej część.