Porównanie dostawców pamięci agentów — Honcho, Mem0, Hindsight i pięć innych

Współczesne asystenty nadal zapominają wszystko po zamknięciu karty, chyba że dane są utrwalone poza oknem kontekstu. Dostawcy pamięci agentów to usługi lub biblioteki przechowujące fakty i streszczenia między sesjami – często integrowane jako wtyczki, dzięki czemu framework pozostaje lekki, a pamięć skalowalna.

Ten przewodnik porównuje osiem backendów dostępnych jako zewnętrzne wtyczki pamięci Hermes Agent – Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover i Supermemory – oraz wyjaśnia, jak wpisują się w szersze stosy systemów AI. Te same dostawcy pojawiają się w OpenClaw i innych narzędziach agentów dzięki integracjom społecznościowym lub oficjalnym. Centrum pamięci systemów AI wymienia ten artykuł wraz z Cognee i powiązanymi przewodnikami.

W sprawie ograniczonej pamięci rdzeniowej specyficznej dla Hermes (MEMORY.md i USER.md), zachowań blokowania i wyzwalaczy, zobacz System pamięci agenta Hermes. W sprawie kontekstu dotyczącego tego, jak osiem natywnych dostawców pamięci Hermes przyczynia się do jego rosnącej przewagi nad OpenClaw – w tym liczby gwiazdek na GitHubie, rankingu tokenów OpenRouter oraz porównań rozmiarów ekosystemów – zobacz OpenClaw vs Hermes Agent: Gwiazdki, pobrań i wykorzystanie 2026.

Hermes Agent udostępnia osiem wtyczek zewnętrznych dostawców pamięci dla trwałej, między-sesyjnej wiedzy. Jednocześnie może być aktywny tylko jeden zewnętrzny dostawca. Wbudowane pliki MEMORY.md i USER.md pozostają załadowane obok niego – są one dodawane, a nie zastępowane.

Zależności zewnętrzne. Każdy zewnętrzny dostawca, z wyjątkiem Holographic, wymaga co najmniej jednego wywołania zewnętrznego – modelu LLM do ekstrakcji pamięci, modelu embeddingów do wyszukiwania semantycznego lub bazy danych, takiej jak PostgreSQL, do przechowywania. Te zależności mają bezpośrednie implikacje dla prywatności, kosztów oraz tego, czy Twój stos pamięci może działać w pełni samodzielnie. Hindsight i ByteRover integrują lub eliminują większość zależności; Honcho, Mem0 i Supermemory wymagają największej liczby komponentów. Tam, gdzie dostawca obsługuje Ollama lub dowolny endpoint zgodny z OpenAI, możesz kierować wywołania LLM i embeddingów do modelu lokalnego i utrzymać dane całkowicie poza serwerami osób trzecich.

Aktywacja z Hermes Agent

Poniższe kroki wiersza poleceń odzwierciedlają tabele z krótkiej instrukcji CLI Hermes Agent.

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ółowa analiza

Honcho

Najlepsze dla: systemów wieloagentowych, kontekstu między sesjami, wyrównania agenta z użytkownikiem.

Honcho działa obok istniejącej pamięci — USER.md pozostaje bez zmian, a Honcho dodaje dodatkową warstwę kontekstu. Modeluje rozmowy jako wymianę wiadomości między równymi sobie podmiotami — jeden podmiot użytkownika i jeden podmiot AI na profil Hermes, wszystkie współdzielące przestrzeń roboczą.

Zależności zewnętrzne: Honcho wymaga LLM do streszczania sesji, wyprowadzania reprezentacji użytkownika i rozumowania dialektycznego; modelu embeddingów do wyszukiwania semantycznego wśród obserwacji; PostgreSQL z rozszerzeniem pgvector do przechowywania wektorów; oraz Redis do cache’owania. Zarządzana chmura na api.honcho.dev obsługuje to wszystko za Ciebie. Dla wdrożeń samodzielnych (Docker, K3s lub Fly.io) dostarczasz własne dane uwierzytelniające. Slot LLM akceptuje dowolny endpoint zgodny z OpenAI, w tym Ollama i vLLM, więc wnioskowanie może odbywać się lokalnie. Slot embeddingów domyślnie używa openai/text-embedding-3-small, ale obsługuje konfigurowalne dostawców poprzez LLM_EMBEDDING_API_KEY i LLM_EMBEDDING_BASE_URL — każdy serwer embeddingów zgodny z OpenAI działa, w tym opcje lokalne, takie jak vLLM z modelem BGE.

Narzędzia: honcho_profile (odczyt/aktualizacja karty podmiotu), honcho_search (wyszukiwanie semantyczne), honcho_context (kontekst sesji – streszczenie, reprezentacja, karta, wiadomości), honcho_reasoning (synteza LLM), honcho_conclude (tworzenie/usuwanie wniosków).

Kluczowe parametry konfiguracji:

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

Architektura: Dwuwarstwowa injekcja kontekstu – warstwa bazowa (streszczenie sesji + reprezentacja + karta podmiotu) + uzupełnienie dialektyczne (rozumowanie LLM). Automatycznie wybiera prompty startowe na zimno vs na gorąco.

Mapowanie wielu podmiotów: Przestrzeń robocza to środowisko współdzielone między profilami. Podmiot użytkownika (peerName) to globalna tożsamość człowieka. Podmiot 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ółdzieloną przestrzenią roboczą
hermes honcho sync                   # Wypełnia podmioty AI dla istniejących profili

OpenViking

Najlepsze dla: zarządzania wiedzą hostowanego samodzielnie z ustrukturyzowaną nawigacją.

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

Zależności zewnętrzne: OpenViking wymaga VLM (modelu językowego wizyjnego) do przetwarzania semantycznego i ekstrakcji pamięci oraz modelu embeddingów do wyszukiwania wektorowego – oba są wymagane. Wspierani dostawcy VLM to OpenAI, Anthropic, DeepSeek, Gemini, Moonshot i vLLM (do wdrożenia lokalnego). Dla embeddingów wspierani dostawcy to OpenAI, Volcengine (Doubao), Jina, Voyage oraz – poprzez Ollama – każdy model embeddingów obsługiwany lokalnie. Interaktywny kreator openviking-server init może wykryć dostępną pamięć RAM i zasugerować odpowiednie modele Ollama (np. Qwen3-Embedding 8B dla embeddingów, Gemma 4 27B dla VLM) oraz skonfigurować wszystko automatycznie dla w pełni lokalnego, bezkluczowego API setupu. 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 ustawień lokalnych)
openviking-server
hermes memory setup  # wybierz "openviking"
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

Najlepsze dla: zarządzania pamięcią bez interwencji z automatyczną ekstrakcją.

Mem0 obsługuje ekstrakcję pamięci po stronie serwera poprzez wywołanie LLM przy każdej operacji add – czyta rozmowę, ekstrahuje dyskretne fakty, usuwa duplikaty i przechowuje je. Zarządzany interfejs API w chmurze obsługuje całą infrastrukturę. Biblioteka open-source i samodzielny serwer dają pełną kontrolę.

Zależności zewnętrzne: Mem0 wymaga LLM do ekstrakcji pamięci (domyślnie: OpenAI gpt-4.1-nano; obsługiwanych jest 20 dostawców, w tym Ollama, vLLM i LM Studio dla modeli lokalnych) oraz modelu embeddingów do odzyskiwania (domyślnie: OpenAI text-embedding-3-small; obsługiwanych jest 10 dostawców, w tym Ollama i HuggingFace dla modeli lokalnych). Przechowywanie używa Qdrant w /tmp/qdrant w trybie biblioteki lub PostgreSQL z pgvector w trybie serwera hostowanego samodzielnie – oba mogą działać lokalnie. W pełni lokalny, bezchmurowy stos Mem0 jest osiągalny: Ollama dla LLM, Ollama dla embeddingów i lokalna instancja Qdrant, wszystko skonfigurowane poprzez Memory.from_config.

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

Najlepsze dla: odzyskiwania 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. Odzyskiwanie uruchamia cztery strategie równolegle (semantyczną, słowową/BM25, traversing grafu, temporalną), a następnie łączy i reorganizuje wyniki używając reciprocal rank fusion.

Zależności zewnętrzne: Hindsight wymaga LLM do ekstrakcji faktów i encji przy wywołaniach retain oraz do syntezy przy wywołaniach reflect (domyślnie: OpenAI; obsługiwani dostawcy to Anthropic, Gemini, Groq, Ollama, LM Studio i dowolny endpoint zgodny z OpenAI). Model embeddingów i model rerankingu cross-encoder są wbudowane w sam Hindsight – działają lokalnie wewnątrz pakietu hindsight-all i nie wymagają zewnętrznego API. PostgreSQL jest również wbudowany z wbudowaną instalacją Pythona poprzez zarządzany katalog danych pg0; możesz również wskazać Hindsight na zewnętrzną instancję PostgreSQL. Dla w pełni lokalnego, bezchmurowego setupu, ustaw HINDSIGHT_API_LLM_PROVIDER=ollama i skieruj go na lokalny model Ollama – retain i recall działają 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=your-key" >> ~/.hermes/.env

Autoinstaluje 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

Najlepsze dla: ustawień skoncentrowanych 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 Twoim sprzęcie.

Zależności zewnętrzne: Brak. Holographic nie wymaga LLM, modelu embeddingów, bazy danych ani połączenia sieciowego. Kodowanie pamięci jest wykonywane w całości poprzez algebra HRR działającą w procesie. Sprawia to, że jest on unikalny spośród wszystkich ośmiu dostawców – jest jedynym, który działa z zerowym wywołaniami zewnętrznymi. Kompromisem jest to, że jakość odzyskiwania jest niższa niż w wyszukiwaniu semantycznym opartym na embeddingach, a nie ma 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ą bezwarunkowe, Holographic jest jedyną opcją, która dostarcza to bezwarunkowo.

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

Konfiguracja:

hermes memory setup  # wybierz "holographic"

RetainDB

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

RetainDB używa kompresji delta do efektywnego przechowywania aktualizacji pamięci i hybrydowego odzyskiwania (wektor + BM25 + reranking) do wyświetlania odpowiedniego kontekstu. Jest oparte na chmurze z kosztem $20/miesiąc, z całą obróbką pamięci obsługiwaną po stronie serwera.

Zależności zewnętrzne: Wywołania LLM RetainDB, potok embeddingów i reranking działają na własnej infrastrukturze chmurowej RetainDB – dostarczasz tylko RETAINDB_KEY. Ekstrakcja pamięci używa Claude Sonnet po stronie serwera. Nie ma opcji hostowania lokalnego ani trybu lokalnego. Wszystkie dane konwersacji są wysyłane na serwery RetainDB do obróbki i przechowywania. Jeśli suwerenność danych lub działanie offline mają znaczenie dla Twojego przypadku użycia, ten dostawca nie jest 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

Najlepsze dla: pamięci lokalnej pierwszej z czytelnością dla człowieka i audytowalnym przechowywaniem.

ByteRover przechowuje pamięć jako ustrukturyzowane drzewo kontekstu markdown – hierarchię plików domen, tematów i podtematów – zamiast wektorów embeddingów lub bazy danych. LLM czyta treść źródłową, wnosi wnioski i umieszcza ekstrahowaną wiedzę w odpowiednim miejscu w hierarchii. Odzyskiwanie to wyszukiwanie pełnotekstowe MiniSearch z warstwowym fallbackiem do wyszukiwania napędzanego LLM, bez wymagania bazy wektorowej.

Zależności zewnętrzne: ByteRover wymaga LLM do kurytowania pamięci i wyszukiwania (obsługiwanych jest 18 dostawców, w tym Anthropic, OpenAI, Google, Ollama i dowolny endpoint zgodny z OpenAI poprzez slot dostawcy openai-compatible). Nie wymaga modelu embeddingów ani bazy danych – drzewo kontekstu to lokalny katalog plików markdown. Synchronizacja chmurowa jest opcjonalna i używana tylko do współpracy zespołowej; wszystko działa w pełni offline domyślnie. Dla w pełni lokalnego, samodzielnego setupu, podłącz Ollama jako dostawcę (brv providers connect openai-compatible --base-url http://localhost:11434/v1) i żadne dane nie opuszczą Twojego urządzenia.

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

Konfiguracja:

hermes memory setup  # wybierz "byterover"

Supermemory

Najlepsze dla: przepływów pracy enterprise z ograniczaniem kontekstu i importem grafu sesji.

Supermemory dostarcza ograniczanie kontekstu (izolowanie pamięci po kontekście) i import grafu sesji (import całych historii konwersacji). Automatycznie ekstrahuje wspomnienia, buduje profile użytkowników i uruchamia hybrydowe odzyskiwanie łączące wyszukiwanie semantyczne i słowowe. Zarządzany interfejs API w chmurze jest głównym celem wdrożenia.

Zależności zewnętrzne: Usługa chmurowa Supermemory obsługuje całą inferencję LLM i serwer embeddingów po stronie serwera – dostarczasz tylko klucz API Supermemory. Hostowanie samodzielne jest dostępne wyłącznie jako dodatek do planu enterprise i wdraża się na Cloudflare Workers; wymaga dostarczenia PostgreSQL z rozszerzeniem pgvector (do przechowywania wektorów) i klucza API OpenAI (wymagany, z Anthropic i Gemini jako opcjonalne dodatki). Nie ma ścieżki hostowania lokalnego opartej na Dockerze ani lokalnej – architektura jest ściśle powiązana z obliczeniami krawędziowymi Cloudflare Workers. Dla użytkowników, którzy potrzebują pełnej suwerenności danych bez kontraktu enterprise, ten dostawca nie jest odpowiednim wyborem.

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

Konfiguracja:

hermes memory setup  # wybierz "supermemory"

Jak wybrać

• Potrzebujesz wsparcia wieloagentowego? Honcho
• Chcesz samodzielne hostowanie i darmowo? OpenViking lub Holographic
• Chcesz zero-konfiguracji? Mem0
• Chcesz grafy wiedzy? Hindsight
• Chcesz kompresję delta? RetainDB
• Chcesz efektywność przepustowości? ByteRover
• Chcesz funkcje enterprise? Supermemory
• Chcesz prywatność (tylko lokalnie)? Holographic
• Chcesz w pełni lokalnie z zerowymi usługami zewnętrznymi? Holographic (bez żadnych zależności) lub Hindsight/Mem0/ByteRover z Ollama
• Chcesz czytelne dla człowieka, audytowalne wspomnienia bez potoku embeddingów? ByteRover

W sprawie pełnych konfiguracji dostawców profil po profilu i rzeczywistych wzorców przepływów pracy, zobacz Produkcjne ustawienie Hermes Agent.

Powiązane przewodniki

• Centrum pamięci systemów AI – zakres tego podklastera i linki do przewodników Cognee
• System pamięci agenta Hermes – rdzeniowa pamięć dwuplikowa przed wtyczkami
• Produkcjne ustawienie Hermes Agent – podłączanie dostawców w praktyce