Jak zbudować własnego agenta AI na serwerze VPS

Czym w rzeczywistości jest agent AI

Agent AI to pętla otaczająca model językowy. Model analizuje sytuację, podejmuje decyzję o jednej akcji, kod wykonuje tę akcję, wynik wraca do modelu, a pętla powtarza się do momentu zakończenia zadania. To cała koncepcja. Zwykły chatbot odpowiada raz i kończy działanie. Agent kontynuuje pracę, podejmując rzeczywiste działania między swoimi turami, aż osiągnie wyznaczony cel. Pętla jest na tyle prosta, że można ją napisać samodzielnie w jedno popołudnie, od czego zaczyna się stopniowa ścieżka nauki tworzenia agentów od podstaw, zanim zostaną dodane narzędzia, pamięć i mechanizmy bezpieczeństwa.

Kluczowym elementem jest akcja. Sam w sobie model językowy generuje jedynie tekst. Nie potrafi odczytać pliku, wywołać API ani uruchomić polecenia. Agent dostarcza modelowi zestaw narzędzi, z których może on korzystać, oraz sposób ich żądania. Gdy model chce przeszukać sieć lub zapisać plik, nie wykonuje pracy samodzielnie. Generuje ustrukturyzowane żądanie, kod uruchamia narzędzie, a odpowiedź wraca jako kolejny element czytany przez model. Model dostarcza osąd; serwer dostarcza narzędzia wykonawcze.

Nie każde zadanie wymaga agenta, a sięganie po niego domyślnie jest częstym błędem. Jeśli kroki są znane z góry, zwykły skrypt jest prostszy, szybszy i bardziej niezawodny. „Pobieraj tę stronę co godzinę i wyślij mi cenę mailem” to zadanie harmonogramowane, a nie agent. Agenta należy budować wtedy, gdy ścieżka nie jest ustalona z góry, gdy model musi przeanalizować to, co znajdzie, i zdecydować, co zrobić dalej. Kosztem agenta jest nieprzewidywalność, więc należy go stosować tylko wtedy, gdy elastyczność jest uzasadniona.

Narzędzia: jak działa agent

Narzędzie to każda zdolność udostępniona modelowi, opisana w sposób pozwalający na rozpoznanie momentu, w którym należy z niej skorzystać. Odczyt pliku, wykonanie polecenia powłoki, zapytanie do bazy danych czy wysłanie wiadomości: każde z nich jest narzędziem posiadającym nazwę, krótki opis oraz listę danych wejściowych. Definiujesz narzędzia, a model decyduje, kiedy je wywołać. Wyszukiwarka internetowa jest zazwyczaj pierwszym narzędziem, które warto dodać. Jeśli uruchamiasz własną instancję SearXNG, możesz przekształcić ją w backend wyszukiwania agenta, zamiast płacić za komercyjne API wyszukiwarek.

Mechanizm ten jest wszędzie taki sam, niezależnie od używanego modelu. Model zwraca ustrukturyzowane żądanie, które wskazuje narzędzie i wypełnia jego parametry wejściowe. Twój kod odczytuje to żądanie, uruchamia odpowiednią funkcję i przesyła wynik w kolejnym kroku. Model analizuje wynik i albo wywołuje kolejne narzędzie, albo formułuje ostateczną odpowiedź. Wywoływanie funkcji (function calling) stanowi fundament każdego agenta, a pętla sterująca tym procesem składa się z zaledwie kilku linii standardowego kodu.

To tutaj znajduje się również punkt kontrolny. Model może zażądać wykonania polecenia, ale nic nie zostanie uruchomione, dopóki Twój kod nie podejmie takiej decyzji. W tej luce możesz umieścić monity o zatwierdzenie dla niebezpiecznych działań, ograniczenia dotyczące zakresu dostępu narzędzia oraz dziennik wszystkich operacji wykonanych przez agenta. Bezpieczeństwo agenta zależy wyłącznie od narzędzi, które mu udostępniasz, oraz kontroli, które przed nimi ustanawiasz.

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

Ręczne tworzenie integracji dla każdej usługi staje się szybko uciążliwe. Model Context Protocol, czyli MCP, to otwarty standard, który rozwiązuje ten problem. Zamiast programować nowe narzędzie dla plików, bazy danych czy systemu śledzenia zgłoszeń, wskazujesz agentowi serwer MCP, który udostępnia te zasoby jako gotowe narzędzia. Agent komunikuje się za pomocą jednego protokołu, a serwer wykonuje pracę polegającą na połączeniu z właściwym systemem.

Zaletą jest możliwość ponownego wykorzystania kodu. Serwer MCP napisany przez kogoś innego dla usługi, z której korzystasz, staje się dostępny dla Twojego agenta bez konieczności pisania nowej integracji. Z kolei serwer, który sam stworzysz, może być użyty przez dowolnego agenta obsługującego ten protokół. Niektóre aplikacje self-hosted oferują już własne rozwiązania: openGym, narzędzie do śledzenia treningów udostępnia serwer MCP w trybie tylko do odczytu, dzięki czemu agent może odpowiadać na pytania dotyczące historii treningów, nie mając możliwości wprowadzania w niej żadnych zmian. Na serwerze VPS ma to duże znaczenie, ponieważ serwery MCP można uruchamiać jako osobne, niewielkie usługi obok agenta, z których każda posiada tylko niezbędne uprawnienia. Gdy systemy obsługujące te serwery znajdują się w sieci niedostępnej dla VPS, na przykład w bazie danych w domu lub w biurze, udostępnienie tej sieci w ramach tailnet za pomocą subnet routera pozwala agentowi na łączenie się z nimi poprzez prywatne adresy, bez wystawiania czegokolwiek na publiczny dostęp do Internetu. Konfigurację tego rozwiązania opisuję w uruchamianiu serwerów MCP na VPS.

Pamięć i odzyskiwanie danych

Model językowy nie posiada własnej pamięci między wywołaniami. Wszystkie informacje o bieżącym zadaniu muszą być mu przekazywane w każdej turze. W przypadku krótkich zadań jest to wystarczające, ponieważ cała konwersacja mieści się w jednym żądaniu. Ilość danych zależy od okna kontekstowego, a model uruchomiony lokalnie przez Ollama posiada domyślnie niewielki rozmiar, który automatycznie usuwa najstarsze tury konwersacji. Dlatego warto wykonać ustawienie num_ctx zgodnie z ruchem generowanym przez pętlę, zanim agent zostanie posądzony o zapominanie informacji. W przypadku dłuższych zadań zarządzanie pamięcią należy przeprowadzić samodzielnie, stosując jeden z dwóch sprawdzonych wzorców.

Pierwszym z nich jest notatnik (scratchpad). Agentowi udostępnia się plik, do którego ma uprawnienia odczytu i zapisu, z instrukcją zapisywania zdobytej wiedzy w trakcie pracy. W kolejnej turze lub sesji agent odczytuje plik i kontynuuje zadanie od miejsca, w którym przerwał. Jest to pamięć w formie zwykłego dokumentu, która działa, ponieważ agent traktuje plik jak każde inne narzędzie.

Drugim wzorcem jest odzyskiwanie danych (retrieval). Gdy agent potrzebuje wiedzy z dużego zbioru dokumentów, które nie mieszczą się w jednym żądaniu, należy przechowywać je w formie przeszukiwalnej i pobierać tylko istotne fragmenty do kontekstu modelu w razie potrzeby. Ten wzorzec nazywany jest generowaniem wspomaganym odzyskiwaniem danych (RAG). Agent zadaje pytanie, kod wyszukuje pasujące fragmenty, a do modelu trafiają wyłącznie one. Magazyn danych znajduje się na serwerze, dzięki czemu prywatne dokumenty nigdy go nie opuszczają.

Wiele agentów, jeden koordynator

Jeden agent z wieloma narzędziami sprawdza się w większości zadań. Gdy zadanie jest rozbudowane lub naturalnie dzieli się na części, pomocna okazuje się inna struktura: agent koordynujący, który deleguje pracę do wyspecjalizowanych podagentów. Koordynator rozbija cel na fragmenty, przekazuje każdy z nich podagentowi stworzonemu do tego typu pracy, a następnie łączy wyniki. Delegowanie wymaga kanału komunikacji między elementami, a najprostsza jego wersja jest już dostępna na serwerze: dwie sesje Claude Code na tym samym VPS mogą przesyłać sobie nawzajem wiadomości. Jest to tani sposób na sprawdzenie, jak zachowują się przekazania zadań, zanim zbuduje się własny mechanizm koordynacji.

Zyskiem jest skupienie. Podagent z wąskim zakresem zadań i ograniczonym zestawem narzędzi podejmuje lepsze decyzje niż jeden generalista zajmujący się wszystkim, a niezależne części mogą być wykonywane jednocześnie. Kosztem jest koordynacja, która stanowi realne wyzwanie, dlatego należy pozostać przy jednym agencie, dopóki zadanie wyraźnie nie wymaga większej liczby. Należy zacząć od prostych rozwiązań i dodawać agentów tylko wtedy, gdy jeden wyraźnie nie radzi sobie z obciążeniem.

Model self-hosted czy hostowany: który model obsługuje agenta

Model jest jedynym elementem agenta, którego nie trzeba uruchamiać samodzielnie, a wybór miejsca jego działania jest najważniejszą decyzją. Model hostowany, dostępny przez API, zapewnia najwyższą jakość wnioskowania bez konieczności zarządzania infrastrukturą: wysyłasz tekst, otrzymujesz odpowiedź. Model self-hosted działa na własnym serwerze, co zapewnia prywatność każdego żądania, stały koszt zamiast opłat za token oraz niezależność od dostępności usług zewnętrznych. Ceną jest wydajność i nakład pracy. Najlepsze modele hostowane przewyższają możliwościami te, które można uruchomić samodzielnie, a własna infrastruktura wymaga zapewnienia odpowiedniej ilości pamięci.

Ostatni punkt to praktyczne ograniczenie. Model musi mieścić się w pamięci operacyjnej serwera, a w przypadku użycia GPU – w pamięci wideo. Model zbyt duży dla danego sprzętu nie zostanie załadowany. Przed zaplanowaniem agenta self-hosted należy sprawdzić, czy wybrany model mieści się na posiadanej maszynie:

Jeśli parametry nie pasują, dostępne są trzy rozwiązania: wybór mniejszego modelu, zastosowanie bardziej agresywnej kwantyzacji w celu jego zmniejszenia lub użycie hostowanego API do wnioskowania przy jednoczesnym przechowywaniu narzędzi i danych na serwerze. Wiele agentów self-hosted rozpoczyna pracę z lokalnym modelem poprzez Ollama na VPS i korzysta z hostowanego API jako rozwiązania zapasowego dla najbardziej złożonych zadań.

Serwer to najbardziej niebezpieczny element

Agent zdolny do wykonywania poleceń powłoki i zapisu plików dysponuje dużymi uprawnieniami, co czyni go niebezpiecznym. Ocena modelu jest dobra, ale nie bezbłędna, a błędna instrukcja, usterka lub wrogie dane wejściowe mogą sprawić, że pomocny agent usunie niewłaściwe dane lub ujawni poufne informacje. Praca nad bezpieczeństwem nie jest opcjonalna, a na serwerze jest to kwestia o kluczowym znaczeniu.

Kilka nawyków ma największe znaczenie. Uruchamiaj agenta jako dedykowanego użytkownika bez uprawnień, nigdy jako root, aby ograniczyć skutki ewentualnego błędu; to samo rozumowanie przedstawiono w uruchamianiu usług jako użytkownik bez uprawnień. Przechowuj sekrety, takie jak klucze API, poza kodem i udostępniaj je tylko temu użytkownikowi. Izoluj narzędzia, które mają dostęp do systemu, aby agent mógł sięgać tylko do tego, co jest mu niezbędne. Jeśli wolisz nie pisać każdego zabezpieczenia ręcznie, wtyczki DeepSeek Harness warte zainstalowania realizują te same założenia w formie gotowych rozwiązań: reguły uprawnień narzędzi, skanowanie pod kątem prompt injection oraz limity wydatków agenta przed jego zatrzymaniem. Przykład praktycznego zabezpieczania własnego agenta znajduje się w bezpiecznym uruchamianiu OpenClaw na VPS. Jeśli wolisz korzystać z modelu hostowanego, przewodnik budowanie agenta z Claude na VPS stosuje te same zasady w odniesieniu do konkretnego modelu.

Przykład praktyczny, budowanie osobistego agenta w stylu OpenClaw, wykorzystuje te elementy, a jeśli wolisz uruchomić gotowe rozwiązanie, zacznij od samodzielnego hostowania Hermes Agent na VPS lub uruchamiania Agent Zero na własnym serwerze, natomiast najlepsze samodzielnie hostowane agenty AI w 2026 porównuje wszystkie omawiane gotowe opcje.

FAQ

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

Chatbot odpowiada na wiadomość i kończy działanie. Agent wykonuje pętlę: model decyduje o akcji, kod ją wykonuje, wynik wraca do modelu i proces powtarza się, aż zadanie zostanie ukończone. Różnica polega na tym, że agent podejmuje rzeczywiste działania między swoimi turami, wywołując narzędzia do odczytu plików, uruchamiania poleceń lub odpytywania usług, zamiast jedynie generować tekst.

Czy potrzebuję GPU, aby uruchomić agenta AI na VPS?

Tylko jeśli hostujesz model samodzielnie. Pętla agenta, narzędzia i pamięć to zwykły kod, który działa poprawnie na standardowym VPS bez GPU. GPU jest istotne, gdy chcesz uruchomić model językowy na własnym sprzęcie, ponieważ model musi zmieścić się w pamięci. Jeśli korzystasz z modelu hostowanego przez API, ciężkie obliczenia odbywają się gdzie indziej i wystarczy skromny VPS.

Czym jest MCP i czy potrzebuję go do zbudowania agenta?

MCP, czyli Model Context Protocol, to otwarty standard łączenia agenta z narzędziami i źródłami danych. Nie jest on ściśle wymagany, ponieważ każde narzędzie można napisać ręcznie. MCP oszczędza ten wysiłek, pozwalając na ponowne wykorzystanie istniejących serwerów dla popularnych usług oraz jednorazowe udostępnienie własnych systemów dla dowolnego agenta. Jest to udogodnienie, które staje się opłacalne wraz ze wzrostem liczby integracji.

Czy bezpieczne jest nadanie agentowi AI dostępu do mojego serwera?

Może być, jeśli zostanie odpowiednio ograniczony. Agent wykonujący polecenia jest tak bezpieczny, jak konto, na którym działa, oraz narzędzia, na które pozwalasz. Uruchamiaj go jako użytkownik bez uprawnień, przechowuj jego sekrety w bezpiecznym miejscu, izoluj narzędzia mające dostęp do systemu plików i wymagaj zatwierdzenia dla działań, których trudno cofnąć. Traktuj agenta jako niezaufany kod, który jest jedynie inteligentny, i zapewnij mu dostęp tylko do tego, co jest niezbędne do wykonania zadania.