System pamięci agenta Hermes: jak naprawdę działa trwała pamięć sztucznej inteligencji

Wiesz, jak to działa. Otwierasz czat z agentem AI, opisujesz swój projekt, dzielicz się preferencjami, wykonujesz pewne zadania i zamykasz kartę. Wraca się tydzień później, a rozmowa wygląda tak, jakbyś miał do czynienia z obcą osobą — cały kontekst zniknął, wszystkie preferencje zostały zapomniane, a projekt trzeba wyjaśnić od zera.

To nie jest błąd. Tak właśnie działają duże modele językowe (LLM) z założenia. Są bezstanowe: każde żądanie jest niezależne, a każda odpowiedź generowana jest na podstawie promptu wysłanego w danej chwili, bez pamięci, bez historii i bez ciągłości poza tokenami znajdującymi się w aktualnym oknie kontekstu.

W przypadku interakcji jednorazowych to nie problem. Zadajesz pytanie, otrzymujesz odpowiedź i przechodzisz dalej. Ale dla agentów — systemów, które mają wykonywać zadania przez sesje, uczyć się z błędów i ewoluować razem z Tobą — brak stanu jest twardym ograniczeniem architektonicznym. Jest to jeden z centralnych, nierozwiązanych problemów w samodzielnie hostowanych systemach AI.

Przemysł próbował to rozwiązać. LangChain dodał moduły pamięci. OpenAI wprowadziło asystentów z wątkami. Frameworki takie jak Letta, Zep i Cognee zbudowały całą architekturę wokół trwałej pamięci. Databricks opublikował materiały na temat „skalowania pamięci” — ideę, że wydajność agentów poprawia się wraz z gromadzonym doświadczeniem. Od 2024 roku powstały dedykowane papiery benchmarkowe, przeglądy pamięci epizodycznej oraz szybko rosnąca ekosystem narzędzi, aby zająć się tym, co coraz szerzej uznawane jest za jeden z centralnych, nierozwiązanych problemów w agencjalnej AI.

Większość tych podejść ma jeden wspólny problem: traktuje pamięć jako dodatek — bazę danych do zapytań, okno kontekstu do „wpychania” treści, system odzyskiwania, który dodaje opóźnienia i szum zamiast jasności.

Hermes Agent podejmuje fundamentalnie inną drogę. Pamięć to nie coś, co agent odzyskuje, gdy jest potrzebna. To coś, czym agent jest w każdej chwili — wbudowane w prompt systemowy, skurowane, ograniczone i zawsze aktywne. Jest wystarczająco mała, aby być szybką, wystarczająco zstrukturyzowana, aby być użyteczną, i wystarczająco dyscyplinowana, aby wiedzieć, co należy zapomnieć.

Ten artykuł wyjaśnia dokładnie, jak to działa — warstwę specyficzną dla Hermes w ramach modelu międzyframeworkowego w Systemach pamięci w asystentach AI oraz szerszy stos w Architekturze asystentów AI. W przypadku poleceń aktywacji i inspekcji (hermes memory, hermes dump, śledzenie dzienników), połącz to z Ściągną CLI Hermes Agent. Aby poznać uzupełniającą stronę „długoterminowej wiedzy” Hermes — wielokrotnego użytku procedury w SKILL.md, a nie skurowane pliki pamięci — zobacz Tworzenie umiejętności Hermes Agent — Struktura SKILL.md i najlepsze praktyki.

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

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

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

Pewien czas to działa. Masz okno kontekstu o rozmiarze 128K. Możesz zmieścić tam dużo tekstu.

Ale kontekst nie jest pamięcią — istnieje między nimi realna i ważna różnica. Kontekst to wszystko, co widzisz w danej chwili; pamięć to to, co aktywnie utrzymujesz i przenosisz dalej.

Kontekst nie ma kuracji. To wyładowisko: wraz ze wzrostem, model musi przetwarzać tysiące tokenów nieistotnej historii, aby znaleźć jeden potrzebny fakt. To kosztuje tokeny i pieniądze, zwiększa opóźnienia i ostatecznie uderza w limit.

Pamięć jest skurowana. To destylacja doświadczenia w coś zwartego i działającego. Nie rośnie nieskończenie — konsoliduje się, aktualizuje i zapomina.

Pamięć ludzka działa w ten sam sposób. Nie pamiętasz każdej rozmowy, jaką kiedykolwiek miałeś. Pamiętasz te części, które mają znaczenie: z kim rozmawiasz, co ich obchodzi, co ustaliliście, czego się nauczyłeś. Reszta jest albo zapomniana, albo dostępna do wyszukania, gdy jest potrzebna.

Krajobraz badań

Przestrzeń pamięci agentów AI eksplodowała od 2024 roku, z dedykowanymi pakietami benchmarkowymi, rosnącą literaturą badawczą i mierzalną luką wydajnościową między różnymi podejściami architektonicznymi. Oto, w którym miejscu sprawy się znajdują.

Letta (dawniej MemGPT) była jednym z pierwszych frameworków, które traktowały trwałą pamięć jako priorytet, osiągając 21,7 tysiąca gwiazdek na GitHubie. Używa inspirowanego systemem operacyjnym, trójpoziomowego modelu: pamięci rdzeniowej (mała, zawsze w kontekście), pamięci przywoływanej (wyszukiwalna historia rozmów) i pamięci archiwalnej (długoterminowe, zimne magazynowanie). Wgląd, że nie всяka pamięć jest równa, był poprawny. Implementacja wymaga jednak, aby agenci działali całkowicie wewnątrz środowiska wykonawczego Letta — jej adopcja oznacza przyjęcie całej platformy, a nie tylko warstwy pamięci.

Zep / Graphiti skupia się na pamięci konwersacyjnej ze śledzeniem encji czasowych — fakty mają okna ważności, więc graf wie, kiedy coś było prawdą. Jest silna dla chatbotów potrzebujących grafów relacji, mniej odpowiednia dla autonomicznych agentów śledzących fakty środowiskowe i konwencje projektowe.

Cognee jest zbudowany do ekstrakcji wiedzy z dokumentów i danych zstrukturyzowanych, z ponad 30 konektorami ingestii i backendem grafu wiedzy. Doskonale radzi sobie z wiedzą instytucjonalną i potokami RAG, ale mniej skupia się na osobistej pamięci agenta. Zobacz samodzielne hostowanie Cognee z lokalnymi LLM po praktyczny przewodnik konfiguracji.

Hindsight wykorzystuje odzyskiwanie oparte na grafach wiedzy z relacjami encji i unikalnym narzędziem syntezy reflect, które przeprowadza syntezę między-pamięciową — łącząc wiele pamięci w nowe wnioski. Jest jednym z najlepszych wyników 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, wymagając minimalnej konfiguracji. Artykuł badawczy Mem0, opublikowany na ECAI 2025 (arXiv:2504.19413), zbadał dziesięć różnych podejść do pamięci AI i potwierdził podejście selektywnej ekstrakcji — przechowywanie dyskretnych faktów, deduplikacja i odzyskiwanie tylko tego, co jest istotne. Mem0 wzrósł do około 48 tysięcy gwiazdek na GitHubie i obsługuje 21 integracji frameworkowych. Kompromisem jest zależność od chmury i koszty.

Badania Databricks nad skalowaniem pamięci wprowadziły koncepcję, że wydajność agentów poprawia się wraz z gromadzonym doświadczeniem. Ich architektura utrzymuje prompty systemowe, zasoby przedsiębiorcze oraz pamięci epizodyczne/semantyczne zakresowane na poziomie organizacji i użytkownika, potwierdzając ideę, że jakość pamięci ma tak samo znaczenie, jak zdolność modelu.

Wspólnym wątkiem większości frameworków jest traktowanie pamięci jako problemu odzyskiwania: przechowuj ją gdzieś, zapytaj, gdy jest potrzebna, wstrzyknij do kontekstu. Hermes robi dokładnie odwrotnie — pamięć nie jest odzyskiwana na żądanie, jest wstrzykiwana na początku sesji i zawsze obecna. Zawsze aktywna, zawsze dostępna, wystarczająco skurowana, aby pozostać użyteczna.

Część 2: Architektura

Przeczytaj tę część od góry do dołu — warstwy i przywoływanie/przechowywanie na turę najpierw, następnie co znajduje się w MEMORY.md i USER.md, a na końcu jak podłączyć zewnętrzny dostawca.

Dwie warstwy

Hermes stosuje pamięć w dwóch warstwach:

1. Wbudowana — MEMORY.md i USER.md, oparta na plikach, zawsze aktywna. Twarde limity to 2200 znaków (notatki agenta) i 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łączasz przez konfigurację. Tylko jeden zewnętrzny backend działa na raz. Dodaje on odzyskiwanie i retencję obok plików; nie zastępuje ich.

Model mentalny jest addytywny — zamrożone pliki rdzeniowe plus co najwyżej jeden wtyczka. Haczyki prefetch i sync orkiestrują zewnętrzną warstwę; dwa pliki pozostają wstrzykiwane osobno jako część zamrożonego promptu systemowego.

Przepływ w czasie działania (prefetch i sync)

Przywoływanie dzieje się przed odpowiedzią modelu; utrwalanie następuje po wiadomości asystenta. W menedżerze pamięci Hermes Agent odpowiada to prefetch przy wchodzeniu i sync przy wychodzeniu. Poniższe nazwy odpowiadają powierzchni implementacji (MemoryManager, prefetch / sync_turn / queue_prefetch dostawcy).

Wiadomość użytkownika
    |
    v
MemoryManager.prefetch_all(zapytanie)        <-- faza odzyskiwania
    |
    +-- provider.prefetch(zapytanie)        <-- każdy zewnętrzny dostawca przeszukuje swoje repozytorium
    |
    v
Kontekst wstrzyknięty do tury LLM
    |
    v
LLM odpowiada (wiadomość asystenta)
    |
    v
MemoryManager.sync_all(użytkownik, asystent)  <-- faza przechowywania
    |
    +-- provider.sync_turn(użytkownik, asystent)
    +-- provider.queue_prefetch(użytkownik)    <-- przeszukiwanie w tle w kierunku następnej tury

Wbudowane MEMORY.md i USER.md nie są pobierane przez prefetch_all — są już częścią zamrożonego promptu systemowego. Zewnętrzne bazy danych podłączają się do prefetch_all / sync_all; queue_prefetch pozwala dostawcy ogrzać odzyskiwanie dla następnej tury bez blokowania aktualnej odpowiedzi.

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

1. Wbudowane narzędzie memory. Model wywołuje memory z add, replace lub remove, gdy instrukcje mówią, że coś powinno zostać utrwalone — trwałe fakty, preferencje, korekty, notatki środowiskowe. target='user' utrzymuje USER.md; target='memory' utrzymuje MEMORY.md. Przykładowy kształt: memory(action='add', target='user', content='…').

2. Pasywna retencja na zewnętrznych dostawcach. Każdą turę framework wywołuje ścieżkę sync dostawcy, więc rozmowa może być dzielenia, 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 uruchamia zstrukturyzowaną retencję z encjami i relacjami; Honcho przesyła dialog przez swój potok dialektyczny; stosy w stylu Mem0 i Supermemory ekstrahują fakty pasywnie z tur.

3. Narzędzia specyficzne dla dostawcy. Gdy wtyczka je udostępnia, jawne zapisy takie jak honcho_conclude, hindsight_retain lub honcho_profile przechowują trwałe fragmenty na żądanie.

Automatyczne odzyskiwanie w przeciwieństwie do narzędzi dostawcy

Pamięć rdzeniowa nie potrzebuje narzędzia do odczytu — jest już w prompcie. Zewnętrzne bazy danych dodają albo automatyczne wstrzykiwanie z prefetch (brak osobnego wywołania narzędzia odzyskiwania dla tej części kontekstu), albo jawne narzędzia odzyskiwania (honcho_search, honcho_reasoning, honcho_context, hindsight_recall, hindsight_reflect i inni), gdy model potrzebuje ostrzejszego zapytania niż sam prefetch.

Tryby odzyskiwania (zewnętrzni dostawcy)

Wtyczki obsługują konfigurowalny tryb odzyskiwania (zazwyczaj recall_mode obok memory.provider w konfiguracji), który wymienia tokeny na kontrolę.

Gdy nie jest ustawiony żaden zewnętrzny dostawca (memory.provider pusty lub nieustawiony), stosują się tylko wbudowane pliki i wyszukiwanie sesji — brak prefetch/sync z wtyczki.

Ścieżki na dysku i budżety

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

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

To cała powierzchnia trwałej pamięci: dwa pliki, mniej niż 3600 znaków łącznie, mniej niż 1300 tokenów. Wygląda to celowo mało, bo tak jest — i to dokładnie jest intencją projektową.

MEMORY.md: Notatki agenta

Tutaj agent przechowuje wszystko, czego się uczy na temat swojego środowiska, projektu, narzędzi, konwencji i wyciągniętych wniosków. Oto jak to wygląda:

Projekt użytkownika to mikrousługa Go w ~/code/gateway używająca gRPC + PostgreSQL
Ten komputer uruchamia Ubuntu 22.04, ma zainstalowane Docker i kubectl
Użytkownik preferuje snake_case dla nazw zmiennych i unika camelCase

To nie są dzienniki. To fakty. Gęste, deklaracyjne, pełne informacji. 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.

Użytkownik to full-stack developer zaznajomiony z TypeScript, Go i Python.
Użytkownik preferuje snake_case dla nazw zmiennych i unika camelCase.
Użytkownik głównie używa Linux Ubuntu 22.04.
Użytkownik wdraża do AWS używając Terraform.

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

Wzór zamrożonego snapshotu

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

══════════════════════════════════════════════
MEMORY (twoje osobiste notatki) [7% — 166/2200 znaków]
══════════════════════════════════════════════
Projekt użytkownika to mikrousługa Go w ~/code/gateway używająca gRPC + PostgreSQL
§
Ten komputer uruchamia Ubuntu 22.04, ma zainstalowane Docker i kubectl
§
Użytkownik preferuje snake_case dla nazw zmiennych i unika camelCase
§

══════════════════════════════════════════════
PROFIL UŻYTKOWNIKA (kim jest użytkownik) [8% — 110/1375 znaków]
══════════════════════════════════════════════
Użytkownik to full-stack developer zaznajomiony z TypeScript, Go i Python.
§
Użytkownik preferuje snake_case dla nazw zmiennych i unika camelCase.
§

Format używa nagłówków, procentów użycia, liczb znaków i separatorów § (znak sekcji). Wpis mogą być wieloliniowe. Zostało to zaprojektowane tak, aby było parsowalne przez model, pozostając jednocześnie czytelne dla człowieka.

Dlaczego zamrożone? Cache prefiksów. Prompt systemowy jest taki sam przez każdą turę w sesji. Dzięki utrzymaniu pamięci statycznej po rozpoczęciu sesji, model może buforować obliczenia prefiksu i przetwarzać tylko zmienne części — rozmowę. To znacząca optymalizacja wydajności. Nie przeliczasz uwagi nad tymi samymi tokenami pamięci w każdej turze.

Zmiany wprowadzone podczas sesji są natychmiastowo utrwalane na dysku, ale pojawiają się w prompcie systemowym dopiero na początku następnej sesji. Odpowiedzi narzędzi zawsze pokazują aktualny stan, ale „umysł” modelu nie zmienia się w trakcie sesji. Zapobiega to modelowi ściganiu własnego ogona — aktualizowaniu pamięci, a następnie reagowaniu na własną aktualizację w tej samej rozmowie.

Limity znaków jako cecha

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

Nielimitowana pamięć jest wadą. Zachęca do wpychania wszystkiego, nigdy do konsolidacji i ostatecznie staje się szumem. Ograniczona pamięć zmusza agenta do bycia selektywnym. 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 cicho. Otrzymuje błąd z aktualnymi wpisami i użyciem, a następnie podąża za przepływem pracy:

1. Przeczytaj aktualne wpisy z odpowiedzi błędu
2. Zidentyfikuj wpisy do usunięcia lub skonsolidowania
3. Użyj replace, aby połączyć powiązane wpisy w krótsze wersje
4. Dodaj nowy wpis

Tak pamięć pozostaje użyteczna. To nie jest baza danych. To skurana kolekcja faktów, które mają znaczenie.

Bezpieczeństwo: Skanowanie wstrzykiwania promptu

Każdy wpis do pamięci jest skanowany przed akceptacją. System blokuje próby wstrzykiwania promptu, wykradania poświadczeń, backdoorów SSH i niewidzialnych znaków Unicode.

Pamięć jest również deduplikowana. Dokładne zduplikowane wpisy są automatycznie odrzucane. Zapobiega to próbom wstrzykiwania złośliwej treści przez powtarzane zgłoszenia.

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

Poza wbudowanymi MEMORY.md i USER.md, Hermes Agent może podłączyć jeden zewnętrzny plugin pamięci na raz — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover lub Supermemory — w celu trwałej, między-sesyjnej wiedzy. Tylko jeden zewnętrzny dostawca jest aktywny naraz; dwa rdzeniowe pliki pozostają załadowane obok niego (addytywnie, nie zastępując).

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

Minimalny kształt YAML tylko z wbudowanym:

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

Przykładowa aktywacja dla jednego backendu (zamień hindsight na honcho, mem0, supermemory lub inne, które obsługuje Twoja instalacja):

memory:
  provider: "hindsight"

Aby zobaczyć pełną tabelę porównawczą, uwagi dotyczące zależności LLM i embeddingi, podziały dostawców oraz jak te bazy danych odnoszą się do OpenClaw i innych stosów, zobacz Dostawcy pamięci agentów porównani.

Aby zobaczyć okablowanie specyficzne dla profilu i przepływy pracy produkcyjne, zobacz Konfiguracja produkcyjna Hermes Agent. Centrum pamięci systemów AI wymienia ten przewodnik wraz z powiązanymi artykułami Cognee i warstwy wiedzy.

Część 3: Gdy pamięć się aktywuje — Wyzwalacze i decyzje

Najczęstszym pytaniem o pamięć Hermes Agent jest, kiedy naprawdę coś zapisuje.

Odpowiedź brzmi: stale, ale selektywnie. Agent zarządza własną pamięcią poprzez narzędzie memory, a decyzja o zapisie jest napędzana kombinacją jawnych sygnałów i implikitywnych wzorców.

Wyzwalacze zapisu: Kiedy agent decyduje się zapisać?

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

Korekty użytkownika. Gdy korygujesz agenta, to sygnał, żeby zapamiętać. „Nie rób tego ponownie.” „Użyj tego zamiast tego.” „Zapamiętaj to.” To jawne instrukcje do aktualizacji pamięci.

Przykład: prosisz agenta o skonfigurowanie środowiska Python. Sugeruje pip. Mówisz: „Używam poetry do wszystkiego.” Agent zapisuje: Użytkownik preferuje używanie menedżera pakietów 'poetry' do wszystkich projektów Python.

Odkryte preferencje. Agent obserwuje wzorce i wnioskuje preferencje. Jeśli stale używasz określonego narzędzia, frameworku lub przepływu pracy, zostaje to zapisane.

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

Fakty środowiskowe. Rzeczy o maszynie, projekcie, zainstalowanych narzędziach. Są one odkrywane poprzez eksplorację i zapisywane jako fakty.

Przykład: agent sprawdza, co jest zainstalowane i zapisuje: Ten komputer uruchamia Ubuntu 22.04, ma zainstalowane Docker i kubectl.

Konwencje projektowe. Jak projekt jest zbudowany, jakie narzędzia używa, jakie wzorce podąża. Są one odkrywane poprzez inspekcję kodu i zapisywane.

Przykład: Projekt użytkownika to mikrousługa Go w ~/code/gateway używająca gRPC + PostgreSQL.

Ukończone złożone przepływy pracy. Po ukończeniu zadania, które wymagało 5+ wywołań narzędzi, agent rozważa zapisanie podejścia jako umiejętności lub co najmniej notowanie tego, co zadziałało.

Ciekawostki narzędzi i obejścia. Gdy agent odkrywa coś nieoczywistego o narzędziu, API lub systemie — ograniczenie, obejście, konwencję — zapisuje to.

Co jest pomijane:

• Trywialne lub oczywiste informacje
• Rzeczy łatwo ponownie odkrywalne
• Surowe wyładowania danych
• Ephemera specyficzne dla sesji
• Informacje już w plikach kontekstowych (SOUL.md, AGENTS.md)

Wyzwalacze odczytu: Kiedy agent przywołuje?

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

Początek sesji (automatycznie). MEMORY.md i USER.md są wstrzykiwane do promptu systemowego. Agent ma je od pierwszego tokena. Brak zapytania, brak opóźnień, brak wywołania narzędzia. To jest pamięć rdzeniowa — zawsze aktywna.

session_search (na żądanie). Gdy agent musi znaleźć coś z poprzednich rozmów, czego nie ma w pamięci rdzeniowej, używa narzędzia session_search. To zapytuje SQLite (~/.hermes/state.db) z pełnotekstowym wyszukiwaniem FTS5 i podsumowaniem Gemini Flash. Użyj tego, gdy pytanie brzmi jak „rozmawialiśmy o tym wcześniej”, a nie „zapamiętaj ten факт na zawsze”.

Przykład: pytasz: „Czy dyskutowaliśmy o sieciowaniu Docker w zeszłym tygodniu?” Agent przeszukuje historię sesji i zwraca podsumowanie odpowiedniej rozmowy.

Narzędzia zewnętrznych dostawców (gdy skonfigurowane). Gdy zewnętrzny dostawca pamięci jest aktywny, framework uruchamia również automatyczny krok prefetch przed każdą odpowiedzią (zobacz Część 2). Dodatkowe narzędzia takie jak honcho_search, hindsight_recall lub mem0_search służą do celowych wyszukiwań, gdy agent wybiera jawne odzyskiwanie — w zależności od recall_mode, aktywne mogą być automatyczne wstrzykiwanie, narzędzia lub oba.

Drzewo decyzyjne

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

Czy to korekta lub jawna instrukcja?
  TAK → Zapisz do pamięci
  NIE → Czy to preferencja lub wzorzec?
    TAK → Zapisz do profilu użytkownika
    NIE → Czy to fakt środowiskowy lub konwencja?
      TAK → Zapisz do pamięci
      NIE → Czy to łatwo ponownie odkrywalne?
        TAK → Pomijaj
        NIE → Czy to specyficzne dla sesji?
          TAK → Pomijaj
          NIE → Zapisz do pamięci

Agent nie nadmyśla tego. Zapisuje proaktywnie, konsoliduje, gdy jest pełna, i ufa limitom znaków, aby utrzymać rzeczy zwartymi.

Część 4: Wewnętrzna pamięć w przeciwieństwie do zewnętrznych baz wiedzy

Tutaj często pojawia się zamieszanie. Hermes Agent ma wewnętrzną pamięć (MEMORY.md, USER.md, zewnętrzni dostawcy) i zewnętrzne bazy wiedzy (LLM Wiki, Obsidian, Notion, ArXiv, system plików), a pełnią one całkowicie różne role. Jest to podobne do rozróżnienia między generowaniem wzbogaconym odzyskiwaniem a pamięcią roboczą agenta — zewnętrzne odzyskiwanie jest dobre do głębokich wyszukiwań wiedzy, nie do przenoszenia tożsamości i preferencji. Wewnętrzna pamięć to mózg agenta — zawsze aktywna, skurana, przenoszona do każdej sesji. Zewnętrzne bazy wiedzy to jego biblioteka — ogromne zasoby referencyjne konsultowane na żądanie.

Rozróżnienie

Wewnętrzna pamięć (mózg):

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

Zewnętrzne bazy wiedzy (biblioteka):

• Ogromne, tylko referencyjne, dostępne na żądanie
• Zawiera: dokumenty, artykuły, kod, notatki, bazy danych
• Dostępne poprzez narzędzia, gdy są potrzebne
• Nie „zapamiętywane” — wyszukiwane
• Przykłady: LLM Wiki, Obsidian, Notion, ArXiv, system plików, GitHub

Jak się do siebie odnoszą

Agent dostaje się do zewnętrznych baz poprzez narzędzia, gdy są potrzebne. Nie je „zapamiętuje” — je wyszukuje.

LLM Wiki (llm-wiki): Połączona w Markdown baza wiedzy Karpathego do budowania i zapytywania wiedzy dziedzinowej. Agent używa umiejętności llm-wiki do czytania, wyszukiwania i zapytywania. To zasób referencyjny, nie pamięć.

Obsidian: Osobiste skrzynie notatek z dwukierunkowymi linkami. Agent używa umiejętności obsidian do czytania, wyszukiwania i tworzenia notatek. Obsidian jest częścią szerszego ekosystemu osobistego zarządzania wiedzą, do którego Hermes może sięgnąć jako do zasobu bibliotecznego.

Notion/Airtable: Zstrukturyzowane bazy danych i wiki dostępne przez API. Agent zapytuje je, gdy są potrzebne.

ArXiv: Repozytoria artykułów akademickich. Agent wyszukuje i ekstrahuje artykuły podczas badania tematu.

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

Wzór destylacji

Oto kluczowy wgląd: kluczowe wnioski z zewnętrznych baz mogą być destylowane do wewnętrznej pamięci.

Przykład: agent czyta artykuł z ArXiv o skalowaniu pamięci dla agentów AI. Nie zapisuje całego artykułu do pamięci. Zapisuje kluczowy wniosek: Skalowanie pamięci: wydajność agentów poprawia się wraz z gromadzonym doświadczeniem poprzez interakcję z użytkownikiem i kontekst biznesowy przechowywany w pamięci.

Zewnętrzny zasób jest ogromny. Wewnętrzna pamięć to destylacja.

Kiedy używać czego

Wewnętrzna pamięć dla:

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

Zewnętrzne bazy wiedzy dla:

• „Jaka jest najnowsza badawcza wiedza na temat X?”
• „Co jest w dokumentacji mojego projektu?”
• „O czym dyskutowaliśmy w zeszłym miesiącu?”
• „Jaki jest API dla tej usługi?”
• „Jaka jest struktura kodu?”

Agent rozumie różnicę i używa każdego odpowiednio — nie utożsamia wyszukiwania dokumentu z przywołaniem czegoś, czego się nauczył o Tobie i Twoim środowisku.

Część 5: Jak to naprawdę działa

Spójrzmy na mechanikę.

Narzędzie memory

Agent zarządza pamięcią poprzez jedno narzędzie z trzema akcjami: add, replace, remove.

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

add — Dodaje nowy wpis.

memory(action="add", target="memory",
       content="Użytkownik uruchamia macOS 14 Sonoma, używa Homebrew, ma zainstalowane Docker Desktop.")

replace — Zastępuje istniejący wpis używając dopasowania podciągów.

memory(action="replace", target="memory",
       old_text="dark mode",
       content="Użytkownik preferuje light mode w VS Code, dark mode w terminalu")

remove — Usuwa wpis używając dopasowania podciągów.

memory(action="remove", target="memory",
       old_text="tymczasowy fakt projektu")

Dopasowanie podciągów

replace i remove używają krótkich, unikalnych podciągów przez old_text. Nie potrzebujesz pełnego tekstu wpisu. To umożliwia chirurgiczne edycje bez znajomości dokładnej zawartości.

Jeśli podciąg pasuje do wielu wpisów, zwracany jest błąd żądający bardziej specyficznej dopasowania. Agent następnie udoskonala swoje zapytanie.

Sklepy docelowe: memory vs user

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

• memory — Osobiste notatki agenta. Fakty środowiskowe, konwencje projektowe, ciekawostki narzędzi, wnioski.
• user — Profil użytkownika. Tożsamość, rola, strefa czasowa, preferencje komunikacyjne, irytujące zwyczaje, nawyki przepływu pracy.

Zarządzanie pojemnością

Gdy pamięć jest >80% pełna, agent konsoliduje. Łączy powiązane wpisy, usuwa przestarzałe fakty i kompresuje informacje.

Dobre wpisy pamięci są zwarte i gęste informacyjnie:

Użytkownik uruchamia macOS 14 Sonoma, używa Homebrew, ma zainstalowane Docker Desktop. Shell: zsh z oh-my-zsh. Edytor: Neovim z wtyczką Telescope.

Złe wpisy pamięci są niejasne lub zbytnie rozwlekłe:

Użytkownik ma projekt.
5 stycznia 2026 roku użytkownik poprosił mnie o sprawdzenie swojego projektu, który znajduje się w ~/code/gateway i używa Go z gRPC oraz PostgreSQL dla warstwy bazy danych.

Pierwszy jest gęsty i użyteczny. Drugi jest albo zbyt niejasny, albo zbyt rozwlekły.

Wyszukiwanie sesji w przeciwieństwie do trwałej pamięci

session_search i trwała pamięć służą różnym celom.

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

Część 6: Filozofia

Dlaczego ograniczona pamięć wygrywa z nielimitowaną

Instynkt mówi, aby uczynić pamięć jak największą. Przechowuj wszystko. Odzyskuj to, czego potrzebujesz.

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

Kuratorstwo wymusza jakość. Gdy masz ograniczoną przestrzeń, zapisujesz tylko to, co ma znaczenie. Kompresujesz, konsolidujesz i priorytujesz. Nielimitowana pamięć zachęca do wpychania wszystkiego i nigdy do sprzątania.

Szybkość ma znaczenie. 1300 tokenów w prompcie systemowym to szybko. 100 000 tokenów odzyskanych z bazy danych to powoli. Pamięć powinna być natychmiastowa, nie zapytanie.

Szum degraduje wydajność. Więcej pamięci nie jest lepszą pamięcią. To głośniejsza pamięć. Model musi rozróżniać sygnał od szumu, a to wymaga uwagi — uwagi, która powinna być spędzona na właściwym zadaniu.

Zapominanie to cecha. Pamięć ludzka zapomina. To nie jest błąd — to sposób, w jaki priorytujemy. Agenci powinni też zapominać. Nie wszystko zasługuje na zapamiętanie.

Problem „zapominania”

Agenci muszą oduczyć się. Nie tylko zapomnieć, ale aktywnie usunąć przestarzałe informacje.

Oto jak Hermes Agent to obsługuje:

• Akcja remove: Usuń wpisy, które nie są już istotne.
• Akcja replace: Zaktualizuj wpisy nowymi informacjami.
• Presja pojemności: Gdy pamięć jest pełna, agent konsoliduje i usuwa stare wpisy.
• Skanowanie bezpieczeństwa: Blokuje złośliwe lub uszkodzone wpisy.

Zapominanie to nie porażka — to utrzymanie. Agent, który nie może się oduczyć, ostatecznie będzie niosł tyle szumu, co sygnału.

Skalowanie pamięci

Databricks wprowadził koncepcję „skalowania pamięci”: czy agent z tysiącami użytkowników działa lepiej niż jeden z pojedynczym użytkownikiem?

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

1. Jakościowej ekstrakcji: Nie wszystkie interakcje są warte zapamiętania. Agent musi ekstrahować wnioski, nie dzienniki.
2. Skutecznego odzyskiwania: Odzyskane pamięci muszą być istotne. Szum degraduje wydajność.
3. Uogólnienia: Pamięci powinny być wzorcami, nie szczegółami. „Użytkownik preferuje Pythona” skaluje się. „Użytkownik uruchomił komendę X w znaczniku czasu Y” nie skaluje się.

Ograniczona pamięć Hermes Agent naturalnie wspiera skalowanie pamięci. Wymuszając kurację, zapewnia, że pamięci są uogólnialne, zwarte i użyteczne.

Co to oznacza dla przyszłości

Pamięć staje się konkurencyjnym rowem w agencjalnej AI — nie sam model, ale to, co model przenosi między sesjami. Dwa agenci z identycznymi podstawowymi modelami mogą działać bardzo różnie: jeden pamiętuje Twoje preferencje, środowisko i przeszłe błędy; drugi zaczyna od zera za każdym razem.

Pytanie nie brzmi już, czy agenci powinni mieć trwałą pamięć. Jest rozstrzygnięte: muszą. Otwartym pytaniem jest, jak dobrze zaprojektować tę pamięć — co zachować, co odrzucić, jak uczynić ją natychmiastową i jak zapobiec jej staniu się szumem.

Odpowiedź Hermes Agent to utrzymanie pamięci małej, skuranej i zawsze aktywnej — nie bazy danych do zapytań, ale działającego modelu użytkownika, który agent przenosi ze sobą do każdej rozmowy.

Podsumowanie

System pamięci Hermes Agent jest celowo prosty: dwa pliki, twarde limity znaków, brak potoku odzyskiwania, brak bazy wektorowej i brak opóźnień na zapytanie. To, co brzmi jak ograniczenie, jest całym punktem.

Działa, bo traktuje pamięć tak, jak działa mózg, a nie tak, jak baza danych — mała, skurana i zawsze aktywna. Agent nie odzyskuje pamięci, gdy jej potrzebuje; pamięć jest po prostu zawsze tam, wpleciona w prompt systemowy od pierwszego tokena każdej sesji.

Zewnętrzni dostawcy pamięci rozszerzają ten system dla użytkowników, którzy potrzebują więcej: grafy wiedzy, wsparcie wieloagentowe, samodzielnie hostowane magazynowanie, funkcje przedsiębiorcze. Ale rdzeń pozostaje taki sam: ograniczona, skurana, zawsze dostępna.

A zewnętrzne bazy wiedzy — LLM Wiki, Obsidian, Notion, ArXiv — pełnią inną rolę. To biblioteka, nie mózg. Agent je wyszukuje, nie pamięta. Kluczowe wnioski są destylowane do wewnętrznej pamięci; reszta pozostaje w bibliotece.

Tak agent AI pamięta Ciebie. Nie poprzez przechowywanie wszystkiego, ale poprzez pamiętanie tego, co ma znaczenie.

Hermes Agent został wydany przez Nous Research w lutym 2026 roku i osiągnął ponad 64 000 gwiazdek na GitHubie do kwietnia 2026 roku (v0.9.0), z ponad 242 współtwórcami. Jest open-source i dostępny na github.com/NousResearch/hermes-agent. Aby zobaczyć instalację, konfigurację i przewodniki po przepływach pracy, zobacz Przegląd Hermes Agent.