Dlaczego agenci AI w produkcji potrzebują czegoś więcej niż tylko dobrego promptu.

W demonstracji agent AI wydaje się niemal zbyt prosty w obsłudze. Podaj modelowi LLM cel, połącz kilka narzędzi, dodaj trochę pamięci i umieść to w pętli. Nagle agent rozumuje, korzysta z API, wyszukuje dokumenty i wykonuje zadania, a pierwsza wersja wydaje się niemal magiczna. To właśnie w środowisku produkcyjnym zaczyna się prawdziwa praca inżynierska.

Jeśli poświęcisz wystarczająco dużo czasu na systemy agentów, centralny problem ulega zmianie. Sprawienie, by model był wystarczająco inteligentny, przestaje być najtrudniejszą częścią. Trudniejszym pytaniem staje się to, jak umieścić sprytny, ale nieoddeterministyczny komponent w systemie, którego ogólne zachowanie pozostaje przewidywalne. Prawie każda decyzja architektoniczna wynika z tego założenia.

Coś więcej niż model LLM z narzędziami

Zwykle mówi się, że agent to LLM w połączeniu z narzędziami i pamięcią. To wystarcza do wyjaśnienia tej koncepcji, ale nie jest wystarczające w praktyce, gdzie obowiązuje pełniejsza formuła: rozumowanie, kontekst, narzędzia, stan, proces pracy, zasady bezpieczeństwa, możliwość obserwacji i odzyskiwanie. LLM jest ważne, ale stanowi tylko jeden komponent.

Weźmy na przykład agenta do analizy dokumentów. Użytkownik przesyła plik i prosi o jego analizę. Za tym jednym żądaniem system może musieć:

1. Sprawdzić, czy żądanie jest ważne.
2. Pobrać informacje z dokumentu.
3. Zdobyć odpowiedni kontekst.
4. Skończyć właściwy prompt.
5. Pozwolić modelowi rozumować na podstawie dostępnych dowodów.
6. Potwierdzić, co model zwrócił.
7. Zastosować dodatkowe narzędzia.
8. Obliczyć wyniki, które muszą być dokładne.
9. Zapisać rezultat.
10. Poinformować interfejs o postępach.
11. Ponowić próbę w przypadku niepowodzenia.

Zapisuj logi i ślady w celu późniejszego debugowania.

W tym momencie praca to już nie projekt szybkiego rozwiązania, lecz projekt systemu rozproszonego, który przypadkowo zawiera LLM. Jasne podziałanie obowiązków jest pomocne.

Dane wejściowe i kontekst

Kontekst obejmuje wszystko, co agent wie o aktualnym zadaniu: instrukcje użytkownika, dokumenty, rekordy bazy danych, stan procesu z poprzednich kroków, pozyskane informacje oraz metadane aplikacji. Główna lekcja brzmi, że dodawanie coraz większej ilości kontekstu samo w sobie nie pomaga. Przekazanie modelowi wszystkiego powoduje dodatkowy hałas, zwiększa koszty i utrudnia przewidywanie jego rozumowania. Celuj w najmniejszy możliwy kontekst, który nadal umożliwia podjęcie decyzji.

Szczegółowe rozumowanie

Tutaj właśnie LLM zarabia na swoje utrzymanie. Potrafi interpretować niejednoznaczne informacje, czytać dokumenty, porównywać dowody, wybierać narzędzia, pisać wyjaśnienia, klasyfikować rzeczy oraz planować kolejny krok. Jedna zasada wymaga szczególnej uwagi: nie powierzaj modelowi żadnych decyzji, które zwykły kod może podejmować w sposób niezawodny.

Załóżmy, że reguła biznesowa brzmi variance <= 5% → PASS. Nikt nie potrzebuje LLM, aby ustalić, czy 3,8% jest mniejsze niż 5%. Wystarczy to obliczyć. Wykorzystuj model tam, gdzie potrzebne jest rozumowanie, a kod tam, gdzie możliwy jest determinizm. Taki podział znacznie ułatwia testowanie systemów agentowych.

Narzędzia czynią agenty przydatnymi

LLM bez narzędzi przede wszystkim opisuje działania. Wyposażony w narzędzia je wykonuje. Typowymi narzędziami są wyszukiwanie, bazy danych, API, odzyskiwanie dokumentów, wykonywanie kodu, usługi wewnętrzne oraz systemy przepływów pracy. Zwykły proces polega na przejściu od żądania użytkownika do agenta, który wybiera narzędzie, je wykonuje, obserwuje wynik i kontynuuje.

To jest istota wzorca ReAct: rozumowanie, działanie, obserwacja, a następnie ponowne rozumowanie. Jest on skuteczny, ponieważ agent nie musi mieć wszystkich faktów od razu i może znaleźć to, czego potrzebuje w trakcie wykonywania zadania.

Każde narzędzie jest również kolejnym miejscem, w którym może dojść do błędu. API może wygaśnąć, dane uwierzytelniające mogą stracić ważność, baza danych może przestać działać, narzędzie może zwrócić uszkodzone dane, a model może przekazać błędne argumenty. Wywoływanie narzędzia nigdy nie powinno oznaczać wysyłania żądania LLM do API i liczenia na najlepszy wynik. W środowisku produkcyjnym konieczne są walidacja, limity czasowe, ponawianie prób, obsługa błędów, uprawnienia oraz dobrze zdefiniowane stany awarii.

Pamięć to nie praktyka gromadzenia

Pamięć należy do najbardziej niezrozumianych elementów projektowania agentów. Intuicja podpowiada, że agent, który pamięta więcej, staje się mądrzejszy. Często tak nie jest. Jeśli przechowywać każdą interakcję na zawsze i włączać ją we wszystkie późniejsze żądania, agent otrzymuje tylko szum, a nie rzeczywistą pamięć.

Pomaga myślenie warstwowo:

• Pamięć robocza przechowuje to, czego potrzebuje aktualne zadanie, takie jak stan procesu pracy, najnowsze wyniki narzędzi oraz obliczenia pośrednie.
• Pamięć długotrwała przechowuje informacje przydatne w różnych zadaniach, takie jak preferencje, wcześniej potwierdzone fakty oraz wyniki historyczne.
• Wiedza zewnętrzna to dane, które już znajdują się gdzie indziej i są pobierane wyłącznie na żądanie, takie jak dokumenty, zasady, rekordy bazy danych oraz wyniki wyszukiwania wektorowego.

Należy zadać pytanie nie o to, ile agent może zapamiętać, ale o to, co musi wiedzieć w danej chwili. Ta niewielka zmiana może znacznie uprościć architekturę.

Bądź ostrożny z wieloma agentami

Układy wieloagentowe są fascynujące. Koordynator może rozdzielić zadania między agenta dokumentowego, agenta badawczego, agenta walidującego oraz agenta raportującego – każdy z nich zajmuje się specjalistyczną częścią problemu. Diagramy przedstawiające takie rozwiązania wyglądają atrakcyjnie, ale nie powinny stanowić domyślnego punktu wyjścia.

Każdy dodatkowy agent wprowadza nowe zadania, kolejne przejścia stanowe, nowe możliwości awarii, dodatkowe granice komunikacji, większą opóźnioność oraz kolejną rzecz do naprawiania. Jeden agent wyposażony w trzy dobrze działające narzędzia często radzi sobie lepiej niż cztery agenty rozmawiające ze sobą.

Dopuszczalną zasadą jest rozpoczęcie od najprostszego projektu, który rozwiązuje problem, a dodawanie kolejnych agentów powinno następować tylko wtedy, gdy ich potrzeba niezależnego rozumowania lub odpowiedzialności może być jasno sformułowana. Projektowanie wieloagentowe powinno rozwiązywać problemy architektoniczne, a nie tylko sprawiać, że schemat wygląda imponująco.

Planowanie na wypadek awarii

Załóżmy proces pracy, który przesyła dokument, wydobywa z niego treść, pobiera kontekst, analizuje go, wywołuje narzędzie i generuje raport. Teraz agent zawiesza się tuż po analizie. Czy wszystko zaczyna się od nowa? Czy coś zostało już zapisane do bazy danych? Czy bezpieczne jest wykonywanie tej operacji dwukrotnie? Czy interfejs nadal pokazuje zadanie jako w trakcie wykonywania? Czy inny pracownik może je przejąć?

Tutaj tradycyjna inżynieria backendu staje się niezbędna. Agenci produkcyjne wymagają:

• Ponawień, aby tymczasowe błędy nie zniszczyły procesu pracy.
• Idempotencji, aby ponowne próby nie powodowały podwójnych skutków ubocznych.
• Punktów kontrolnych, aby długi proces wiedział, które kroki zostały już zakończone.
• Czasów wygaśnięcia, ponieważ agent nie powinien pracować w nieskończoność.

Zabezpieczenia i ograniczenia dotyczące liczby iteracji, wywołań narzędzi, kosztów oraz czasu działania.

Jasno określone stany, takie jak QUEUED → RUNNING → COMPLETED lub QUEUED → RUNNING → FAILED → RETRYING.

Niczego z tego nie brzmi tak ekscytująco jak inżynieria promptów, a jednak to właśnie te elementy sprawiają, że agenci są godni zaufania.

Zobaczenie tego, co zrobił agent

Zwykłe aplikacje już wymagają logów i metryk. Agenci potrzebują czegoś więcej. Gdy agent dostarczy zły wynik, informacja o tym, że żądanie HTTP zwróciło 200 OK, niewiele mówi. Ważna jest cała ścieżka: żądanie, pobrany kontekst, utworzony prompt, wywołanie modelu, wybrane narzędzie, jego uruchomienie, ocena wyniku oraz ostateczna odpowiedź.

Dla każdego uruchomienia zespół powinien móc odzyskać następujące informacje:

• Kontekst, który otrzymał agent
• Model, który został uruchomiony
• Narzędzia, które zostały wywołane, oraz w jakiej kolejności
• Czas spędzony na każdym kroku
• Użycie tokenów
• Powód awarii – czy to infrastruktura, czy proces rozumowania
• Werdykt z kroku oceny

To jeden z powodów, dla których śledzenie i ocena stały się tak ważnymi elementami ekosystemu agentów. Tego, czego nie można zaobserwować, nie da się poprawić.

Testowanie zachowań niedeterministycznych

Klasyczne oprogramowanie oferuje prostą zasadę: dane wejściowe A dają wynik B. LLM nie muszą się do niej stosować, ponieważ dwa poprawne odpowiedzi mogą być sformułowane zupełnie inaczej. Dlatego testowanie wymaga kilku warstw.

Części deterministyczne są testowane w zwykły sposób: API, obliczenia, schematy, przejścia stanowe oraz operacje bazy danych. Części oparte na modelu są oceniane pod kątem poprawności faktograficznej, kompletności, istotności, jakości rozumowania, doboru narzędzi oraz przestrzegania instrukcji. Realistyczne procesy end-to-end powinny być uruchamiane na reprezentatywnych danych, ponieważ ujawniają problemy, których nie dostrzegają pojedyncze zapytania. Nawet rozbudowany zestaw narzędzi nie może obejmować wszystkich możliwych danych z rzeczywistego świata, dlatego pętla oceny trwa również po wdrożeniu.

Autonomia powinna uwzględniać ryzyko

Niektórzy zakładają, że „prawdziwy” agent musi być w pełni autonomiczny. Taki pogląd pomija rolę ryzyka. Porównajmy trzy działania: streszczanie dokumentu, proponowanie zmiany w rekordzie finansowym oraz automatyczne przeprowadzenie transakcji o dużym wpływie. Nie powinny one korzystać z tego samego modelu zatwierdzania. Praktyczne rozwiązanie wygląda następująco:

• Niskie ryzyko: wykonać automatycznie.
• Ryzyko średnie: wykonać, a następnie zarejestrować lub przejrzeć.
• Ryzyko wysokie: wymaga ludzkiej aprobaty przed wykonaniem.

Celem nie jest maksymalna autonomia, lecz użyteczna autonomia z kontrolowanym ryzykiem.

Podsumowując, obraz jest jasny, a LLM okazuje się w nim stosunkowo małym elementem. To celowe.

Pytania przed wyborem frameworka

Zanim wybierzesz framework lub napiszesz złożony prompt, warto postawić kilka pytań:

1. Która decyzja naprawdę wymaga AI? Jeden krok rozumowania nie czyni całego procesu inteligentnym.
2. Co może pozostać deterministyczne? Obliczenia, weryfikacja, uprawnienia oraz kluczowe zasady biznesowe powinny znajdować się w kodzie.

Jaki kontekst naprawdę potrzebuje agent? Pobieraj dane selektywnie i pomijaj pełny dump zapytania.

Co się stanie, jeśli zawiedzie w połowie? Zaprojektuj mechanizmy ponawiania prób i przywracania funkcjonowania, zanim produkcja spowoduje problem.

Jak będzie oceniana jakość? Zdefiniuj kryteria oceny, zanim celebrować pierwszą udaną demonstrację.

Jak będzie to debugowane za sześć miesięcy? Od pierwszego dnia wdrażaj śledzenie i uporządkowane logowanie.

Czy uzasadnione jest użycie więcej niż jednego agenta? Jeśli powód nie może być jasno wyjaśniony, prawdopodobnie jeszcze nie.

Inżynieria promptów, wybór modeli oraz technologia RAG wciąż odgrywają kluczową rolę. Jednak w warunkach produkcji wymagana jest szersza dyscyplina: architektura oprogramowania oparta na inteligencji probabilistycznej. Najlepszy projekt to nie ten z największą liczbą agentów, największym modelem czy najnowocześniejszym frameworkiem do orkiestracji. To taki, w którym można określić, co agent wie, co może, a czego nie może robić, jak mierzy się poprawność działania, co dzieje się w przypadku awarii oraz jak system się odzyskuje. Wtedy agent AI przestaje być tylko ładną demonstracją i staje się oprogramowaniem godnym zaufania.

Literatura pokrewna

• Jak przetrwać nagłe wzrosty ruchu w systemach wielu agentów dzięki trójwarstwowemu kontraktowi — Jak utrzymać spójność grafu agentów, gdy obciążenie wzrasta dziesięciokrotnie: mechanizm zarządzania kolejką, ograniczanie wykorzystania narzędzi oraz synchroniczne sprawdzanie zasad, a także metryki i szczegółowy opis procedur radzenia sobie z takimi sytuacjami.
• Strumieniowanie agentów głębokich LangChain: plany w czasie rzeczywistym, wywołania narzędzi i tokeny — Jak zastąpić blokujące wywołania strumieniem, aby użytkownicy mogli obserwować pracę agenta głębokiego: trzy tryby strumieniowania, przestrzenie nazw dla podagentów oraz filtrowanie tokenów służących do streszczania.