AI agent může udělat devět správně vypadajících kroků, zdvořile odpovědět zákazníkovi a přitom pokazit to nejdůležitější: zanechat špatný stav v systému. Přesně na tuhle nepříjemnou mezeru míří nový benchmark ThinkingBox od Microsoftu, který je dostupný přes Hugging Face. Mně osobně to přijde jako mnohem užitečnější test než další soutěž v tom, kdo napíše přesvědčivější odstavec.
Databáze má poslední slovo
Ukázkový případ je až bolestně uvěřitelný. Zákaznici se zpozdil kuchyňský spotřebič za 745 dolarů, zásilka patnáct dní visela v přepravní výjimce a agent si pečlivě dohledal objednávku, sledování zásilky i pravidla refundace. Správně zjistil, že zákaznice nemá nárok na kompenzaci za zpoždění, založil ticket a zapsal časovou osu.
Pak ale ticket uzavřel jako vyřešený. Jenže přepravní problém pořád trval a požadovaný konečný stav měl být hold, tedy podržení případu do dalšího vyřešení. Zákaznice navíc nedostala pořádnou odpověď na svůj dotaz. Agent zkrátka působil jako ten kolega, který napíše „hotovo“, protože už se těší na oběd.
ThinkingBox proto nehodnotí jen textovou odpověď ani to, zda nástrojové volání proběhlo bez chyby. Spouští agenta v izolovaném prostředí s MCP servery. MCP neboli Model Context Protocol je způsob, kterým modely přistupují k externím nástrojům a službám. Test následně ověřuje výsledný stav backendu a vedlejší účinky: změnil agent správné pole, založil potřebný záznam a nezpůsobil něco navíc?
Jedno povedené spuštění je málo
Benchmark obsahuje 507 stavových pracovních postupů z retailu, pojištění aut, cestování, neobankovnictví a consultingu. Každý úkol autoři pustili dvacetkrát z čistého výchozího stavu. To je detail, který se snadno přehlédne, ale pro nasazení agentů je podle mě úplně klíčový.
Vedle známého pass@1, tedy podílu úspěšných jednotlivých pokusů, sleduje ThinkingBox také pass@20: zda se úkol podařil aspoň jednou ze dvaceti pokusů. A pak uvádí doslovný počet úloh, které prošly všech dvacet běhů. Právě poslední číslo se blíží otázce, kterou by si měl položit každý, kdo chce agentovi svěřit objednávky, refundace nebo pojistné případy: udělá to správně pokaždé?
V jednom společném testu zahrnujícím 121 680 platných pokusů napříč dvanácti modely selhalo 79 853 běhů při spustitelných kontrolách. Z těchto selhání přitom 67,24 % běhů skončilo čistě, použilo nástroj, který mění stav, a neohlásilo chybu nástroje. Navenek tedy docela dobrá práce. Kontroly ale našly chybné hodnoty polí v 77,61 % těchto případů, nechtěné vedlejší efekty ve 43,30 % a chybějící nutné změny v 25,36 %. Kategorie se překrývají, takže je nelze prostě sečíst.
Žebříček vypadá jinak, když chcete spolehlivost
Na samotném pass@1 vedl Claude Opus 5.5 s celkovým skóre 67,16 %, těsně před Claude Opus 5 s 66,50 % a GPT-5.4 s 65,36 %. Z open-weight modelů, tedy modelů s veřejně dostupnými vahami pro vlastní provoz, vyšel nejlépe Kimi-K3 s 57,37 %. To nejsou vůbec špatná čísla, ale také to znamená, že ani špička v tomto testu nedokončí správně zhruba třetinu jednotlivých pokusů.
Zajímavější je propad při opakování. GPT-6 Astra si udržel 78 % svého skóre z jednoho pokusu, Claude Opus 5.5 a Claude Opus 5 po 71 %. Naproti tomu GLM-5.1, Kimi-K2.6 a DeepSeek-V4-Pro si držely kolem 8 %. Neznamená to, že jsou tyto modely obecně k ničemu; jde o konkrétní benchmark a konkrétní způsob sestavení agentů. Ukazuje to ale, že věta „jednou to zvládl“ má pro produkční automatizaci dost omezenou cenu.
Hodně záleží i na doméně. Claude Opus 4.6 dosáhl v retailu 68,62 %, ale u pojištění aut jen 8,30 %. Musela jsem se nad tím na chvíli zastavit: obecné skóre modelu je fajn orientační cedulka, jenže zákaznická podpora, banka a pojišťovna nejsou stejná hra s jinými kulisami.
Test výsledku místo dojmu
ThinkingBox mi nepřijde jako definitivní odpověď na otázku, který agent je bezpečný. Benchmark je pořád benchmark: pokrývá vybrané scénáře a jeho metodiku je potřeba číst spolu s technickým článkem. Z podkladu také neplyne, jak by se výsledky proměnily v reálných firmách s nepořádkem v datech, výpadky služeb a lidskými eskalacemi. To už je bohužel disciplína, kde se tabulky obvykle začnou potit.
Směr se mi ale líbí. Agent nemá dostat bod za to, že hezky mluvil o vyřešeném ticketu, nýbrž za správně vyřešený ticket. U nástrojů, které mají něco skutečně měnit, je databáze méně okouzlující porotce než AI hodnotitel, ale zato se nenechá ukecat.
Čím více agentům svěříme práci v interních systémech, tím méně by nás mělo zajímat, zda jejich stopa vypadá elegantně. Důležitější je, co po nich zůstane.
