System Hermes Agent Memory: Jak w rzeczywistości działa trwała pamięć AI

Znasz to. Otwierasz czat z agentem AI, wyjaśniasz swój projekt, dzielisz się preferencjami, wykonujesz jakąś pracę i zamykasz kartę. Wracasz tydzień później i czujesz się, jakbyś rozmawiał z nieznajomym — cały kontekst zniknął, każda preferencja została zapomniana, a projekt trzeba tłumaczyć od nowa.

To nie jest błąd. Tak właśnie z założenia działają Duże Modele Językowe (LLM). Są bezstanowe (stateless): każde zapytanie jest niezależne, każda odpowiedź jest generowana na podstawie promptu, który wysyłasz w danej chwili, bez pamięci, historii i ciągłości wykraczającej poza tokeny w bieżącym oknie kontekstowym.

W przypadku pojedynczych interakcji to nie problem. Zadaj pytanie, otrzymaj odpowiedź i idź dalej. Ale w przypadku agentów — systemów, które mają robić rzeczy w różnych sesjach, uczyć się na błędach i ewoluować razem z Tobą — bezstanowość jest twardym ograniczeniem architektonicznym. To jeden z centralnych, nierozwiązanych problemów w systemach AI typu self-hosted.

Branża próbowała to rozwiązać. LangChain dodał moduły pamięci. OpenAI wprowadziło asystentów z wątkami (threads). Frameworki takie jak Letta, Zep i Cognee zbudowały całe architektury wokół pamięci trwałej. Databricks opublikowało prace na temat „skalowania pamięci” — idei, że wydajność agenta poprawia się wraz z kumulowanym doświadczeniem. Od 2024 roku pojawiły się dedykowane prace benchmarkowe, badania nad pamięcią epizodyczną oraz szybko rozwijający się ekosystem narzędzi, aby stawić czoła temu, co coraz powszechniej uznaje się za jeden z głównych problemów w dziedzinie agentic AI.

Większość tych podejść ma wspólny problem: traktują pamięć jako dodatek — bazę danych, którą odpytujesz, okno kontekstowe, którym próbujesz „zapchać” model, lub system wyszukiwania, który zamiast klarowności dodaje opóźnienia i szum.

Hermes Agent przyjmuje fundamentalnie inne podejście. Pamięć nie jest czymś, co agent pobiera w razie potrzeby. Jest czymś, czym agent jest przez cały czas — jest wbudowana w systemowy prompt, kuratowana, ograniczona i zawsze aktywna. Jest wystarczająco mała, by działać szybko, wystarczająco ustrukturyzowana, by być użyteczną, i wystarczająco zdyscyplinowana, by wiedzieć, co zapomnieć.

Ten artykuł wyjaśnia dokładnie, jak to działa.

Część 1: Problem pamięci agenta AI

Dlaczego „po prostu dodaj kontekst” nie skaluje się dla agentów

Oczywistym rozwiązaniem dla bezstanowego AI jest dodanie kontekstu. Dołącz poprzednią rozmowę. Dołącz dokumentację projektu. Wyślij całą historię.

Przez jakiś czas to działa. Masz okno kontekstowe o rozmiarze 128K. Możesz tam zmieścić mnóstwo tekstu.

Ale kontekst to nie pamięć — istnieje między nimi realna i ważna różnica. Kontekst to wszystko, co widzisz w tej chwili; pamięć to to, co aktywnie przechowujesz i niesiesz ze sobą dalej.

Kontekst nie podlega kurateli. To zrzut danych: wraz z jego wzrostem model musi przetwarzać tysiące tokenów nieistotnej historii, aby znaleźć jeden fakt, którego potrzebuje. To kosztuje tokeny i pieniądze, potęguje opóźnienia i ostatecznie uderza w sufit możliwości.

Pamięć jest kuratowana. To destylacja doświadczenia w coś zwartego i użytecznego. Nie rośnie w nieskończoność — konsoliduje się, aktualizuje i zapomina.

Ludzka pamięć działa w ten sam sposób. Nie pamiętasz każdej rozmowy, jaką kiedykolwiek odbyłeś. Pamiętasz te części, które są istotne: z kim rozmawiasz, co go interesuje, na co się zgodziliście, czego się nauczyłeś. Reszta jest albo zapomniana, albo przeszukuje się ją wtedy, gdy jest potrzebna.

Krajobraz badawczy

Przestrzeń pamięci agentów AI eksplodowała od 2024 roku, przynosząc dedykowane zestawy benchmarkowe, rosnącą literaturę badawczą i mierzalną lukę w wydajności między różnymi podejściami architektonicznymi. Oto jak wygląda obecna sytuacja.

Letta (dawniej MemGPT) była jednym z pierwszych frameworków traktujących pamięć trwałą jako priorytet, osiągając 21,7 tys. gwiazdek na GitHubie. Wykorzystuje model trójwarstwowy inspirowany systemami operacyjnymi: pamięć rdzeniową (mała, zawsze w kontekście), pamięć przywoływania (przeszukiwalna historia rozmów) oraz pamięć archiwalną (długoterminowa pamięć zimna). Wniosek, że nie wszystkie dane w pamięci są równe, był słuszny. Implementacja wymaga jednak, aby agenci działali w całości w środowisku uruchomieniowym Letta — przyjęcie jej oznacza przyjęcie całej platformy, a nie tylko warstwy pamięci.

Zep / Graphiti koncentruje się na pamięci konwersacyjnej z temporalnym śledzeniem encji — fakty posiadają okna ważności, dzięki czemu graf wie, kiedy coś było prawdą. Sprawdza się w chatbotach wymagających grafów relacji, ale jest mniej odpowiedni dla autonomicznych agentów śledzących fakty środowiskowe i konwencje projektowe.

Cognee jest zbudowany do ekstrakcji wiedzy z dokumentów i ustrukturyzowanych danych, oferując ponad 30 konektorów ingestii oraz backend oparty na grafie wiedzy. Doskonale radzi sobie z wiedzą instytucjonalną i potokami RAG, ale mniej skupia się na osobistej pamięci agenta. Więcej informacji w przewodniku po samodzielnym hostowaniu Cognee z lokalnymi modelami LLM.

Hindsight oferuje przywoływanie oparte na grafie wiedzy z relacjami encji oraz unikalne narzędzie syntezy reflect, które wykonuje syntezę między pamięciami — łączy wiele wspomnień w nowe spostrzeżenia. Należy do najlepszych rozwiązań w benchmarkach pamięci agentów i jest dostępny jako dostawca pamięci dla Hermes Agent.

Mem0 obsługuje ekstrakcję pamięci po stronie serwera poprzez analizę LLM, co wymaga minimalnej konfiguracji. Praca badawcza Mem0, opublikowana na ECAI 2025 (arXiv:2504.19413), porównała dziesięć różnych podejść do pamięci AI i potwierdziła skuteczność metody selektywnej ekstrakcji — przechowywania odrębnych faktów, deduplikacji i przywoływania tylko tego, co istotne. Mem0 urosło do około 48 tys. gwiazdek na GitHubie i wspiera 21 integracji z frameworkami. Kosztem jest zależność od chmury i koszty operacyjne.

Badania Databricks nad skalowaniem pamięci wprowadziły koncepcję, że wydajność agenta poprawia się wraz z kumulowanym doświadczeniem. Ich architektura przechowuje prompty systemowe, zasoby przedsiębiorstwa oraz pamięć epizodyczną/semantyczną w zakresie organizacji i użytkownika, co potwierdza ideę, że jakość pamięci jest równie ważna jak możliwości modelu.

Wspólnym mianownikiem większości frameworków jest traktowanie pamięci jako problemu wyszukiwania: zapisz ją gdzieś, zapytaj, gdy będzie potrzebna, wstrzyknij do kontekstu. Hermes robi coś przeciwnego — pamięć nie jest pobierana na żądanie, lecz wstrzykiwana na początku sesji i jest zawsze obecna. Zawsze aktywna, zawsze dostępna, wystarczająco kuratowana, by pozostać użyteczną.

Część 2: Architektura

Przeczytaj tę część od góry — najpierw warstwy i przywoływanie/zapis w turach, następnie to, co znajduje się w MEMORY.md i USER.md, a na końcu jak podłączyć zewnętrznego dostawcę.

Dwie warstwy

Hermes stosuje pamięć w dwóch warstwach:

1. Wbudowana — MEMORY.md i USER.md, oparte na plikach, zawsze aktywne. Sztywne limity to 2200 znaków (notatki agenta) oraz 1375 znaków (profil użytkownika).
2. Jeden zewnętrzny dostawca (opcjonalnie) — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory i inni, których włączysz w konfiguracji. W danym momencie działa tylko jeden zewnętrzny backend. Dodaje on funkcje wyszukiwania i retencji obok plików; nie zastępuje ich.

Model mentalny jest addytywny — stałe pliki rdzeniowe plus maksymalnie jeden plugin. Hooki prefetch i sync orchestrują warstwę zewnętrzną; dwa pliki wbudowane są wstrzykiwane oddzielnie jako część zamrożonego promptu systemowego.

Przepływ w czasie uruchomienia (prefetch i sync)

Przywoływanie (recall) następuje zanim model odpowie; trwałość (persistence) następuje po wiadomości asystenta. W managerze pamięci Hermes Agent przekłada się to na prefetch przy wejściu i sync przy wyjściu. Poniższe nazwy odpowiadają implementacji (MemoryManager, dla każdego dostawcy prefetch / sync_turn / queue_prefetch).

Wiadomość użytkownika
    |
    v
MemoryManager.prefetch_all(query)        <-- faza przywoływania (recall)
    |
    +-- provider.prefetch(query)        <-- każdy zewnętrzny dostawca przeszukuje swój magazyn
    |
    v
Kontekst wstrzykiwany do tury LLM
    |
    v
LLM odpowiada (wiadomość asystenta)
    |
    v
MemoryManager.sync_all(user, assistant)  <-- faza zapisu (store)
    |
    +-- provider.sync_turn(user, assistant)
    +-- provider.queue_prefetch(user)    <-- wyszukiwanie w tle przed kolejną turą

Wbudowane pliki MEMORY.md i USER.md nie są pobierane przez prefetch_all — są już częścią zamrożonego promptu systemowego. Zewnętrzne backendy podłączają się pod prefetch_all / sync_all; queue_prefetch pozwala dostawcy przygotować wyszukiwanie dla następnej tury bez blokowania bieżącej odpowiedzi.

Trzy ścieżki do pamięci długoterminowej

1. Wbudowane narzędzie memory. Model wywołuje memory z akcjami add, replace lub remove, gdy instrukcje wskazują, że coś powinno zostać zachowane — trwałe fakty, preferencje, poprawki, notatki środowiskowe. target='user' aktualizuje USER.md; target='memory' aktualizuje MEMORY.md. Przykład: memory(action='add', target='user', content='…').

2. Pasywna retencja u zewnętrznych dostawców. W każdej turze framework wywołuje ścieżkę synchronizacji dostawcy, dzięki czemu konwersacja może być dzielona na fragmenty, podsumowywana lub ekstrahowana bez konieczności nazywania każdego faktu przez model. Zachowanie różni się w zależności od backendu — na przykład Hindsight grupuje tury i wykonuje ustrukturyzowaną retencję z encjami i relacjami; Honcho przesyła dialog przez swój potok dialektyczny; stosy w stylu Mem0 i Supermemory pasywnie ekstrahują fakty z tur.

3. Narzędzia specyficzne dla dostawcy. Jeśli plugin je udostępnia, jawne zapisy, takie jak honcho_conclude, hindsight_retain lub honcho_profile, pozwalają na zapisywanie trwałych fragmentów danych na żądanie.

Automatyczne przywoływanie a narzędzia dostawcy

Pamięć rdzeniowa nie potrzebuje narzędzia do odczytu — znajduje się ona już w prompcie. Zewnętrzne backendy dodają albo automatyczną iniekcję z prefetch (bez osobnego wywołania narzędzia przy tej części kontekstu), albo jawne narzędzia wyszukiwania (honcho_search, honcho_reasoning, honcho_context, hindsight_recall, hindsight_reflect i inne), gdy model potrzebuje bardziej precyzyjnego zapytania niż samo prefetch.

Tryby przywoływania (zewnętrzni dostawcy)

Plugin wspiera konfigurowalny tryb przywoływania (zazwyczaj recall_mode obok memory.provider w konfiguracji), który pozwala handlować tokenami za kontrolę.

Gdy żaden zewnętrzny dostawca nie jest ustawiony (memory.provider jest pusty lub nieustawiony), stosowane są tylko wbudowane pliki i wyszukiwanie w sesji — bez prefetch/sync z pluginu.

Ścieżki na dysku i limity

Wbudowana pamięć Hermes Agent znajduje się w dwóch plikach.

• ~/.hermes/memories/MEMORY.md — Osobiste notatki agenta (2200 znaków, ok. 800 tokenów)
• ~/.hermes/memories/USER.md — Profil użytkownika (1375 znaków, ok. 500 tokenów)

To jest cała powierzchnia pamięci trwałej: dwa pliki, łącznie poniżej 3600 znaków, mniej niż 1300 tokenów. Wydaje się to celowo małe, ponieważ takie jest założenie projektowe.

MEMORY.md: Notatki agenta

Tutaj agent przechowuje wszystko, czego nauczy się o swoim środowisku, projekcie, narzędziach, konwencjach i wyciągniętych wnioskach. Wygląda to następująco:

User's project is a Go microservice at ~/code/gateway using gRPC + PostgreSQL
This machine runs Ubuntu 22.04, has Docker and kubectl installed
User prefers snake_case for variable names and avoids camelCase

To nie są logi. To fakty. Gęste, deklaratywne, nasycone informacjami. Bez znaczników czasu, bez zbędnych słów, bez „5 stycznia użytkownik poprosił mnie o…”.

USER.md: Profil użytkownika

Tutaj agent przechowuje wszystko, co wie o Tobie.

User is a full-stack developer comfortable with TypeScript, Go, and Python.
User prefers snake_case for variable names and avoids camelCase.
User primarily uses Linux Ubuntu 22.04.
User deploys to AWS using Terraform.

Tożsamość, rola, preferencje, umiejętności techniczne, styl komunikacji, irytujące kwestie. Rzeczy, które sprawiają, że agent odpowiada Ci inaczej niż komukolwiek innemu.

Wzorzec zamrożonego migawki (Frozen Snapshot)

Na początku sesji oba pliki są ładowane z dysku i wstrzykiwane jako zamrożony blok do promptu systemowego. Wygląda to tak:

══════════════════════════════════════════════
MEMORY (your personal notes) [7% — 166/2,200 chars]
══════════════════════════════════════════════
User's project is a Go microservice at ~/code/gateway using gRPC + PostgreSQL
§
This machine runs Ubuntu 22.04, has Docker and kubectl installed
§
User prefers snake_case for variable names and avoids camelCase
§

══════════════════════════════════════════════
USER PROFILE (who the user is) [8% — 110/1,375 chars]
══════════════════════════════════════════════
User is a full-stack developer comfortable with TypeScript, Go, and Python.
§
User prefers snake_case for variable names and avoids camelCase.
§

Format wykorzystuje nagłówki, procentowe zużycie, licznik znaków i separator § (znak sekcji). Wpisy mogą być wielolinijkowe. Zostało to zaprojektowane tak, aby model mógł je łatwo przetwarzać, zachowując jednocześnie czytelność dla człowieka.

Dlaczego zamrożone? Prefix caching. Prompt systemowy jest taki sam w każdej turze sesji. Dzięki zachowaniu statycznej pamięci po rozpoczęciu sesji, model może buforować obliczenia prefiksu i przetwarzać tylko zmienne części — czyli konwersację. Jest to znacząca optymalizacja wydajności. Nie przeliczasz mechanizmu uwagi (attention) nad tymi samymi tokenami pamięci w każdej turze.

Zmiany wprowadzone podczas sesji są zapisywane na dysku natychmiast, ale w prompcie systemowym pojawią się dopiero przy następnym uruchomieniu sesji. Odpowiedzi narzędzi zawsze pokazują aktualny stan, ale „umysł” modelu nie zmienia się w trakcie trwania sesji. Zapobiega to sytuacji, w której model „goni własny ogon” — aktualizuje pamięć, a następnie natychmiast reaguje na tę własną aktualizację w tej samej rozmowie.

Limity znaków jako funkcja

2200 znaków. 1375 znaków. To nie są przypadkowe limity. To ograniczenia projektowe, które wymuszają kuratelę.

Nieograniczona pamięć jest obciążeniem. Zachęca do wrzucania wszystkiego bez ładu i składu, nigdy do konsolidacji i ostatecznie zamieniania się w szum. Ograniczona pamięć zmusza agenta do selektywności. Co jest naprawdę ważne? Czego będę potrzebował ponownie? Co można skompresować bez utraty znaczenia?

Gdy pamięć jest pełna, agent nie zawodzi po cichu. Otrzymuje błąd zawierający obecne wpisy i stopień wykorzystania, a następnie postępuje zgodnie z procesem:

1. Odczytaj obecne wpisy z odpowiedzi o błędzie.
2. Zidentyfikuj wpisy, które można usunąć lub skonsolidować.
3. Użyj replace, aby połączyć powiązane wpisy w krótsze wersje.
4. Dodaj nowy wpis.

W ten sposób pamięć pozostaje użyteczna. To nie jest baza danych. To starannie dobrana kolekcja istotnych faktów.

Bezpieczeństwo: Skanowanie Prompt Injection

Każdy wpis w pamięci jest skanowany przed zaakceptowaniem. System blokuje próby prompt injection, eksfiltrację poświadczeń, backdoory SSH oraz niewidoczne znaki Unicode.

Pamięć jest również poddawana deduplikacji. Dokładne, powielone wpisy są automatycznie odrzucane. Zapobiega to próbom wstrzykiwania złośliwej zawartości poprzez wielokrotne przesyłanie tych samych danych.

Zewnętrzni dostawcy pamięci (aktywacja i linki)

Poza wbudowanymi plikami MEMORY.md i USER.md, Hermes Agent może podłączyć jeden zewnętrzny plugin pamięci naraz — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover lub Supermemory — w celu uzyskania trwałej wiedzy między sesjami. Tylko jeden zewnętrzny dostawca jest aktywny w danym czasie; dwa pliki rdzeniowe pozostają załadowane obok niego (metoda addytywna, a nie zastępcza).

Aktywuj i sprawdzaj dostawców za pomocą hermes memory setup, hermes memory status oraz hermes memory off, lub ustaw memory.provider i recall_mode w ~/.hermes/config.yaml. Wzorce poświadczeń różnią się (np. HINDSIGHT_API_KEY, klucze Honcho pod $HERMES_HOME/honcho.json); użyj hermes memory setup do interaktywnego łączenia.

Minimalny kształt YAML tylko dla wbudowanych funkcji:

memory:
  provider: ""
  memory_enabled: true
  user_profile_enabled: true

Przykład aktywacji dla jednego backendu (zamień hindsight na honcho, mem0, supermemory lub inne obsługiwane przez Twoją instalację):

memory:
  provider: "hindsight"

Aby zobaczyć pełną tabelę porównawczą, uwagi dotyczące zależności od LLM i embeddingów, szczegółowe opisy dostawców oraz informacje o tym, jak te backendy łączą się z OpenClaw i innymi stosami, sprawdź porównanie dostawców pamięci agentów.

W celu uzyskania informacji o konfiguracji pod profil użytkownika i procesach produkcyjnych, sprawdź konfigurację produkcyjną Hermes Agent. Centrum pamięci systemów AI zawiera ten przewodnik oraz powiązane artykuły o Cognee i warstwie wiedzy.

Część 3: Kiedy działa pamięć — Wyzwalacze i decyzje

Najczęstsze pytanie dotyczące pamięci Hermes Agent brzmi: kiedy on faktycznie coś zapisuje?

Odpowiedź brzmi: stale, ale selektywnie. Agent zarządza własną pamięcią za pomocą narzędzia memory, a decyzja o zapisaniu jest wynikiem kombinacji jawnych sygnałów i niejawnych wzorców.

Wyzwalacze zapisu: Kiedy agent decyduje się zapisać?

Agent zapisuje pamięć proaktywnie. Nie czeka, aż o to poprosisz. Oto co to wyzwala.

Poprawki użytkownika. Gdy poprawiasz agenta, jest to sygnał do zapamiętania. „Nie rób tego więcej”. „Użyj tego zamiast tego”. „Zapamiętaj to”. Są to jawne instrukcje aktualizacji pamięci.

Przykład: prosisz agenta o skonfigurowanie środowiska Python. On sugeruje pip. Mówisz: „Do wszystkiego używam poetry”. Agent zapisuje: User prefers using the 'poetry' package manager for all Python projects.

Odkryte preferencje. Agent obserwuje wzorce i wnioskuje o preferencjach. Jeśli konsekwentnie używasz konkretnego narzędzia, frameworku lub workflow, zostaje to zapisane.

Przykład: po zobaczeniu, jak wielokrotnie używasz poetry w różnych projektach, agent zapisuje to jako preferencję.

Fakty środowiskowe. Rzeczy dotyczące maszyny, projektu, zainstalowanych narzędzi. Są one odkrywane podczas eksploracji i zapisywane jako fakty.

Przykład: agent sprawdza, co jest zainstalowane i zapisuje: This machine runs Ubuntu 22.04, has Docker and kubectl installed.

Konwencje projektowe. Jak ustrukturyzowany jest projekt, jakich narzędzi używa, jakie wzorce stosuje. Są one odkrywane podczas analizy kodu i zapisywane.

Przykład: User's project is a Go microservice at ~/code/gateway using gRPC + PostgreSQL.

Zakończone złożone workflow. Po ukończeniu zadania, które wymagało więcej niż 5 wywołań narzędzi, agent rozważa zapisanie podejścia jako umiejętności lub przynajmniej odnotowanie, co zadziałało.

Dziwne zachowania narzędzi i obejścia (workarounds). Gdy agent odkryje coś nieoczywistego w narzędziu, API lub systemie — ograniczenie, obejście, konwencję — zapisuje to.

Co jest pomijane:

• Błahe lub oczywiste informacje
• Rzeczy, które łatwo odkryć ponownie
• Surowe zrzuty danych
• Efemeryczne dane specyficzne dla danej sesji
• Informacje już znajdujące się w plikach kontekstu (SOUL.md, AGENTS.md)

Wyzwalacze odczytu: Kiedy agent przywołuje pamięć?

Pamięć nie jest pobierana — ona zawsze tam jest. Ale istnieją różne poziomy dostępu.

Start sesji (automatycznie). Pliki MEMORY.md i USER.md są wstrzykiwane do promptu systemowego. Agent ma do nich dostęp od pierwszego tokenu. Nie jest potrzebne zapytanie, nie ma opóźnień, nie ma wywołań narzędzi. To jest pamięć rdzeniowa — zawsze aktywna.

session_search (na żądanie). Gdy agent musi znaleźć coś z przeszłych rozmów, czego nie ma w pamięci rdzeniowej, używa narzędzia session_search. Przeszukuje ono SQLite (~/.hermes.state.db) przy uży użyciu wyszukiwania pełnotekstowego FTS5 oraz podsumowania Gemini Flash. Użyj tego, gdy pytanie brzaje raczej „rozmawialiśmy o tym wcześniej”, a nie „zapamiętaj ten fakt na zawsze”.

Przykład: pytasz „Czy omawialiśmy sieciowanie Docker w zeszłym tygodniu?”. Agent przeszukuje historię sesji i zwraje podsumowanie odpowiedniej rozmowy.

Narzędzia zewnętrznych dostawców (gdy skonfigurowane). Gdy aktywny jest zewnętrzny dostawca pamięci, framework wykonuje również automatyczny krok prefetch przed każdą odpowiedzią (patrz Część 2). Dodatkowe narzędzia, takie jak honcho_search, hindsight_recall lub mem0_search, służą do celowanych wyszukiwań, gdy agent decyduje się na jawne pobranie danych — w zależności od recall_mode może być aktywna automatyczna iniekcja, narzędzia lub oba te rozwiązania.

Drzewo decyzyjne

Oto jak agent waży pytanie „czy warto to zapamiętać?”:

Czy to jest poprawka lub jawna instrukcja?
  TAK → Zapisz w pamięci
  NIE → Czy to jest preferencja lub wzorzec?
    TAK → Zapisz w profilu użytkownika
    NIE → Czy to jest fakt środowiskowy lub konwencja?
      TAK → Zapisz w pamięci
      NIE → Czy to jest łatwe do ponownego odkrycia?
        TAK → Pomiń
        NIE → Czy to jest specyficzne dla sesji?
          TAK → Pomiń
          NIE → Zapisz w pamięci

Agent nie analizuje tego zbyt długofalowo. Zapisuje proaktywnie, konsoliduje, gdy pamięć jest pełna, i ufa limitom znaków, aby utrzymać zwięzłość.

Część 4: Pamięć wewnętrzna a zewnętrzne bazy wiedzy

Tutaj często dochodzi do nieporozumień. Hermes Agent posiada pamięć wewnętrzną (MEMORY.md, USER.md, zewnętrzni dostawcy) oraz zewnętrzne bazy wiedzy (LLM Wiki, Obsidian, Notion, ArXiv, system plików), które pełnią całkowicie odmienne role. Jest to podobne do rozróżnienia między potokami generowania wspomaganego wyszukiwaniem (RAG) a pamięcią operacyjną agenta — wyszukiwanie zewnętrzne jest dobre do głębokiego sprawdzania wiedzy, a nie do przenoszenia tożsamości i preferencji. Pamięć wewnętrzna to mózg agenta — zawsze aktywny, kuratowany, niesiony przez każdą sesję. Zewnętrzne bazy wiedzy to jego biblioteka — ogromne zasoby referencyjne, do których zagląda na żądanie.

Rozróżnienie

Pamięć wewnętrzna (mózg):

• Mała, trwała, wstrzykiwana do promptu systemowego
• Zawiera: preferencje użytkownika, konwencje agenta, natychmiastowe lekcje
• Zawsze „w myślach” podczas rozmowy
• Kuratowana, ograniczona, aktywnie zarządzana
• Przykłady: MEMORY.md, USER.md, Honcho, Hindsight, Mem0

Zewnętrzne bazy wiedzy (biblioteka):

• Ogromne, służące wyłącznie jako punkt odniesienia, dostępne na żądanie
• Zawierają: dokumenty, prace naukowe, kod, notatki, bazy danych
• Dostęp do nich następuje za pomocą narzędzi w razie potrzeby
• Nie są „pamiętane” — są sprawdzane
• Przykłady: LLM Wiki, Obsidian, Notion, ArXiv, system plików, GitHub

Jak one się ze sobą łączą

Agent uzyskuje dostęp do zewnętrznych baz za pomocą narzędzi, gdy jest to potrzebne. On ich nie „pamięta” — on je sprawdza.

LLM Wiki (llm-wiki): Połączona Markdownowa baza wiedzy Karpathy’ego do budowania i odpytywania wiedzy domenowej. Agent używa umiejętności llm-wiki, aby ją czytać, przeszukiwać i odpytywać. To zasób referencyjny, nie pamięć.

Obsidian: Osobiste repozytoria notatek z dwukierunkowymi linkami. Agent używa umiejętności obsidian, aby czytać, przeszukiwać i tworzyć notatki. Obsidian jest częścią szerszego ekosystemu osobistego zarządzania wiedzą, z którego Hermes może korzystać jako z biblioteki.

Notion/Airtable: Ustrukturyzowane bazy danych i wiki dostępne przez API. Agent odpytuje je w razie potrzeby.

ArXiv: Repozytoria prac akademickich. Agent przeszukuje i ekstrahuje prace podczas badania tematu.

System plików: Kod projektu, dokumentacja, konfiguracje. Agent czyta pliki podczas pracy nad projektem.

Wzorzec destylacji

Oto kluczowa myśl: krytyczne spostrzeżenia z zewnętrznych baz mogą zostać zdestylowane do pamięci wewnętrznej.

Przykład: agent czyta na ArXiv pracę na temat skalowania pamięci dla agentów AI. Nie zapisuje całej pracy w pamięci. Zapisuje kluczowy wniosek: Memory scaling: agent performance improves with accumulated experience through user interaction and business context stored in memory.

Zasób zewnętrzny jest ogromny. Pamięć wewnętrzna to destylacja.

Kiedy czego używać

Pamięć wewnętrzną stosuj do:

• „Komu pomagam?”
• „Czego oni preferują?”
• „Czego właśnie się nauczyliśmy?”
• „Jaka jest konfiguracja projektu?”
• „Jakie narzędzia są dostępne?”

Zewnętrzne bazy wiedzy stosuj do:

• „Jakie są najnowsze badania na temat X?”
• „Co jest w dokumentacji mojego projektu?”
• „O czym rozmawialiśmy w zeszłym miesiącu?” | - „Jakie jest API dla tego serwisu?”
• „Jaka jest struktura kodu?”

Agent rozumie różnicę i używa każdego z nich odpowiednio — nie myli sprawdzenia dokumentu z przywoływaniem czegoś, czego nauczył się o Tobie i Twoim środowisku.

Część 5: Jak to działa w praktyce

Przyjrzyjmy się mechanice.

Narzędzie memory

Agent zarządza pamięcią za pomocą jednego narzędzia z trzema akcjami: add, replace, remove.

Nie ma akcji read — zawartość pamięci jest automatycznie wstrzykiwana do promptu systemowego. Agent nie musi jej czytać, ponieważ ona zawsze tam jest.

add — Dodaje nowy wpis.

memory(action="add", target="memory",
       content="User runs macOS 14 Sonoma, uses Homebrew, has Docker Desktop installed.")

replace — Zastępuje istniejący wpis przy użyciu dopasowania podciągu (substring).

memory(action="replace", target="memory",
       old_text="dark mode",
       content="User prefers light mode in VS Code, dark mode in terminal")

remove — Usuwa wpis przy użyciu dopasowania podciągu.

memory(action="remove", target="memory",
       old_text="temporary project fact")

Dopasowanie podciągu (Substring Matching)

replace i remove używają krótkich, unikalnych podciągów poprzez parametr old_text. Nie musisz podawać pełnego tekstu wpisu. Umożliwia to precyzyjne edycje bez konieczności znajomości dokładnej treści.

Jeśli podciąg się zgadza z wieloma wpisami, zwracany jest błąd z prośbą o bardziej specyficzne dopasowanie. Agent doprecyzowuje wtedy swoje zapytanie.

Magazyny docelowe: memory vs user

Parametr target określa, który plik zostanie zaktualizowany.

• memory — Osobiste notatki agenta. Fakty środowiskowe, konwencje projektowe, dziwne zachowania narzędzi, wyciągnięte lekcje.
• user — Profil użytkownika. Tożsamość, rola, strefa czasowa, preferencje komunikacyjne, irytujące kwestie, nawyki pracy.

Zarządzanie pojemnością

Gdy pamięć jest zapełniona w ponad 80%, agent dokonuje konsolidacji. Łączy powiązane wpisy, usuwa nieaktualne fakty i kompresuje informacje.

Dobre wpisy w pamięci są zwarte i nasycone informacjami:

User runs macOS 14 Sonoma, uses Homebrew, has Docker Desktop installed. Shell: zsh with oh-my-zsh. Editor: Neovim with Telescope plugin.

Złe wpisy są niejasne lub zbyt rozwlekłe:

User has a project.
On January 5th, 2026, the user asked me to look at their project which is located at ~/code/gateway and it uses Go with gRPC and PostgreSQL for the database layer.

Pierwszy jest gęsty i użyteczny. Drugi jest albo zbyt ogólny, albo zbyt gadatliwy.

Wyszukiwanie w sesji a pamięć trwała

session_search i pamięć trwała służą innym celom.

Zasada kciuka: używaj pamięci dla kluczowych faktów, które zawsze powinny być w kontekście. Używaj wyszukiwania w sesji do przeszukiwania historii.

Część 6: Filozofia

Dlaczego ograniczona pamięć wygrywa z nieograniczoną

Instynkt podpowiada, aby pamięć była jak największa. Zapisuj wszystko. Pobieraj to, czego potrzebujesz.

Ograniczona pamięć działa lepiej. Oto dlaczego.

Kuratela wymusza jakość. Gdy masz ograniczoną przestrzeń, zapisujesz tylko to, co istotne. Kompresujesz, konsolidujesz i nadajesz priorytety. Nieograniczona pamięć zachęca do wrzucania wszystkiego bez ładu i składu i nigdy do sprzątania.

Szybkość ma znaczenie. 1300 tokenów w prompcie systemowym działa szybko. 100 000 tokenów pobieranych z bazy danych działa wolno. Pamięć powinna być natychmiastowa, a nie być wynikiem zapytania.

Szum obniża wydajność. Więcej pamięci nie oznacza lepszą pamięć. Oznacza szumniejszą pamięć. Model musi odróżnić sygnał od szumu, a to wymaga uwagi — uwagi, która powinna być poświęcona właściwemu zadaniu.

Zapominanie to funkcja. Ludzka pamięć zapomina. To nie jest błąd — tak właśnie ustalamy priorytety. Agenci również powinni zapominać. Nie wszystko zasługuje na zapamiętanie.

Problem „zapominania”

Agenci muszą się „oduczać”. Nie tylko zapominać, ale aktywnie usuwać nieaktualne informacje.

Oto jak robi to Hermes Agent:

• akcja remove: Usuwanie wpisów, które nie są już istotne.
• akcja replace: Aktualizacja wpisów nowymi informacjami.
• Presja pojemności: Gdy pamięć jest pełna, agent konsoliduje i usuwa stare wpisy.
• Skanowanie bezpieczeństwa: Blokowanie złośliwych lub uszkodzonych wpisów.

Zapominanie to nie porażka — to konserwacja. Agent, który nie potrafi się oduczyć, w końcu będzie niósł ze sobą tyle samo szumu, co sygnału.

Skalowanie pamięci

Databricks wprowadziło koncepcję „skalowania pamięci”: czy agent z tysiącami użytkowników radzi sobie lepiej niż agent z jednym użytkownikiem?

Ich badania sugerują, że tak, ale z zastrzeżeniami. Skalowanie pamięci wymaga:

1. Jakościowej ekstrakcji: Nie każda interakcja jest warta zapamiętania. Agent musi wydobywać spostrzeżenia, a nie logi.
2. Skutecznego przywoływania: Przywołane wspomnienia muszą być istotne. Szum obniża wydajność.
3. Generalizacji: Wspomnienia powinny być wzorcami, a nie szczegółami. „User prefers Python” się skaluje. „User ran command X at timestamp Y” nie skaluje się.

Ograniczona pamięć Hermes Agent naturalnie wspiera skalowanie pamięci. Wymuszając kuratelę, zapewnia, że wspomnienia są możliwe do uogólnienia, zwarte i użyteczne.

Co to oznacza dla przyszłości

Pamięć staje się przewagą konkurencyjną w dziedzinie agentic AI — nie sam model, ale to, co model niesie między sesjami. Dwaj agenci o identycznych modelach bazowych mogą działać bardzo różnie: jeden pamięta Twoje preferencje, Twoje środowisko i Twoje przeszłe błędy; drugi za każdym razem zaczyna od zera.

Pytanie nie brz brzmi, czy agenci powinni mieć trwałą pamięć. To już rozstrzygnięte: muszą ją mieć. Otwarte pytanie brzmi, jak dobrze zaprojektować tę pamięć — co zachować, co odrzucić, jak sprawić, by była natychmiastowa i jak zapobiec jej zamianie w szum.

Odpowiedź Hermes Agent brzmi: trzymaj pamięć małą, kuratowaną i zawsze aktywną — nie jako bazę danych, którą odpytujesz, lecz jako pracujący model użytkownika, który agent niesie ze sobą do każdej rozmowy.

Podsumowanie

System pamięci Hermes Agent jest celowo prosty: dwa pliki, sztywne limity znaków, brak potoku wyszukiwania, brak bazy wektorowej i brak opóźnień przy każdym zapytaniu. To, co brzmi jak ograniczenie, jest właśnie głównym celem.

Działa, ponieważ traktuje pamięć tak, jak działa mózg, a nie jak baza danych — jako coś małego, kuratowanego i zawsze aktywnego. Agent nie pobiera pamięci, gdy jej potrzebuje; pamięć po prostu zawsze tam jest, wpleciona w prompt systemowy od pierwszego tokenu każdej sesji.

Zewnętrzni dostawcy pamięci rozszerzają ten system dla użytkowników, którzy potrzebują więcej: grafów wiedzy, wsparcia dla wielu agentów, przechowywania self-hosted czy funkcji klasy enterprise. Ale rdzeń pozostaje ten sam: ograniczony, kuratowany, zawsze dostępny.

A zewnętrzne bazy wiedzy — LLM Wiki, Obsidian, Notion, ArXiv — pełnią inną rolę. Są biblioteką, a nie mózgiem. Agent sprawdza je, a nie pamięta. Krytyczne spostrzeżenia są destylowane do pamięci wewnętrznej; reszta zostaje w bibliotece.

Tak właśnie agent AI zapamiętuje Ciebie. Nie poprzez przechowywanie wszystkiego, lecz poprzez pamiętanie tego, co istotne.

Hermes Agent został wydany przez Nous Research w lutym 2026 roku i do kwietnia 2026 roku (v0.9.0) zdobył ponad 64 000 gwiazdek na GitHubie, przy ponad 242 kontrybutorach. Jest oprogramowaniem open-source i jest dostępny pod adresem github.com/NousResearch/hermes-agent. Informacje o instalacji, konfiguracji i przewodnikach po workflow znajdziesz w przeglądzie Hermes Agent.