Konsolowy agent AI "Botinok": Automatyzacja serwerów Linux

Konsolowy agent AI „Botinok”: Automatyzacja serwerów Linux przy minimalnym zużyciu zasobów

„Botinok” to innowacyjny konsolowy agent AI, zaprojektowany do efektywnej automatyzacji rutynowych zadań na serwerach Linux. Skierowany do specjalistów z ograniczonymi zasobami obliczeniowymi, zwłaszcza w zakresie VRAM, narzędzie to pozwala zintegrować moc dużych modeli językowych (LLM) bezpośrednio w terminalu, eliminując potrzebę skomplikowanych interfejsów graficznych (GUI) lub zasobożernych usług działających w tle. Staje się niezastąpionym pomocnikiem dla administratorów, inżynierów DevOps i programistów, którzy potrzebują szybkiej diagnostyki i zarządzania infrastrukturą przez SSH.

Rezygnacja z ciężkich rozwiązań: filozofia „Botinka”

Wieloletnie doświadczenie w pracy z serwerami Linux pokazuje, że mimo ewolucji narzędzi – od ręcznej konfiguracji po Kubernetes – rutyna administracyjna pozostaje. Wraz z pojawieniem się LLM pojawiła się możliwość delegowania modelom analizy logów czy generowania konfiguracji. Jednak ciągłe przełączanie się między terminalem a interfejsem webowym chatbota generuje znaczne niedogodności.

Na rynku istnieją agenci AI, tacy jak OpenClaw, oferujący kompleksowe rozwiązania do automatyzacji. OpenClaw, na przykład, to potężny agent self-hosted o czterowarstwowej architekturze, skupiony na automatyzacji stylu życia (e-mail, kalendarz, rezerwacje) i działający jako demon 24/7 z interfejsem przez komunikatory. Dla zadań korporacyjnych i osobistych asystentów może to być efektywne, ale dla administracji systemami na serwerze takie podejście okazało się nadmierne i zasobożerne.

Do pracy konsolowej z serwerami przez SSH wymagane jest inne podejście. Potrzebne jest narzędzie, które nie jest stale działającą usługą, nie wymaga skomplikowanej architektury i nie zużywa nadmiernych zasobów. „Botinok” został stworzony właśnie w tym celu: to zwykła aplikacja, która uruchamia się w razie potrzeby, wykonuje zadanie i kończy działanie. Takie podejście jest analogiczne do tego, jak deweloperzy używają asystentów AI w IDE (np. Cursor), gdzie AI aktywnie uczestniczy w procesie rozwoju, ale nie działa stale w tle. „Botinok” przenosi tę koncepcję do konsoli:

# Przykład użycia: konfiguracja środowiska na serwerze
ssh [email protected]
botinok "Skonfiguruj docker, nginx i wdrożenie dla mojej aplikacji Flask"
# ... pracujemy z agentem, który wykonuje zadanie ...
# Po zakończeniu pracy, agent się zamyka

Do działania „Botinka” wymagana jest Ollama, którą można zainstalować lokalnie, na sąsiednim serwerze lub na potężnej stacji roboczej. Połączenie z Ollamą konfiguruje się interaktywnie za pomocą --wizard, co upraszcza początkową konfigurację i weryfikację dostępności modeli. Ta architektura sprawia, że „Botinok” jest idealny dla:

Administratorów, którzy potrzebują szybkiej diagnostyki i naprawy problemów na serwerze przez SSH.
Inżynierów DevOps do konfiguracji potoków CI/CD lub pracy z konfiguracjami.
Programistów, którzy muszą szybko wdrożyć środowisko na nowej maszynie.
Entuzjastów z ograniczonym sprzętem, pozwalając używać potężnej Ollamy na jednym komputerze i uruchamiać lekkiego klienta na innym.

Instrumentarium agenta: Function Calling i kluczowe możliwości

„Botinok” wykorzystuje pełnoprawny mechanizm Function Calling poprzez API Ollamy, zapewniając agentowi dostęp do szeregu specjalistycznych narzędzi do interakcji z systemem i siecią. Pozwala to LLM nie tylko generować tekst, ale także wykonywać konkretne działania, analizować dane i uzyskiwać aktualne informacje.

Lista głównych narzędzi:

🌐 Sieć i wyszukiwanie:

* web_search: Wyszukiwanie informacji przez DuckDuckGo za pomocą lynx.

* open_url: Pobieranie zawartości ze stron internetowych.

🛠 Narzędzia systemowe:

* file_system: Nawigacja, wyszukiwanie, czytanie plików i wykonywanie poleceń grep.

* shell_exec: Wykonywanie dowolnych poleceń bash (wymaga jawnego zezwolenia --dangerous).

* journal: Analiza logów systemd za pomocą journalctl.

💻 Rozwój:

* code_editor: Narzędzia do czytania, pisania i modyfikacji kodu.

* github: Podstawowe operacje na repozytoriach (clone, log, status, diff).

📚 Umiejętności i doświadczenie:

* skills: Ładowanie instrukcji i promptów z repozytorium ClawHub.

* experience: Baza danych pozytywnych i negatywnych doświadczeń w celu poprawy podejmowania decyzji przez agenta.

Podejście do wyszukiwania w sieci: dlaczego Lynx?

Szczególną uwagę poświęcono implementacji narzędzi sieciowych, w szczególności web_search i open_url. Zamiast standardowych bibliotek Pythona czy ciężkich silników przeglądarek, „Botinok” wykorzystuje konsolową przeglądarkę tekstową lynx. To rozwiązanie może wydawać się nietradycyjne, ale wynika z kilku kluczowych zalet w scenariuszu serwerowym:

Powody wyboru lynx:

Lekkość i dostępność: lynx jest preinstalowany w większości dystrybucji Linuxa, nie wymaga dodatkowych zależności i zużywa minimum zasobów.
Szybkość: Brak renderowania JavaScript, CSS, obrazów i czcionek zapewnia wysoką szybkość uzyskiwania treści tekstowej.
Czysty tekst: Parametr -dump pozwala lynx wyświetlać ustrukturyzowaną zawartość tekstową bez tagów HTML, co znacznie upraszcza jej późniejsze parsowanie przez LLM.
Praca przez SSH: Idealnie nadaje się do zdalnej pracy na serwerze, gdzie graficzny interfejs jest niedostępny.

Przykład wywołania web_search poprzez subprocess:

result = subprocess.run([
    "lynx", "-dump", "-number_links",
    "-display_charset=utf-8",
    f"-useragent={user_agent}",
    f"https://html.duckduckgo.com/html/?q={encoded_query}"
], capture_output=True, text=True, timeout=15)

Ograniczenia lynx i ich rozwiązania:

| Problem | Przykład | Rozwiązanie |

| :------------------------- | :----------------------------------- | :---------------------------------------------------------------------- |

| Brak JavaScript | Strony SPA (React, Vue) mogą być puste | Agent rozpoznaje pustą zawartość i informuje o tym |

| CAPTCHA | DDG czasami blokuje | Fallback na inny URL, ponowna próba z timeoutem |

| Brak autoryzacji | Zamknięte strony niedostępne | Ograniczenie projektowe: praca tylko z publiczną zawartością |

| Utrata kontekstu wizualnego | Tabele, diagramy zamieniają się w tekst | Agent adaptuje się do formatu tekstowego |

| Rozmiar zawartości | Przycinanie do N znaków | Pełny zrzut jest zapisywany w sesji, agent może go odczytać w razie potrzeby |

Ten kompromis między prostotą, szybkością i funkcjonalnością sprawia, że lynx jest optymalnym wyborem do szybkiego dostępu do dokumentacji, artykułów i plików README z GitHub w środowisku konsolowym.

System plików: „oczy i ręce” agenta na serwerze

Narzędzie file_system jest kluczowe dla interakcji agenta z systemem operacyjnym serwera. Pozwala „Botinkowi” rozumieć stan systemu plików, diagnozować problemy i uzyskiwać niezbędne informacje. Wszystkie działania file_system są domyślnie tylko do odczytu, co zapewnia wysoki poziom bezpieczeństwa.

Główne działania file_system:

list: Wyświetla listę plików i katalogów wraz z ich rozmiarem i datą modyfikacji. Przykład: list /etc/nginx.
search: Wyszukiwanie plików według maski. Przykład: search /var/log "*.log".
grep: Wyszukiwanie tekstu w plikach. Przykład: grep /etc "server_name" "*.conf".
read: Odczyt zawartości pliku z obsługą paginacji dla dużych plików. Przykład: read /var/log/syslog offset=0 limit=500.
info: Uzyskiwanie metadanych pliku. Przykład: info /etc/passwd.

Ponadto istnieje potężny zestaw poleceń inspect, które pozwalają uzyskać zagregowane informacje systemowe:

inspect command="fs.tree" path="/var/www" depth=3       # Drzewo katalogów
inspect command="du.top_files" path="/var/log"          # Największe pliki
inspect command="du.dir_total" path="/home/user"        # Rozmiar folderu
inspect command="sys.meminfo"                           # Informacje o pamięci z /proc/meminfo
inspect command="sys.disk_free" path="/"                # Wolne miejsce na dysku
inspect command="proc.list"                             # Lista uruchomionych procesów
inspect command="proc.info" pid=1234                    # Szczegóły konkretnego procesu
inspect command="svc.status" unit="nginx"               # Status usługi systemd
inspect command="env.os_release"                        # Wersja systemu operacyjnego

Typowy scenariusz diagnostyczny z wykorzystaniem tych narzędzi może wyglądać następująco:

botinok "Dowiedz się, dlaczego nginx zwraca 502"

# Agent może automatycznie wykonać następujące kroki:
# 1. inspect command="svc.status" unit="nginx"        # Sprawdź status usługi Nginx
# 2. journal action="unit_tail" unit="nginx"          # Przejrzyj ostatnie logi Nginx
# 3. read /etc/nginx/sites-enabled/default            # Przeczytaj plik konfiguracyjny Nginx
# 4. grep /var/log/nginx "error" "*.log"              # Poszukaj błędów w logach Nginx
# 5. inspect command="proc.list" | grep "php-fpm"     # Sprawdź, czy backend (np. PHP-FPM) jest uruchomiony

Pozwala to agentowi samodzielnie wybierać i stosować odpowiednie narzędzia do rozwiązania postawionego zadania, minimalizując ręczną interwencję.

Diagnostyka z Journal: głęboka analiza logów

Do pracy z logami systemowymi „Botinok” wykorzystuje specjalistyczne narzędzie journal, które współpracuje z systemd-journald. Jest to znacznie efektywniejsze niż proste grep po /var/log, ponieważ journalctl zapewnia ustrukturyzowany dostęp do logów z możliwością filtrowania według czasu, priorytetu, jednostki i innych parametrów.

Główne działania journal:

tail: Pobieranie ostatnich N linii logów. Przykład: tail lines=100.
unit_tail: Przeglądanie logów konkretnej jednostki systemd. Przykład: unit_tail unit="docker" lines=200.
since: Filtrowanie logów według czasu rozpoczęcia. Przykład: since since="2 hours ago".
query: Łączenie różnych filtrów w celu uzyskania specyficznych logów. Przykład: query unit="nginx" grep="error" since="today".
stats: Uzyskiwanie statystyk poziomów logowania dla określonej jednostki w danym okresie. Pozwala to agentowi szybko ocenić ogólny obraz błędów i ostrzeżeń.

Przykład statystyk, które może uzyskać agent:

{
  "action": "stats",
  "unit": "nginx",
  "since": "1 hour ago",
  "levels": {
    "emerg": 0, "alert": 0, "crit": 0,
    "err": 12,
    "warning": 45,
    "notice": 120,
    "info": 340,
    "debug": 0
  }
}

Tak szczegółowe informacje dają agentowi możliwość nie tylko znajdowania konkretnych błędów, ale także oceny ogólnej stabilności systemu, identyfikowania trendów i potencjalnych problemów przed ich eskalacją.

Architektura i bezpieczeństwo: kluczowe aspekty

Filozofia „Botinka” jako narzędzia, a nie stale działającej usługi, leży u podstaw jego architektury. Ta aplikacja uruchamia się na żądanie użytkownika, wykonuje postawione zadanie, wykorzystując dostępne narzędzia, i kończy działanie. Takie podejście znacznie obniża zużycie zasobów systemowych, zwłaszcza VRAM, ponieważ LLM nie musi stale znajdować się w pamięci.

Kluczowe aspekty bezpieczeństwa i projektowania:

Operacje tylko do odczytu domyślnie: Większość narzędzi, takich jak file_system i journal, działa w trybie odczytu, zapobiegając przypadkowym lub złośliwym zmianom w systemie. Możliwość wykonania shell_exec wymaga jawnego flagi --dangerous.
Zarządzanie kontekstem: Do pracy z dużymi wolumenami danych (np. logami lub stronami internetowymi) używana jest paginacja i przycinanie zawartości z oznaczeniem [TRUNCATED]. Pełne dane są przy tym przechowywane w sesji, pozwalając agentowi odwołać się do nich w razie potrzeby, ale nie przeciążając okna kontekstowego LLM.
Minimalne zależności: Stawianie na natywne narzędzia konsolowe, takie jak lynx i journalctl, minimalizuje liczbę zewnętrznych zależności i upraszcza wdrożenie.
Elastyczność Ollamy: Użycie Ollamy pozwala użytkownikowi wybierać i uruchamiać różne modele LLM w zależności od dostępnych zasobów i konkretnych zadań, od małych modeli do pracy lokalnej po większe na zdalnych serwerach.

„Botinok” demonstruje, jak efektywnie wykorzystać potencjał LLM do automatyzacji złożonych i rutynowych zadań administracji systemami, zachowując jednocześnie kontrolę, bezpieczeństwo i minimalne zużycie zasobów. To niezawodne narzędzie dla tych, którzy cenią sobie efektywność i pracują w środowisku konsolowym.

Co ważne

„Botinok” to konsolowy agent AI, przeznaczony do automatyzacji zadań na serwerach Linux przez SSH, działający z ograniczonymi zasobami VRAM.
Funkcjonuje jako narzędzie na żądanie, a nie jako stale aktywny demon, co minimalizuje zużycie zasobów systemowych.
Wykorzystuje Ollamę do integracji LLM i zapewnia szeroki zestaw narzędzi poprzez Function Calling, w tym wyszukiwanie w sieci (przez lynx), nawigację po systemie plików i analizę logów systemd.
Zapewnia bezpieczeństwo dzięki domyślnym operacjom tylko do odczytu i wymaga jawnego potwierdzenia dla wykonania potencjalnie niebezpiecznych poleceń.
Zoptymalizowany dla administratorów systemów, inżynierów DevOps i programistów, którzy potrzebują efektywnej i lekkiej automatyzacji w terminalu.

— Editorial Team