Dlaczego agenci AI zawodzą w produkcji: wyjaśnienie inżynierii harnessu

Załóżmy programistę o drugiej w nocy, który spędził trzy tygodnie na przepisywaniu instrukcji, testowaniu najnowszego modelu flagowego oraz dostosowywaniu rozmiarów fragmentów danych RAG. W środowisku testowym agent funkcjonuje doskonale. W warunkach produkcyjnych jednak zawodzi: zapomina o decyzji podjętej dwa kroki wcześniej, ogłasza sukces tuż przed oddaniem uszkodzonego wyniku, a jego stopa skuteczności w wykonywaniu zadań wynosi 68%, niezależnie od używanego modelu. Przekroczenie tego procentu wydaje się niemożliwe.

Wiele zespołów rozpoznaje tę sytuację. Powszechną diagnozą jest stwierdzenie, że model nie jest wystarczająco dobry. Lepszą diagnozą jest to, że problem leży w systemie zbudowanym wokół modelu, i dopóki tego nie zaakceptuje się, żadna zamiana modelu niewiele zmieni.

Trzy etapy pracy z LLM

Rozważania na temat zastosowań LLM przechodziły przez trzy etapy, a wiele zespołów wciąż utknęło na jednym lub dwóch z nich, napotykając problemy charakterystyczne dla trzeciego etapu.

Etap pierwszy: inżynieria promptów

Wszyscy zaczynają tutaj, pytając się, czy model zrozumiał prośbę. Modele językowe są niezwykle wrażliwe na sposób, w jaki są kierowane. Dobrze dobrane role, kilka przykładów oraz określony format wyjściowy mogą znacząco poprawić wyniki, a przy zadaniami jednoetapowymi dobre formułowanie promptów jest niezbędne.

Jednak istnieje też granica. Bez względu na to, jak elegancko sformułowane są instrukcje, nie mogą one dostarczyć modelowi brakujących faktów, sprawić, by zapamiętał to, co wydarzyło się trzy wcześniejsze wezwania narzędzi, ani powstrzymać go przed wymyślaniem danych, gdy rzeczywistość jest niezadowalająca. Powszechnym błędem jest przekonanie, że bardziej precyzyjny prompt może zastąpić brakujące informacje lub aktualny kontekst. Nie może tego zrobić.

Etap drugi: inżynieria kontekstu

Następnym pytaniem jest to, czy model posiada niezbędne fakty. Zespoły dodają pipeline’y typu RAG, dynamiczne wyszukiwanie informacji, wyniki działania narzędzi wprowadzane w obieg oraz starannie dołączaną historię rozmów, zaczynając zwracać uwagę na to, co model może zobaczyć podczas podejmowania decyzji. To prawdziwy postęp – agenci stają się znacznie mądrzejsi, gdy odpowiednie informacje trafiają we właściwym czasie.

To, czego nie naprawia praca nad kontekstem, to odchylenie w realizacji planu. Agent opracowuje doskonały plan, poprawnie wykonuje pierwszy krok, ale przy drugim kroku błędnie interpretuje wartość zwróconą przez narzędzie i dalej zbacza z kursu przez kolejne kilkanaście kroków. Nic w systemie tego nie zauważa – nadal realizuje plan, który już dawno się sprawdził jako błędny.

Jednym z częstych błędów jest traktowanie inżynierii kontekstu jako czegoś tożsamego z RAG w bazach danych wektorowych. Prawdziwe zarządzanie kontekstem obejmuje również dynamiczne wprowadzanie stanu, podsumowywanie odpowiedzi narzędzi oraz celowe skracanie historii. RAG to dopiero początek.

Etap trzeci: inżynieria wspomagająca

Pytanie brzmi teraz, czy model może nadal działać poprawnie z biegiem czasu, a odpowiedź jest nieco demotywująca dla tych, którzy mieli nadzieję, że lepszy model to załatwi. Inżynieria wspomagająca to praktyka budowania „szkieletu” wokół modelu: systemów deterministycznych, które obserwują jego działania, wykrywają błędy, narzucają ograniczenia i przywracają go na właściwą ścieżkę, gdy się zbłądzi. Słowo to pochodzi od wodzy i lin bezpieczeństwa – sprzętu służącego do kontroli.

Model mentalny: agent to model plus system wspomagający

Framing upowszechniony przez LangChain wyjaśnia to prosto: agent to model w połączeniu z narzędziem pomocniczym. Prawie wszystko w bazie kodu, co umożliwia działanie agenta w środowisku produkcyjnym, z wyjątkiem żądania do API modelu bazowego, należy do tego narzędzia pomocniczego.

Pomyśl o wysłaniu młodszego kolegi na ważne spotkanie z klientem.

• Prompting to agenda: powitanie, prezentacja produktu, pytania o wymagania.
• Context to informacje tła: historia współpracy z klientem, lista cen oraz cele spotkania.
• Narzędzie pomocnicze to wszystko inne: lista kontrolna, sprawdzenie z tobą w połowie spotkania, nagrana transkrypcja, sposób na skorygowanie błędów oraz jasne kryteria akceptacji raportu z spotkania.

Lepsze informacje nie mogą zrekompensować braku struktury odpowiedzialności. Pierwsze dwa etapy pomagają modelowi myśleć lepiej, a narzędzie umożliwia mu niezawodne działanie. Relacja jednej z drużyn, która stanowi anegdotę a nie punkt odniesienia, pokazuje, że przeprojektowanie rozkładu zadań, obsługi stanów, weryfikacji kluczowych kroków oraz procedur naprawczych po awarii sprawiło, że ten sam model przy tych samych instrukcjach osiągnął od około 70% do ponad 95% skuteczności w wykonywaniu zadań.

Sześć warstw dojrzałego narzędzia

Narzędzie to nie jest jeden plik ani sprytna otoczka – składa się z warstw, przy czym każda z nich zajmuje się innym rodzajem awarii.

Warstwa 1: granice informacji

To, co model widzi w swoim bezpośrednim kontekście, wpływa na jego wydajność bardziej niż prawie cokolwiek innego. Dodatkowe dane nie czynią go mądrzejszym – sprawiają, że traci koncentrację. Mieszanie reguł systemowych, aktualnego stanu zadania oraz zewnętrznych dowodów w jedną niestруктуrowaną całość jest jeszcze gorsze, ponieważ model zaczyna ignorować określone ograniczenia, a kluczowe reguły stają się tylko szumem tła. System powinien wyraźnie określić i oznaczyć, co model otrzymuje: jego rolę, aktualny cel, kryteria sukcesu oraz dokładnie rozdzielić rodzaje informacji.

Szczegół 2: system narzędzi

Bez narzędzi model językowy potrafi jedynie przewidywać tekst. Dzięki dobremu systemowi narzędzi może działać w rzeczywistym świecie. Typowym błędem na początku jest dostarczenie mu zbyt wielu narzędzi. Piętnaście dobrze udokumentowanych narzędzi może wydawać się imponujące, ale uwaga modelu jest rozproszona, a on zaczyna wymyślać parametry, które w rzeczywistości nie istnieją, lub niewłaściwie używa interfejsów API, których ledwo rozumie.

The harness should govern when tools get used, not just which ones exist. It should stop the model from guessing when it ought to search, and from searching when it already knows. And one rule has no exceptions: don't pipe raw tool output straight back to the LLM. A 50-item JSON reply from an API poisons the context. Filter, parse and summarise results before the model sees them.

Layer 3: execution orchestration

Models often fail not for lack of individual skills but because they can't chain them in order. They run in a stream of consciousness, hopping between steps, skipping checks and writing output before they have what they need. The harness sets fixed rails: understand the goal, assess what information is held, fetch what's missing, analyse, generate, verify, then output.

To przenosi zarządzanie projektem z modelu probabilistycznego na system deterministyczny. Model nie powinien decydować o kolejności zadań, a ta struktura należy do narzędzi pomocniczych.

Słoj 4: pamięć i stan

Agent bez stanu ma amnezję przy każdej turze, jakby każdy krok w zadaniu wieloetapowym był nową rozmową. Skuteczne podejście trzyma trzy rodzaje pamięci ściśle oddzielone:

1. Bieżący stan zadania, czyli który krok jest aktywny, co jest w toku i co zostało potwierdzone.
2. Wnioсы pochodzące z tej sesji.
3. Pamięć długoterminowa i profile użytkowników, takie jak preferencje i kontekst utrzymujący się między sesjami.

Największym błędem jest łączenie stanu zadania z historią rozmowy. W rezultacie powstaje coraz większe, bezkształtne okno kontekstu, które pogarsza działanie modelu w miarę postępów w zadaniu.

Słoj 5: ocena i obserwowalność

Proste agenty tutaj zawodzą. Tworzą wyniki, informują o sukcesie, ale nie mają sposobu, by sprawdzić, czy to prawidłowe. Agent oceniający własną pracę ma wrodzony optymistyczny uprzedzenie: uznaje uszkodzony kod za działający i ocenia odpowiedź jako zadowalającą, mimo że w ogóle nie odpowiedział na pytanie.

Narzędzie to wymaga niezależnych, zautomatyzowanych sprawdzeń. Ludzka weryfikacja później jest zbyt powolna i nie nadaje się do skalowania. Ta warstwa obejmuje zautomatyzowaną weryfikację wyników, środowiska testowe, szczegółowe rejestrowanie działań, metryki oraz identyfikację błędów. System musi ciągle udowadniać, że jego działania są prawidłowe, a nie po prostu o tym zakładać.

Warstwa 6: ograniczenia, weryfikacja i przywracanie stanu

Powodzenie to stan normalny w produkcji. API wygasają, JSON ulega uszkodzeniu, a wyniki wyszukiwania są błędne. Agent bez możliwości samodzielnego przywrócenia stanu wymaga pełnego restartu przez człowieka po każdym błędzie. Potrzebne są trzy elementy:

• Ograniczenia: sztywno zdefiniowane reguły określające, czego agent absolutnie nie może robić.
• Walidacja : sprawdzania przed i po wygenerowaniu wyniku, takie jak walidacja schematu, kontrola formatu oraz weryfikacja ograniczeń.
• Odzyskiwanie : próby ponownego wykonania, ścieżki awaryjne oraz powrót do ostatniego znanej stabilnego stanu.

Lęk przed kontekstem

W zadaniach obejmujących wiele dziesiątek kroków pojawiają się dziwne zjawiska, które badacze z Anthropic nazwali „lękiem przed kontekstem”. Gdy okno kontekstowe zbliża się do swojego limitu, modele tracą drobne szczegóły, zapominają o głównych celach i wydają się spieszyć z zakończeniem pracy. Tworzą wnioski, do których nigdy nie doszły, i pomijają weryfikację – robią to w takim pośpiechu, że stają się nieostrożne.

Oczywistym rozwiązaniem jest kompresja: streszczamy historię, wstawiamy to streszczenie i kontynuujemy. Dzięki temu zmniejsza się liczba tokenów, ale nie resetuje się stanu poznawczego modelu ani stopnia rozproszenia uwagi. Skuteczne jest podejście bardziej radykalne – całkowite restartowanie agenta. Gdy kontekst staje się zbyt duży, skompresowane streszczenie trafia do zupełnie nowej instancji agenta z czystym kontekstem i bez żadnych nagromadzonych problemów. To jak naprawa wycieku pamięci poprzez restart procesu, a nie poprzez gorączkowe zbieranie śmieci. Nazwą używaną dla tego podejścia jest „context reflect”.

Korzyści z dostępu do narzędzi wynikają z podobnej koncepcji zwanej stopniowym ujawnianiem informacji. Zamiast ładować całą bibliotekę narzędzi od razu, model widzi tylko minimalne elementy. Gdy sygnalizuje potrzebę określonej funkcji, system wtedy dostarcza szczegółową dokumentację oraz schemat parametrów. Optymalizacja kontekstu nie polega na dawaniu modelowi więcej informacji, lecz na dostarczaniu mu odpowiednich materiałów w momencie ich potrzeby.

Rozdzielenie generowania od oceny

Jedna z najprzydatniejszych koncepcji pochodzi od sposobu, w jaki Anthropic tworzy autonomiczne agenty, które potrafią przez godziny generować kompletny produkt bez żadnej ludzkiej interwencji. Podstawą jest ścisłe podział na trzy elementy:

• Planista przekształca niejasne prośby ludzi w precyzyjne specyfikacje inżynieryjne.
• Generator bierze te specyfikacje i realizuje je krok po kroku.

Ewaluator pełni rolę niezależnego specjalisty ds. jakości, funkcjonalnie oddzielonego od generatora.

Ewaluator nie tylko czyta kod generatora. Wchodzi w interakcję z wynikiem. W przypadku prac z interfejsem użytkownika przegląda go, sprawdza układ oraz testuje stan interaktywny. Porównuje wyniki z rzeczywistością, a nie z opisem rzeczywistości dostarczonym przez generatora.

OpenAI posunęło się dalej. Gdy agenci zaczęli pisać kod szybciej, niż ludzie mogli przejrzeć prośby o włączenie zmian, dostali oni własny zautomatyzowany pipeline CI/CD. Agenci wykonywają swoje zadania w izolowanych środowiskach testowych, robią skróty ekranu za pomocą bezokiennej przeglądarki, analizują własne logi i wciąż powtarzają proces, aż deplojacja zostanie zatwierdzona, i to bez żadnego nadzoru. „Gotowe” nie oznacza już tylko wygenerowania tekstu – oznacza to, że kod został uruchomiony, sprawdzono logi, znaleziono i naprawiono błąd oraz zweryfikowano deplojację w środowisku testowym.

Gdzie naprawdę znajduje się sufit możliwości

Inteligencja modelu podstawowego określa teoretyczną granicę na liście najlepszych wyników. To, jak dobrze zaprojektowana jest infrastruktura wspierająca, decyduje o tym, czy ta inteligencja będzie w stanie przetrwać, odzyskać funkcjonalność i przynieść korzyści w trudnych warunkach rzeczywistych. Po osiągnięciu określonego poziomu model przestaje być wąskim gardłem. Różnica pomiędzy wskaźnikiem skuteczności 70% a 95%, która odpowiada również różnicy pomiędzy wersją demonstracyjną a produktem końcowym, leży właśnie w tej infrastrukturze.