Porównanie Agent Memory Providers — Honcho, Mem0, Hindsight oraz pięć innych rozwiązań

Nowoczesni asystenci wciąż zapominają wszystko po zamknięciu karty, chyba że coś zachowuje trwałość poza oknem kontekstowym. Dostawcy pamięci agentów (Agent memory providers) to usługi lub biblioteki, które przechowują fakty i podsumowania pomiędzy sesjami — często integrowane jako wtyczki (plugins), dzięki czemu framework pozostaje lekki, podczas gdy pamięć jest skalowalna.

Niniejszy przewodnik porównuje osiem backendów dostarczanych jako zewnętrzne wtyczki pamięci dla Hermes Agent — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover oraz Supermemory — i wyjaśnia, jak pasują one do szerszych stosów AI systems. Ci sami dostawcy pojawiają się w OpenClaw oraz innych narzędziach dla agentów poprzez integracje społecznościowe lub oficjalne. AI Systems Memory hub wymienia ten artykuł obok Cognee i powiązanych przewodników.

Aby dowiedzieć się więcej o ograniczonej pamięci rdzeniowej specyficznej dla Hermes (MEMORY.md i USER.md), zachowaniu zamrażania oraz wyzwalaczach, sprawdź Hermes Agent Memory System.

Hermes Agent wymienia osiem wtyczek zewnętrznych dostawców pamięci dla trwałej wiedzy między sesjami. W danym czasie może być aktywny tylko jeden zewnętrzny dostawca. Wbudowane pliki MEMORY.md i USER.md pozostają załadowane obok niego — działają addytywnie, a nie jako zamienniki.

Zależności zewnętrzne. Każdy zewnętrzny dostawca z wyjątkiem Holographic wymaga co najmniej jednego zewnętrznego wywołania usługi — modelu LLM do ekstrakcji pamięci, modelu embeddingów do wyszukiwania semantycznego lub bazy danych, takiej jak PostgreSQL, do przechowywania danych. Zależności te mają bezpośredni wpływ na prywatność, koszty oraz to, czy Twój stos pamięci może działać w pełni samodzielnie. Hindsight i ByteRover posiadają najmniej lub eliminują większość zależności; Honcho, Mem0 i Supermemory wymagają największej liczby komponentów. Jeśli dostawca obsługuje Ollama lub dowolny punkt końcowy zgodny z OpenAI, możesz przekierować wywołania LLM i embeddingów do lokalnego modelu, dzięki czemu dane pozostaną całkowicie poza serwerami stron trzecich.

Aktywacja w Hermes Agent

hermes memory setup   # Interaktywny wybór + konfiguracja
hermes memory status  # Sprawdzenie, co jest aktywne
hermes memory off     # Wyłączenie zewnętrznego dostawcy

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

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

Porównanie dostawców

Szczegółowa analiza

Honcho

Najlepszy dla: systemów wieloagentowych, kontekstu między sesjami, dopasowania 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ówieśników wymieniających wiadomości — jeden partner użytkownika plus jeden partner AI na profil Hermes, przy czym wszyscy współdzielą obszar roboczy.

Zależności zewnętrzne: Honcho wymaga modelu LLM do podsumowywania sesji, wywodzenia reprezentacji użytkownika i rozumowania dialektycznego; modelu embeddingów do wyszukiwania semantycznego w obserwacjach; PostgreSQL z rozszerzeniem pgvector do przechowywania wektorów; oraz Redis do buforowania. Zarządzana chmura pod adresem api.honcho.dev zajmuje się tym wszystkim za Ciebie. W przypadku wdrożeń self-hosted (Docker, K3s lub Fly.io) musisz dostarczyć własne dane uwierzytelniające. Slot LLM akceptuje dowolny punkt końcowy zgodny z OpenAI, w tym Ollama i vLLM, dzięki czemu wnioskowanie może odbywać się lokalnie (on-premises). Slot embeddingów domyślnie ustawiony jest na openai/text-embedding-3-small, ale obsługuje konfigurowalnych dostawców poprzez LLM_EMBEDDING_API_KEY oraz LLM_EMBEDDING_BASE_URL — działa każdy serwer embeddingów zgodny z OpenAI, w tym opcje lokalne, takie jak vLLM z modelem BGE.

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

Kluczowe parametry konfiguracji:

• contextCadence (domyślnie 1): Minimalna liczba tur między odświeżeniami warstwy podstawowej
• dialecticCadence (domyślnie 2): Minimalna liczba tur między wywołaniami LLM peer.chat() (zalecane 1-5)
• dialecticDepth (domyślnie 1): Liczba przejść .chat() na wywołanie (ograniczone do 1-3)
• recallMode (domyślnie ‘hybrid’): hybrid (auto+narzędzia), context (tylko wstrzykiwanie), tools (tylko narzędzia)
• writeFrequency (domyślnie ‘async’): Czas wypychania danych: async, turn, session lub liczba całkowita N
• observationMode (domyślnie ‘directional’): directional (wszystko włączone) lub unified (wspólna pula)

Architektura: Dwuwarstwowe wstrzykiwanie kontekstu — warstwa podstawowa (podsumowanie sesji + reprezentacja + karta partnera) + uzupełnienie dialektyczne (rozumowanie LLM). Automatycznie wybiera prompty typu cold-start vs warm.

Mapowanie wielu partnerów: Obszar roboczy jest wspólnym środowiskiem dla profili. Partner użytkownika (peerName) jest globalną tożsamością ludzką. Partner AI (aiPeer) jest jeden na profil Hermes (hermes domyślnie, hermes.<profil> dla pozostałych).

Konfiguracja:

hermes memory setup  # wybierz "honcho"
# lub starsza wersja: hermes honcho setup

Konfiguracja: $HERMES_HOME/honcho.json (lokalna dla profilu) lub ~/.honcho/config.json (globalna).

Zarządzanie profilami:

hermes profile create coder --clone  # Tworzy hermes.coder ze wspólnym obszarem roboczym
hermes honcho sync                   # Uzupełnia partnerów AI dla istniejących profili

OpenViking

Najlepszy dla: zarządzania wiedzą w modelu self-hosted ze strukturalnym przeglądaniem.

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

Zależności zewnętrzne: OpenViking wymaga modelu VLM (model językowo-wizualny) do przetwarzania semantycznego i ekstrakcji pamięci oraz modelu embeddingów do wyszukiwania wektorowego — oba są obowiązkowe. Obsługiwani dostawcy VLM to OpenAI, Anthropic, DeepSeek, Gemini, Moonshot oraz vLLM (dla wdrożeń lokalnych). W przypadku embeddingów obsługiwani dostawcy to OpenAI, Volcengine (Doubao), Jina, Voyage oraz — poprzez Ollama — dowolny lokalnie serwowany model embeddingów. Interaktywny kreator openviking-server init może wykryć dostępny RAM i zarekomendować odpowiednie modele Ollama (np. Qwen3-Embedding 8B dla embeddingów, Gemma 4 27B dla VLM) oraz automatycznie skonfigurować wszystko dla w pełni lokalnej konfiguracji bez kluczy API. Nie jest wymagana zewnętrzna baza danych; OpenViking przechowuje pamięć w systemie plików.

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

Konfiguracja:

pip install openviking
openviking-server init   # interaktywny kreator (rekomenduje modele Ollama dla lokalnej konfiguracji)
openviking-server
hermes memory setup  # wybierz "openviking"
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

Najlepszy dla: bezobsługowego zarządzania pamięcią z automatyczną ekstrakcją.

Mem0 obsługuje ekstrakcję pamięci po stronie serwera poprzez wywołanie LLM przy każdej operacji add — czyta rozmowę, wyodrębnia odrębne fakty, usuwa duplikaty i przechowuje je. Zarządzane API chmurowe obsługuje całą infrastrukturę. Biblioteka open-source oraz serwer self-hosted dają pełną kontrolę.

Zależności zewnętrzne: Mem0 wymaga modelu LLM do ekstrakcji pamięci (domyślnie: OpenAI gpt-4.1-nano; obsługowanych jest 20 dostawców, w tym Ollama, vLLM i LM Studio dla modeli lokalnych) oraz modelu embeddingów do wyszukiwania (domyślnie: OpenAI text-embedding-3-small; obsługowanych jest 10 dostawców, w tym Ollama i HuggingFace dla modeli lokalnych). Przechowywanie wykorzystuje Qdrant w /tmp/qdrant w trybie biblioteki lub PostgreSQL z pgvector w trybie serwera self-hosted — oba mogą działać lokalnie. Możliwe jest stworzenie w pełni lokalnego stosu Mem0 bez chmury: Ollama dla LLM, Ollama dla embeddingów oraz lokalna instancja Qdrant, wszystko skonfigurowane przez Memory.from_config.

Narzędzia: mem0_profile, mem0_search, mem0_conclude.

Konfiguracja:

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

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

Hindsight

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

Hindsight buduje graf wiedzy Twojej pamięci, wyodrębniając encje i relacje. Jego unikalne narzędzie reflect wykonuje syntezę między-pamięciową — łącząc wiele wspomnień w nowe spostrzeżenia. Przywoływanie (recall) uruchamia cztery strategie wyszukiwania równolegle (semantyczne, słowo kluczowe/BM25, przechodzenie grafu, czasowe), a następnie łączy i porządkuje wyniki przy użyciu algorytmu reciprocal rank fusion.

Zależności zewnętrzne: Hindsight wymaga modelu LLM do ekstrakcji faktów i encji podczas wywołań retain oraz do syntezy podczas wywołań reflect (domyślnie: OpenAI; obsługiwani dostawcy to m.in. Anthropic, Gemini, Groq, Ollama, LM Studio oraz dowolny punkt końcowy zgodny z OpenAI). Model embeddingów oraz model rerankingowy typu cross-encoder są pakowane wewnątrz samego Hindsight — działają lokalnie w pakiecie hindsight-all i nie wymagają zewnętrznego API. PostgreSQL jest również pakowany wraz z osadzoną instalacją Python poprzez zarządzany katalog danych pg0; alternatywnie można wskazać Hindsight na zewnętrzną instancję PostgreSQL. Dla w pełni lokalnej konfiguracji bez chmury ustaw HINDSIGHT_API_LLM_PROVIDER=ollama i wskaż lokalny model Ollama — funkcje retain i recall będą działać w pełni; reflect wymaga modelu zdolnego do wywoływania narzędzi (np. qwen3:8b).

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

Konfiguracja:

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

Automatycznie instaluje hindsight-client (chmura) lub hindsight-all (lokalnie). Wymaga wersji >= 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 interfejs UI: hindsight-embed -p hermes ui start

Holographic

Najlepszy dla: konfiguracji skoncentrowanych na prywatności z wyłącznie lokalnym przechowywaniem.

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

Zależności zewnętrzne: Brak. Holographic nie wymaga modelu LLM, modelu embeddingów, bazy danych ani połączenia z siecią. Kodowanie pamięci odbywa się całkowicie za pomocą algebry HRR działającej w procesie. To czyni go wyjątkowym wśród ośmiu dostawców — jest to jedyny, który operuje przy zerowej liczbie zewnętrznych wywołań. Ceną jest niższa jakość wyszukiwania w porównaniu do wyszukiwania semantycznego opartego na embeddingach oraz brak syntezy między-pamięciowej, takiej jak reflect w Hindsight. Dla użytkowników, dla których prywatność i działanie bez zależności są niepodważalne, Holographic jest jedyną opcją, która dostarcza to bezwarunkowo.

Narzędzia: 2 narzędzia do operacji na pamięci za pomocą algebry HRR.

Konfiguracja:

hermes memory setup  # wybierz "holographic"

RetainDB

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

RetainDB wykorzystuje kompresję delta do wydajnego przechowywania aktualizacji pamięci oraz hybrydowe wyszukiwanie (wektorowe + BM25 + reranking) w celu ujawniania istotnego kontekstu. Jest to usługa chmurowa o koszcie 20 USD/miesiąc, gdzie całe przetwarzanie pamięci odbywa się po stronie serwera.

Zależności zewnętrzne: Wywołania LLM, potok embeddingów i reranking w RetainDB odbywają się na własnej infrastrukturze chmurowej RetainDB — dostarczasz jedynie RETAINDB_KEY. Ekstrakcja pamięci wykorzystuje model Claude Sonnet po stronie serwera. Nie ma opcji self-hostingu ani trybu lokalnego. Wszystkie dane rozmów są przesyłane na serwery RetainDB w celu przetwarzania i przechowywania. Jeśli suwerenność danych lub działanie offline są ważne w Twoim przypadku, dostawca ten nie będzie odpowiedni.

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 dla: pamięci typu local-first z przechowywaniem czytelnym dla człowieka i audytowalnym.

ByteRover przechowuje pamięć jako ustrukturyzowane drzewo kontekstu markdown — hierarchię plików domeny, tematu i podtematu — zamiast wektorów embeddingów czy bazy danych. Model LLM czyta treść źródłową, analizuje ją i umieszcza wydobytą wiedzę we właściwym miejscu w hierarchii. Wyszukiwanie to pełnotekstowe wyszukiwanie MiniSearch z warstwowym przejściem (fallback) na wyszukiwanie oparte na LLM, bez konieczności posiadania bazy wektorowej.

Zależności zewnętrzne: ByteRover wymaga modelu LLM do kurateli pamięci i wyszukiwania (obsługiwanych jest 18 dostawców, w tym Anthropic, OpenAI, Google, Ollama oraz dowolny punkt końcowy zgodny z OpenAI poprzez slot dostawcy openai-compatible). Nie wymaga modelu embeddingów ani bazy danych — drzewo kontekstu to lokalny katalog zwykłych plików markdown. Synchronizacja z chmurą jest opcjonalna i służy jedynie do współpracy zespołowej; domyślnie wszystko działa w pełni offline. Dla w pełni samodzielnej konfiguracji lokalnej, połącz Ollama jako dostawcę (brv providers connect openai-compatible --base-url http://localhost:11434/v1) i żadne dane nie opuszczą Twojej maszyny.

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

Konfiguracja:

hermes memory setup  # wybierz "byterover"

Supermemory

Najlepszy dla: przepływów pracy klasy enterprise z context fencing i ingestem grafu sesji.

Supermemory zapewnia context fencing (izolowanie pamięci według kontekstu) oraz ingest grafu sesji (importowanie całych historii rozmów). Automatycznie ekstrahuje wspomnienia, buduje profile użytkowników i uruchamia hybrydowe wyszukiwanie łączące wyszukiwanie semantyczne i słowa kluczowe. Zarządzane API chmurowe jest głównym celem wdrożenia.

Zależności zewnętrzne: Usługa chmurowa Supermemory obsługuje całe wnioskowanie LLM i embeddingi po stronie serwera — dostarczasz jedynie klucz API Supermemory. Self-hosting jest dostępny wyłącznie jako dodatek do planu enterprise i wdraża się na Cloudflare Workers; wymaga to dostarczenia PostgreSQL z rozszerzeniem pgvector (do przechowywania wektorów) oraz klucza API OpenAI (obowiązkowy, z opcjonalnymi dodatkami w postaci Anthropic i Gemini). Nie ma ścieżki self-hostingu opartej na Dockerze ani wersji lokalnej — architektura jest ściśle powiązana z edge compute Cloudflare Workers. Dla użytkowników potrzebujących pełnej suwerenności danych bez kontraktu enterprise, dostawca ten nie jest właściwym wyborem.

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

Konfiguracja:

hermes memory setup  # wybierz "supermemory"

Jak wybrać

• Potrzebujesz wsparcia dla wielu agentów? Honcho
• Chcesz self-hostingu i darmowego rozwiązania? OpenViking lub Holographic
• Chcesz zero-konfiguracji? Mem0
• Chcesz grafy wiedzy? Hindsight
• Chcesz kompresję delta? RetainDB
• Chcesz oszczędności przepustowości? ByteRover
• Chcesz funkcji klasy enterprise? Supermemory
• Chcesz prywatności (tylko lokalnie)? Holographic
• Chcesz pełnej lokalności bez zewnętrznych usług? Holographic (brak jakichkolwiek zależności) lub Hindsight/Mem0/ByteRover z Ollama
• Chcesz czytelnej dla człowieka, audytowalnej pamięci bez potoku embeddingów? ByteRover

Aby uzyskać pełne konfiguracje dostawców dla poszczególnych profili oraz wzorce przepływu pracy w rzeczywistych warunkach, sprawdź Hermes Agent production setup.

Powiązane przewodniki

• AI Systems Memory hub — zakres tego podzbioru i linki do przewodników Cognee
• Hermes Agent Memory System — rdzeń pamięci składający się z dwóch plików przed użyciem wtyczek
• Hermes Agent production setup — konfigurowanie profili dla dostawców w praktyce