Jak zbudować agenta AI na własnym VPS

Czym w rzeczywistości jest agent AI

Agent AI to pętla otaczająca model językowy. Model analizuje sytuację, wybiera jedną akcję, kod wykonuje tę akcję, wynik wraca do modelu, a pętla uruchamia się ponownie, aż zadanie zostanie ukończone. To jest główna idea. Zwykły chatbot odpowiada raz i kończy działanie. Agent kontynuuje pracę, podejmując realne działania między swoimi turami, aż osiągnie wyznaczony cel.

Akcja jest kluczowym elementem. Sam model językowy generuje jedynie tekst. Nie potrafi odczytać pliku, wywołać API ani uruchomić polecenia. Agent przekazuje modelowi zestaw narzędzi, których może używać, oraz sposób wnioskowania o ich użycie. Gdy model chce przeszukać sieć lub zapisać plik, nie wykonuje tej pracy samodzielnie. Generuje ustrukturyzowane żądanie, kod uruchamia narzędzie, a odpowiedź wraca jako kolejna informacja do odczytu przez model. Model dostarcza osąd; serwer dostarcza możliwości wykonawcze.

Nie każde zadanie wymaga agenta; sięganie po niego domyślnie jest częstym błędem. Jeśli kroki są znane z góry, prosty skrypt jest prostszy, szybszy i bardziej niezawodny. "Pobieraj tę stronę co godzinę i wysyłaj mi cenę e-mailem" to zadanie harmonogramowane, a nie agent. Buduj agenta wtedy, gdy ścieżka nie jest ustalona z góry, a model musi przeanalizować znalezione informacje i zdecydować, co zrobić dalej. Kosztem agenta jest nieprzewidywalność, więc stosuj go tylko wtedy, gdy elastyczność uzasadnia ten koszt.

Narzędzia: w jaki sposób działa agent

Narzędzie to każda zdolność przekazana modelowi, opisana na tyle precyzyjnie, aby model wiedział, kiedy z niej skorzystać. Odczyt pliku, uruchomienie polecenia shell, zapytanie do bazy danych, wysłanie wiadomości: każde z nich to narzędzie posiadające nazwę, krótki opis i listę wejściowych parametrów. Narzędzia definiuje użytkownik; model decyduje o ich wywołaniu.

Mechanizm jest identyczny dla każdego modelu. Model zwraca ustrukturyzowane żądanie zawierające nazwę narzędzia i wypełnione parametry wejściowe. Kod rozpoznaje to żądanie, uruchamia odpowiednią funkcję i odsyła wynik w następnej turze. Model odczytuje wynik i albo wywołuje kolejne narzędzie, albo generuje ostateczną odpowiedź. Function calling stanowi fundament każdego agenta, a pętla sterująca tym procesem to zaledwie kilka linii standardowego kodu.

To tutaj znajduje się kontrola nad procesem. Model może poprosić o uruchomienie polecenia, ale nic nie zostanie wykonane, dopóki kod nie zdecyduje o jego uruchomieniu. W tej przerwie można umieścić komunikaty o zatwierdzaniu niebezpiecznych akcji, limity dostępu narzędzi oraz logi wszystkich działań agenta. Bezpieczeństwo agenta zależy od narzędzi, które otrzyma, oraz od mechanizmów kontrolnych przed nimi umieszczonych.

MCP: standardowy sposób łączenia narzędzi

Ręczne pisanie osobnej integracji dla każdego serwisu jest nieefektywne. Model Context Protocol (MCP) to otwarty standard rozwiązujący ten problem. Zamiast kodować nowe narzędzia dla plików, bazy danych i systemu zgłoszeń, można skierować agenta do serwera MCP, który już udostępnia te zasoby jako narzędzia. Agent komunikuje się za pomocą jednego protokołu; serwer zajmuje się komunikacją z rzeczywistym systemem.

Zaletą jest reużywalność. Serwer MCP napisany przez kogoś innego dla używanego serwisu staje się dostępny dla agenta bez dodatkowego kodu integracyjnego. Serwer napisany przez użytkownika może być używany przez dowolnego agenta obsługującego ten protokół. Ma to znaczenie na VPS, ponieważ serwery MCP można uruchamiać jako oddzielne, małe usługi obok agenta, każda z ograniczonym zakresem uprawnień. Konfigurację opisano w running MCP servers on a VPS.

Pamięć i wyszukiwanie

Model językowy nie posiada własnej pamięci między wywołaniami. Wszystkie informacje o bieżącym zadaniu muszą być przekazywane mu w każdej turze. W krótkich zadaniach jest to wystarczające, ponieważ cała konwersacja mieści się w jednym żądaniu. W dłuższych procesach konieczne jest samodzielne zarządzanie pamięcią, co realizowane jest poprzez dwa wzorce.

Pierwszym jest scratchpad (brudnopis). Agent otrzymuje plik, który może czytać i zapisywać, oraz instrukcję rejestrowania zdobytej wiedzy. W następnej turze lub sesji agent odczytuje plik i kontynuuje pracę od miejsca, w którym skończył. Jest to pamięć w formie dokumentu, działająca dlatego, że agent traktuje plik jako kolejne narzędzie.

Drugim wzorcem jest retrieval (wyszukiwanie). Gdy agent potrzebuje wiedzy z dużego zbioru dokumentów, które nie zmieściłyby się w jednym żądaniu, dokumenty te przechowuje się w formie przeszukiwalnej. Tylko istotne fragmenty są przesyłane do modelu w momencie, gdy są potrzebne. Wzorzec ten nazywa się retrieval-augmented generation (RAG). Agent zadaje pytanie, kod znajduje pasujące fragmenty, a jedynie one trafiają do modelu. Magazyn danych znajduje się na serwerze, więc prywatne dokumenty nigdy go nie opuszczają.

Wielu agentów, jeden koordynator

Jeden agent z wieloma narzędziami wystarcza do większości zadań. Gdy zadanie jest duże lub dzieli się na części, skuteczniejszy jest model koordynatora, który deleguje zadania do wyspecjalizowanych sub-agentów. Koordynator dzieli cel na części, przekazuje każdą część sub-agentowi wyspecjalizowanemu w danej dziedzinie i łączy wyniki.

Zaletą jest koncentracja na zadaniu. Sub-agent o wąskim zakresie zadań i ograniczonym zestawie narzędzi podejmuje lepsze decyzje niż ogólny agent obsługujący wszystko, a niezależne procesy mogą działać równolegle. Kosztem jest koordynacja, która jest realnym obciążeniem, dlatego należy trzymać się jednego agenta, dopóki zadanie wyraźnie tego nie wymaga. Należy zacząć od prostych rozwiązań i dodawać agentów tylko wtedy, gdy jeden agent staje się niewydolny.

Self-hosted lub hosted: który model zasila agenta

Model jest jedynym elementem agenta, którego nie trzeba uruchamiać samodzielnie, a decyzja o miejscu jego hostingu jest kluczowa. Model hostowany (dostępny przez API) zapewnia najsilniejsze możliwości wnioskowania bez konieczności zarządzania infrastrukturą: wysyła się tekst i otrzymuje tekst. Model self-hosted działa na własnym serwerze, co zapewnia prywatność każdego zapytania, stały koszt zamiast opłat za tokeny i niezależność od dostępności zewnętrznych dostawców. Wybór to kompromis między możliwościami a nakładem pracy. Najlepsze modele hostowane przewyższają możliwości modeli uruchamianych lokalnie, a własna instalacja wymaga zapewnienia odpowiedniej ilości pamięci.

Ostatni punkt stanowi ograniczenie praktyczne. Model musi zmieścić się w pamięci serwera, a w przypadku użycia GPU – w pamięci wideo. Model zbyt duży dla sprzętu nie zostanie załadowany. Przed zaplanowaniem agenta typu self-hosted należy sprawdzić, czy wybrany model pasuje do posiadanego sprzętu:

Jeśli parametry są niewystarczające, istnieją trzy wyjścia: wybór mniejszego modelu, zastosowanie agresywnej kwantyzacji w celu zmniejszenia rozmiaru lub użycie zewnętrznego API do wnioskowania przy zachowaniu narzędzi i danych na własnym serwerze. Wiele systemów self-hosted zaczyna od lokalnego modelu poprzez Ollama on a VPS, a w trudniejszych etapach przechodzi na API.

Serwer to najbardziej niebezpieczny element

Agent zdolny do uruchamiania poleceń shell i zapisywania plików jest potężny, co czyni go niebezpiecznym. Osąd modelu nie jest doskonały; błędna instrukcja, błąd w kodzie lub złośliwe dane wejściowe mogą sprawić, że pomocny agent usunie niewłaściwe dane lub wycieknie sekrety. Zabezpieczenia nie są opcjonalne, a na serwerze są najważniejszym elementem.

Kluczowe są kilka nawyki. Agent powinien działać jako dedykowany użytkownik o ograniczonych uprawnieniach (unprivileged user), a nie jako root, aby ograniczyć skutki ewentualnego błędu; zasady te opisano w running services as an unprivileged user. Tajne dane, takie jak klucze API, powinny znajdować się poza kodem i być dostępne tylko dla tego użytkownika. Narzędzia operujące na systemie należy izolować (sandbox), aby agent miał dostęp tylko do niezbędnych zasobów. Przykładowy proces utwardzania (hardening) agenta self-hosted opisano w running OpenClaw safely on a VPS. Jeśli preferowane jest użycie modelu hostowanego do celów intelektualnych, przewodnik building an agent with Claude on a VPS stosuje te same zasady przy konkretnym modelu.

W celu uzyskania przykładu praktycznego, building an OpenClaw-style personal agent stosuje te komponenty, natomiast gotowe rozwiązania można znaleźć w self-hosting Hermes Agent on a VPS lub running Agent Zero on your own server. Zestawienie wszystkich gotowych opcji znajduje się w the best self-hosted AI agents in 2026.

FAQ

Jaka jest różnica między agentem AI a chatbotem?

Chatbot odpowiada na wiadomość i kończy działanie. Agent działa w pętli: model podejmuje decyzję o akcji, kod ją wykonuje, wynik wraca do modelu, a proces powtarza się do zakończenia zadania. Różnica polega na tym, że agent podejmuje realne działania między swoimi turami (np. odczyt plików, uruchamianie poleceń, zapytania do serwisów), zamiast generować wyłącznie tekst.

Czy do uruchomienia agenta AI na VPS potrzebna jest karta GPU?

Tylko w przypadku hostowania modelu samodzielnie (self-hosting). Pętla agenta, narzędzia i pamięć to standardowy kod, który działa poprawnie na zwykłym VPS bez GPU. GPU jest wymagane, gdy model językowy ma działać na własnym sprzęcie, ponieważ musi on zmieścić się w pamięci. W przypadku korzystania z modelu hostowanego przez API, obliczenia odbywają się na zewnętrznym sprzęcie, więc wystarczy standardowy VPS.

Czym jest MCP i czy jest niezbędny do budowy agenta?

MCP (Model Context Protocol) to otwarty standard służący do łączenia agenta z narzędziami i źródłami danych. Nie jest on absolutnie wymagany, ponieważ każde narzędzie można napisać ręcznie. MCP przyspiesza pracę, umożliwiając reużywanie istniejących serwerów dla popularnych usług oraz jednorazowe udostępnianie własnych systemów dla dowolnego agenta. Jest to udogodnienie, które zyskuje na znaczeniu wraz ze wzrostem liczby integracji.

Czy udostępnianie agentowi AI dostępu do serwera jest bezpieczne?

Może być bezpieczne, pod warunkiem wprowadzenia ograniczeń. Agent zdolny do wykonywania poleceń jest tak bezpieczny, jak konto, z którego korzysta, oraz narzędzia, które ma do dyspozycji. Należy uruchamiać go jako użytkownik o ograniczonych uprawnieniach, chronić sekrety, izolować narzędzia operujące na systemie plików oraz wymagać zatwierdzania akcji, których nie można łatwo cofnąć. Agenta należy traktować jako kod niepewny, przyznając mu tylko niezbędne uprawnienia.