Agent AI to nie chatbot. Co potrafi zrobić sam?

Zanim przejdziemy do technicznych smaczków, zacznijmy od podstaw: czym właściwie jest agent AI?

Od modelu językowego do agenta

Najprostsza aplikacja wykorzystująca LLM działa zwykle tak:

Użytkownik → Model → Odpowiedź

Użytkownik zadaje pytanie, model generuje odpowiedź i cały proces się kończy.

Agent AI działa inaczej.

Zamiast od razu wygenerować końcową odpowiedź, może najpierw zdecydować, że potrzebuje dodatkowych informacji albo musi wykonać jakąś akcję.

Agent rozszerza więc możliwości samego modelu, ponieważ oprócz generowania tekstu może otrzymać dostęp do narzędzi (tools) - funkcjonalności udostępnionych mu przez aplikację.

Takim narzędziem może być na przykład:

• baza danych,
• wyszukiwarka internetowa,
• system RAG,
• zewnętrzne API,
• kalkulator,
• interpreter Pythona,
• przeglądarka,
• system plików,
• terminal.

I nie musimy zatrzymywać się na świecie cyfrowym.

Jeżeli agent działa jako część robota albo urządzenia wyposażonego w sensory, jego narzędziami mogą być również kamera, mikrofon, czujniki odległości, temperatury czy nawet sensory chemiczne.

Model otrzymuje wtedy możliwość nie tylko generowania tekstu, ale również obserwowania środowiska i podejmowania w nim działań.

Prosty przykład

Wyobraźmy sobie, że użytkownik pyta:

„Ile wydałem na jedzenie w tym miesiącu?”

Sam model językowy nie zna naszych aktualnych transakcji.

Agent może jednak stwierdzić, że do udzielenia odpowiedzi potrzebuje danych z naszego konta.

Proces może więc wyglądać tak:

Użytkownik → Agent → pobranie transakcji → analiza → odpowiedź

Agent może wykonać zapytanie do bazy danych, otrzymać listę transakcji, wybrać wydatki związane z jedzeniem, zsumować je i dopiero wtedy odpowiedzieć użytkownikowi.

Co ważne, agent nie musi korzystać tylko z jednego narzędzia.

Może wykonać serię kroków:

Użytkownik → Model → Baza danych → Model → Kalkulator → Model → Odpowiedź

W wielu architekturach to właśnie model może zdecydować:

• jakich informacji potrzebuje,
• którego narzędzia użyć,
• jakie argumenty mu przekazać,
• co zrobić z otrzymanym wynikiem,
• czy potrzebuje jeszcze kolejnego kroku,
• oraz kiedy ma już wystarczająco dużo informacji, żeby zakończyć zadanie.

Powstaje w ten sposób pętla:

planuj → działaj → obserwuj wynik → zdecyduj, co dalej

I właśnie tutaj pojawia się jedna z najważniejszych różnic między zwykłym chatbotem a agentem.

Chatbot przede wszystkim odpowiada. Agent może również działać.

Narzędzia wyznaczają możliwości agenta

Oczywiście nadal to programista określa, do jakiego środowiska agent ma dostęp i jakie uprawnienia mu nadajemy.

Nie oznacza to jednak, że jesteśmy w stanie przewidzieć każdą konkretną operację, którą agent wykona.

Jeżeli udostępnimy mu tylko trzy bardzo konkretne narzędzia:

search_products()

get_order_status()

get_return_policy()

jego możliwości pozostają stosunkowo łatwe do zrozumienia.

Może wyszukiwać produkty, sprawdzać status zamówienia i pobierać zasady zwrotów.

Sytuacja zmienia się jednak, gdy jednym z narzędzi staje się na przykład:

execute_python()

run_shell_command()

browser()

To narzędzia znacznie bardziej ogólne.

Agent posiadający dostęp do Pythona może podczas wykonywania zadania sam napisać funkcję, wykorzystać bibliotekę, przetworzyć plik albo przygotować skrypt wykonujący serię operacji.

Jeżeli dodatkowo ma dostęp do shella, sieci i systemu plików, jego rzeczywiste możliwości mogą być dużo większe, niż sugerowałaby sama liczba tools widocznych w kodzie.

Możemy mieć pozornie tylko jedno narzędzie:

run_shell_command()

ale poprzez nie agent może - zależnie od konfiguracji środowiska - tworzyć skrypty, uruchamiać programy, pracować na plikach, komunikować się z API, korzystać z zainstalowanych bibliotek czy łączyć wiele poleceń w nową procedurę.

I tutaj pojawia się ważne rozróżnienie.

Agent nie tworzy sobie magicznie nowych uprawnień. Może jednak tworzyć nowe sposoby wykorzystania tych, które już posiada.

Dlatego rzeczywiste możliwości systemu agentowego zależą nie tylko od liczby zdefiniowanych tools, ale również od:

• uprawnień procesu,
• dostępu do sieci,
• systemu plików,
• dostępnych bibliotek i programów,
• przechowywanych poświadczeń,
• izolacji środowiska,
• systemów, z którymi agent może się komunikować,
• oraz błędów i luk występujących w tych systemach.

Co się dzieje, gdy agent znajdzie inną drogę?

To nie jest już wyłącznie teoretyczny problem.

W lipcu 2026 roku podczas wewnętrznych ewaluacji cyberbezpieczeństwa OpenAI agenci działający na modelach firmy pracowali w specjalnym środowisku testowym z ograniczonymi zabezpieczeniami.

Ich zadaniem było rozwiązywanie trudnych zadań związanych z wykorzystywaniem podatności oprogramowania.

W trakcie ewaluacji agenci znaleźli jednak sposoby na obejście części mechanizmów izolacji, uzyskali dostęp do internetu, wykorzystali podatności w kolejnych systemach i ostatecznie dotarli również do infrastruktury Hugging Face.

Nie istniała żadna funkcja:

attack_huggingface()

System składał większy proces z kolejnych, mniejszych działań.

Hugging Face odtworzył później około 17 600 działań wykonanych między 9 a 13 lipca - pogrupowanych w około 6280 klastrów.

Były to tysiące kolejnych komend, prób, obserwacji wyników i decyzji wykonywanych z prędkością maszyny.

Co ciekawe, Hugging Face podsumował powód publikacji tak szczegółowej analizy jednym zdaniem:

“The technique matters more than the incident.”

Czyli: technika jest ważniejsza niż sam incydent.

I właśnie to jest tutaj najciekawsze.

Nie chodzi wyłącznie o jeden konkretny atak. Chodzi o pokazanie, jak zmienia się charakter oprogramowania, gdy część kolejnych kroków przestaje być sztywno zaprogramowana, a zaczyna być wybierana dynamicznie przez model.

Agent nie potrzebuje funkcji dla każdego zadania

O prostych systemach agentowych często myślimy tak:

LLM → Tool A / Tool B / Tool C

Model otrzymuje kilka gotowych funkcji i wybiera jedną z nich.

Bardziej autonomiczny system może jednak działać inaczej:

LLM → plan → kod → narzędzie → wynik → nowy plan → kolejne działanie

Model nie musi mieć gotowej funkcji odpowiadającej każdemu możliwemu zadaniu.

Jeżeli posiada wystarczająco ogólne narzędzie, może podczas wykonywania zadania stworzyć brakujący fragment logiki.

Dlatego podczas projektowania agentów coraz ważniejsze staje się nie tylko pytanie:

Jakie tools dam agentowi?

ale również:

Do czego te tools pozwalają mu pośrednio dotrzeć?

To jedna z najciekawszych różnic między klasyczną aplikacją a systemem agentowym.

W klasycznej aplikacji programista zazwyczaj definiuje większość możliwych ścieżek wykonania.

W systemie agentowym programista coraz częściej definiuje środowisko, narzędzia i granice, natomiast model może dynamicznie wybierać drogę prowadzącą do celu.

Im bardziej rosną możliwości modeli, tym ważniejsze staje się więc odpowiednie zaprojektowanie właśnie tych granic.

Inteligencja to tylko część systemu

Im bardziej rozbudowany agent powstaje, tym więcej pojawia się pytań:

• jak połączyć model z narzędziami?
• jak przechowywać stan pomiędzy kolejnymi krokami?
• jak kontrolować wykonywaną pętlę?
• jak ograniczać uprawnienia?
• jak tworzyć rozgałęzienia i warunki?
• co zrobić, gdy agent zachowa się inaczej, niż przewidzieliśmy?
• jak zatrzymać go przed wykonaniem wrażliwej operacji?
• gdzie wymagać zgody człowieka?
• jak później sprawdzić, dlaczego wykonał określoną sekwencję działań?

I właśnie tutaj zaczynają przydawać się narzędzia takie jak LangChain, LangGraph i LangSmith.

• LangChain pomaga łączyć modele z narzędziami i innymi elementami aplikacji.
• LangGraph pozwala budować bardziej kontrolowane, stanowe przepływy agentowe.
• LangSmith pomaga obserwować, debugować i oceniać to, co dzieje się podczas wykonywania tych przepływów.