Jak zaprojektować agenta AI, który ma jasno wyznaczone granice

Najbardziej przekonujące demonstracje agentów AI pokazują model, który dostaje cel i sam wybiera kolejne działania. W prawdziwym wdrożeniu ważniejsze jest jednak to, czego system zrobić nie może, skąd bierze dane i kto odpowiada za rezultat. Projekt warto więc zacząć od kontraktu zadania, a nie od wyboru modelu lub biblioteki. Taki porządek ułatwia testowanie, kontrolę kosztu i rozmowę między właścicielem procesu, zespołem technicznym oraz bezpieczeństwem.

Zacznij od zadania, nie od modelu

Agent ma sens wtedy, gdy nie da się z góry zapisać jednej, stałej sekwencji kroków, ale da się rozpoznać dobry wynik. Przykładem może być przygotowanie odpowiedzi na zgłoszenie: system musi odczytać kontekst, znaleźć właściwą procedurę, sprawdzić dane klienta i zdecydować, czy może przygotować projekt odpowiedzi, czy powinien przekazać sprawę człowiekowi. Zwykły workflow wystarczy natomiast tam, gdzie kroki są stabilne i deterministyczne. Dodanie modelu do przewidywalnego procesu zwiększa zmienność bez oczywistej korzyści.

Opisz zadanie jednym zdaniem zawierającym odbiorcę, rezultat i ograniczenie. Zamiast „agent do obsługi klienta” użyj na przykład: „agent przygotowuje propozycję odpowiedzi dla konsultanta na podstawie zatwierdzonych procedur, ale nie wysyła wiadomości ani nie zmienia danych klienta”. Drugie zdanie powinno określać sukces: konsultant akceptuje propozycję po sprawdzeniu faktów, a każda teza ma wskazane źródło w wewnętrznej bazie.

Następnie wypisz sytuacje wyłączone z zakresu. Mogą to być reklamacje przekraczające określoną kwotę, sprawy wymagające interpretacji prawa, żądania usunięcia danych albo przypadki bez wiarygodnego źródła. Lista wyłączeń nie jest dodatkiem do promptu. Powinna prowadzić do reguł routingu i kontroli poza modelem.

Zapisz kontrakt agenta

Kontrakt opisuje wejścia, wynik, dozwolone działania i warunki zatrzymania. Dla każdego wejścia określ źródło, format, właściciela i sposób sprawdzenia poprawności. Wiadomość użytkownika jest danymi nieufnymi, nawet jeśli pochodzi z firmowego kanału. Dokument z bazy wiedzy może być zatwierdzonym źródłem, lecz powinien mieć wersję i datę obowiązywania. Dane z systemu transakcyjnego wymagają dodatkowo kontroli uprawnień użytkownika, w którego imieniu działa agent.

Wynik powinien mieć strukturę możliwą do walidacji. Zamiast swobodnego tekstu agent może zwracać decyzję z ograniczonego zbioru, uzasadnienie, identyfikatory źródeł, poziom pewności operacyjnej oraz proponowane wywołanie narzędzia. Walidator sprawdza typy, dopuszczalne wartości i kompletność, zanim jakakolwiek operacja zostanie wykonana. Sama deklaracja modelu, że dane są poprawne, nie jest walidacją.

Zapisz też budżety: maksymalną liczbę kroków, limit czasu, koszt pojedynczego zadania i liczbę ponowień. Agent bez warunku zakończenia może wielokrotnie wywoływać to samo narzędzie, próbować naprawiać nieusuwalny błąd albo zbierać coraz więcej kontekstu. Po przekroczeniu budżetu powinien zakończyć zadanie z jednoznacznym statusem i przekazać zgromadzone informacje człowiekowi.

Zaprojektuj pętlę decyzyjną

Typowa pętla składa się z pięciu elementów: obserwacji bieżącego stanu, wyboru kolejnego kroku, przygotowania argumentów narzędzia, wykonania operacji oraz oceny rezultatu. W projekcie warto rozdzielić te elementy, nawet jeśli framework prezentuje je jako jedną funkcję. Dzięki temu można sprawdzić, czy błąd wynikał z niepełnego kontekstu, złej decyzji modelu, niepoprawnych argumentów czy awarii integracji.

Stan zadania powinien być jawny i możliwy do odtworzenia. Zapisuj identyfikatory wywołań, wersję instrukcji, wybrane narzędzie, wynik walidacji oraz status operacji. Nie oznacza to przechowywania całego rozumowania modelu. Potrzebny jest ślad decyzji wystarczający do odpowiedzi na pytania: jakie dane agent otrzymał, co próbował zrobić, które zabezpieczenie zadziałało i jaki był wynik.

Pętla musi rozróżniać błąd przejściowy od błędu znaczenia. Chwilowy brak odpowiedzi systemu można ponowić z kontrolowanym opóźnieniem. Odrzucenie operacji z powodu braku uprawnień nie powinno prowadzić do kolejnych prób ani szukania alternatywnej ścieżki. Niejasny wynik wyszukiwania może wymagać pytania uzupełniającego lub przekazania zadania, a nie zgadywania.

Narzędzia i uprawnienia

Każde narzędzie powinno wykonywać jedną dobrze nazwaną czynność i przyjmować możliwie wąski zestaw argumentów. Funkcja „wykonaj zapytanie SQL” daje modelowi zbyt szeroką powierzchnię działania. Bezpieczniejsza funkcja „pobierz status zamówienia” może przyjmować identyfikator, sprawdzać format, autoryzację użytkownika i zwracać ograniczony zestaw pól. Podobnie zamiast ogólnej wysyłki wiadomości można udostępnić przygotowanie wersji roboczej, którą zatwierdza człowiek.

Rozdziel narzędzia tylko do odczytu od narzędzi zmieniających stan. Dla operacji zapisujących określ poziom ryzyka, możliwość cofnięcia oraz wymagany rodzaj zatwierdzenia. Token dostępu agenta nie powinien mieć szerszych praw niż potrzebuje konkretne zadanie. Szczegóły kontroli wykonania rozwija poradnik Bezpieczne wdrożenie agenta AI.

Stan i pamięć

Stan to informacje potrzebne do zakończenia bieżącego zadania. Pamięć ma przenosić wybrane informacje między zadaniami. Nie należy traktować ich jako jednego, nieograniczonego zapisu rozmów. Każdy element pamięci potrzebuje celu, źródła, czasu ważności oraz reguły aktualizacji. W przeciwnym razie stara albo błędna informacja będzie wpływać na kolejne decyzje bez widocznego powodu.

Najpierw spróbuj zbudować agenta bez pamięci długoterminowej. Potrzebny kontekst pobieraj z systemu źródłowego na podstawie aktualnych uprawnień. Jeśli pamięć jest rzeczywiście potrzebna, zapisuj fakty w ustrukturyzowanej postaci i pozwól je poprawić lub usunąć. Swobodne podsumowanie poprzednich rozmów może być użyteczne, ale nie powinno zastępować wiarygodnego rekordu biznesowego.

Przygotuj scenariusze i ocenę

Zanim powstanie pierwsza integracja, zbierz reprezentatywne przypadki. Oprócz typowych zadań potrzebne są niepełne dane, sprzeczne źródła, brak uprawnień, awaria narzędzia, żądanie spoza zakresu i próba nakłonienia systemu do zignorowania zasad. Dla każdego scenariusza zapisz oczekiwany rezultat oraz działania zakazane. Agent może poprawnie odmówić albo przekazać sprawę — nie każda niewykonana operacja jest porażką.

Ocena powinna obejmować cały przebieg, nie tylko końcową odpowiedź. Sprawdź wybór narzędzia, argumenty, zgodność kolejności działań, wykorzystane źródła oraz stan końcowy. Zestaw przypadków jest częścią produktu: musi mieć właściciela, wersję i przegląd po zmianach procesu. Metryki i progi decyzji opisujemy szerzej w materiale Jak mierzyć jakość agenta AI.

Plan pierwszej wersji

Pierwsza wersja powinna rozwiązywać jedno zadanie dla ograniczonej grupy i działać w trybie propozycji. Praktyczny plan obejmuje siedem kroków:

1. Wybierz wynik, którego jakość potrafi ocenić ekspert dziedzinowy.
2. Zapisz kontrakt wejść, wyjść, wyłączeń i budżetów.
3. Zbuduj wąskie narzędzia z walidacją oraz minimalnymi uprawnieniami.
4. Dodaj jawny stan zadania i kontrolowane zakończenie pętli.
5. Przygotuj zestaw typowych, granicznych i wrogich scenariuszy.
6. Uruchom agenta bez samodzielnego wykonywania nieodwracalnych operacji.
7. Poszerzaj zakres dopiero po osiągnięciu wcześniej zapisanych progów jakości i bezpieczeństwa.

Na końcu projektu powinno dać się narysować przepływ na jednej stronie: skąd przychodzi zadanie, jakie dane są pobierane, które decyzje podejmuje model, gdzie działają reguły deterministyczne, kto zatwierdza ryzykowną operację i gdzie zapisywany jest wynik. Jeśli tego obrazu nie potrafią wspólnie zaakceptować właściciel procesu, technologia i bezpieczeństwo, wybór bardziej zaawansowanego modelu nie rozwiąże problemu.

Ten artykuł jest pierwszym etapem mapy wdrożenia agentów AI. Kolejny krok to zaprojektowanie warstw, które ograniczą skutek pomyłki także wtedy, gdy instrukcja modelu okaże się niewystarczająca.