Twoje testy przechodzą, a agent i tak robi głupoty — dlaczego klasyczne QA tu nie działa i co z tym zrobić

Napisałeś testy, wszystkie zielone. Agent trafia na produkcję i po trzech dniach klient zgłasza, że coś poszło nie tak. Nie błąd składni, nie null pointer — agent po prostu wybrał złe narzędzie, rozumował inaczej niż w testach i doszedł do sensownie brzmiącej, ale błędnej odpowiedzi. Twoja dekada w QA nie przygotowała cię na to.

Twoje testy przechodzą, a agent i tak robi głupoty

Problem deterministyczności: temp=0 nie wystarczy

Pierwsza intuicja większości inżynierów: ustaw temperature=0, a model będzie deterministyczny. W praktyce — nie do końca. Nawet przy temp=0 obserwuje się wariację w wyborze narzędzi i intermediate steps między kolejnymi runami [1]. Model może dwa razy z rzędu wybrać inne wywołanie API, żeby dojść do tego samego wyniku. Albo raz dojść do niego, raz nie.

To nie jest bug do naprawienia. To właściwość systemu, z którą musisz się nauczyć pracować.

Snapshot testing, regex i human eval — trzy ślepe uliczki

Snapshot testing na finalnych outputach jest zbyt kruchy. Poprawna odpowiedź sformułowana inaczej łamie test — agent napisał "Nie znaleziono rekordu" zamiast "Brak rekordu w bazie", wynik identyczny, test czerwony [1].

Regex i keyword matching idą w drugą stronę: agent może przypadkowo trafić na poprawne słowo kluczowe, rozumując zupełnie błędnie. Test zielony, logika uszkodzona [1].

Human eval jest dokładny, ale nie da się go uruchomić automatycznie. Przy regression suite liczącym 10–50 tysięcy promptów — a takie stosują zespoły produkcyjne w 2025–2026 — ręczna ocena każdego przypadku przestaje być opcją [2].

Regression suites na 10–50 tys. promptów: jak firmy produkcyjne faktycznie mierzą jakość

Scenario-based evaluation zamiast assert X→Y

Zmiana mentalna jest prosta do opisania, trudna do wdrożenia: przestajesz pytać "czy agent zwrócił Y na wejście X" i zaczynasz pytać "czy agent zachował się poprawnie w scenariuszu S". Scenariusz to nie pojedynczy prompt — to sekwencja kroków, kontekst, dostępne narzędzia i kryterium sukcesu zdefiniowane na poziomie intencji, nie tekstu [2].

Przykład: zamiast asercji output == "Zamówienie anulowane" definiujesz scenariusz: użytkownik chce anulować zamówienie złożone ponad 24h temu, agent ma dostęp do API zamówień i bazy klientów. Kryterium sukcesu: agent sprawdził status zamówienia, zidentyfikował ograniczenie czasowe i poinformował użytkownika o braku możliwości anulowania — lub eskalował do człowieka. Poprawnych sformułowań tego wyniku jest kilkadziesiąt. Wszystkie powinny przejść.

Kiedy uruchamiać evaluation pipeline

Zespoły produkcyjne uruchamiają evaluation pipeline na każdy większy release modelu lub promptu [2]. To oznacza, że zmiana jednej linii w system promptcie wymaga pełnego przejścia przez suite. Brzmi drogo — i jest drogo, jeśli suite liczy 50 tys. przypadków. Dlatego warto podzielić go na warstwy: szybki smoke test (200–500 scenariuszy, wyniki w kilka minut) i pełna regresja uruchamiana przed każdym wdrożeniem na produkcję.

LLM-as-a-judge: oceniaj reasoning, nie tylko końcowy output

Jak skonstruować rubric scoringowy

LLM-as-a-judge to podejście, w którym osobny model ocenia jakość odpowiedzi agenta według zdefiniowanej rubryki. Rubrica powinna obejmować co najmniej: poprawność faktyczną, spójność reasoning z podjętą akcją, kompletność odpowiedzi względem intencji użytkownika i brak halucynacji w odwołaniach do zewnętrznych danych.

Każde kryterium dostaje wagę i skalę (np. 1–5). Wynik końcowy to suma ważona. Próg pass/fail ustawiasz empirycznie — zaczynasz od ręcznej oceny 100–200 przypadków, kalibrujesz próg tak, żeby sędzia zgadzał się z twoją oceną w co najmniej 85% przypadków, a potem monitorujesz dryft.

Brak mechanizmu ustawiania progów pass/fail to jeden z najczęstszych problemów przy pierwszych wdrożeniach rubric scoringu [1]. Rubrica "prawie działa" bez twardego progu to nie test — to opinia.

Pułapki LLM-as-a-judge

Największa: sędzia może mylić się razem z agentem. Jeśli oba modele mają podobne błędy w wiedzy bazowej lub podobne tendencje do nadmiernej pewności siebie, sędzia oceni błędną odpowiedź jako poprawną. Dlatego sędzia i agent nie powinni być tym samym modelem — a najlepiej nie powinni pochodzić od tego samego dostawcy.

Drugi problem: sędzia ocenia to, co widzi. Jeśli logujesz tylko finalny output, sędzia nie ma dostępu do reasoning steps i może ocenić poprawnie brzmiącą odpowiedź, która powstała z błędnego rozumowania. To prowadzi nas do następnego punktu.

Loguj pętlę agenta, nie tylko wynik końcowy

Co logować

Bez pełnego logu pętli agenta nie masz podstaw do debugowania ani regresji. Lista tego, co powinno trafiać do logów, jest konkretna [3]:

• prompty i pełny kontekst wejściowy,
• etapy chain-of-thought,
• wybór narzędzi i każde wywołanie API,
• dane pobrane z zewnętrznych źródeł,
• finalny output.

To nie jest lista "nice to have". Jeśli agent podjął złą decyzję i nie masz logu chain-of-thought, nie wiesz, czy błąd leży w reasoning, w danych wejściowych, czy w wywołaniu narzędzia. Debugujesz w ciemno.

Human-in-the-loop dla akcji wysokiego ryzyka

Nie każda akcja agenta powinna być w pełni autonomiczna. Dla transferów środków, usuwania danych i zmian zasad kontroli dostępu wymagany jest human-in-the-loop [3]. To nie jest kwestia zaufania do modelu — to kwestia odpowiedzialności prawnej i operacyjnej. W polskich firmach działających jako sp. z o.o. lub JDG, gdzie agent ma dostęp do systemów finansowych lub danych osobowych klientów, brak takiego mechanizmu to ryzyko regulacyjne, nie tylko techniczne.

Implementacja jest prosta: przed wykonaniem akcji z listy wysokiego ryzyka agent generuje uzasadnienie i czeka na potwierdzenie. Czas oczekiwania można zmierzyć i zoptymalizować — w naszych wdrożeniach median approval time dla prostych przypadków wynosi poniżej 90 sekund, co nie blokuje procesu w sposób odczuwalny dla użytkownika końcowego.

Red teaming agentów: prompt injection, memory poisoning i podszywanie się

Zero Trust według NIST SP 800-207

Klasyczny red teaming sprawdza, czy system robi to, czego nie powinien. Przy agentach lista wektorów ataku jest szersza niż przy tradycyjnych aplikacjach. Trzy najważniejsze to: prompt injection (złośliwe instrukcje wstrzyknięte w dane pobrane przez agenta), memory poisoning (manipulacja pamięcią długoterminową agenta) i podszywanie się pod inne agenty w przepływach multi-agentowych [3].

Podejście Zero Trust oparte na NIST SP 800-207 traktuje każdego agenta jako "untrusted" dopóki nie zostanie zweryfikowany. W praktyce oznacza to just-in-time access i least privilege zamiast stałych, szerokich uprawnień [3]. Agent do obsługi zamówień nie powinien mieć dostępu do bazy pracowników — nawet jeśli technicznie można mu go nadać.

Uzasadnienie działań jako mechanizm obronny

Jeden z bardziej eleganckich mechanizmów obronnych: agent bez spójnego uzasadnienia działania jest blokowany, nawet jeśli uprawnienie formalnie istnieje [3]. Jeśli agent chce usunąć rekord, ale jego chain-of-thought nie zawiera logicznego powiązania między intencją użytkownika a tą akcją — system odmawia wykonania.

To działa w dwie strony: jako zabezpieczenie przed atakami i jako mechanizm wykrywania regresji jakości reasoning. Agent, który przestał spójnie uzasadniać swoje decyzje, prawdopodobnie przeszedł przez zmianę promptu lub modelu, która uszkodziła jego zachowanie.

Twój minimalny stos do testowania agentów w produkcji — od czego zacząć w tym tygodniu

Trzy warstwy, jeden kierunek

Nie zaczynaj od kupowania narzędzi. Zacznij od architektury w trzech warstwach:

Warstwa pierwsza — unit evals na krokach. Testujesz pojedyncze kroki agenta w izolacji: czy wywołanie narzędzia X na wejściu Y zwraca sensowny wynik. Deterministyczne, szybkie, tanie. Pokrywają 60–70% błędów integracyjnych zanim trafią do wyższych warstw.

Warstwa druga — integration tests na scenariuszach. Pełne scenariusze end-to-end z LLM-as-a-judge jako sędzią. Tu ląduje twój regression suite. Uruchamiasz na każdy release promptu lub modelu.

Warstwa trzecia — monitoring w produkcji. Logowanie pełnej pętli agenta, alerty na anomalie w rozkładzie wyboru narzędzi, dashboardy do śledzenia dryfu jakości w czasie.

Frameworki i narzędzia w 2026

W 2026 roku dostępnych jest co najmniej siedem darmowych frameworków do budowania agentów AI, różniących się podejściem do obserwowalności i logowania kroków [4][5]. Wybór zależy od skali zespołu i istniejącego stosu.

Dla małego zespołu (1–3 inżynierów): zacznij od frameworku, który ma wbudowane logowanie chain-of-thought i eksport do formatu umożliwiającego późniejszą ewaluację. Nie buduj własnego systemu logowania od zera — to pułapka, która pochłonie więcej czasu niż sama ewaluacja.

Dla większego zespołu: rozdziel odpowiedzialność — jeden inżynier odpowiada za utrzymanie regression suite, drugi za monitoring produkcji. Bez właściciela suite rośnie, starzeje się i przestaje być uruchamiana.

Jedno ograniczenie, o którym warto wiedzieć: LLM-as-a-judge kosztuje. Przy regression suite liczącym 50 tys. scenariuszy i modelu sędziego w cenie [do sprawdzenia aktualnych stawek dostawcy], miesięczny koszt ewaluacji może przekroczyć koszt samego agenta na produkcji. Zanim zbudujesz pełny pipeline, policz to dla swojej skali.

Zacznij od jednej rzeczy: wybierz pięć scenariuszy, które najczęściej kończą się błędem na produkcji, i napisz dla nich ewaluacje oparte na intencji, nie na tekście. To zajmie jeden dzień roboczy i pokaże ci, gdzie leżą twoje rzeczywiste luki — zanim zainwestujesz w narzędzia.

Źródła

[1] How do you test AI agents in production? The unpredictability is overwhelming. — r/MachineLearning — https://www.reddit.com/r/MachineLearning/comments/1sx3p40/how_do_you_test_ai_agents_in_production_the/

[2] Running AI agents in production – what does your stack look like in 2026? — r/AI_Agents — https://www.reddit.com/r/AI_Agents/comments/1rtiplc/running_ai_agents_in_production_what_does_your/

[3] Największe zagrożenia bezpieczeństwa dla sztucznej inteligencji agentowej — Stellar Cyber (2025) — https://stellarcyber.ai/pl/learn/agentic-ai-securiry-threats/

[4] Top 7 darmowych frameworków agentów AI [2026] — Botpress — https://botpress.com/pl/blog/ai-agent-frameworks

[5] 7 najlepszych narzędzi do budowania agentów AI w 2026 — Dokodu — https://dokodu.it/blog/agenci-ai/narzedzia-agenty-ai