Niezawodność agentów AI trudno ocenić po tym, co agent sam raportuje. Microsoft razem z Hugging Face opublikował 3 października ThinkingBox, otwarte środowisko testowe, które sprawdza nie wypowiedź agenta, lecz faktyczny stan bazy danych po zakończeniu zadania. Wnioski z pierwszych pomiarów są niewygodne dla każdego, kto planuje oddać agentom procesy biznesowe.
Autorzy zaczynają od przykładu z obsługi zgłoszeń. Agent wykonał dziewięć poprawnych wywołań narzędzi i zamknął sprawę klienta ze statusem „solved”. Wymagany był status „hold”. W logach wszystko wyglądało dobrze, a w systemie został błędny wpis.
Co mierzy ThinkingBox
Benchmark obejmuje 507 zadań z pięciu obszarów: handlu detalicznego, ubezpieczeń komunikacyjnych, podróży, bankowości cyfrowej i doradztwa. Każde zadanie uruchamiane jest 20 razy od czystego stanu. Ocena opiera się na automatycznych testach końcowego stanu bazy, a nie na podsumowaniu przebiegu. Przetestowano 18 modeli, m.in. GPT-6 Astra, Claude Opus 5.5, Kimi-K3 i DeepSeek-V4-Pro. Narzędzia zdefiniowano jako serwery MCP, a kod udostępniono na licencji MIT.
Najciekawsza jest różnica między „potrafi” a „robi to za każdym razem”. Kimi-K3 rozwiązał co najmniej raz 93,89% zadań, ale komplet 20 na 20 zaliczył tylko w 13,41% przypadków. Claude Opus 5 osiągnął odpowiednio 79,09% i 47,53%. Do tego 67,24% nieudanych prób zakończyło się bez żadnego zgłoszonego błędu narzędzia. Agent nie sygnalizował problemu, po prostu zostawiał zły stan danych.
„A trajectory is a claim. Database state is the evidence. Repetition is the trust test.” — Tuhin Kundu (Microsoft), blog Hugging Face
Autorzy policzyli też koszt jednego zadania wykonywanego niezawodnie, czyli zaliczonego 20 razy z rzędu. Dla GPT-5.4 wyniósł 6,80 USD (128 takich zadań), dla GPT-6 Astra 7,45 USD (231 zadań), a dla Claude Opus 5.5 7,80 USD (241 zadań). Najtańszy model nie musi więc oznaczać najtańszego wdrożenia, jeśli niezawodnie radzi sobie z mniejszą liczbą zadań.
Niezawodność agentów AI w polskiej firmie: co z tego wynika
Dla firm, które testują agentów w obsłudze klienta, back office czy finansach, wniosek jest praktyczny. Jedno udane demo nie dowodzi, że agent poradzi sobie przy setnym zgłoszeniu. Pilotaż warto oceniać powtarzalnością na tych samych przypadkach, a nie pojedynczym wynikiem. Weryfikacja powinna sprawdzać skutek w systemie, czyli w CRM, ERP czy narzędziu do zgłoszeń, a nie raport agenta.
Cichy błąd, czyli zadanie „zakończone” z niepoprawnymi danymi, bywa droższy niż błąd jawny. Gdy dotyczy danych klientów, może też kolidować z wymogiem prawidłowości danych z RODO. Dlatego przy procesach wpływających na klienta człowiek w pętli i automatyczne kontrole stanu nadal mają sens. ThinkingBox jest otwarty, więc zespoły IT mogą wykorzystać jego podejście do budowy własnych testów.
Źródło: Hugging Face Blog: „The Agent Said It Was Done. The Database Disagreed.” (EN, 3 października 2026). Kod projektu: microsoft/thinkingbox na GitHubie (EN).
