Tech Handbook Null Yard

Hermes Agent

Hermes Agent jest środowiskiem agentowym łączącym model AI z shellem, plikami, skills, pamięcią, cronem i kanałami komunikacji. Najbezpieczniejsza ścieżka wdrożenia to uruchomić najpierw zwykły chat/CLI, a dopiero potem dokładać gateway, Signal, cron, browser automation i szersze uprawnienia.

Oficjalna ścieżka instalacyjna obejmuje Linux, macOS, WSL2 i Android/Termux. FreeBSD nie jest wymieniony jako podstawowy host, dlatego w tym handbooku traktujemy go przede wszystkim jako maszynę zarządzaną przez SSH.

Powiązane tematy: Promptowanie AI, SSH i zdalna administracja, Debian - desktop i serwer, FreeBSD jako serwer oraz Dokumentowanie rozwiązań technicznych.

Debian jako host, FreeBSD jako host/maszyna zarządzana

Stan dokumentacji: 19 września 2026
Projekt: NousResearch Hermes Agent
Oficjalna dokumentacja: https://hermes-agent.nousresearch.com/docs/


1. Czym jest Hermes Agent

Hermes Agent to lokalnie uruchamiany agent AI, który może:

  • prowadzić normalną rozmowę z modelem językowym,
  • wykonywać polecenia w shellu,
  • czytać i modyfikować pliki,
  • pracować na repozytoriach Git,
  • korzystać z przeglądarki i narzędzi webowych,
  • tworzyć i używać własnych skills,
  • zapamiętywać informacje pomiędzy sesjami,
  • uruchamiać zadania cykliczne,
  • działać przez komunikatory, np. Signal,
  • używać różnych modeli i providerów,
  • delegować zadania do podagentów,
  • pracować lokalnie albo na zdalnej maszynie przez SSH.

To nie jest tylko klient do API modelu. Hermes jest warstwą wykonawczą pomiędzy Tobą, modelem AI, systemem operacyjnym i narzędziami.

Najprostszy model działania:

Ty
 │
 ▼
Hermes
 │
 ├── model AI
 ├── shell
 ├── pliki
 ├── Git
 ├── przeglądarka
 ├── skills
 ├── pamięć
 ├── cron
 └── komunikatory

2. Najważniejsza decyzja: gdzie uruchamiać Hermesa

Debian

Debian jest bardzo dobrym środowiskiem dla Hermesa.

Hermes oficjalnie wspiera Linux x86_64 i ARM64. Instalator zakłada środowisko typowego Linuksa, a część funkcji korzysta z systemd, glibc, Node.js, Pythona, Playwrighta i Chromium.

Dla serwera lub VPS najwygodniejszy układ to:

Debian
└── Hermes Agent
    ├── Signal
    ├── modele AI
    ├── narzędzia
    ├── skills
    └── SSH
         ├── FreeBSD
         ├── inne serwery
         └── urządzenia w LAN

To jest konfiguracja rekomendowana w tym kompendium.


FreeBSD

FreeBSD nie jest oficjalnie wspieraną platformą Hermesa.

Nie oznacza to, że absolutnie niczego nie da się uruchomić ręcznie. Problemem jest jednak cały ekosystem zależności:

  • instalator jest pisany pod Linux/macOS,
  • niektóre elementy zakładają systemd,
  • Chromium/Playwright mają inne wymagania,
  • Docker nie jest natywnym mechanizmem FreeBSD,
  • nie wszystkie Pythonowe lub Node'owe zależności muszą działać,
  • aktualizacja Hermesa może w każdej chwili popsuć nieoficjalny port.

Dlatego znacznie rozsądniejszy układ to:

Debian / VPS
└── Hermes
    └── SSH
         └── FreeBSD

Hermes wykonuje wtedy polecenia FreeBSD przez SSH.

Alternatywnie na fizycznym hoście FreeBSD można uruchomić maszynę wirtualną Debian przez bhyve i wewnątrz niej uruchomić Hermesa.

Rekomendacja

Na FreeBSD:

  • nie instaluj Hermesa natywnie jako podstawowej konfiguracji, jeśli zależy Ci na stabilności;
  • używaj FreeBSD jako zarządzanej maszyny przez SSH;
  • ewentualnie użyj Debiana w VM przez bhyve.

3. Minimalna architektura domowa / VPS

Praktyczny układ:

Internet
   │
   ▼
VPS Debian
   │
   ├── Hermes Agent
   │
   ├── Signal gateway
   │
   ├── repozytoria Git
   │
   ├── cron
   │
   └── SSH
   │      │
   │      ├── serwer FreeBSD
   │      └── inne hosty
   │
   └── nginx / aplikacje / Docker

Hermes może działać praktycznie cały czas na VPS.

Nie potrzebujesz mocnego GPU, jeżeli modele są używane przez API.


4. Instalacja na Debianie

4.1. Minimalne wymagania

Najpierw:

sudo apt update
sudo apt install -y git curl xz-utils

Dla funkcji desktopowych / natywnych modułów:

sudo apt install -y build-essential

Oficjalny instalator sam instaluje między innymi:

  • uv,
  • Python 3.11,
  • Node.js,
  • ripgrep,
  • ffmpeg,
  • środowisko wirtualne,
  • zależności Hermesa.

5. Instalacja Hermesa

Oficjalna metoda:

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

Po instalacji przeładuj shell:

source ~/.bashrc

albo wyloguj się i zaloguj ponownie.

Sprawdzenie:

which hermes
hermes --help

Typowa lokalizacja:

~/.local/bin/hermes

Kod programu:

~/.hermes/hermes-agent/

Dane użytkownika:

~/.hermes/

6. Diagnostyka po instalacji

Uruchom:

hermes doctor

To jedna z najważniejszych komend diagnostycznych.

Jeżeli:

hermes: command not found

sprawdź:

ls ~/.local/bin/hermes

i PATH:

echo $PATH

W razie potrzeby:

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

7. Pierwsze uruchomienie

Najprościej:

hermes

Hermes otworzy interaktywną sesję.

Zasada na początku:

Najpierw doprowadź do sytuacji, w której zwykła rozmowa z jednym modelem działa poprawnie. Dopiero później konfiguruj Signal, crona, browser, skills i routing modeli.


8. Konfiguracja

Główna komenda:

hermes setup

Można konfigurować poszczególne części:

hermes setup model
hermes setup terminal
hermes setup gateway
hermes setup tools
hermes setup agent

Konfigurację można również później modyfikować poleceniami:

hermes config get
hermes config set

9. Katalog ~/.hermes

To najważniejszy katalog instalacji.

Przykładowa struktura:

~/.hermes/
├── config.yaml
├── .env
├── auth.json
├── SOUL.md
├── memories/
│   ├── MEMORY.md
│   └── USER.md
├── skills/
├── cron/
├── sessions/
├── logs/
└── hermes-agent/

Warto wiedzieć, co gdzie trzymać.


10. config.yaml

Główny plik konfiguracji:

~/.hermes/config.yaml

Tu powinny znajdować się ustawienia, które nie są sekretami.

Na przykład:

  • model,
  • provider,
  • ustawienia terminala,
  • pamięć,
  • bezpieczeństwo,
  • cron,
  • zachowanie interfejsu,
  • gateway,
  • konfiguracja skills.

Nie wpisuj tu kluczy API, jeżeli istnieje możliwość trzymania ich w .env.


11. .env

Sekrety:

~/.hermes/.env

Na przykład:

OPENROUTER_API_KEY=...
OPENAI_API_KEY=...
SIGNAL_HTTP_URL=http://127.0.0.1:8080
SIGNAL_ACCOUNT=+48...

Zabezpiecz plik:

chmod 600 ~/.hermes/.env

Nigdy nie commituj go do Git.


12. Provider i model

Do konfiguracji modeli służy:

hermes model

To jest pełny konfigurator providerów.

Możesz w nim:

  • dodać providera,
  • wpisać klucz API,
  • zalogować się przez OAuth,
  • wybrać model,
  • skonfigurować własny endpoint,
  • ustawić model domyślny.

13. hermes model a /model

To ważne.

Poza sesją

hermes model

służy do konfiguracji providerów.

W rozmowie

/model

służy do zmiany pomiędzy modelami/providerami, które są już skonfigurowane.

Czyli:

hermes model

= administracja

a:

/model

= szybkie przełączenie podczas pracy.


14. OpenRouter

Hermes obsługuje OpenRouter.

Klucz:

OPENROUTER_API_KEY=...

Możesz wpisać go przez:

hermes model

albo ręcznie do:

~/.hermes/.env

OpenRouter jest przydatny, gdy chcesz mieć dostęp do wielu różnych modeli bez konfigurowania osobnego API każdego dostawcy.


15. OpenAI

Jeżeli używasz bezpośredniego endpointu OpenAI lub zgodnego API:

OPENAI_API_KEY=...

Hermes obsługuje także endpointy zgodne z API OpenAI.

Można więc podpiąć m.in.:

  • lokalny serwer modeli,
  • vLLM,
  • SGLang,
  • inne serwery OpenAI-compatible.

16. Strategia modeli

Nie ma potrzeby uruchamiać każdego zadania na najmocniejszym modelu.

Dobry schemat:

Model szybki/tani
        │
        ├── proste pytania
        ├── pliki
        ├── statusy
        └── proste zadania
                │
                ▼
Model średni
        │
        ├── programowanie
        ├── analiza
        ├── refaktoryzacja
        └── zadania wieloetapowe
                │
                ▼
Model mocny
        ├── trudne debugowanie
        ├── architektura
        └── skomplikowane zadania

Hermes umożliwia również konfigurację fallbacków i bardziej rozbudowanego routingu.


17. Fallback modeli

Hermes posiada mechanizm providerów zapasowych:

hermes fallback

Idea:

model podstawowy
      │
      ├── działa → odpowiedź
      │
      └── błąd
            │
            ▼
      provider zapasowy

To szczególnie przydatne dla agenta działającego 24/7.


18. Mixture of Agents

Hermes posiada również:

hermes moa

MoA oznacza Mixture of Agents.

Pozwala używać kilku agentów/modeli do rozwiązania jednego zadania.

Nie warto uruchamiać tego do wszystkiego - zwiększa:

  • koszt,
  • liczbę tokenów,
  • czas odpowiedzi.

Przydaje się przy bardziej złożonych analizach.


19. Terminal - najważniejsza funkcja agenta

Hermes może wykonywać polecenia systemowe.

Na Debianie np.:

systemctl status nginx
df -h
free -h
git status
docker ps
journalctl -u nginx

Na FreeBSD przez SSH:

service nginx status
df -h
sysctl hw.model
pkg info
zpool status

To właśnie powoduje, że agent jest czymś więcej niż zwykłym chatbotem.


20. Ostrożnie z uprawnieniami

Agentowi nie warto dawać pełnego roota bez ograniczeń.

Lepszy układ:

użytkownik hermes
        │
        ├── zwykłe polecenia
        ├── repozytoria
        ├── Docker
        └── sudo tylko do wybranych operacji

Nie dawaj agentowi:

NOPASSWD: ALL

jeżeli nie ma ku temu realnego powodu.


21. Lokalny terminal vs sandbox

Hermes może wykonywać polecenia:

  • lokalnie,
  • w Dockerze,
  • przez SSH,
  • w zdalnych sandboxach.

Dla ważnego serwera dobrym podejściem jest używanie izolacji.

Schemat:

Hermes
  │
  ├── bezpieczne operacje → host
  │
  └── eksperymenty → sandbox

22. Docker

Hermes obsługuje backend Docker.

Daje to izolację dla wykonywanego kodu.

Przydaje się np. gdy agent:

  • instaluje przypadkowe zależności,
  • uruchamia kod z repozytorium,
  • testuje skrypty,
  • analizuje nieznane projekty.

Docker jest dobrym dodatkiem na Debianie.

Na FreeBSD nie należy zakładać natywnego Dockera jako podstawowej warstwy.


23. SSH - najważniejszy sposób pracy z FreeBSD

Najbardziej praktyczny układ:

Hermes na Debianie
        │
        └── SSH
             │
             └── FreeBSD

Najpierw skonfiguruj normalne logowanie SSH.

Na Debianie:

ssh-keygen -t ed25519

Skopiuj klucz:

ssh-copy-id user@freebsd-host

Jeżeli ssh-copy-id nie jest dostępne po stronie FreeBSD, można ręcznie wkleić zawartość:

~/.ssh/id_ed25519.pub

do:

~/.ssh/authorized_keys

na FreeBSD.

Test:

ssh user@freebsd-host

Dopiero gdy zwykłe SSH działa bezproblemowo, konfiguruj korzystanie z niego przez Hermesa.


24. ~/.ssh/config

Bardzo warto utworzyć aliasy hostów.

Przykład:

Host homeserver
    HostName 192.168.1.10
    User user
    IdentityFile ~/.ssh/id_ed25519

Host vps
    HostName 203.0.113.10
    User user
    IdentityFile ~/.ssh/id_ed25519

Wtedy:

ssh homeserver

zamiast:

ssh user@192.168.1.10

Agentowi również łatwiej operować nazwami typu:

homeserver
backup
vps
router

niż zapamiętywać IP.


25. Rozpoznawanie Debiana i FreeBSD

Hermes powinien najpierw sprawdzić system.

Uniwersalnie:

uname -a
uname -s

Debian:

cat /etc/os-release

FreeBSD:

freebsd-version
uname -K

Dzięki temu agent może dobrać prawidłowe polecenia.


26. Różnice Debian vs FreeBSD, które agent powinien znać

Pakiety

Debian:

sudo apt update
sudo apt install nginx
sudo apt upgrade

FreeBSD:

sudo pkg update
sudo pkg install nginx
sudo pkg upgrade

Usługi

Debian:

systemctl status nginx
systemctl restart nginx
systemctl enable nginx

FreeBSD:

service nginx status
service nginx restart
sysrc nginx_enable=YES

Logi

Debian:

journalctl -u nginx

FreeBSD:

tail -f /var/log/messages

oraz logi konkretnej aplikacji.


27. Projektowe instrukcje dla Hermesa

Hermes potrafi czytać instrukcje umieszczone w repozytorium.

Najważniejsze pliki:

.hermes.md
AGENTS.md
CLAUDE.md
.cursorrules

Hermes wybiera plik kontekstu projektu według priorytetu.

Najlepiej używać:

AGENTS.md

albo:

.hermes.md

28. Przykład AGENTS.md

# Projekt

Backend napisany w Go.

## Build

go build ./...

## Test

go test ./...

## Frontend

Pliki statyczne znajdują się w ./web.

## Zasady

- nie zmieniaj API bez pytania,
- przed commitem uruchom testy,
- nie modyfikuj plików w /vendor,
- kod formatuj przez gofmt.

Taki plik może dramatycznie poprawić jakość pracy agenta.


29. SOUL.md

Plik:

~/.hermes/SOUL.md

definiuje osobowość agenta.

Możesz tam ustawić:

  • styl komunikacji,
  • ton,
  • imię,
  • sposób zachowania,
  • poziom szczegółowości,
  • rzeczy, których ma unikać.

Przykład:

# Identity

Your name is Hermes.

Be concise and technical.

Explain destructive commands before executing them.

Never hide uncertainty.

Prefer simple solutions over unnecessary frameworks.

Nie wpisuj tu instrukcji dotyczących jednego konkretnego projektu.

Od tego jest AGENTS.md.


30. USER.md

Plik:

~/.hermes/memories/USER.md

zawiera informacje o użytkowniku.

Hermes może zapisywać tam np.:

  • preferowany styl odpowiedzi,
  • poziom wiedzy,
  • preferowane technologie,
  • zwyczaje pracy.

Jest to część pamięci trwałej.


31. MEMORY.md

Plik:

~/.hermes/memories/MEMORY.md

zawiera informacje, które agent zapamiętał.

Na przykład:

Serwer homeserver działa na FreeBSD.
Projekt X używa PostgreSQL.
Do deploymentu używamy Dockera.

Pamięć jest mała i celowo ograniczona.

Nie jest przeznaczona do przechowywania całej historii rozmów.


32. Pamięć a historia sesji

Hermes posiada dwa różne mechanizmy:

MEMORY / USER

oraz:

historia sesji

Pamięć przechowuje wybrane ważne fakty.

Historia sesji może być przeszukiwana, gdy agent potrzebuje znaleźć wcześniejszą rozmowę.

To lepsze niż upychanie wszystkiego do MEMORY.md.


33. Ważna cecha pamięci

Pamięć jest ładowana na początku sesji.

Jeżeli agent zapisze coś do pamięci podczas rozmowy, nowa wersja będzie w pełni widoczna dla system promptu dopiero w kolejnej sesji.

Dlatego po dużej zmianie kontekstu warto użyć:

/new

34. Kontrola zapisu pamięci

Możesz wymusić zatwierdzanie zapisów pamięci.

W config.yaml:

memory:
  write_approval: true

Wtedy możesz sprawdzać proponowane zapisy:

/memory pending

zatwierdzić:

/memory approve <id>

odrzucić:

/memory reject <id>

To dobry pomysł, gdy agent ma samodzielnie działać przez długi czas.


35. Skills

Skill to zestaw instrukcji i narzędzi opisujących, jak agent ma wykonywać konkretny typ zadania.

Przykładowe skills:

deploy-go-app
check-freebsd-zfs
backup-project
publish-website
check-server-health
manage-nginx

Skills znajdują się między innymi w:

~/.hermes/skills/

36. Po co skills

Zamiast za każdym razem tłumaczyć:

wejdź na serwer,
sprawdź repo,
git pull,
zbuduj aplikację,
zrestartuj usługę,
sprawdź log

tworzysz skill:

deploy-martwy-kompas

i agent zna procedurę.

To jest jedna z najważniejszych funkcji Hermesa w długim okresie.


37. Skills i sekrety

Skill może deklarować potrzebne zmienne środowiskowe.

Np.:

required_environment_variables:
  - name: API_KEY
    prompt: API key

Sekret jest przechowywany poza samym skillem.

To znacznie bezpieczniejsze niż wpisanie tokena do pliku instrukcji.


38. Cron - automatyzacja

Hermes może uruchamiać zadania cyklicznie.

Przykłady:

sprawdź codziennie wolne miejsce
sprawdź logi o 7:30
co godzinę sprawdź działanie strony
wyślij rano status serwera

Zadania przechowywane są w:

~/.hermes/cron/

39. Zadania bez modelu AI

Nie każde zadanie potrzebuje LLM.

Jeżeli chcesz tylko:

df -h

i alarm, gdy dysk przekroczy 90%, można zrobić zadanie skryptowe bez modelu.

To:

  • jest tańsze,
  • szybsze,
  • bardziej przewidywalne.

AI powinno być używane tam, gdzie potrzebna jest interpretacja.


40. Quick commands

Możesz tworzyć własne szybkie polecenia.

Przykład:

quick_commands:
  disk:
    type: exec
    command: df -h /

  nginx:
    type: exec
    command: systemctl status nginx

Potem:

/disk

lub:

/nginx

nie wymaga wywołania modelu AI.


41. Signal

Hermes obsługuje Signal poprzez signal-cli.

Układ:

telefon
  │
Signal
  │
signal-cli
  │
Hermes Gateway
  │
Hermes

Signal jest bardzo wygodny do zdalnego sterowania agentem działającym na VPS.


42. Signal - wymagania

Potrzebujesz:

  • numeru telefonu,
  • signal-cli,
  • Java 17+,
  • działającego demona HTTP signal-cli,
  • Hermes Gateway.

Najpierw uruchom i skonfiguruj samo signal-cli.


43. Signal - konfiguracja Hermesa

Uruchom:

hermes gateway setup

Wybierz Signal.

Hermes zapyta między innymi o:

  • URL signal-cli,
  • numer konta,
  • użytkowników mających dostęp.

Domyślny URL może wyglądać tak:

http://127.0.0.1:8080

44. Signal - przykładowe zmienne

W:

~/.hermes/.env

np.:

SIGNAL_HTTP_URL=http://127.0.0.1:8080
SIGNAL_ACCOUNT=+48XXXXXXXXX
SIGNAL_ALLOWED_USERS=+48YYYYYYYYY
SIGNAL_HOME_CHANNEL=+48YYYYYYYYY

Numery zapisuj w formacie E.164:

+48123456789

45. Signal - bezpieczeństwo

To szczególnie ważne.

Agent przez Signal może mieć dostęp do shella.

Dlatego zawsze ogranicz użytkowników:

SIGNAL_ALLOWED_USERS=...

Nie ustawiaj bez potrzeby:

SIGNAL_ALLOW_ALL_USERS=true

Grupy Signal najlepiej pozostawić wyłączone, jeśli nie są potrzebne.


46. Uruchamianie gateway

Na pierwsze testy:

hermes gateway

lub zależnie od wersji CLI:

hermes gateway run

Dzięki temu widzisz logi bezpośrednio w terminalu.

Gdy wszystko działa, uruchom jako usługę.


47. Gateway jako usługa na Debianie

Hermes potrafi zainstalować gateway jako usługę użytkownika:

hermes gateway install

Dla systemowej usługi startującej przy bootowaniu:

sudo hermes gateway install --system

Można potem sprawdzić:

hermes gateway status

oraz:

systemctl status ...

w zależności od sposobu instalacji.


48. Usługi użytkownika i linger

Jeżeli gateway działa jako systemd user service i ma przeżyć logout, może być potrzebne:

sudo loginctl enable-linger USER

Np.:

sudo loginctl enable-linger hermes

49. FreeBSD i gateway

Na FreeBSD nie ma systemd.

Dlatego oficjalne mechanizmy instalacji usługi Hermesa nie są przeznaczone dla tego systemu.

To kolejny powód, by:

Hermes + gateway → Debian
FreeBSD → host zarządzany przez SSH

50. hermes send

Hermes może wysłać pojedynczą wiadomość bez uruchamiania pełnej sesji agenta.

Przykład:

hermes send --to signal "Backup zakończony."

Albo plik:

hermes send --to signal --file /tmp/report.txt

To bardzo użyteczne w zwykłych skryptach shellowych.


51. Przykład użycia w skrypcie

#!/bin/sh

if ! zpool status -x | grep -q "all pools are healthy"; then
    hermes send --to signal "UWAGA: problem z ZFS."
fi

Na Debianie Hermes może w ten sposób wysyłać informacje o stanie zdalnego FreeBSD.


52. Browser / Chromium

Hermes może korzystać z automatyzacji przeglądarki.

Wykorzystuje m.in. Playwright i Chromium.

Ta część ma więcej zależności systemowych niż zwykły agent CLI.

Na Debianie wymagane biblioteki można zainstalować przez Playwright.

Jeżeli nie potrzebujesz browser automation, instalator można uruchomić bez przeglądarki:

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash -s -- --skip-browser

Na małym VPS jest to całkiem rozsądna opcja na początek.


53. Kiedy browser jest potrzebny

Przydaje się, gdy agent ma:

  • obsługiwać stronę WWW jak użytkownik,
  • klikać w interfejs,
  • logować się do paneli,
  • pobierać dane niedostępne przez API.

Do zwykłego web search browser nie zawsze jest potrzebny.


54. Aktualizacja Hermesa

Przed aktualizacją dobrze wykonać backup.

Następnie korzystaj z oficjalnego mechanizmu aktualizacji dla sposobu, w jaki Hermes został zainstalowany.

Sprawdź:

hermes --help

oraz dokumentację aktualnej wersji.

Nie aktualizuj na ślepo działającego produkcyjnego agenta tuż przed ważnym zadaniem.


55. Backup

Najważniejszy katalog:

~/.hermes/

Zawiera on:

  • konfigurację,
  • osobowość,
  • pamięć,
  • skills,
  • cron,
  • historię,
  • część credentiali.

Hermes posiada własne mechanizmy backup/import.

Warto jednak dodatkowo wykonywać zwykłą kopię katalogu.

Przykład:

tar -czf hermes-backup.tar.gz ~/.hermes

UWAGA:

taki backup może zawierać sekrety.

Traktuj go jak magazyn haseł.


56. Backup zaszyfrowany

Lepszy wariant:

tar -czf - ~/.hermes | age -p > hermes-backup.tar.gz.age

albo użyj innego sprawdzonego narzędzia szyfrującego.

Nie wrzucaj surowego ~/.hermes/ do publicznego repozytorium.


57. Logi

Logi znajdują się w:

~/.hermes/logs/

Przykładowo mogą występować:

gateway.log
errors.log
agent.log

Podstawowa diagnostyka:

ls -lah ~/.hermes/logs
tail -f ~/.hermes/logs/gateway.log

Szukaj błędów:

grep -Ri "error" ~/.hermes/logs

58. Przydatne narzędzia shellowe do administracji Hermesa

ps aux | grep hermes
pgrep -af hermes
ss -lntp
df -h
free -h
uptime
top
htop
journalctl
systemctl
tail
grep
rg

Na FreeBSD odpowiednio:

ps aux
sockstat -4 -6
df -h
top
service
sysrc
tail
grep

59. Profile

Hermes może obsługiwać wiele niezależnych profili/agentów.

Przykładowo:

default
work
server
experiments

Każdy może mieć:

  • inną osobowość,
  • inne API keys,
  • inne memories,
  • inne skills,
  • inną konfigurację.

To bardzo wygodne.


60. Po co profile

Przykład:

Hermes "Siostra"
 ├── codzienne użycie
 └── Signal

Hermes "Dev"
 ├── repozytoria
 ├── coding
 └── szerokie uprawnienia

Hermes "Infra"
 ├── serwery
 ├── FreeBSD
 └── ograniczone komendy administracyjne

Nie musisz mieszać wszystkiego w jednej instancji.


61. Tworzenie profilu

Przykładowo:

hermes profile create work

Można także klonować konfigurację istniejącego profilu.

Sprawdź dostępne opcje:

hermes profile --help

62. Nie współdziel jednego HERMES_HOME pomiędzy niezależnymi agentami

Dwa procesy zapisujące tę samą pamięć mogą doprowadzić do konfliktów.

Każdy agent powinien mieć własny profil lub własne:

HERMES_HOME

63. Sesje

Hermes przechowuje historię sesji.

Możesz je przeglądać między innymi przez:

hermes sessions list

Agent posiada także narzędzie wyszukiwania wcześniejszych rozmów.


64. Kiedy zaczynać nową sesję

Nową sesję warto rozpocząć:

  • po zakończeniu zadania,
  • przy zmianie projektu,
  • gdy kontekst stał się ogromny,
  • po zmianie SOUL.md,
  • po zmianie projektowego AGENTS.md,
  • gdy chcesz załadować świeżą pamięć.

W rozmowie:

/new

65. Checkpointy

Hermes może wykonywać checkpointy plików przed zmianami.

Jeżeli coś pójdzie źle, przydatne jest:

/rollback

Mimo tego Git nadal powinien być podstawowym mechanizmem wersjonowania kodu.


66. Git + Hermes

Przed większą pracą:

git status
git add .
git commit -m "checkpoint before Hermes changes"

Po pracy:

git diff
git status

Nigdy nie traktuj pamięci agenta jako zamiennika kontroli wersji.


67. Uprawnienia repozytoriów

Dobrą praktyką jest uruchamianie Hermesa jako użytkownika, który posiada tylko te repozytoria, do których agent powinien mieć dostęp.

Nie dawaj mu automatycznie całego:

/home

jeżeli nie jest to potrzebne.


68. Sekrety projektowe

Nie umieszczaj sekretów w:

AGENTS.md
SOUL.md
README.md
skills

Sekrety trzymaj w:

.env

albo dedykowanym managerze sekretów.


69. Prompt injection

Agent może czytać:

  • strony WWW,
  • pliki,
  • dokumenty,
  • repozytoria.

Treść takiego pliku może próbować przekonać model do wykonania czegoś niepożądanego.

Hermes posiada mechanizmy skanowania kontekstu, ale nie należy zakładać, że rozwiązują każdy możliwy przypadek.

Zasada:

Kod lub dokument pobrany z Internetu jest niezaufanym inputem.


70. Polecenia destrukcyjne

Szczególną ostrożność zachowuj przy:

rm -rf
zpool destroy
zfs destroy
dd
mkfs
gpart destroy
pkg delete
apt purge
DROP DATABASE
docker system prune

Przed pozwoleniem agentowi na takie operacje dobrze wymusić:

  1. pokazanie dokładnego polecenia,
  2. wyjaśnienie skutków,
  3. backup lub snapshot,
  4. dopiero później wykonanie.

71. FreeBSD + ZFS

Jeżeli Hermes ma zarządzać FreeBSD z ZFS, warto stworzyć osobny skill opisujący:

zpool status
zfs list
zfs snapshot
zfs rollback
zfs send
zfs receive

Operacje destrukcyjne powinny wymagać potwierdzenia.


72. Przykładowy workflow: sprawdzenie FreeBSD

Ty:

Sprawdź stan homeservera.

Hermes może wykonać:

ssh homeserver 'uptime'
ssh homeserver 'zpool status'
ssh homeserver 'df -h'
ssh homeserver 'service nginx status'

i zinterpretować wynik.

To jest idealny przykład zastosowania Hermesa.


73. Przykładowy workflow: deployment aplikacji Go

Hermes:

cd project
git status
git pull
go test ./...
go build ./...
docker build -t app .
docker compose up -d
docker compose ps

Na końcu:

curl -I https://example.com

Taki proces warto później zapisać jako skill.


74. Przykładowy workflow: monitoring

Cron:

co 10 minut

wykonuje skrypt:

curl -fsS https://example.com/health

Jeżeli skrypt wykryje błąd:

hermes send --to signal "Serwis nie odpowiada."

AI wcale nie musi być angażowane.


75. Przykładowy workflow: analiza błędu

Ty:

Strona zwraca 502. Sprawdź dlaczego, ale niczego nie restartuj bez pytania.

Hermes może:

systemctl status nginx
journalctl -u nginx
docker ps
docker logs app
ss -lntp

następnie przedstawić diagnozę.

To jest bardzo dobry styl wydawania poleceń agentowi: jasno określ granicę autonomii.


76. Dobry prompt do agenta

Zamiast:

Napraw serwer.

lepiej:

Sprawdź dlaczego nginx zwraca 502.
Możesz czytać logi i konfigurację.
Nie restartuj usług i nie modyfikuj plików bez mojego potwierdzenia.
Na końcu przedstaw diagnozę i proponowaną zmianę.

Agent działa lepiej, gdy dokładnie wie:

  • cel,
  • zakres,
  • czego może dotknąć,
  • czego nie wolno robić,
  • jak ma zakończyć zadanie.

77. Tryby autonomii

Możesz mentalnie podzielić zadania na trzy poziomy.

Poziom 1 - tylko analiza

Sprawdź i powiedz, co jest nie tak.
Nic nie zmieniaj.

Poziom 2 - ograniczone działanie

Możesz poprawić konfigurację aplikacji,
ale nie restartuj usług.

Poziom 3 - autonomiczne wykonanie

Napraw problem, uruchom testy,
zrestartuj usługę i zweryfikuj rezultat.

Do produkcji najlepiej zaczynać od poziomu 1.


78. WebUI

Hermes może mieć dodatkowe interfejsy WWW.

Nie są one potrzebne do działania samego agenta.

Na początku zdecydowanie wystarczają:

CLI + Signal

WebUI warto dodać dopiero wtedy, gdy faktycznie zacznie brakować wygodniejszego interfejsu.


79. Co warto uruchomić najpierw

Kolejność wdrożenia:

1. Debian
2. Hermes
3. jeden model
4. zwykły chat
5. shell
6. SSH do FreeBSD
7. SOUL.md
8. AGENTS.md dla projektów
9. Signal
10. skills
11. cron
12. dodatkowe modele
13. fallback
14. browser
15. WebUI

Taka kolejność bardzo upraszcza diagnostykę.


80. Czego NIE robić pierwszego dnia

Nie konfiguruj od razu:

  • pięciu providerów,
  • dziesięciu modeli,
  • kilkunastu skills,
  • wielu komunikatorów,
  • browser automation,
  • crona,
  • WebUI,
  • pełnego roota,
  • automatycznych deploymentów produkcyjnych.

Najpierw zwykła rozmowa i shell.


81. Proponowany układ na VPS

Dla małego Debiana:

Debian VPS
├── nginx
├── Docker
├── projekty
├── Hermes
├── Signal CLI
└── SSH
     └── homelab FreeBSD

4 GB RAM jest rozsądnym punktem startowym dla samego Hermesa i lekkich usług, jeżeli modele działają przez API.

Chromium może jednak zauważalnie zwiększyć zużycie RAM.


82. Proponowany osobny użytkownik

Możesz utworzyć:

sudo adduser hermes

i uruchamiać agenta właśnie na tym koncie.

Zalety:

  • osobny katalog domowy,
  • łatwiejsze kontrolowanie uprawnień,
  • osobne klucze SSH,
  • prostsza separacja sekretów.

83. Kontrolowane sudo

Przez:

sudo visudo

można dopuścić tylko konkretne polecenia.

Nie twórz jednak skomplikowanych reguł sudo bez zrozumienia ich konsekwencji - obejścia są czasem możliwe przez pozornie niewinne programy.


84. Firewall

Hermes sam w sobie nie wymaga wystawiania całego systemu na Internet.

Jeżeli signal-cli słucha na:

127.0.0.1:8080

nie wystawiaj tego portu publicznie.

Sprawdź:

ss -lntp

Powinno być:

127.0.0.1:8080

a nie:

0.0.0.0:8080

chyba że dokładnie wiesz, dlaczego tego potrzebujesz.


85. SSH z Hermesa do FreeBSD - bezpieczeństwo

Dobrze utworzyć osobny klucz:

ssh-keygen -t ed25519 -f ~/.ssh/hermes_freebsd

i użyć go w:

~/.ssh/config

Przykład:

Host homeserver
    HostName 192.168.1.10
    User hermes
    IdentityFile ~/.ssh/hermes_freebsd

Możesz wtedy ograniczyć konto hermes na FreeBSD.


86. FreeBSD - użytkownik dla agenta

Na FreeBSD:

adduser

utwórz osobnego użytkownika np.:

hermes

Nie musi być rootem.

Daj mu tylko prawa potrzebne do:

  • odczytu logów,
  • sprawdzania usług,
  • deploymentu konkretnych aplikacji,
  • wykonywania uzgodnionych komend.

87. FreeBSD - sudo/doas

Możesz użyć:

sudo

lub:

doas

Nie dawaj agentowi automatycznie pełnej kontroli nad hostem.

Na początek zwykły użytkownik SSH często w zupełności wystarczy.


88. Native Hermes na FreeBSD - eksperymentalnie

Jeżeli mimo wszystko chcesz próbować:

  1. zainstaluj Git,
  2. zainstaluj nowego Pythona,
  3. zainstaluj Node.js,
  4. zainstaluj ripgrep,
  5. zainstaluj ffmpeg,
  6. sklonuj repo,
  7. utwórz virtualenv,
  8. spróbuj instalacji zależności ręcznie.

Ale:

Nie traktuj takiej instalacji jako stabilnej konfiguracji.

Aktualizacje Hermesa mogą ją złamać.

Nie jest to oficjalnie wspierana platforma.


89. Debian VM na FreeBSD

Jeżeli fizyczny serwer działa na FreeBSD, możesz zrobić:

FreeBSD
└── bhyve
     └── Debian VM
          └── Hermes

Hermes może wtedy zarządzać hostem FreeBSD przez SSH.

To bardzo czysta architektura.


90. Monitorowanie samego Hermesa

Warto sprawdzać:

pgrep -af hermes
hermes gateway status
df -h
free -h

i logi:

tail -n 100 ~/.hermes/logs/gateway.log

91. Watchdog

Na Debianie można użyć systemd, żeby gateway był automatycznie restartowany po błędzie.

Jeżeli Hermes sam instaluje usługę, warto najpierw użyć jego własnego mechanizmu.

Potem sprawdź jednostkę:

systemctl --user list-units | grep -i hermes

lub systemową:

systemctl list-units | grep -i hermes

92. Aktualizacje systemu

Debian:

sudo apt update
sudo apt upgrade

FreeBSD:

sudo pkg update
sudo pkg upgrade

System bazowy FreeBSD aktualizuje się innymi mechanizmami niż pakiety.

Agent powinien odróżniać:

base system

od:

pkg

93. Nie pozwalaj agentowi ślepo aktualizować produkcji

Polecenie:

zaktualizuj wszystko

jest kiepskim zadaniem dla serwera produkcyjnego.

Lepsze:

Sprawdź dostępne aktualizacje.
Pokaż pakiety, które zostaną zmienione.
Nie wykonuj aktualizacji bez potwierdzenia.

94. Agent jako administrator

Hermes może być świetnym pomocnikiem administracyjnym, ale powinien działać według zasady:

obserwuj → diagnozuj → zaproponuj → zmień → zweryfikuj

Nie:

zmieniaj wszystko aż zacznie działać

95. Agent jako developer

Dobry workflow:

issue
  │
  ▼
analiza repo
  │
  ▼
plan
  │
  ▼
zmiany
  │
  ▼
testy
  │
  ▼
git diff
  │
  ▼
commit

Warto wpisać ten workflow do projektowego AGENTS.md.


96. Agent jako operator serwera

Dobry workflow:

status
  │
  ▼
logi
  │
  ▼
diagnoza
  │
  ▼
snapshot / backup
  │
  ▼
zmiana
  │
  ▼
restart
  │
  ▼
health check

97. Najważniejsze slash commands

Lista może się zmieniać pomiędzy wersjami, dlatego zawsze możesz użyć:

/help

Szczególnie przydatne są:

/new
/model
/memory
/context
/rollback
/help

Dokładny zestaw sprawdzaj w aktualnej wersji Hermesa.


98. Najważniejsze komendy administracyjne CLI

Warto zapamiętać:

hermes
hermes doctor
hermes setup
hermes model
hermes tools
hermes gateway setup
hermes gateway status
hermes config get
hermes config set
hermes sessions list
hermes send
hermes profile
hermes memory

Sprawdzanie podkomend:

hermes COMMAND --help

99. Diagnostyka - pierwszy zestaw

Jeżeli Hermes przestaje działać:

hermes doctor
which hermes
hermes --help
pgrep -af hermes
df -h
free -h

Następnie:

ls -lah ~/.hermes/logs
tail -n 200 ~/.hermes/logs/errors.log
tail -n 200 ~/.hermes/logs/gateway.log

100. Signal nie działa - checklista

Sprawdź:

java -version
signal-cli --version

Czy daemon działa:

ps aux | grep signal-cli

Czy port działa:

ss -lntp | grep 8080

Czy endpoint jest dostępny tylko lokalnie.

Następnie:

hermes gateway status

i logi gateway.


101. SSH do FreeBSD nie działa - checklista

Na Debianie:

ssh -v homeserver

Na FreeBSD:

service sshd status
sockstat -4 -6 | grep :22

Sprawdź:

~/.ssh/authorized_keys

oraz uprawnienia:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

102. Hermes używa złej komendy systemowej

Jeżeli agent próbuje np.:

systemctl

na FreeBSD, popraw jego kontekst.

W AGENTS.md dla infrastruktury napisz:

Host homeserver runs FreeBSD.

Use:
- `service`, not `systemctl`
- `pkg`, not `apt`
- `sysrc` for service enablement
- `sockstat`, not `ss`

To prosty sposób na ograniczenie pomyłek.


103. Osobny repozytorium infrastruktury

Warto mieć np.:

infra/
├── AGENTS.md
├── hosts.md
├── procedures/
│   ├── backup.md
│   ├── restore.md
│   └── deploy.md
└── scripts/

Hermes uruchomiony w tym katalogu dostanie dobry kontekst infrastruktury.


104. Hosts.md

Przykład:

# Hosts

## vps
OS: Debian
Role: public applications

## homeserver
OS: FreeBSD
Role: storage, Jellyfin, backups

## router
OS: RouterOS
Role: firewall and routing

Nie wpisuj tu haseł.


105. Procedury zamiast improwizacji

Im bardziej krytyczne zadanie, tym lepiej, by istniała procedura.

Np.:

procedures/update-freebsd.md
procedures/deploy-site.md
procedures/recover-postgresql.md

Hermes może je czytać i wykonywać krok po kroku.


106. Klucze API

Podstawowe zasady:

  • jeden klucz na usługę,
  • ograniczaj uprawnienia,
  • rotuj klucze,
  • nie zapisuj ich w repo,
  • nie wysyłaj ich w rozmowie, jeśli nie jest to konieczne,
  • trzymaj w .env lub managerze sekretów.

107. Koszty modeli

Największym bieżącym kosztem agenta są zwykle wywołania modeli.

Koszt ograniczają:

  • tani model jako domyślny,
  • mocny model tylko do trudnych zadań,
  • quick commands,
  • zadania cron bez LLM,
  • sensowne rozpoczynanie nowych sesji,
  • niezapychana pamięć,
  • ograniczanie niepotrzebnych podagentów.

108. Tokeny a długie sesje

Bardzo długa rozmowa:

  • zwiększa kontekst,
  • może zwiększyć koszt,
  • może spowolnić pracę,
  • zwiększa ryzyko pomyłek.

Po zakończeniu tematu:

/new

Hermes zachowa pamięć i historię sesji.


109. Kiedy używać podagentów

Podagenci są sensowni, gdy zadanie można podzielić.

Np.:

agent 1 → analizuje backend
agent 2 → analizuje frontend
agent 3 → analizuje testy

Nie ma sensu uruchamiać podagentów do:

sprawdź wolne miejsce na dysku

110. Minimalna konfiguracja produkcyjna

Po kilku dniach zabawy sensowne minimum może wyglądać tak:

Debian VPS
│
├── osobny user hermes
├── Hermes
├── jeden tani model
├── jeden mocny model
├── fallback
├── Signal
├── SSH do FreeBSD
├── backup ~/.hermes
└── ograniczone sudo

111. Sensowny model pracy

Na co dzień:

Signal
  │
  ▼
Hermes na VPS
  │
  ├── pytania
  ├── projekty
  ├── cron
  ├── monitoring
  └── SSH
       └── FreeBSD

Do poważniejszych prac developerskich:

SSH / terminal
   │
   ▼
Hermes CLI
   │
   ▼
repozytorium

112. Co trzymać gdzie

Informacja Miejsce
osobowość agenta SOUL.md
preferencje użytkownika USER.md
wiedza trwała agenta MEMORY.md
instrukcje projektu AGENTS.md / .hermes.md
konfiguracja config.yaml
sekrety .env
własne procedury agenta skills/
harmonogramy cron/
historia sessions/
diagnostyka logs/

113. Komendy - ściąga

Instalacja

sudo apt update
sudo apt install -y git curl xz-utils
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
source ~/.bashrc

Diagnostyka

hermes doctor

Start

hermes

Konfiguracja

hermes setup
hermes model
hermes tools

Gateway

hermes gateway setup
hermes gateway status

Sesje

hermes sessions list

Profile

hermes profile --help

Pamięć

hermes memory --help

Wiadomość

hermes send --to signal "test"

114. FreeBSD - ściąga dla Hermesa

System

freebsd-version
uname -a

Pakiety

pkg info
sudo pkg update
sudo pkg upgrade
sudo pkg install PACKAGE

Usługi

service -e
service SERVICE status
sudo service SERVICE restart

Enable

sudo sysrc service_enable=YES

Sieć

ifconfig
netstat -rn
sockstat -4 -6

Dyski

df -h
gpart show
camcontrol devlist

ZFS

zpool status
zpool list
zfs list

115. Debian - ściąga dla Hermesa

System

cat /etc/os-release
uname -a

Pakiety

apt list --installed
sudo apt update
sudo apt upgrade
sudo apt install PACKAGE

Usługi

systemctl status SERVICE
sudo systemctl restart SERVICE
sudo systemctl enable SERVICE

Logi

journalctl -u SERVICE
journalctl -xe

Sieć

ip addr
ip route
ss -lntup

Zasoby

df -h
free -h
uptime

116. Jak uczyć własnego Hermesa

Najlepsza droga to nie ogromny prompt startowy.

Lepsza jest ewolucja:

SOUL.md
   +
USER.md
   +
MEMORY.md
   +
AGENTS.md
   +
skills

Agent stopniowo poznaje:

  • Ciebie,
  • Twoje środowisko,
  • Twoje projekty,
  • procedury pracy.

117. Najważniejsza zasada

Hermes jest najbardziej użyteczny, gdy staje się operatorem znanego środowiska, a nie modelem, który za każdym razem zgaduje od zera.

Dlatego:

dobre instrukcje
+ ograniczone uprawnienia
+ powtarzalne procedury
+ Git
+ SSH
+ skills
+ monitoring

są ważniejsze niż samo użycie najmocniejszego dostępnego modelu.


118. Rekomendowana architektura Debian + FreeBSD

Docelowo:

                     ┌─────────────┐
                     │   Signal    │
                     └──────┬──────┘
                            │
                            ▼
                 ┌────────────────────┐
                 │     Debian VPS     │
                 │                    │
                 │  Hermes Agent      │
                 │  ├── models        │
                 │  ├── memory        │
                 │  ├── skills        │
                 │  ├── cron          │
                 │  ├── Git           │
                 │  └── gateway       │
                 └─────────┬──────────┘
                           │
                          SSH
                           │
                ┌──────────▼──────────┐
                │      FreeBSD        │
                │                     │
                │ ZFS                 │
                │ jails               │
                │ services            │
                │ backups             │
                │ Jellyfin / storage  │
                └─────────────────────┘

To daje Ci:

  • stabilne środowisko dla agenta,
  • pełną funkcjonalność Hermesa,
  • prostą aktualizację,
  • naturalne zarządzanie FreeBSD,
  • izolację systemów,
  • możliwość łatwego przeniesienia Hermesa na inny VPS.

119. Pierwszy dzień - konkretna checklista

[ ] Zainstaluj Debiana
[ ] Zaktualizuj system
[ ] Zainstaluj git/curl/xz-utils
[ ] Zainstaluj Hermesa
[ ] Uruchom hermes doctor
[ ] Skonfiguruj jeden model
[ ] Uruchom zwykłą rozmowę
[ ] Sprawdź terminal
[ ] Utwórz ~/.hermes/SOUL.md
[ ] Skonfiguruj SSH do FreeBSD
[ ] Sprawdź z Hermesa uname/freebsd-version
[ ] Dopiero potem skonfiguruj Signal

120. Drugi etap

[ ] Signal
[ ] gateway jako usługa
[ ] ograniczenie dostępu Signal
[ ] backup ~/.hermes
[ ] osobny użytkownik systemowy
[ ] pierwszy AGENTS.md
[ ] pierwszy skill
[ ] prosty cron
[ ] powiadomienie przez hermes send

121. Trzeci etap

[ ] drugi model
[ ] model fallback
[ ] profile
[ ] browser automation
[ ] rozbudowane skills
[ ] monitoring usług
[ ] automatyczny deployment
[ ] WebUI, jeśli faktycznie potrzebne

122. Przydatne źródła

Oficjalna dokumentacja:

https://hermes-agent.nousresearch.com/docs/

Instalacja:

https://hermes-agent.nousresearch.com/docs/getting-started/installation

Obsługiwane platformy:

https://hermes-agent.nousresearch.com/docs/getting-started/platform-support

Konfiguracja:

https://hermes-agent.nousresearch.com/docs/user-guide/configuration

CLI:

https://hermes-agent.nousresearch.com/docs/reference/cli-commands

Slash commands:

https://hermes-agent.nousresearch.com/docs/reference/slash-commands

Pamięć:

https://hermes-agent.nousresearch.com/docs/user-guide/features/memory

Skills:

https://hermes-agent.nousresearch.com/docs/user-guide/features/skills

Cron:

https://hermes-agent.nousresearch.com/docs/user-guide/features/cron

Security:

https://hermes-agent.nousresearch.com/docs/user-guide/security

Messaging gateway:

https://hermes-agent.nousresearch.com/docs/user-guide/messaging

Signal:

https://hermes-agent.nousresearch.com/docs/user-guide/messaging/signal

GitHub:

https://github.com/NousResearch/hermes-agent


123. TL;DR

Jeżeli chcesz po prostu wiedzieć, jak to ustawić:

Debian → Hermes → Signal
               → modele przez API
               → Git
               → cron
               → skills
               → SSH → FreeBSD

Nie próbuj robić z FreeBSD głównego hosta Hermesa, dopóki projekt oficjalnie go nie wspiera.

FreeBSD świetnie nadaje się natomiast na maszynę, którą Hermes administruje przez SSH.

Na początek wystarczą:

hermes
hermes doctor
hermes setup
hermes model
hermes gateway setup

oraz wiedza, gdzie znajdują się:

~/.hermes/config.yaml
~/.hermes/.env
~/.hermes/SOUL.md
~/.hermes/memories/
~/.hermes/skills/
~/.hermes/logs/

Resztę warto dokładać dopiero wtedy, gdy podstawowy agent działa stabilnie.