Hermes Agent od Nous Research to jeden z tych projektów, które wyglądają jak kolejny agent AI, dopóki nie zobaczysz, gdzie jest różnica. To nie jest tylko chat w terminalu. To runtime dla agenta, który ma pamiętać, uczyć się powtarzalnych procedur i działać tam, gdzie faktycznie pracujesz: w CLI, Telegramie, Discordzie, Slacku albo na serwerze VPS.
Najkrótsza wersja: Hermes próbuje zrobić z agenta AI nie jednorazowego asystenta, tylko długowieczny system operacyjny do pracy cyfrowej. Brzmi ambitnie. I właśnie dlatego warto oddzielić hype od konkretów.
Dlaczego wokół Hermes zrobiło się głośno
Do tematu podszedłem od dwóch stron: oficjalnej dokumentacji Nous Research i materiału NetworkChucka z 20 maja 2026. Film jest mocno entuzjastyczny, ale pokazuje ważny sygnał rynkowy: ludzie nie szukają już tylko modelu, który ładnie odpowiada. Szukają agenta, który zostaje z nimi na dłużej.
Hermes w dokumentacji przedstawia się jako self-improving AI agent. W praktyce chodzi o trzy warstwy: pamięć, skille i bramkę komunikacyjną. Model językowy jest mózgiem, ale Hermes jest uprzężą: daje narzędzia, sesje, terminal, pliki, harmonogram, komunikatory, subagentów i mechanizmy zapisywania wiedzy.
To ważne, bo większość agentów AI resetuje się mentalnie po rozmowie. Niby można doklejać kontekst, ale po kilku tygodniach pracy robi się z tego śmietnik. Hermes próbuje rozwiązać ten problem strukturalnie: oddziela fakty o użytkowniku, fakty o środowisku i procedury, które agent może ponownie załadować.
Co to jest Hermes Agent
Hermes Agent jest open-source'owym agentem od Nous Research, czyli zespołu znanego z modeli Hermes, Nomos i Psyche. To ważne rozróżnienie: Hermes Agent nie jest jednym modelem. To system, który może używać różnych modeli i dostawców, m.in. Nous Portal, OpenRouter, OpenAI albo własnego endpointu.
Z punktu widzenia firmy najciekawsze jest to, że Hermes nie musi siedzieć na laptopie. Dokumentacja opisuje uruchamianie na tanim VPS, backendach Docker, SSH, Modal, Daytona czy Singularity. Możesz rozmawiać z agentem przez Telegram, kiedy on wykonuje zadanie na zdalnym środowisku. To jest bliżej prywatnego operatora IT niż zwykłego copilotowego okienka.
W repozytorium widać też, że projekt nie jest tylko landingiem. Są katalogi dla gatewaya, skilli, narzędzi, terminali, batch runnera, API servera, TUI i adapterów. Architektura kręci się wokół klasy AIAgent, która składa prompt, wybiera providera, odpala narzędzia i zapisuje sesje w SQLite z FTS5.
Pamięć jest najważniejsza
Najmocniejszy pomysł w Hermes to pamięć. System rozdziela kilka poziomów kontekstu. SOUL.md definiuje osobowość agenta. USER.md trzyma najważniejsze informacje o użytkowniku. MEMORY.md trzyma fakty operacyjne: serwery, konwencje projektu, poprawki, lekcje i stałe preferencje.
Dokumentacja podaje konkretne limity: około 2 200 znaków dla memory i 1 375 znaków dla user. To nie jest wada. To wymusza gęsty, użyteczny zapis zamiast wklejania historii rozmów. Hermes ma zapisywać preferencje, fakty o środowisku, korekty od użytkownika i zakończone prace. Ma pomijać rzeczy oczywiste, tymczasowe albo łatwe do ponownego znalezienia.
Druga warstwa to session search. Sesje są zapisywane w SQLite i przeszukiwane przez FTS5. To rozwiązuje inny problem: nie wszystko musi trafić do stałej pamięci. Agent może odszukać dawną rozmowę, gdy potrzebuje szczegółu, ale nie płacisz tokenami za całą przeszłość w każdym promptcie.
W materiale NetworkChucka dobrze widać, dlaczego to robi wrażenie. Agent, który pamięta styl pracy, serwery, narzędzia i decyzje z poprzednich dni, przestaje być "narzędziem do odpowiedzi". Zaczyna być współpracownikiem od kontekstu. Ale pod jednym warunkiem: pamięć musi być kuratowana. Zła pamięć jest gorsza niż brak pamięci.
Skille: proceduralna pamięć agenta
Drugi filar to skills system. Skille są dokumentami instrukcyjnymi ładowanymi na zadanie, zgodnymi z otwartym standardem agentskills.io. Najbardziej interesujące jest to, że Hermes może tworzyć i aktualizować własne skille przez narzędzie skill_manage.
Kiedy? Po złożonym zadaniu, po serii błędów, po korekcie od użytkownika albo po odkryciu nietrywialnego workflow. Czyli jeśli agent nauczy się, jak w twojej firmie robić deploy, przygotować raport SEO, obsłużyć konkretne API albo diagnozować incydent, może zapisać ten proces jako skill i użyć go następnym razem.
To jest blisko tego, czego brakuje większości automatyzacji AI. Nie chodzi tylko o to, żeby model był mądrzejszy. Chodzi o to, żeby organizacja nie traciła lekcji z każdej iteracji. Skill jest małą instrukcją operacyjną. Jeśli jest dobrze napisana, zmniejsza koszt kolejnych zadań i ogranicza chaos.
Jest też ryzyko. Dokumentacja jasno mówi, że katalogi skilli nie są granicą bezpieczeństwa. Jeśli Hermes ma prawo pisać w zewnętrznym katalogu skilli, może go zmienić. W firmie trzeba więc rozdzielić skille prywatne, zespołowe i tylko do odczytu. Inaczej agent zacznie "ulepszać" procedury, które powinny być zatwierdzane przez człowieka.
Narzędzia, gateway i życie poza terminalem
Hermes ma rozbudowany system toolsets. Narzędzia są grupowane w zestawy: pliki, terminal, web, przeglądarka, pamięć, skille, delegacja, cron, TTS, obraz, vision, Home Assistant, MCP i inne. Są też presety platformowe, np. hermes-cli, hermes-telegram, hermes-discord czy hermes-api-server.
To oznacza, że agent może mieć inne uprawnienia w terminalu, inne w Telegramie, inne w API. I to jest dobry kierunek. Agent w prywatnym CLI może mieć szeroki dostęp. Agent na Discordzie zespołowym powinien mieć ostrzejsze granice.
Messaging Gateway to osobny powód, dla którego Hermes jest ciekawy. Oficjalna dokumentacja wymienia Telegram, Discord, Slack, WhatsApp, Signal, SMS, Email, Home Assistant, Matrix, Mattermost, Microsoft Teams, LINE i kilka innych platform. Jeden proces gatewaya odbiera wiadomości, trzyma sesje, odpala crony i dostarcza odpowiedzi.
W praktyce to zmienia ergonomię. Nie musisz odpalać IDE, żeby zlecić agentowi sprawdzenie logów, przygotowanie raportu albo uruchomienie zadania cyklicznego. Piszesz do niego tam, gdzie i tak pracujesz. To jest mały szczegół, ale w codziennym użyciu robi ogromną różnicę.
Jak wygląda użycie pokazane w filmie
W filmie NetworkChuck pokazuje typowy setup: instalacja Hermes, wybór modelu, konfiguracja backendu terminala, ustawienie Telegram bota, ograniczenie dostępu do konkretnych user ID i uruchomienie gatewaya jako usługi na VPS. Nie ma tu jednej magicznej sztuczki. Jest raczej składanie znanych klocków w sensowny system.
Pojawia się też ważna idea: Hermes jako agent, który może działać stale, a nie tylko podczas aktywnej sesji na laptopie. W materiale przewija się praca przez Telegram, Home Assistant, skille do infrastruktury, subagenci i dashboard do zarządzania profilami, modelami oraz umiejętnościami.
Najbardziej praktyczny wniosek z filmu: wartość nie leży w tym, że agent "potrafi wszystko". Wartość leży w tym, że można mu stopniowo oddawać wąskie, powtarzalne obszary pracy. Najpierw raport dzienny. Potem monitoring. Potem review PR. Potem wewnętrzny skill do klienta, serwera albo repozytorium.
Bezpieczeństwo: tu trzeba być dorosłym
Agent, który ma terminal, pliki, przeglądarkę, komunikatory i dostęp do API, nie jest zabawką. Hermes ma kilka sensownych zabezpieczeń: approval flow dla niebezpiecznych komend, allowlisty użytkowników w gatewayu, parowanie DM, izolację kontenerową i filtrowanie zmiennych środowiskowych.
Przykładowo w gatewayu, jeśli nie ustawisz allowlisty ani trybu allow-all, domyślnie nikt nie powinien mieć dostępu. W Telegramie można ustawić TELEGRAM_ALLOWED_USERS, a globalnie GATEWAY_ALLOWED_USERS. Dla produkcji dokumentacja rekomenduje backendy izolowane, takie jak Docker, Modal albo Daytona.
To nie usuwa ryzyka. To tylko daje narzędzia do jego kontrolowania. Jeśli dasz agentowi lokalny terminal na hoście, pełne sekrety w env i dostęp do poczty, to nie jest problem Hermesa. To jest problem architektury wdrożenia. Minimum to osobny user systemowy, kontener, ograniczone tokeny, brak sekretów bez potrzeby, logowanie akcji i lista komend wymagających akceptacji.
Hermes kontra klasyczne copiloty i OpenClaw
Claude Code, Codex, Cursor czy inne coding copilots są mocne, gdy siedzisz w repozytorium i chcesz dowieźć kod. Hermes celuje szerzej: ma być agentem do ciągłej pracy operacyjnej, komunikacji i automatyzacji. To nie jest zamiennik IDE. To warstwa nad narzędziami.
Porównania z OpenClaw pojawiają się naturalnie, bo oba projekty grają w kategorii osobistych agentów uruchamianych na własnej infrastrukturze i obsługiwanych przez komunikatory. Różnica w narracji jest taka: OpenClaw mocno kojarzy się z osobistym systemem operacyjnym i ekosystemem komunikacji, a Hermes stawia w centrum pętlę uczenia: pamięć, skille, sesje, ponowne użycie procedur.
Nie ma sensu ogłaszać zwycięzcy po jednym filmie. Sens ma pytanie praktyczne: czy potrzebujesz agenta, który głównie łączy kanały i działa jako operator, czy agenta, którego chcesz karmić procedurami i uczyć firmowego stylu pracy? Jeśli to drugie, Hermes wygląda bardzo obiecująco.
Dla kogo Hermes ma sens
Dla software house'u, małego zespołu IT, freelancera, devopsa albo właściciela firmy technicznej Hermes jest ciekawy jako prywatny agent operacyjny. Może pilnować backlogu, generować raporty, przeszukiwać dokumentację, wykonywać skrypty, robić research, odpalać audyty i utrzymywać wiedzę o projektach.
Dla firmy regulowanej, z danymi medycznymi, finansowymi albo wrażliwą pocztą, wdrożenie bez sandboxa byłoby proszeniem się o kłopoty. Najpierw proof of concept na odizolowanym środowisku. Potem wąski zakres. Potem audyt uprawnień. Dopiero później integracje z prawdziwymi systemami.
Najlepszy pierwszy use case? Agent do raportów i researchu. Drugi: agent do review wewnętrznych procedur. Trzeci: agent do monitoringu serwerów z uprawnieniami tylko do odczytu. Dopiero na końcu agent, który może zmieniać produkcję.
FAQ: Hermes Agent
Co to jest Hermes Agent? Hermes Agent to open-source runtime dla agentów AI od Nous Research. Łączy model językowy z pamięcią, skillami, narzędziami, gatewayem komunikacyjnym i uruchamianiem w kontrolowanym środowisku.
Czym Hermes różni się od zwykłego copilota? Zwykły copilot zwykle pomaga w pojedynczej sesji. Hermes jest projektowany jako długowieczny agent, który może zapamiętywać kontekst, budować procedury i działać przez kanały takie jak CLI, Telegram, Discord czy Slack.
Czy Hermes Agent nadaje się do produkcji? Hermes może być dobrym fundamentem do eksperymentów i automatyzacji, ale wdrożenie produkcyjne wymaga sandboxingu, limitów uprawnień, audytu narzędzi, kontroli sekretów, monitoringu kosztów i procesu zatwierdzania działań wysokiego ryzyka.
Co z tego wynika dla MKM Labs
Hermes Agent jest ważny nie dlatego, że ma ładny branding. Jest ważny, bo pokazuje kierunek: agent AI ma mieć pamięć, procedury i kanał komunikacji poza oknem chatu. Dla firm to jest przejście od "napisz mi maila" do "pilnuj tego procesu co tydzień i ucz się, jak robimy to u nas".
To jeszcze nie znaczy, że każda firma powinna jutro stawiać Hermesa na VPS. Ale każda firma, która myśli o automatyzacji AI, powinna już dziś projektować workflow tak, jakby agent miał pamiętać i doskonalić procedury. Inaczej za rok będzie miała dziesiątki promptów, setki półautomatyzacji i zero operacyjnej pamięci.
Najkrótszy werdykt: Hermes jest jednym z najciekawszych open-source'owych agentów AI, bo próbuje rozwiązać problem ciągłości pracy. Nie tylko "co model umie teraz", ale "czego agent nauczył się przez ostatnie tygodnie".
Źródła
Hermes Agent - oficjalna dokumentacja, NousResearch/hermes-agent na GitHubie, Persistent Memory, Skills System, Toolsets Reference, Messaging Gateway, Security, Nous Tool Gateway, NetworkChuck - you need to use Hermes RIGHT NOW.