Mateusz Pilecki
Hermes Agent od Nous Research wygląda jak kolejny agent AI, dopóki nie zobaczysz różnicy. To nie tylko chat w terminalu. To runtime agenta, który ma pamiętać, uczyć się powtarzalnych procedur i działać tam, gdzie realnie pracujesz: w CLI, Telegramie, Discordzie, Slacku albo na VPS.
Najkrócej: Hermes próbuje zrobić z agenta AI nie jednorazowego asystenta, tylko system do dłuższej pracy cyfrowej. Brzmi ambitnie. Dlatego warto oddzielić hype od faktów.
Dlaczego wokół Hermes zrobiło się głośno
Do tematu wszedłem od dwóch stron: oficjalnej dokumentacji Nous Research i materiału NetworkChucka z 20 maja 2026. Film jest entuzjastyczny, ale dobrze pokazuje sygnał rynkowy: ludzie nie szukają już tylko modelu, który ładnie odpowiada. Szukają agenta, który zostaje na dłużej. To jest kierunek wdrożeń AI dla firm.
W dokumentacji Hermes nazywa się self-improving AI agent. W praktyce to trzy warstwy: pamięć, skille i bramka komunikacyjna. Model językowy jest mózgiem, a Hermes spina narzędzia, sesje, terminal, pliki, harmonogram, komunikatory, subagentów i zapis wiedzy.
To ma znaczenie, bo większość agentów AI po rozmowie mentalnie się resetuje. Można doklejać kontekst, ale po kilku tygodniach robi się śmietnik. Hermes próbuje rozwiązać to strukturalnie: oddziela fakty o użytkowniku, fakty o środowisku i procedury, które agent może załadować ponownie.
Co to jest Hermes Agent
Hermes Agent to open-source'owy agent od Nous Research, zespołu znanego z modeli Hermes, Nomos i Psyche. Ważne rozróżnienie: Hermes Agent nie jest jednym modelem. To system, który może brać różne modele i dostawców, m.in. Nous Portal, OpenRouter, OpenAI albo własny endpoint.
Z perspektywy firmy: Hermes nie musi siedzieć na laptopie. Dokumentacja opisuje VPS, Dockera, SSH, Modal, Daytonę, Singularity. Możesz pisać do agenta na Telegramie, kiedy on pracuje na zdalnym środowisku. Bliżej prywatnego operatora IT niż copilotowego okienka.
W repo widać, że to nie sam landing: gateway, skille, narzędzia, terminale, batch runner, API server, TUI, adaptery. Architektura kręci się wokół klasy AIAgent - 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 poziomy kontekstu. SOUL.md definiuje osobowość agenta. USER.md trzyma kluczowe info o użytkowniku. MEMORY.md - fakty operacyjne: serwery, konwencje projektu, poprawki, lekcje, stałe preferencje.
Dokumentacja podaje limity: około 2 200 znaków dla memory i 1 375 dla user. To nie wada. To wymusza gęsty zapis zamiast wklejania historii rozmów. Hermes ma zapisywać preferencje, fakty o środowisku, korekty i zakończone prace. Ma pomijać rzeczy oczywiste, tymczasowe albo łatwe do ponownego znalezienia.
Druga warstwa to session search. Sesje lądują w SQLite i są przeszukiwane przez FTS5. Nie wszystko musi iść do stałej pamięci. Agent odszuka starą rozmowę, gdy potrzebuje szczegółu, a Ty nie płacisz tokenami za całą przeszłość w każdym prompcie.
W materiale NetworkChucka widać, dlaczego to robi wrażenie. Agent, który pamięta styl pracy, serwery, narzędzia i decyzje z poprzednich dni, przestaje być tylko "narzędziem do odpowiedzi". Zaczyna być współpracownikiem od kontekstu. Pod warunkiem, że pamięć jest kuratowana. Zła pamięć jest gorsza niż brak pamięci.
Skille: proceduralna pamięć agenta
Drugi filar to skills system. Skille to dokumenty instrukcyjne ładowane na zadanie, zgodne z agentskills.io. Hermes może tworzyć i aktualizować własne skille przez skill_manage.
Kiedy? Po złożonym zadaniu, serii błędów, korekcie od użytkownika albo po odkryciu nietrywialnego workflow. Jeśli agent nauczy się, jak u Ciebie robić deploy, raport SEO, konkretne API albo diagnozować incydent, zapisuje to jako skill i używa następnym razem.
Tego elementu brakuje w większości automatyzacji AI. Nie chodzi tylko o mądrzejszy model. Chodzi o to, żeby organizacja nie gubiła lekcji z każdej iteracji. Dobry skill obniża koszt kolejnych zadań i ogranicza chaos.
Jest też ryzyko. Dokumentacja mówi wprost: katalogi skilli nie są granicą bezpieczeństwa. Jeśli Hermes może pisać w zewnętrznym katalogu skilli, może go zmienić. W firmie trzeba rozdzielić skille prywatne, zespołowe i tylko do odczytu. Inaczej agent zacznie "ulepszać" procedury, które powinien zatwierdzać człowiek.
Narzędzia, gateway i życie poza terminalem
Hermes ma rozbudowany system toolsets. Narzędzia w zestawach: pliki, terminal, web, przeglądarka, pamięć, skille, delegacja, cron, TTS, obraz, vision, Home Assistant, MCP i inne. Są presety platformowe: hermes-cli, hermes-telegram, hermes-discord, hermes-api-server.
Agent może mieć inne uprawnienia w terminalu, inne w Telegramie, inne w API. Dobry kierunek: w prywatnym CLI szerzej, na Discordzie zespołowym ostrzej.
Messaging Gateway to osobny powód, by Hermes był ciekawy. Dokumentacja wymienia Telegram, Discord, Slack, WhatsApp, Signal, SMS, Email, Home Assistant, Matrix, Mattermost, Microsoft Teams, LINE i kilka innych. Jeden proces gatewaya bierze wiadomości, trzyma sesje, odpala crony i oddaje odpowiedzi.
W praktyce zmienia to ergonomię. Nie musisz odpalać IDE, żeby zlecić sprawdzenie logów, raport albo zadanie cykliczne. Piszesz tam, gdzie i tak jesteś. Drobiazg, w codziennym użyciu duża różnica.
Jak wygląda użycie pokazane w filmie
NetworkChuck pokazuje typowy setup: instalacja Hermes, wybór modelu, backend terminala, bot Telegram, ograniczenie dostępu do konkretnych user ID, gateway jako usługa na VPS. Bez jednej magicznej sztuczki - składanie znanych klocków w sensowny system.
Pojawia się też idea: Hermes jako agent stale dostępny, nie tylko podczas sesji na laptopie. W materiale: Telegram, Home Assistant, skille do infrastruktury, subagenci i dashboard do profili, modeli oraz umiejętności.
Najbardziej praktyczny wniosek z filmu: wartość nie leży w tym, że agent "potrafi wszystko". Leży w tym, że można mu oddawać wąskie, powtarzalne obszary. Najpierw raport dzienny. Potem monitoring. Potem review PR. Potem skill do klienta, serwera albo repozytorium.
Bezpieczeństwo: tu trzeba być dorosłym
Agent z terminalem, plikami, przeglądarką, komunikatorami i API nie jest zabawką. Hermes ma sensowne zabezpieczenia: approval flow dla niebezpiecznych komend, allowlisty w gatewayu, parowanie DM, izolację kontenerową i filtrowanie zmiennych środowiskowych.
Przykład: w gatewayu bez allowlisty i bez trybu allow-all domyślnie nikt nie powinien mieć dostępu. W Telegramie TELEGRAM_ALLOWED_USERS, globalnie GATEWAY_ALLOWED_USERS. Na produkcję dokumentacja poleca backendy izolowane: Docker, Modal, Daytona.
To nie usuwa ryzyka. Daje narzędzia do jego kontroli. Lokalny terminal na hoście, pełne sekrety w env i dostęp do poczty to nie wada Hermesa - to zła architektura. Minimum: osobny user systemowy, kontener, ograniczone tokeny, sekrety tylko gdy trzeba, logowanie akcji i lista komend wymagających akceptacji.
Hermes kontra klasyczne copiloty i OpenClaw
Claude Code, Codex, Cursor i inne coding copilots są mocne, gdy siedzisz w repo i dowieziesz kod. Hermes celuje szerzej: ciągła praca operacyjna, komunikacja, automatyzacja. To nie zamiennik IDE. To warstwa nad narzędziami.
Porównania z OpenClaw pojawiają się naturalnie: oba projekty to osobiste agenty na własnej infrastrukturze, obsługiwane przez komunikatory. W narracji: OpenClaw mocniej kojarzy się z osobistym systemem operacyjnym i ekosystemem komunikacji, 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: potrzebujesz agenta, który głównie łączy kanały i działa jako operator, czy agenta, którego karmisz procedurami i firmowym stylem pracy? Jeśli to drugie, Hermes wygląda obiecująco.
Dla kogo Hermes ma sens
Dla software house'u, małego zespołu IT, freelancera, devopsa albo właściciela firmy tech Hermes jest ciekawy jako prywatny agent operacyjny. Może pilnować backlogu, generować raporty, przeszukiwać dokumentację, odpalać skrypty, robić research, audyty i trzymać wiedzę o projektach.
Dla firmy regulowanej, z danymi medycznymi, finansowymi albo wrażliwą pocztą, wdrożenie bez sandboxa to proszenie się o kłopoty. Najpierw proof of concept na izolowanym ś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: review wewnętrznych procedur. Trzeci: monitoring serwerów tylko do odczytu. Na końcu agent, który może ruszać 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 jednej sesji. Hermes jest projektowany jako długowieczny agent: pamięta kontekst, buduje procedury i działa przez CLI, Telegram, Discord czy Slack.
Czy Hermes Agent nadaje się do produkcji? Może być dobrym fundamentem do eksperymentów i automatyzacji, ale produkcja wymaga sandboxingu, limitów uprawnień, audytu narzędzi, kontroli sekretów, monitoringu kosztów i zatwierdzania działań wysokiego ryzyka.
Co z tego wynika dla MKM Labs
Czas na szczerość, bo sami przepuściliśmy Hermesa przez kilka dni realnych testów w MKM Labs. Nasz werdykt jest dwustronny: w jednych zadaniach to świetne narzędzie, w innych - przynajmniej na razie - kompletnie nie dowozi.
Tam, gdzie Hermes błyszczy, działa jak dobra multi-sekretarka. Świetnie ogarnia codzienne zadania: szybko odpowiada, sprawnie porusza się po naszym vaulcie w Obsidianie, pilnuje i segreguje dane, a dzięki sporej liczbie gotowych integracji MCP bez problemu wpina się w nasze kanały komunikacji. Do researchu, notatek, monitoringu i utrzymywania porządku w informacjach sprawdza się naprawdę dobrze.
Schody zaczynają się przy kodowaniu. Do programowania Hermes się nie nadaje - i nie tylko wtedy, gdy ma pisać kod sam. Nie sprawdził się nawet jako warstwa, która zleca kodowanie Claude Code czy Codexowi: za często gubi wątek. Przy naszej liczbie projektów nie mamy czasu, żeby go cierpliwie doszkalać do tej roli.
Najmocniej dał nam to odczuć paradoks z testów: kilka dni dochodziliśmy do momentu, w którym wydawało się, że jest dobrze i zaraz ruszy - a następnego dnia agent zapominał instrukcji i zaczynaliśmy od zera. Obietnica ciągłej pamięci przy złożonych, długich procesach jeszcze nie domyka się tak, jak byśmy chcieli.
Decyzja jest prosta: wrócimy do Hermesa, gdy dojrzeje albo gdy znajdziemy czas, żeby go porządnie wytrenować. Na dziś używamy go wyłącznie jako wewnętrzny CRM. Cyfrowa sekretarka do ogarniania firmy - tak. Inżynier czy menedżer kodu - jeszcze nie.
Stan na sierpień 2026: w MKM Labs Hermes zostaje na roli wewnętrznego CRM, nie na kodzie. Żeby nie wracać do zera po restarcie sesji, procedury zapisujemy w skillach w repozytorium, a nie w pamięci czatu. Notatki z Telegrama i porządki w Obsidianie mogą iść same. Zlecenie do Claude Code albo Codexu nadal wymaga człowieka w pętli, bo agent gubi wątek przy wielu projektach. Produkcja zostaje za zatwierdzeniem, tak jak w werdykcie wyżej.
Ź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.
Wróć do wszystkich artykułów