Strona główna / Artykuły / Dlaczego sztuczne agenty produkcyjne zawodzą w ciszy i jak wykryć błędne odpowiedzi

AI AgentsLLMObservabilityProductionHuman-in-the-Loop

Dlaczego sztuczne agenty produkcyjne zawodzą w ciszy i jak wykryć błędne odpowiedzi

Przypadek badawczy dwunastu agentów sztucznej inteligencji służących do produkcji pokazuje, dlaczego wiarygodny błędny wynik jest rzeczywistym modelem awarii, oraz jakie zasady projektowe sprawiły, że te, które przetrwały, pozostały przydatne.

1816 słów

Najgroźniejszym błędem w produkcji dla agenta AI nie jest awaria ani przekroczenie czasu reakcji. To odpowiedź, która wygląda poprawnie, przechodzi wszystkie sprawdzenia stanu i jest błędna. Poniższe studium przypadku opisuje małą firmę oprogramowania, która w ciągu jednego kwartału wprowadziła do produkcji dwanaście agentów, ale zachowała tylko trzy, i wyjaśnia, co odróżniło te, które przetrwały, od pozostałych, aby można było zaprojektować mechanizmy wykrywania przed wdrożeniem.

Zespół, narzędzia i podstawowe zasady

Firma była przedsiębiorstwem typu B2B SaaS liczącym około czterdziestu pracowników, w tym dziewięciu inżynierów – nie była to laboratorium badawcze. W okresie od 6 stycznia do 27 marca 2026 roku zespół uruchomił dwanaście agentów. Te, które działały w repozytorium kodu, funkcjonowały w środowisku Claude Code; pozostałe były agentami dostosowanymi na bazie API Anthropic i hostowanymi za pomocą małej usługi wewnętrznej, dzięki czemu każdy agent miał wspólny rejestr audytu oraz jeden przycisk wyłączania.

Dwie zasady zostały wdrożone od pierwszego dnia i obie okazały się przydatne do utrzymania:

  • Każdy agent rejestruje każdą akcję w kanale audytowym, włączając akcje odczytu tylko.
  • Każdy członek zespołu może wyłączyć dowolnego agenta w dowolnym momencie, bez potrzeby zatwierdzenia ani zgłoszenia.

Sukces został zdefiniowany w sposób celowo wymagający. Agent uznawany był za udany tylko wtedy, gdy nadal działał po trzydziestu dniach i ktoś sprzeciwił się jego wyłączeniu. Wskaźniki użyteczności łatwo rosną dzięki nowości; znacznie trudniej jest sfałszować sygnał pochodzący od osób broniących narzędzia, od którego są zależne.

Tabela wyników: trzy agenty nadal działają, dziewięć wyłączonych

Na koniec kwartału nadal działały trzy agenty:

  • program do pisania opisów prośb o zmianę
  • pomocnik do przygotowywania zapytań o wsparcie
  • narzędzie do zbierania informacji o incydentach

Dziewięć z nich zostało wyłączonych w ciągu miesiąca: automatyczny recenzent kodu, system odpowiadający na pytania analityczne, bot do aktualizacji zależności, narzędzie do kwarantanny niestabilnych testów, system odpowiadający na e-maile klientów, konwerter notatek z spotkań w zgłoszenia, narzędzie do aktualizacji dokumentacji wiki, system reagujący na anomalie w dziennikach oraz narzędzie do publikowania changelogów.

Wskazówka zabezpieczająca, która nie pomogła

Jak większość zespołów, ten również rozpoczął od wskazówki zabezpieczającej umieszczonej w promptach systemowych każdego agenta, która nakazywała modelowi przyznawać się do niepewności, unikać wartości niemożliwych do weryfikacji oraz podawać źródło dla każdej liczby:

If you are not confident in an answer, say "I don't know" and stop.
Never state a value you cannot verify from the tools available to you.
Cite the source of every number you report.

W praktyce ta instrukcja prawie w ogóle nie miała wpływu, a powód tego jest najważniejszą lekcją z całego ćwiczenia. Jest to szczegółowo omówione w poniższym przypadku niepowodzenia analitycznego.

Prawa dostępu również nadawano ostrożnie: na początku każdy agent miał tylko prawo do odczytu. W ciągu kwartału czterem agentom przyznano prawo do zapisu. Trzy z tych czterech zostały później wyłączone.

To, co łączyło agenty, które przetrwały

Autor opisów wniosków pull request

Działający w Claude Code, ten agent mógł odczytać różnice oraz powiązany problem, a następnie napisać opis do treści wniosku pull request. Inżynier edytował ten opis i łączył go z kodem. Agent obsługiwał około 35 wniosków pull request tygodniowo, a jego opisy były zazwyczaj lepsze od tych napisanych ręcznie przez inżynierów, głównie dlatego, że zmęczony programista ma tendencję do pisania „naprawić błąd”, podczas gdy agent się nie męczy.

Twórca planu triażu wsparcia

Ten agent czytał każdą przychodzącą zgłoszenie, nadawał jej etykietę i sporządzał propozycję odpowiedzi jako notatkę wewnętrzną w systemie obsługi klienta. Nie miał możliwości wysyłania żadnych wiadomości, w ogóle. Około 60% jego propozycji trafiało do użytkowników po niewielkiej edycji, a średni czas pierwszej reakcji zmniejszył się z nieco ponad czterech godzin do około osiemdziesięciu minut.

Zbieracz kontekstu incydentu

Każdy raz, gdy alarm powiadamiał kogoś, ten agent publikował dokładnie jedną wiadomość w kanale incydentu, zawierającą trzy najnowsze aktualizacje z godzinami, zmianę wskaźnika błędów w poszczególnych usługach oraz linki do podobnych incydentów z ostatnich dziewięćdziesięciu dni. Nie podejmował żadnych działań ani nie oferował diagnozy; po prostu zbierał dane z paneli kontrolnych i linki, które inżynier dyżurny musiałby otworzyć ręcznie. Był to najprostszy agent stworzony przez zespół, a jednocześnie ten, którego zespół cenił najbardziej.

Anatomia agenta, który z całą pewnością się myli

Na papierze agent analityczny był najlepiej zaprojektowany spośród dwunastu. Miał dostęp do repliki do odczytu, ręcznie napisanego dokumentu schematu w swoim kontekście oraz interfejsu Slack, a jego zadaniem było odpowiadanie na pytania dotyczące metryk, aby zespół ds. danych nie był przerywany dwadzieścia razy dziennie.

3 lutego ktoś poprosił go o informacje o tygodniowych przychodach. Wygenerował zapytanie, które łączyło zamówienia z płatnościami, traktując przy tym wiersze dotyczące zwrotów jako dodatnie kwoty. Wynik okazał się o około 12% zbyt wysoki, ale w pełni wiarygodny: wielkość była prawidłowa, trend tygodniowy również, a nawet sezonowe spadki po zakończeniu promocji w styczniu były widoczne.

To zawyżone liczby pojawiły się w wpisie z danymi z poniedziałku, a potem także w dwóch kolejnych wpisach z tego dnia. Błąd ujawnił się dopiero 24 lutego, podczas zamykania miesiąca stycznia, gdy suma wyliczona przez zespół finansowy nie zgadzała się ze sumą uzyskaną przez agenta.

Rozważmy, czego nie wydarzyło się w tych trzech tygodniach. Nie było żadnych wyjątków, żadnych alertów ani nagłego wzrostu opóźnień. Zapytanie SQL było poprawne, dane zostały przywrócone, a agent podał źródło dokładnie tak, jak wymagała to instrukcja. Tradycyjne systemy monitoringu służą do wykrywania systemów, które przestają działać, a ten w żadnym momencie nie przestał funkcjonować.

To właśnie w tym miejscu prompt dotyczący barierki ochronnej zawodzi. Polecenie mówienia „Nie wiem”, gdy jesteśmy niepewni, działa tylko wtedy, gdy model posiada własny wewnętrzny sygnał wskazujący na tę niepewność. W tym przypadku model nie był niepewny – po prostu się pomylił. Z zewnątrz pewne błędy nie różnią się od poprawnych rozwiązań, więc prompt nie może ich wykluczyć.

Powstaje stąd użyteczna zasada ogólna: połączenie, które w tajemnicy zmienia znak lub liczbę wierszy, stanowi klasyczny błąd analityczny również dla ludzi. Różnica polega na tym, że analityk ludzki zazwyczaj wie, jakie liczby będą sprawdzane przez dział finansowy, podczas gdy agent nie ma żadnego interesu w uzgodnieniach, chyba że zostanie mu to zapewnione.

Gdy poprawny agent jest ignorowany

Automaticzny recenzent kodu zawiodł w sposób, którego wiele zespołów się nie spodziewało: nie popełnił błędu. Każda prośba o połączenie repozytoriów otrzymywała około 40 jego komentarzy; większość z nich była uzasadniona, a wiele dotyczyło drobnych uwag dotyczących nazewnictwa lub stylu obsługi błędów.

W ciągu trzech tygodni inżynierowie rozwiązywali jego komentarze, nawet ich nie czytając. Następnie pojawił się naprawdę poważny problem – zapytanie bez filtru tenanta – a ten komentarz został pogrzebany wśród 38 uwag dotyczących stylu. Błąd odkryto dwa dni później w środowisku testowym. Recenzent miał rację, ale nadmierna ilość komentarzy zatopiła jego sygnał.

Dlaczego te dziewięć zostało wyłączonych

Powodzenia te można było jasno sklasyfikować:

  • sześć z nich dostarczało pewnych, ale błędnych wyników
  • dwa dostarczały wyniki, których nikt nie czytał
  • jedno zostało wyłączone, ponieważ nikt nie mógł stwierdzić, czy w ogóle coś robi

Zasada projektowa: zatrzymać się o krok przed działaniem człowieka

Trzy nadal funkcjonujące agenty mają jedną wspólną cechę – nie jest nią model, prompt ani framework. Każdy z nich zatrzymuje się o krok przed podjęciem działania przez człowieka. Tworzą one projekt, streszczenie lub zbiór kontekstu, a osoba wykonuje ostateczny krok. Wykonanie tego kroku zmusza osobę do przeczytania przygotowanej pracy.

Każdy agent, który został wyłączony, albo działał samodzielnie, albo wytwarzał wyniki, które bez żadnej rzeczywistej weryfikacji przeradzały się w działanie. Doskonałym przykładem jest agent analityczny: nie miał w ogóle uprawnień do edycji, a mimo to jego rekomendacje trafiały bezpośrednio do decyzji biznesowych dzięki ludziom, którzy mu ufali.

Wynikająca z tego zasada jest prosta: niech agenci przygotowują materiały, ale nie pozwól im przejąć ostatecznego kroku, w którym błąd może mieć poważne konsekwencje.

To ograniczenie nie jest oceną możliwości modelu, a silniejszy model go nie usunie. Chodzi tu o wykrywanie błędów. Typowym problemem agenta jest prawdopodobna, ale błędna odpowiedź, a nie awaria, przy czym większość zespołów ma bardzo niewiele narzędzi do identyfikacji takich błędnych odpowiedzi.

Koszt nigdy nie był wąskim gardłem. Wszystkie dwanaście agentów razem zużyło w tym kwartale nieco mniej niż 900 dolarów na tokeny. Rzadkim zasobem była ludzka uwaga.

Trzy zmiany, które możesz wprowadzić w tym tygodniu

  • Zanim uruchomisz rozwiązanie, udokumentuj, w jaki sposób można wykryć pewnie błędną odpowiedź. Nie chodzi o to, jak zauważysz awarię, ale o to, skąd będziesz wiedział, że wynik jest błędny. Jeśli nie potrafisz napisać takiego zdania, agent powinien jedynie przygotować propozycję, zamiast działać.
  • Uzgadnij każdą liczbę generowaną przez agenta z drugim źródłem według ustalonego harmonogramu. Tygodniowe, automatyczne porównanie z danymi finansowymi wykryłoby błąd w przychodach już drugiego dnia, a jego sprawdzenie zajęłoby zaledwie popołudnie.
  • Dostarczaj wyniki pracy agenta w miejscach, gdzie ludzie już patrzą, i ogranicz ich ilość. Całkowicie nowy kanał zazwyczaj pozostaje niewidoczny, a ściana czterdziestu komentarzy jest tylko przeglądana pobieżnie, podczas gdy zaledwie kilka skupionych komentarzy naprawdę przyciąga uwagę.

    • Porównaj liczbę z drugim źródłem

    Porównaj liczbę agenta z księgą i przerwij, gdy różnica przekracza pół procenta albo jedną jednostkę waluty.

    const reconcile = (agentRevenue: number, ledgerRevenue: number) => {
  const delta = Math.abs(agentRevenue - ledgerRevenue);
  const tolerance = Math.max(1, Math.abs(ledgerRevenue) * 0.005);
  return { ok: delta <= tolerance, delta };
};

    Odpalaj porównanie według harmonogramu. Monitor awarii zostanie zielony; ta kontrola woła człowieka.

    Główne wnioski

    • Największym problemem do rozwiązania jest wiarygodny, błędny wynik, a nie przerwy w działaniu; standardowe monitorowanie go nie wykryje.
    • Instrukcje dotyczące poziomu pewności nie mogą wykryć błędów, których model nie jest świadomy.
    • Dostęp tylko do odczytu nie oznacza czegoś nieszkodliwego: wyniki służące do podejmowania decyzji są w rzeczywistości formą działania.
    • Ilość sygnału sama w sobie stanowi problem; poprawny sygnał przytłoczony szumem nie ma żadnej wartości.
    • Potrzebnym testem dla każdego agenta jest to, czy ktoś miałby zastrzeżenia, gdyby został wyłączony jutro.

    Literatura pokrewna

    Wszystkie artykułyWyślij brief