System pamięci agentów Hermes: jak naprawdę działa trwała pamięć AI

Znasz ten schemat. Otwierasz czat z agentem AI, opisujesz swój projekt, dzielimy się preferencjami, wykonujemy jakąś pracę i zamykamy kartę. Wraca się tydzień później i okazuje się, że rozmawia się z obcym – cały kontekst zniknął, wszystkie preferencje zostały zapomniane, a projekt trzeba wyjaśnić od podstaw.

To nie jest błąd. Tak działają duże modele językowe (LLM) z założenia. Są bezstanowe: każde żądanie jest niezależne, 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 bieżącym oknie kontekstu.

W przypadku interakcji jednorazowych jest to akceptowalne. Zadajesz pytanie, otrzymujesz odpowiedź i przechodzisz dalej. Ale w przypadku agentów — systemów, które mają wykonywać zadania przez różne sesje, uczyć się z błędów i ewoluować wraz z użytkownikiem — bezstanowość jest twardym ograniczeniem architektonicznym. Jest to jeden z centralnych, nierozwiązanych problemów w samodzielnie hostowanych systemach AI.

Branża próbowała to rozwiązać. LangChain dodał moduły pamięci. OpenAI wprowadziła 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” — koncepcji, że wydajność agenta poprawia się wraz z nabywanym doświadczeniem. Od 2024 roku pojawiły się dedykowane papiery benchmarkowe, przeglądy pamięci epizodycznej oraz szybko rosnąca ekosystem narzędzi mających na celu rozwiązanie tego, co coraz częściej uznawane jest za jeden z centralnych, nierozwiązanych problemów w agencjalnej AI.

Większość tych podejść łączy wspólny problem: traktują pamięć jako afterthought — bazę danych do zapytań, okno kontekstu do nadmiernego wypełniania, system wyszukiwania, który dodaje opóźnienia i szum zamiast jasności.

Hermes Agent podejmuje fundamentally inną ścieżkę. Pamięć to nie coś, co agent odzyskuje, gdy tylko tego potrzebuje. To coś, czym agent jest w każdym momencie — wbudowane w systemowy prompt, kurygowane, ograniczone i zawsze aktywne. Jest wystarczająco małe, aby być szybkim, wystarczająco strukturalizowane, aby być użytecznym, i wystarczająco dyscyplinowane, aby wiedzieć, co należy zapomnieć.

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

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

Dlaczego „po prostu dodanie kontekstu” nie skaluje się dla agentów

Oczwistym 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 128K. Możesz zmieścić tam mnóstwo tekstu.

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

Kontekst nie jest kurygowany. To zrzut danych: wraz ze wzrostem wielkości, model musi przetworzyć tysiące tokenów nieistotnej historii, aby znaleźć jeden potrzebny fakt. To kosztuje tokeny i pieniądze, nakłada opóźnienia i ostatecznie uderza w sufit.

Pamięć jest kurygowana. To destylacja doświadczenia w coś kompaktowego i wykonawczego. Nie rośnie w nieskończoność — konsoliduje się, aktualizuje i zapomina.

Pamięć ludzka działa w ten sam sposób. Nie pamiętasz każdej rozmowy, jaką kiedykolwiek prowadził. Pamiętasz fragmenty, które mają znaczenie: z kim rozmawiasz, co ich obchodzi, nad czym się zgodzili, czego nauczyli się. Reszta jest albo zapomniana, albo dostępna do wyszukania, gdy tylko jest potrzebna.

Krajobraz badań

Przestrzeń pamięci agentów AI eksplodowała od 2024 roku, z dedykowanymi zestawami benchmarkowymi, rosnącą literaturą badawczą i mierzalną luką wydajnościową między różnymi podejściami architektonicznymi. Oto gdzie jesteśmy.

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

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

Cognee jest zbudowany do ekstrakcji wiedzy z dokumentów i danych strukturalizowanych, z ponad 30 konektorami ingestu i backendem grafu wiedzy. Doskonale radzi sobie z wiedzą instytucjonalną i pipelinami RAG, ale jest mniej skupiony na osobistej pamięci agenta. Zobacz samodzielne hostowanie Cognee z lokalnymi LLM dla praktycznego przewodnika konfiguracji.

Hindsight wykonuje przywoływanie oparte na grafie wiedzy z relacjami encji i unikalnym narzędziem syntezy reflect, które wykonuje syntezę między-pamięciową — łącząc wiele wspomnień w nowe wnioski. Jest jednym z najlepszych wykonawców w benchmarkach pamięci agenta 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. Papier badawczy Mem0, opublikowany na ECAI 2025 (arXiv:2504.19413), zbenchmarkował dziesięć odrębnych podejść do pamięci AI i zweryfikował podejście selektywnej ekstrakcji — przechowywanie dyskretnych faktów, usuwanie duplikatów i odzyskiwanie tylko tego, co jest istotne. Mem0 wzrósł do około 48 tys. gwiazdek na GitHubie i obsługuje 21 integracji z frameworkami. Kompromisem jest zależność od chmury i koszt.

Badania nad skalowaniem pamięci Databricks wprowadziły koncepcję, że wydajność agenta poprawia się wraz z nabywanym doświadczeniem. Ich architektura zawiera prompty systemowe, aktywa 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 możliwości modelu.

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

Część 2: Architektura — Dwa pliki, jeden mózg

Wbudowany system pamięci Hermes Agent istnieje 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 lekcji z życia. Oto jak to wygląda:

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

To nie są logi. To fakty. Gęste, deklaracyjne, pełne informacji. Bez znaczników czasu, bez bzdur, 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 biegły w 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, drażliwe punkty. Rzeczy, które sprawiają, że agent odpowiada inaczej do Ciebie niż do kogokolwiek innego.

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/2,200 znaków]

Projekt użytkownika to mikrousługa Go w ~/code/gateway używająca gRPC + PostgreSQL § Ten komputer działa na 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/1,375 znaków] ══════════════════════════════════════════════ Użytkownik to full-stack developer biegły w 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). Wpisu mogą być wieloliniowe. Jest zaprojektowany tak, aby być parsowalnym przez model, pozostając jednocześnie czytelnym dla człowieka.

Dlaczego zamrożony? [Prefiksowe cache'owanie](https://www.glukhov.org/pl/llm-performance/). Prompt systemowy jest taki sam przez każdą turę w sesji. Dzięki utrzymaniu pamięci statycznej po rozpoczęciu sesji, model może zcache'ować 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 zapisywane na dysku, ale pojawiają się w promptie 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 goniącemu własny ogon — aktualizowaniu pamięci, a następnie reagowaniu na własną aktualizację w tej samej rozmowie.

### Limity znaków jako funkcja

2200 znaków. 1375 znaków. To nie są arbitralne limity. To ograniczenia projektowe wymuszające kurygowanie.

Nielimitowana pamięć jest wadą. Zachęca do wtrącania wszystkiego, nigdy nie konsolidując, a ostatecznie staje się szumem. 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 tylko milcząco się nie udaje. Otrzymuje błąd z bieżącymi wpisami i użyciem, a następnie podąża za workflowem:

1. Przeczytaj bieżące wpisy z odpowiedzi błędu
2. Zidentyfikuj wpisy do usunięcia lub konsolidacji
3. Użyj `replace` do połączenia powiązanych wpisów w krótsze wersje
4. Dodaj nowy wpis

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

### Bezpieczeństwo: Skanowanie wstrzykiwania promptów

Każdy wpis pamięci jest skanowany przed akceptacją. System blokuje próby wstrzykiwania promptów, wyciek haseł, backdoory SSH i niewidoczne znaki Unicode.

Pamięć jest również deduplikowana. Dokładne duplikaty wpisów są automatycznie odrzucane. Zapobiega to przeciwnikom próbie wstrzyknięcia złośliwej treści poprzez powtarzane przesyłania.

---

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

Najczętszym pytaniem dotyczącym pamięci Hermes Agent jest, kiedy faktycznie 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 ukrytych wzorców.

### Wyzwalacze zapisu: Kiedy agent decyduje się zapisać?

Agent zapisuje pamięć proaktywnie. Nie czeka na Twoje prośby. Oto co go wyzwala.

**Korekty użytkownika.** Gdy poprawiasz agenta, to sygnał do zapamiętania. „Nie rób tego ponownie.” „Użyj tego zamiast tego.” „Zapamiętaj to.” To są 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' dla wszystkich projektów Python.`

**Odkryte preferencje.** Agent obserwuje wzorce i wnioskuje preferencje. Jeśli konsekwentnie używasz określonego narzędzia, frameworku lub workflowu, 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 komputerze, projekcie, zainstalowanych narzędziach. Są odkrywana poprzez eksplorację i zapisywane jako fakty.

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

**Konwencje projektu.** Jak projekt jest skonstruowany, jakie narzędzia używa, jakie wzorce podąża. Są odkrywana 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 workflowy.** 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 zanotowanie, 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 odkryte
- Surowe zrzuty danych
- Efemeryczne dane sesyjne
- Informacje już znajdujące się w plikach kontekstowych (SOUL.md, AGENTS.md)

### Wyzwalacze odczytu: Kiedy agent przypomina?

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

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

**`session_search` (na żądanie).** Gdy agent potrzebuje znaleźć coś z przeszłych rozmów, czego nie ma w pamięci podstawowej, używa narzędzia `session_search`. To zapytuje SQLite (`~/.hermes/state.db`) z pełnotekstowym wyszukiwaniem FTS5 i podsumowaniem Gemini Flash.

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

**Narzędzia dostawców zewnętrznych (gdy skonfigurowane).** Gdy zewnętrzny dostawca pamięci jest aktywny, agent ma dodatkowe narzędzia dostępne: `honcho_search`, `hindsight_recall`, `mem0_search` itp. Są używane, gdy agent określi, że potrzebny jest zewnętrzny kontekst.

### Drzewo decyzyjne

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

Czy to jest 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 jest łatwo ponownie odkryte? TAK → Pomiń NIE → Czy to jest specyficzne dla sesji? TAK → Pomiń NIE → Zapisz do pamięci

Agent nie nadmiernie to myśli. Zapisuje proaktywnie, konsoliduje, gdy jest pełne, i ufa limitom znaków, aby utrzymać rzeczy zwięzłe.

---

## Część 4: Pamięć wewnętrzna vs. Zewnętrzne bazy wiedzy

Tutaj często pojawia się zamieszanie. Hermes Agent ma *pamięć wewnętrzną* (MEMORY.md, USER.md, zewnętrzne dostawcy) i *zewnętrzne bazy wiedzy* (LLM Wiki, Obsidian, Notion, ArXiv, system plików), a one pełnią zupełnie różne role. Jest to podobne do rozróżnienia między [generowaniem wspartym wyszukiwaniem](https://www.glukhov.org/pl/rag/) a pamięcią roboczą agenta — zewnętrzne wyszukiwanie jest dobre do głębokich wyszukiwań wiedzy, nie do przenoszenia tożsamości i preferencji. Pamięć wewnętrzna to mózg agenta — zawsze aktywna, kurygowana, przenoszona do każdej sesji. Zewnętrzne bazy wiedzy to jego biblioteka — ogromne zasoby referencyjne konsultowane 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 głowie” podczas rozmowy
- Kurygowana, ograniczona, aktywnie zarządzana
- Przykłady: MEMORY.md, USER.md, Honcho, Hindsight, Mem0

**Zewnętrzne bazy wiedzy (biblioteka):**

- Ogromne, tylko do referencji, dostępne na żądanie
- Zawiera: dokumenty, papiery, kod, notatki, bazy danych
- Dostępne poprzez narzędzia, gdy potrzebne
- Nie „zapamiętywane” — wyszukane
- 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 potrzebne. Nie je „zapamiętuje” — je wyszukuje.

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

**[Obsidian](https://www.glukhov.org/pl/knowledge-management/tools/obsidian-for-personal-knowledge-management/):** Osobiste skrzynie notatek z dwukierunkowymi linkami. Agent używa umiejętności `obsidian` do odczytu, wyszukiwania i tworzenia notatek. Obsidian jest częścią szerszego ekosystemu [zarządzania osobistą wiedzą](https://www.glukhov.org/pl/knowledge-management/), do którego Hermes może sięgnąć jako do zasobu bibliotecznego.

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

**ArXiv:** Repozytoria artykułów akademickich. Agent wyszukuje i ekstrahuje artykuły, gdy badając temat.

**System plików:** Kod projektu, dokumentacja, konfiguracje. Agent czyta pliki, gdy pracując nad projektem.

### Wzór destylacji

Oto kluczowa inspiracja: krytyczne wnioski z zewnętrznych baz mogą być *destylowane* do pamięci wewnętrznej.

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ść agenta poprawia się z nabywanym doświadczeniem poprzez interakcję użytkownika i kontekst biznesowy przechowywany w pamięci.`

Zewnętrzny zasób jest ogromny. Wewnętrzna pamięć jest destylacją.

### Kiedy używać którego

**Pamięć wewnętrzna dla:**

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

**Zewnętrzne bazy wiedzy dla:**

- „Jakie są najnowsze badania nad 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 wyszukania dokumentu ze wspomnieniem czegoś, czego się o Tobie i Twoim środowisku nauczył.

---

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

Spójrzmy na mechanikę.

### Narzędzie `memory`

Agent zarządza pamięcią poprzez pojedyncze 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ć, ponieważ jest zawsze tam.

**`add`** — Dodaje nowy wpis.

```python
memory(action="add", target="memory",
       content="Użytkownik działa na 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="tryb ciemny",
       content="Użytkownik preferuje tryb jasny w VS Code, tryb ciemny w terminalu")

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

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

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 specyficznego 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 projektu, ciekawostki narzędzi, lekcje z życia.
• user — Profil użytkownika. Tożsamość, rola, strefa czasowa, preferencje komunikacyjne, drażliwe punkty, nawyki workflowowe.

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ą kompaktowe i gęste informacyjnie:

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

Słabe wpisy pamięci są niejasne lub werbalne:

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

Pierwszy jest gęsty i użyteczny. Drugi jest albo zbyt niejasny, albo zbyt werbalny.

Wyszukiwanie sesyjne vs Trwała pamięć

session_search i trwała pamięć pełnią różne cele.

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

Część 6: Zewnętrzni dostawcy pamięci — Wszystkie 8 opcji porównane

Oprócz wbudowanych MEMORY.md i USER.md, Hermes Agent obsługuje 8 zewnętrznych wtyczek dostawców pamięci dla trwałej, między-sesyjnej wiedzy.

Tylko jeden zewnętrzny dostawca może być aktywny w danym momencie. Wbudowane pliki są zawsze aktywne obok dostawcy zewnętrznego — addytywnie, nie zastępująco.

Aktywacja

hermes memory setup   # Interaktywny wybór + konfiguracja
hermes memory status  # Sprawdź, co jest aktywne
hermes memory off     # Wyłącz dostawcę zewnętrznego

Lub ręcznie w ~/.hermes/config.yaml:

memory:
  provider: openviking  # lub honcho, mem0, hindsight, holographic, retaindb, byterover, supermemory

Porównanie dostawców

Szczegółowe omówienie

Honcho

Najlepszy do: systemów wieloagentowych, kontekstu między-sesyjnego, wyrównania użytkownik-agent.

Honcho działa obok istniejącej pamięci — USER.md pozostaje bez zmian, a Honcho dodaje dodatkową warstwę kontekstu. Modeluje rozmowy jako równe wymianę wiadomości — jeden rówieśnik użytkownika plus jeden rówieśnik AI na profil Hermes, wszyscy dzielący przestrzeń roboczą.

Narzędzia: honcho_profile (odczyt/aktualizacja karty rówieśnika), honcho_search (wyszukiwanie semantyczne), honcho_context (kontekst sesji — podsumowanie, reprezentacja, karta, wiadomości), honcho_reasoning (syntezowane przez LLM), honcho_conclude (tworzenie/usuwanie wniosków).

Kluczowe pokrętła konfiguracji:

• contextCadence (domyślnie 1): Minimalne tury między odświeżeniem warstwy bazowej
• dialecticCadence (domyślnie 2): Minimalne tury między wywołaniami LLM peer.chat() (zalecane 1-5)
• dialecticDepth (domyślnie 1): Przejścia .chat() na wywołanie (ograniczone 1-3)
• recallMode (domyślnie ‘hybrid’): hybrid (auto+narzędzia), context (tylko wstrzyknięcie), tools (tylko narzędzia)
• writeFrequency (domyślnie ‘async’): Czas zrzutu: async, turn, session lub liczba całkowita N
• observationMode (domyślnie ‘directional’): directional (wszystkie włączone) lub unified (wspólny pul)

Architektura: Dwuwarstwowe wstrzyknięcie kontekstu — warstwa bazowa (podsumowanie sesji + reprezentacja + karta rówieśnika) + uzupełnienie dialektyczne (rozumowanie LLM). Automatycznie wybiera prompty zimnego startu vs ciepłe.

Mapowanie wielu rówieśników: Przestrzeń robocza jest środowiskiem wspólnym między profilami. Rówieśnik użytkownika (peerName) to globalna tożsamość ludzka. Rówieśnik AI (aiPeer) to jeden na profil Hermes (hermes domyślnie, hermes.<profil> dla innych).

Konfiguracja:

hermes memory setup  # wybierz "honcho"
# lub legacy: hermes honcho setup

Konfiguracja: $HERMES_HOME/honcho.json (lokalnie dla profilu) lub ~/.honcho/config.json (globalnie).

Zarządzanie profilami:

hermes profile create coder --clone  # Tworzy hermes.coder ze wspólną przestrzenią roboczą
hermes honcho sync                   # Wypełnia wstecznie rówieśników AI dla istniejących profili

OpenViking

Najlepszy do: zarządzania wiedzą samodzielnie hostowanej z strukturalizowanym przeglądaniem.

OpenViking zapewnia hierarchię systemu plików z warstwowym ładowaniem. Jest darmowy, samodzielnie hostowany, i daje pełną kontrolę nad przechowywaniem pamięci.

Narzędzia: viking_search, viking_read (warstwowe), viking_browse, viking_remember, viking_add_resource.

Konfiguracja:

pip install openviking
openviking-server
hermes memory setup  # wybierz "openviking"
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

Najlepszy do: zarządzania pamięcią bez interwencji z automatyczną ekstrakcją.

Mem0 obsługuje ekstrakcję pamięci po stronie serwera. Nie konfigurujesz nic — po prostu działa. Kompromis: zależność od chmury i koszt.

Narzędzia: mem0_profile, mem0_search, mem0_conclude.

Konfiguracja:

pip install mem0ai
hermes memory setup  # wybierz "mem0"
echo "MEM0_API_KEY=your-key" >> ~/.hermes/.env

Konfiguracja: $HERMES_HOME/mem0.json (user_id: hermes-user, agent_id: hermes).

Hindsight

Najlepszy do: przywoływania opartego na grafie wiedzy z relacjami encji.

Hindsight buduje graf wiedzy Twojej pamięci, ekstrahując encje i relacje. Jego unikalne narzędzie reflect wykonuje syntezę między-pamięciową — łącząc wiele wspomnień w nowe wnioski.

Narzędzia: hindsight_retain, hindsight_recall, hindsight_reflect (unikalna synteza między-pamięciowa).

Konfiguracja:

hermes memory setup  # wybierz "hindsight"
echo "HINDSIGHT_API_KEY=your-key" >> ~/.hermes/.env

Automatycznie instaluje hindsight-client (chmura) lub hindsight-all (lokalnie). Wymaga >= 0.4.22.

Konfiguracja: $HERMES_HOME/hindsight/config.json

• mode: cloud lub local
• recall_budget: low / mid / high
• memory_mode: hybrid / context / tools
• auto_retain / auto_recall: true (domyślnie)

Lokalny UI: hindsight-embed -p hermes ui start

Holographic

Najlepszy do: ustawień skupionych na prywatności z wyłącznie lokalnym przechowywaniem.

Holographic używa algebry HRR (Holographic Reduced Representation) do kodowania pamięci, z ocenianiem zaufania dla niezawodności pamięci. Brak zależności od chmury — wszystko działa lokalnie na własnym sprzęcie.

Narzędzia: 2 narzędzia do operacji pamięci poprzez algebrę HRR.

Konfiguracja:

hermes memory setup  # wybierz "holographic"

Brak zależności. Wszystko działa lokalnie.

RetainDB

Najlepszy do: częstych aktualizacji z kompresją delta.

RetainDB używa kompresji delta do efektywnego przechowywania aktualizacji pamięci. Jest oparty na chmurze z kosztem $20/miesiąc, ale kompresja oznacza mniejszy transfer danych i szybsze aktualizacje.

Narzędzia: retaindb_profile (profil użytkownika), retaindb_search (wyszukiwanie semantyczne), retaindb_context (kontekst istotny dla zadania), retaindb_remember (przechowywanie z typem + ważnością), retaindb_forget (usuwanie wspomnień).

Konfiguracja:

hermes memory setup  # wybierz "retaindb"

ByteRover

Najlepszy do: środowisk ograniczonych przepustowością z ekstrakcją przed kompresją.

ByteRover kompresuje pamięć przed ekstrakcją, redukując użycie przepustowości. Dostępne w trybie lokalnym lub chmurowym.

Narzędzia: 3 narzędzia do operacji pamięci.

Konfiguracja:

hermes memory setup  # wybierz "byterover"

Supermemory

Najlepszy do: workflowów przedsiębiorczych z ograniczeniem kontekstu i importem grafu sesji.

Supermemory zapewnia ograniczenie kontekstu (izolowanie pamięci według kontekstu) i import grafu sesji (importowanie całych historii rozmów). Jest oparty na chmurze i płatny, ale zaprojektowany do zarządzania pamięcią w skali przedsiębiorczej.

Narzędzia: 4 narzędzia do operacji pamięci.

Konfiguracja:

hermes memory setup  # wybierz "supermemory"

Jak wybrać

• Potrzebujesz wsparcia wieloagentowego? Honcho
• Chcesz samodzielnie hostowane i darmowe? OpenViking lub Holographic
• Chcesz zero-konfigurację? Mem0
• Chcesz grafy wiedzy? Hindsight
• Chcesz kompresję delta? RetainDB
• Chcesz efektywność przepustowości? ByteRover
• Chcesz funkcje przedsiębiorcze? Supermemory
• Chcesz prywatność (wyłącznie lokalnie)? Holographic

Pełne konfiguracje dostawców profil-po-profil i rzeczywiste wzorce workflow, zobacz Konfiguracja produkcyjna Hermes Agent.

Część 7: Filozofia

Dlaczego ograniczona pamięć pokonuje nieograniczoną pamięć

Instynkt polega na tym, aby uczynić pamięć jak największą. Przechowuj wszystko. Odzyskuj, czego potrzebujesz.

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

Kurygowanie wymusza jakość. Gdy masz ograniczoną przestrzeń, zapisujesz tylko to, co ma znaczenie. Kompresujesz, konsolidujesz i priorytizujesz. Nielimitowana pamięć zachęca do wtrącania wszystkiego i nigdy nie porządkowania.

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

Szum degradowa wydajność. Więcej pamięci nie jest lepszą pamięcią. To szumsiejsza pamięć. Model musi rozróżnić sygnał od szumu, a to wymaga uwagi — uwagi, która powinna być spędzona na rzeczywistym zadaniu.

Zapominanie to funkcja. Pamięć ludzka zapomina. To nie jest błąd — to jak priorytujemy. Agenci powinni też zapominać. Nie wszystko zasługuje na zapamiętanie.

Problem „zapominania”

Agenci muszą odnaukać. Nie tylko zapominać, ale aktywnie usuwać 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 odnaukać, ostatecznie będzie przenosił tyle szumu co sygnał.

Skalowanie pamięci

Databricks wprowadził koncepcję „skalowania pamięci”: czy agent z tysiącami użytkowników działa lepiej niż ten 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 logi.
2. Efektywnego odzyskiwania: Odzyskane wspomnienia muszą być istotne. Szum degradowa wydajność.
3. Uogólnienia: Wspomnienia powinny być wzorcami, nie specyfikami. „Użytkownik preferuje Python” 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 kurygowanie, zapewnia, że wspomnienia są uogólnialne, kompaktowe i użyteczne.

Co to oznacza dla przyszłości

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

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

Odpowiedź Hermes Agent polega na utrzymaniu pamięci małej, kurygowanej i zawsze aktywnej — nie bazy danych do zapytań, ale 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 pipeline’u odzyskiwania, brak bazy wektorowej i brak opóźnień na zapytanie. To, co brzmi jak ograniczenie, jest całym punktem.

Działa, ponieważ traktuje pamięć tak, jak działa mózg, a nie baza danych — małą, kurygowaną i zawsze aktywną. Agent nie odzyskuje pamięci, gdy jej potrzebuje; pamięć jest po prostu zawsze tam, utkana 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, samodzielne hostowanie, funkcje przedsiębiorcze. Ale rdzeń pozostaje taki sam: ograniczona, kurygowana, 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. Krytyczne wnioski są destylowane do pamięci wewnętrznej; reszta pozostaje w bibliotece.

Tak AI agent pamięta Cię. Nie poprzez przechowywanie wszystkiego, ale poprzez zapamiętywanie 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 otwartoźródłowy i dostępny na github.com/NousResearch/hermes-agent. Dla instalacji, konfiguracji i przewodników workflow, zobacz Przegląd Hermes Agent.