Jak zbudować agenta AI: pętla, narzędzia, pamięć, zabezpieczenia | We.Inc
Zbuduj agenta AI od podstaw: pętla decyzja, działanie, obserwacja, definicje narzędzi, pamięć, limity kroków, akceptacja człowieka i testy. Zawiera symulator kroków.
Jak zbudować agenta AI
Agent AI to pętla. Model językowy czyta cel i wszystko, co wydarzyło się do tej pory, a potem albo wywołuje jedno ze zdefiniowanych przez Ciebie narzędzi, albo podaje ostateczną odpowiedź. Twój kod uruchamia narzędzie, dopisuje wynik i pyta ponownie. Limity kroków, uprawnienia, akceptacja człowieka i testy sprawiają, że ta pętla jest bezpieczna.
Pięć części agenta
Część
Co budujesz
Co idzie źle bez niej
Pętla
Kod, który wywołuje model, uruchamia narzędzia i powtarza
Po pierwszej odpowiedzi nic się nie dzieje
Narzędzia
Nazwane funkcje z opisem i schematem wejścia
Model może tylko mówić, a nie działać
Pamięć
Bieżący zapis rozmowy plus notatki zapisane między uruchomieniami
Model powtarza wywołania, które już wykonał
Zabezpieczenia
Limity kroków i kosztów, minimalne uprawnienia, akceptacja ryzykownych działań
Niekończące się pętle, niespodziewane rachunki, szkodliwe działania
Ewaluacja
Stałe zadania testowe ze sprawdzeniami uruchamianymi po każdej zmianie
O regresjach dowiadujesz się od użytkowników
Uruchom symulator, aby zobaczyć, jak jedno zadanie przechodzi przez pętlę. Wyłącz i włącz akceptację, aby zobaczyć, gdzie zabezpieczenie przerywa ryzykowny krok. Przebieg jest zaskryptowany, abyś mógł go przeanalizować; prawdziwe uruchomienie pytałoby model na każdym kroku decyzji.
Naciśnij Następny krok, aby przesuwać pętlę po jednym ruchu.
Czytaj każdą linię: decyzja to wybór modelu, działanie to Twój kod uruchamiający narzędzie, obserwacja to wynik dodawany do pamięci.
Przełącz akceptację dla send_email i uruchom ponownie, aby porównać oba przebiegi.
Naciśnij Resetuj, aby zacząć od nowa.
Zacznij od jednego narzędzia i jednego zadania. Dodawaj narzędzia dopiero wtedy, gdy zadanie testowe nie przechodzi z braku jakiegoś, bo każde dodatkowe narzędzie to kolejny wybór, w którym model może się pomylić.
Wyniki narzędzi powinny być krótkie i rzeczowe. Cały zapis wraca do modelu na każdym kroku, więc długie wyniki kosztują i zakopują to, co ważne.
Sprawdzanie uprawnień umieszczaj w kodzie narzędzia, a nie w instrukcjach. Model można przekonać do zignorowania instrukcji; nie obejdzie on sprawdzenia, które wymusza Twoja funkcja.
Loguj każdy krok wraz z wejściem, wyjściem i kosztem. Gdy uruchomienie pójdzie źle, log jest jedynym sposobem, by zobaczyć, która decyzja była błędna.
Najczęściej zadawane pytania
Czy do zbudowania agenta potrzebuję frameworka?
Nie. Rdzeń to pętla while wokół jednego wywołania modelu i instrukcja switch po nazwach narzędzi, jak pokazuje przykład na tej stronie. Frameworki dodają ponowienia, śledzenie i integracje, co pomaga później, ale ukrywa pętlę, gdy dopiero się uczysz.
Jak model wywołuje narzędzie?
Z każdym żądaniem wysyłasz definicje narzędzi. Gdy model chce użyć któregoś, odpowiada nazwą narzędzia i argumentami zamiast zwykłego tekstu. Twój kod uruchamia funkcję i odsyła wynik jako kolejną wiadomość.
Czym różni się pamięć od kontekstu?
Kontekst to to, co model widzi przy tym wywołaniu: instrukcje, cel i dotychczasowy zapis. Pamięć to wszystko, co przechowujesz i później decydujesz się z powrotem umieścić w kontekście, na przykład notatki z poprzedniego uruchomienia.
Jak powstrzymać agenta przed działaniem w nieskończoność?
Ogranicz liczbę kroków i łączne wydatki, a gdy któryś limit zostanie osiągnięty, zakończ uruchomienie jasnym komunikatem. OWASP wymienia Unbounded Consumption wśród swoich zagrożeń na 2025 rok dla aplikacji opartych na modelach językowych.
Jak testować agenta?
Przygotuj zestaw stałych zadań z wynikami, które da się sprawdzić: wywołano właściwe narzędzie, ryzykowne działanie czekało na akceptację, ostateczna odpowiedź zawiera liczbę. Uruchamiaj zestaw po każdej zmianie promptu lub narzędzia i porównuj liczbę zaliczonych testów.
Zabezpieczenia, które naprawdę działają
Lista OWASP na 2025 rok wymienia Excessive Agency jako kluczowe zagrożenie i wskazuje trzy jego przyczyny: nadmierną funkcjonalność, nadmierne uprawnienia i nadmierną autonomię. Każdej odpowiada poprawka, którą kontrolujesz w kodzie.
Daj agentowi tylko narzędzia potrzebne do zadania, każdemu narzędziu najwęższe działające dane uwierzytelniające i wymagaj, by człowiek akceptował działania o dużym wpływie, takie jak wysyłanie, płacenie czy usuwanie. Sprawdzaj autoryzację w systemie, który wywołuje narzędzie, zamiast ufać, że model zachowa się poprawnie.
Niezaufany tekst to główna powierzchnia ataku
Wszystko, co pobiera narzędzie, na przykład strona internetowa, e-mail czy plik, może zawierać instrukcje wymierzone w Twój model. OWASP nazywa to pośrednim prompt injection.
Wyraźnie oznaczaj pobraną treść jako dane, trzymaj ją z dala od własnych instrukcji i nigdy nie pozwól, by tekst z wyniku narzędzia sam odblokował potężniejsze narzędzie. Akceptacja człowieka przy uprzywilejowanych krokach to ostatnia linia obrony, gdy inne zawiodą.
Pętla w czystym JavaScripcie
Bez frameworka i bez SDK dostawcy. callModel to atrapa odtwarzająca stałe decyzje, aby plik działał bez zmian; zastąp ją żądaniem do usługi modelu, z której korzystasz.
Narzędzia znajdują się w jednym obiekcie, ryzykowne wymagają akceptacji, a pętla zatrzymuje się na limicie kroków. Uruchom ją poleceniem node agent.mjs.
Zagrożenia, przed którymi trzeba się zabezpieczyć
Pozycje z OWASP Top 10 for LLM Applications 2025 najważniejsze dla agentów
Zagrożenie
Jak przejawia się w agencie
Poprawka w kodzie
LLM01:2025 Prompt Injection
Pobrana strona każe modelowi wysłać Twoje dane mailem gdzie indziej
Oddzielaj niezaufaną treść, akceptuj uprzywilejowane działania
LLM06:2025 Excessive Agency
Agent może usuwać rekordy, które potrzebował tylko odczytać
Mniej narzędzi, wąskie dane uwierzytelniające, akceptacja działań o dużym wpływie
LLM10:2025 Unbounded Consumption
Pętla przez całą noc ponawia wywołanie niedziałającego narzędzia