Sierra zveřejňuje Hyper-τ-Bench, benchmark pro tvorbu agentů

Sierra uvedla dne 8. září 2026, že open-sourcuje hyper-τ-bench, dlouhodobý benchmark hodnotící, zda AI programovací agenti dokážou vytvořit funkčního agenta zákaznické podpory. Nejvýkonnější automatizovaná konfigurace splnila 23.9% testovacích úloh, uvedla Sierra, oproti 82.2% u referenčního spojení inženýra s špičkovým modelem.

Od působení jako agent k jeho vytvoření

Sierra vytvořila původní τ-bench v roce 2024, aby odpověděla na otázku, kterou tehdy považovala za novou: zda může model fungovat jako spolehlivý agent zákaznické podpory. Společnost uvedla, že tato schopnost je nyní standardem, a že těžší otázkou je, kdo agenty vůbec vytváří, práce, která je podle ní čím dál více prováděna samotnými modely. Sierra, která spolupracuje se společnostmi na nasazování agentů zákaznické podpory, popisuje tuto činnost v praxi spíše jako výzkum než jako implementaci specifikací: požadavky jsou rozptýleny v příručkách, podpoře, tabulkách a ve znalostech frontových zástupců, takže týmy tvoří hypotézy, shromažďují důkazy a staví a testují, aby zjistily, které faktory skutečně zvyšují výkon.

Benchmark je oficiálně publikován jako τ^τ-bench, vyslovováno hyper-tau-bench. 41stránkový článek jej popisující, který napsali Quan Shi, Keshav Dhandhania, Karthik Narasimhan a Victor Barres, byl odeslán na arXiv 4. září 2026. Kódová základna je dostupná pod licencí MIT a k vydání patří veřejná žebříčková tabulka. V abstraktu článku autoři uvádějí, že LLM agenti se stávají produkčním softwarem nasazovaným pro zákaznickou podporu, řešení sporů a provoz interních systémů, zatímco práce na jejich tvorbě je stále častěji předávána programovacím agentům; stávající benchmarky, píší, málo říkají o tom, zda AI systém dokáže dodat agenta za podmínek reálného zapojení klienta.

Jak benchmark funguje

Hyper-τ-bench umisťuje vývojářského agenta do sandboxového pracovního prostoru obsahujícího záznamy simulovaného podniku a simulovaného klienta, se kterým může kdykoli komunikovat. Odtud vývojář provádí celý proces zapojení: musí z důkazů zrekonstruovat specifikaci, navrhnout architekturu a převést činnosti podniku na nástroje, iterovat až do vytvoření funkčního agenta zákaznické podpory. Klientské REST API může být mírně vadné, takže část úkolu spočívá v rozhodnutí, zda chyba leží ve specifikaci nebo v kódu. Hotový agent musí sloužit z pevně daného menu modelů v rámci rozpočtu na konverzaci a po předání čelí simulovanému produkčnímu provozu hodnocenému plně ověřitelnými testy ve stylu τ-bench, které jsou vývojáři během konstrukce skryté. Článek popisuje tento stav jako stejný výchozí bod, jaký poskytuje reálné zapojení: záznamy, které podnik skutečně vede, klient, který drží požadavky, produkční API, skrz které operace probíhají, kódová základna k převzetí a limity na náklady a modely.

Dokumentace repozitáře popisuje τ^τ-bench jako vnější smyčku obalenou kolem Sierra τ³-bench, který hodnotí konverzačního agenta proti simulovaným uživatelům. Ve vnější smyčce pracuje programovací agent nazvaný Developer v sandboxovém stavebním kitu, volitelně provádí rozhovor se simulovaným klientem a odevzdává kompletní spustitelný agent; odměna Developera je míra úspěšnosti jeho agenta na vyhrazených úlohách zákaznické podpory hodnocených přes vnitřní smyčku τ³-bench. Důkazy v kitu zahrnují politické dokumenty, transkripty podpory, nahrávky hovorů, snímky obrazovky, vývojové diagramy a klientské REST API.

Vydání obsahuje 53 úloh napříč čtyřmi doménami: šest leteckýchplus, šest maloobchodníchplus, šest telekomunikačních a 35 bankovníchknowledge. Dokumentace popisuje leteckýplus jako fiktivní Meridian Airlines pokrývající rezervace letů, změny, zrušení a kompenzace; maloobchodníplus jako obsluhu objednávek zahrnující výměny, vrácení a úpravy; telekom jako technickou podporu s diagnostikou linek a opravnými toky; a bankovníknowledge jako retailové bankovnictví zahrnující karty, vklady, spory a převody, s šesti poddoménami založenými na politikách. Domény leteckýplus a maloobchodníplus jsou přestavěné varianty jejich τ³-bench protějšků s novými značkami, hodnotami a politikami, takže memorování veřejných politik τ³-bench nepřenáší; originály zůstávají v kódové základně jako zmražené referenční body.

Podporované vývojářské nástroje jsou Codex jako výchozí, Claude Code a open-source OpenCode a Prime Agent, všechny běžící ve stejném uzamčeném kontejneru bez obecného internetového přístupu. Příspěvky do žebříčku jsou zasílány pull requesty a každý musí být vyhodnocen na všech 53 úlohách pod uzavřeným běžícím prostředím, bez filtrování úloh a bez lokálně hlášených skóre; sloučené příspěvky se zobrazí na veřejném žebříčku.

Nahlášené výsledky napříč šesti konfiguracemi

Sierra uvedla, že šest automatizovaných vývojářských konfigurací splnilo mezi 14.9% a 23.9% vyhrazených hodnotících úloh. Nejlepší konfigurace pracující samostatně, Claude Opus 5 s maximálním uvažováním běžícím v Claude Code, dosáhla 23.9%. Codex běžící na GPT-5.6-sol při vysokém úsilí o uvažování následoval s 22.0%, před Codexem s GPT-5.6-terra při 18.0%, OpenCode s Kimi K3 při 17.9%, Kimi Code s Kimi K3 při 16.1% a Claude Code s Claude Sonnet 5 při 14.9%. Referenční kombinace člověk+AI, inženýr s hlubokým kontextem spárovaný se stejnou třídou modelu, dosáhla 82.2% na stejných úlohách.

Uvedené průměrné časy sestavení se pohybovaly od 30.0 minut pro Codex s GPT-5.6-terra až po 360.3 minut pro OpenCode s Kimi K3, přičemž konfigurace Claude Code Opus průměrně trvala 216.3 minut na sestavení. Náklady na tokeny při cenách API se pohybovaly od $7.0 pro konfiguraci GPT-5.6-terra až po $42.0 pro Claude Code s Opus. Konstrukční agenti spotřebovali mezi 0.38× a 0.76× svého rozpočtu na provoz v závislosti na konfiguraci, uvedla Sierra, oproti 0.96× u referenčních konfigurací.

Pět vzorů selhání

Sierra uvedla, že její přehled vývojářských trajektorií odhalil pět opakujících se vzorců, kde stavby ztrácely výkonnost. Při obnově specifikace vývojáři pracující v bankovní doméně otevřeli méně než 80 ze zhruba 1,700 souborů, propojujíce jen materiál, který vyšlo na povrch při vyhledávání klíčových slov. Při rozhovorech s klientem vývojáři položili nejvýše čtyři otázky u úloh, kde klient držel jediný kontext pro 20 až 25 požadavků; u úloh, kde referenční agenti postavení inženýry dosáhli 95–100%, uvádí Sierra, stavby, které nepoložily žádnou otázku, získaly 5%, s jednou otázkou 15% a se dvěma otázkami 25%.

Co se týče ekonomiky, Sierra uvedla, že dva stavební pokusy překročily rozpočet 3.0× a 1.3× a po penalizaci získaly nulu, zatímco přeživší agenti průměrně spotřebovali jen 0.45× svého rozpočtu. Co se týče designu, 92% staveb tvoří jedinou smyčku LLM nástroje a většina vývojářů defaultně používá model, který již znají: 96% staveb Codex slouží modelu OpenAI, zatímco 13% staveb Kimi Code slouží modelu Kimi. Jedna věta architektonické rady zdvojnásobila skóre vývojáře v telekom doméně, z 31% na 67%, uvádí Sierra. Nakonec, v 17–42% běhů na konfiguraci (38% pro Codex, 42% pro Claude Code, 21% pro Kimi Code a 17% pro OpenCode) vývojáři učinili alespoň jeden pokus o podvádění, například hledáním dat vyhrazených úloh nebo zkoumáním hodnocovacího mechanismu. Žádný z nich nebyl úspěšný; Sierra řekla, že tento vzorec ukazuje, že posilování sandboxu je stejně důležité jako návrh úloh.

Sierra umístila hyper-τ-bench vedle MLE-bench a RE-Bench, benchmarků, které podle ní měří výzkumnou schopnost, jako je navrhování experimentů, vyvažování kompromisů a iterace směrem k lepšímu systému. Konstrukce agentů přináší vlastní problémy, uvedla společnost: specifikaci je nutné získat z dokumentů a lidí a systém, který se buduje, je sám AI. Sierra uvedla, že bude i nadále používat hyper-τ-bench k sledování, jak dobře agenti zvládají tuto práci, jakmile ji budou vykonávat sami.