
„Hermes Agent” porównywany z OpenClaw w polskich wyszukiwaniach to ten od Nous Research (NousResearch/hermes-agent, licencja MIT), nie klient webowy hermes-webui ani społecznościowy indeks „HermesHub”. Zainstalowany i utwardzony pod Dockerem w izolowanym laboratorium, bez wpisanego klucza ani identyfikatora, uruchamia się w 17 do 19 sekund do rzeczywiście pozytywnego punktu kontroli stanu. Dwa nieudokumentowane ustawienia do poznania przed udostępnieniem: internal: true odcina też opublikowany port, nie tylko wyjście do internetu, a bramka domyślnie nasłuchuje tylko na własnej pętli lokalnej, nawet za portem już ograniczonym do 127.0.0.1 po stronie hosta.
„Hermes agent” i „hermes vs openclaw” regularnie wracają w polskich wyszukiwaniach, ale nazwa jest niejednoznaczna: kilka projektów nazywa się Hermes. Tylko jeden jest porównywany z OpenClaw w źródłach datowanych na 2026 rok. Jest tu zidentyfikowany, zainstalowany i utwardzony pod Dockerem w izolowanym laboratorium, rozróżniając na każdym etapie to, co naprawdę zostało uruchomione, od tego, co pozostaje udokumentowane.
Który dokładnie Hermes Agent?
Projekt, o który chodzi w tych wyszukiwaniach, to Hermes Agent, rozwijany przez Nous Research i publikowany na licencji MIT w repozytorium NousResearch/hermes-agent, . Repozytorium pokazywało 242 851 gwiazdek i 49 953 forków 7 września 2026, przy utworzeniu 22 lipca 2025. Jego opis mieści się w jednym zdaniu: „the agent that grows with you”. Jeden agent, który tworzy i dopracowuje własne umiejętności na podstawie doświadczenia, w przeciwieństwie do platformy orkiestrującej wielu agentów. Ta różnica filozofii wraca w porównaniach publikowanych w 2026 wobec OpenClaw i potwierdza, że za zapytaniami „hermes vs openclaw” stoi właśnie ten projekt.
Dwie pułapki nazewnictwa, których trzeba unikać. hermes-webui to zewnętrzny klient webowy, nieutrzymywany przez Nous Research. „HermesHub” oznacza społecznościowy indeks umiejętności, odrębny od oficjalnego huba wbudowanego w CLI. Oba łatwo pomylić z głównym projektem w wynikach wyszukiwania. Hermes Agent dołącza zresztą do listy, którą nasz przegląd agentów kodu w linii poleceń porównuje między sobą.
Zainstalować Hermes Agent z Dockerem
Oficjalny obraz to nousresearch/hermes-agent. Dokumentacja Docker opisuje interaktywnego asystenta konfiguracji, a potem uruchomienie jako usługi:
mkdir -p ~/.hermes
docker run -it --rm -v ~/.hermes:/opt/data nousresearch/hermes-agent setup
docker run -d --name hermes --restart unless-stopped \
-v ~/.hermes:/opt/data -p 8642:8642 \
nousresearch/hermes-agent gateway runLaboratorium poniżej nie korzysta z tego interaktywnego asystenta: przechodzi bezpośrednio przez utwardzony compose, który odtwarza gateway run na innej sieci i innych portach. Port 8642 służy jednocześnie jako punkt kontroli stanu i bramka kompatybilna z API OpenAI, port 9119, opcjonalny, służy do tablicy webowej. Wolumin zamontowany na /opt/data zawiera .env, config.yaml, SOUL.md, a także foldery sessions/, memories/ i skills/. Dokumentacja zaleca od 1 do 4 GB pamięci i od 1 do 2 rdzeni, zależnie od użycia.
Przypiąłem ostatnią wersję z datą zamiast latest. Wydania na GitHubie wskazują v0.21.0 (tag v2026.8.31, „The Pantheon Release”), opublikowaną 31 sierpnia 2026, około 5 800 commitów i 760 kontrybutorów po poprzedniej wersji. Pobranie zajęło 1 min 47 s na tej maszynie za 908 MB skompresowanych (3,93 GB po dekompresji, architektura arm64). Obraz v2026.4.30, 8,2 GB, umiejscawia prawdziwą zmianę architektury wewnętrznej między kwietniem a majem 2026. Ten punkt kontrolny wciąż startuje na tini, podczas gdy sierpniowa wersja używa s6-overlay jako PID 1, z porzuceniem uprawnień na rzecz użytkownika hermes (domyślnie UID 10000). Ciekawostka odnotowana przy okazji: rejestr Docker Hub pokazuje, że rozmiar obrazu spadł z około 2,5 GB w kwietniu do poniżej 900 MB od lipca 2026.
Utwardzić konfigurację: sieć, porty, sekrety
Oficjalny docker-compose.yml deklaruje network_mode: host zarówno dla bramki, jak i dla tablicy, wygodne, ale bez żadnej izolacji sieciowej. Dla laboratorium zbudowałem utwardzoną wersję: dedykowana sieć, porty publikowane wyłącznie na pętli lokalnej, sekrety poza plikiem compose.
services:
hermes:
image: nousresearch/hermes-agent:v2026.8.31
container_name: hermes-lab
networks:
- hermes_lab
ports:
- "127.0.0.1:8642:8642"
- "127.0.0.1:9119:9119"
volumes:
- ./data:/opt/data
env_file:
- ./secrets/hermes.env # ewentualny klucz dostawcy, poza repozytorium
environment:
- HERMES_UID=501
- HERMES_GID=20
- HERMES_DASHBOARD=1
- HERMES_DASHBOARD_HOST=0.0.0.0
- API_SERVER_HOST=0.0.0.0 # zobacz niżej: bez tej linii, /health
deploy: # pozostaje nieosiągalny, mimo opublikowanego portu
resources:
limits:
memory: 1g
cpus: "1.0"
command: ["gateway", "run"]
networks:
hermes_lab:
driver: bridgeDwa ustawienia oficjalnego compose zachowują się inaczej, niż pozwala oczekiwać dokumentacja. Pierwsza dotyczy sieci. Oznaczenie jej jako internal: true, żeby odciąć całe wyjście do internetu, odcina też opublikowany port. W laboratorium żądanie wysłane z wnętrza kontenera otrzymuje HTTP 200 na /health. To samo żądanie z maszyny hosta, na opublikowanym porcie, nie otrzymuje żadnej odpowiedzi. Próba wyjścia do example.com zawodzi na niemożliwym rozwiązaniu DNS. Izolacja trzyma więc, ale zabiera ze sobą uzasadnione lokalne użycie portu. internal: true nadaje się tylko do laboratorium całkowicie offline. Dla rzeczywistego użycia ze zdalnym dostawcą modelu izolacja przechodzi przez klasyczną dedykowaną sieć i zaporę wychodzącą, nie przez to ustawienie.
Druga zaskakuje bardziej. Nawet na dedykowanej sieci nieoznaczonej jako internal, opublikowany port pozostawał nieosiągalny, połączenie TCP akceptowane, odpowiedź HTTP pusta. Poszukiwanie w zainstalowanym kodzie daje dokładne wyjaśnienie:
docker exec hermes-lab grep -r API_SERVER_HOST /opt/hermes/hermes_cli/security_audit_startup.py
host = extra.get("host") or os.environ.get("API_SERVER_HOST", "127.0.0.1")Domyślnie bramka nasłuchuje tylko na pętli lokalnej wewnątrz kontenera, niezależnie od wybranej sieci Docker. Stąd linia API_SERVER_HOST=0.0.0.0 w compose powyżej: niczego nie zmienia w zewnętrznej ekspozycji, ponieważ to prefiks 127.0.0.1: opublikowanego portu już ją ogranicza. Zweryfikowane po poprawce: curl http://127.0.0.1:8642/health odpowiada 200 z hosta, to samo żądanie wysłane na lokalny adres sieciowy maszyny (192.168.x.x) nie otrzymuje żadnej odpowiedzi. Co do tablicy, odmawia ona wprost uruchomienia na nielokalnym interfejsie bez skonfigurowanego dostawcy uwierzytelniania:
Refusing to bind dashboard to 0.0.0.0 — the auth gate engages on non-loopback
binds (0.0.0.0), but no auth providers are registered.
There is no unauthenticated public-dashboard option.Zdrowe zachowanie domyślne, z efektem ubocznym widocznym w dziennikach. Pozostawiona tak, bez skonfigurowanego uwierzytelniania, usługa nie zostaje po prostu wyłączona, zawodzi, a potem restartuje się w pętli pod nadzorem s6. Nic poważnego, ale wystarczająco głośno, żeby warto było o tym wiedzieć. Ostatni zweryfikowany punkt: limit deploy.resources.limits z compose powyżej rzeczywiście stosuje się poza trybem Swarm z Docker Compose v5.1.0. docker inspect potwierdza Memory=1073741824 i NanoCpus=1000000000 na uruchomionym kontenerze. Starsze wersje Compose ignorowały deploy: poza Swarm.
Co widać przy uruchamianiu
Po poprawieniu konfiguracji, docker compose up -d, a potem sondowanie /health co 0,3 sekundy dają czas uruchamiania około 18,9 sekundy na zimno (pusty folder danych) i 16,6 sekundy po zwykłym restarcie. Różnica bierze się głównie z fazy wewnętrznego rozgrzewania, którą dzienniki nazywają wprost „turn-machinery warm-up” i która otwiera bramę wejściową po 20 sekundach, mimo że trwa dalej w tle. Wewnątrz ps aux potwierdza, że nadzorca zostaje rootem, ale że proces hermes gateway run działa rzeczywiście pod nieuprzywilejowanym użytkownikiem hermes. Baner startowy pokazuje Hermes Agent v0.21.0 (2026.8.31), Python 3.13.5 i SDK OpenAI 2.24.0.
| Port albo plik | Rola | Dostęp domyślny |
|---|---|---|
| 8642 | Stan zdrowia + bramka kompatybilna z API OpenAI | Pętla lokalna kontenera (API_SERVER_HOST=127.0.0.1) |
| 9119 | Tablica webowa | Odmawia każdego nielokalnego powiązania bez uwierzytelniania |
/opt/data/.env | Klucze dostawców modeli i narzędzi | Wzorzec całkowicie zakomentowany, brak aktywnego klucza przy instalacji |
/opt/data/config.yaml | Model domyślny, terminal, kompresja kontekstu | Generowany przy pierwszym uruchomieniu |
Podłączenie do modelu
Plik .env wygenerowany przy pierwszym uruchomieniu wylicza, całkowicie w komentarzach, ze trzydziestu dostawców (Fireworks, OpenRouter, NovitaAI, Gemini, z.ai, Kimi, MiniMax, OpenCode Zen…) i tyle samo kluczy narzędzi (Firecrawl, Exa, Browserbase), żaden nie jest aktywny. „Ollama” pojawia się tam tylko w postaci OLLAMA_API_KEY, płatnej usługi chmurowej Ollama, i żaden wpis nie celuje w instancję lokalną. Wbudowana diagnostyka potwierdza neutralny stan instalacji:
docker exec hermes-lab hermes doctor
✓ No active security advisories
✓ No suspicious MCP stdio commands
✓ Version files consistent (0.21.0)
◆ API Connectivity
⚠ OpenRouter API (not configured)
◆ Memory Provider
✓ Built-in memory active (no external provider configured — this is fine)Jedyna wartość obecna w .env na koniec testu: API_SERVER_KEY wygenerowana automatycznie przez kontener, żeby chronić jego własną lokalną bramkę. Nigdy nie pojawia się jawnym tekstem w dziennikach, nikt jej nie wpisał i nie ma związku z kontem u dostawcy modelu.
Umiejętności, i jak zweryfikować jedną przed instalacją
Umiejętności („skills”) żyją w /opt/data/skills/ i podążają za otwartym standardem Agent Skills opisanym szczegółowo w naszym przewodniku po SKILL.md. hermes skills list naliczał 53 wbudowane umiejętności aktywne w tym laboratorium, żadna niezainstalowana z huba. Instalacja odbywa się przez rejestr: hermes skills install official/security/1password albo hermes skills install openai/skills/k8s, na przykład. Zanim cokolwiek zainstalujesz, dwie komendy pozwalają uniknąć ślepego zaufania:
hermes skills inspect openai/skills/k8s # metadane, repozytorium źródłowe, audyt już dostępny
hermes skills audit # ponownie skanuje wszystkie umiejętności zainstalowane z hubaWbudowany skaner klasyfikuje każdy wynik na trzy poziomy: dangerous blokuje instalację, warn/caution omija się przez --force, advisory pozostaje informacyjny. Według oficjalnej dokumentacji, hub agregował 90 700 umiejętności rozłożonych na 11 rejestrach na 26 sierpnia 2026, nie mylić z „HermesHub”, zewnętrznym indeksem społecznościowym wspomnianym wyżej.
MCP: podłączyć narzędzia albo udostępnić Hermes jako serwer
hermes mcp catalog, uruchomiony w laboratorium, pokazuje już długi katalog gotowych do użycia serwerów (Airtable, Atlassian, Cloudflare, ClickUp, Buildkite…). hermes mcp list potwierdzał, że żaden nie był skonfigurowany, zgodnie z oczekiwaniem dla świeżej instalacji. Dodawanie odbywa się przez znane ustawienie wstępne albo ręczny wpis:
hermes mcp add codex --preset codex
hermes mcp add filesystem --command npx --args "-y @modelcontextprotocol/server-filesystem /projet"W drugą stronę, hermes mcp serve udostępnia sesję Hermes jako serwer MCP zewnętrznemu klientowi, Claude Code, na przykład, kierując jego konfigurację na komendę hermes mcp serve. Jeśli chodzi o bezpieczeństwo, dokumentacja precyzuje trzy rzeczy. Zdalne tokeny OAuth są zapisywane w cache z uprawnieniami 0600. Odnowienie przechodzi przez PKCE. Dla serwerów w stdio tylko jawnie zadeklarowane zmienne środowiskowe, plus minimalna baza, są przekazywane do podprocesu. To ogranicza wycieki sekretów do źle zaudytowanego zewnętrznego serwera MCP, ryzyko już udokumentowane w naszym artykule o agentach kodu, sandboksie i uprawnieniach.
Hermes Agent kontra OpenClaw: uczciwe porównanie
Oba projekty są open source, instalują się pod Dockerem i obsługują skille oraz MCP, to ich filozofia się rozchodzi. OpenClaw buduje bramkę, która routuje i nadzoruje wielu agentów, konektorów i kanałów. Hermes Agent stawia na jednego agenta, który gromadzi własne umiejętności w miarę użytkowania. Nasz artykuł o utwardzonej instalacji OpenClaw opisuje szczegółowo to samo ćwiczenie po stronie OpenClaw, oba czyta się jak lustrzane odbicie.
Jeśli chodzi o bezpieczeństwo, notatka badawcza Cloud Security Alliance datowana na 4 maja 2026 odnotowuje, w tym samym okresie, dziewięć CVE dla OpenClaw, w tym jedno krytyczne ocenione na 9,9, wobec dwóch dla rdzenia Hermes Agent. CVE-2026-7396 dotyczy przejścia ścieżki w adapterze WeCom (CVSS 4,0), CVE-2026-7397 podążania za dowiązaniem symbolicznym w narzędziach plikowych (CVSS 4,8), oba na wersji 0.8.0 i poprawione już w 0.9.0. Trzecie wymienione CVE dotyczy nie agenta, lecz hermes-webui, zewnętrznego klienta już wspomnianego wyżej. Strona GitHub Security Advisories repozytorium nie odnotowuje z kolei żadnego opublikowanego ostrzeżenia na 7 września 2026: te CVE zostały zgłoszone przez kanały zewnętrzne, nie przez samego Nous Research. Do dziś nie opublikowano żadnego zestawienia narażonych instancji Hermes porównywalnego ze zweryfikowaną liczbą dla OpenClaw (42 900 instancji, 93% bez uwierzytelniania, SecurityScorecard 2026), co nie dowodzi ich braku.
Datowany incydent ilustruje, dlaczego izolacja sieciowa i brak trybu automatycznego liczą się tyle samo, co wybór projektu. The Hacker News udokumentował, 24 lipca 2026, przypadek, w którym atakujący, mający już wstępny dostęp do sieci tajlandzkiego ministerstwa finansów, zainstalował Hermes Agent na wynajętym serwerze, a następnie włączył jego tryb „YOLO”, który pomija potwierdzenia przed ryzykownymi komendami. Agent eksplorował potem sieć bez nadzoru, znalazł usługi Hadoop z domyślnymi danymi uwierzytelniającymi i wdrożył implant. Punkt podkreślony przez samo źródło: Hermes nie spowodował włamania, zautomatyzował jego kolejną fazę. Dedykowana sieć, porty na pętli lokalnej i brak wpisanego klucza w tym laboratorium mają zapobiec dokładnie tej fazie.
Co warto zapamiętać
- „Hermes Agent” porównywany z OpenClaw w 2026 to ten od Nous Research (NousResearch/hermes-agent, licencja MIT), nie
hermes-webuiani „HermesHub”, dwa zewnętrzne projekty o zbliżonej nazwie. - Ostatnia testowana wersja z datą: v0.21.0 (tag
v2026.8.31, 31 sierpnia 2026), zainstalowana przez Docker w 1 min 47 s (908 MB skompresowanych, 3,93 GB po dekompresji). - Sieć oznaczona jako
internal: trueodcina też opublikowany port, nie tylko wyjście do internetu. Domyślnie bramka nasłuchuje tylko na własnej pętli lokalnej (API_SERVER_HOST=127.0.0.1), do jawnego poprawienia nawet za portem już ograniczonym do 127.0.0.1 po stronie hosta. - Tablica odmawia ekspozycji poza pętlą lokalną bez skonfigurowanego uwierzytelniania. Zdrowe zachowanie domyślne, ale zostawiona tak zapętla się w niepowodzeniu, zamiast pozostać po prostu nieaktywna.
- Uruchamianie zmierzone na około 17 do 19 sekund do rzeczywiście pozytywnego
/health, bez żadnego klucza ani identyfikatora wpisanego od początku do końca. - W tym samym okresie Cloud Security Alliance odnotowuje dwa drobne CVE dla rdzenia Hermes Agent wobec dziewięciu dla OpenClaw, w tym jedno krytyczne. Różnicę czyta się z tą samą ostrożnością co resztę tego porównania: dla Hermes nie opublikowano równoważnego zestawienia narażenia.
Częste błędy
ports:, przetestowane tutaj: docker exec otrzymuje 200, to samo wywołanie z hosta nie otrzymuje żadnej odpowiedzi.API_SERVER_HOST=0.0.0.0, opublikowany port łączy się, ale zwraca pustą odpowiedź HTTP, nawet poza siecią internal.HERMES_DASHBOARD=1 bez dostawcy uwierzytelniania nie wyłącza jej po cichu: zawodzi i restartuje się w pętli pod s6.

