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

Nowoczesne asystenci nadal zapominają wszystko, gdy zamkniesz kartę, chyba że coś przetrwa poza oknem kontekstu. Dostawcy pamięci agentów to usługi lub biblioteki, które przechowują fakty i podsumowania 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 dla Hermes Agent – Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover i Supermemory – oraz wyjaśnia, jak wpisują się one w szersze stosy systemów AI. Te same dostawcy pojawiają się w OpenClaw i innych narzędziach dla agentów poprzez integracje społecznościowe lub oficjalne. Centrum pamięci systemów AI wymienia ten artykuł obok Cognee i powiązanych przewodników.

W przypadku specyficznej dla Hermes ograniczonej pamięci rdzeniowej (MEMORY.md i USER.md), zachowania „zamrażania” i wyzwalaczy, zobacz System pamięci agenta Hermes.

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

Zależności zewnętrzne. Każdy zewnętrzny dostawca z wyjątkiem Holographic wymaga co najmniej jednego połączenia z zewnętrzną usługą – 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średni wpływ na prywatność, koszty oraz możliwość pełnego hostingu własnego stosu pamięci. Hindsight i ByteRover redukują 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 punkt końcowy zgodny z OpenAI, można kierować wywołania LLM i embeddingów do modelu lokalnego i całkowicie unikać wysyłania danych na serwery stron trzecich.

Aktywacja z 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 do: systemów wieloagentowych, kontekstu między sesjami, alignmentu użytkownika-agents.

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 partnerami — jeden partner użytkownika plus jeden partner AI na profil Hermes, wszyscy współdzielący przestrzeń roboczą.

Zależności zewnętrzne: Honcho wymaga LLM do podsumowywania sesji, wyprowadzania reprezentacji użytkownika i rozmyślenia dialektycznego; modelu embeddingów do wyszukiwania semantycznego wśród obserwacji; PostgreSQL z rozszerzeniem pgvector do przechowywania wektorów; oraz Redis do cache. Zarządzana chmura na api.honcho.dev obsługuje to wszystko za Ciebie. W przypadku wdrożeń własnych (Docker, K3s lub Fly.io) dostarczasz własne dane uwierzytelniające. Slot LLM akceptuje dowolny punkt końcowy zgodny z OpenAI, w tym Ollama i vLLM, więc wnioskowanie może pozostawać na miejscu. Slot embeddingów domyślnie używa openai/text-embedding-3-small, ale obsługuje konfigurowalnych dostawców przez LLM_EMBEDDING_API_KEY i LLM_EMBEDDING_BASE_URL — działa z dowolnym serwerem embeddingów zgodnym z OpenAI, w tym opcjami lokalnymi takimi jak vLLM z modelem BGE.

Narzędzia: honcho_profile (odczytaj/aktualizuj kartę partnera), honcho_search (wyszukiwanie semantyczne), honcho_context (kontekst sesji — podsumowanie, reprezentacja, karta, wiadomości), honcho_reasoning (syntetyzowane przez LLM), honcho_conclude (twórz/usuwaj wnioski).

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): Przekazy .chat() na każde wywołanie (ograniczone do 1-3)
• recallMode (domyślnie ‘hybrid’): hybrid (auto+narzędzia), context (tylko wstrzyknięcie), tools (tylko narzędzia)
• writeFrequency (domyślnie ‘async’): Czas zapisu: async, turn, session lub liczba całkowita N
• observationMode (domyślnie ‘directional’): directional (wszystkie włączone) lub unified (wspólny pul)

Architektura: Dwuwarstwowe wstrzykiwanie kontekstu — warstwa bazowa (podsumowanie sesji + reprezentacja + karta partnera) + uzupełnienie dialektyczne (rozmyślanie LLM). Automatycznie wybiera prompty startowe zimne vs ciepłe.

Mapowanie wielu partnerów: Przestrzeń robocza jest środowiskiem współdzielonym między profilami. Partner użytkownika (peerName) to globalna tożsamość ludzka. Partner 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 do 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                   # Dopasowuje partnerów AI dla istniejących profili

OpenViking

Najlepsze do: zarządzania wiedzą własnego hostingu z ustrukturyzowaną nawigacją.

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

Zależności zewnętrzne: OpenViking wymaga VLM (modelu językowo-wizualnego) do przetwarzania semantycznego i ekstrakcji pamięci oraz modelu embeddingów do wyszukiwania wektorowego — oba są wymagane. Obsługiwani dostawcy VLM to OpenAI, Anthropic, DeepSeek, Gemini, Moonshot i vLLM (do wdrożenia lokalnego). Dla embeddingów obsługiwani dostawcy to OpenAI, Volcengine (Doubao), Jina, Voyage oraz — przez Ollama — dowolny 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) i skonfigurować wszystko automatycznie dla w pełni lokalnego setupu bez kluczy API. Nie wymaga zewnętrznej bazy 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 (sugeruje modele Ollama dla setupu lokalnego)
openviking-server
hermes memory setup  # wybierz "openviking"
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

Najlepsze do: 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 — odczytuje rozmowę, ekstrahuje dyskretne fakty, usuwa duplikaty i je przechowuje. Zarządzany API chmurowy obsługuje całą infrastrukturę. Biblioteka open-source i serwer własnego hostingu 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 własnego hostingu — 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 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=your-key" >> ~/.hermes/.env

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

Hindsight

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

Hindsight buduje graf wiedzy z 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. Przywoływanie uruchamia cztery strategie odzyskiwania równolegle (semantyczną, słów kluczowych/BM25, traversing grafu, temporalną), a następnie łączy i ponownie uporządkowuje 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 punkt końcowy zgodny z OpenAI). Model embeddingów i model rerankowania cross-encoder są wbudowane w samym Hindsight — działają lokalnie w pakiecie hindsight-all i nie wymagają zewnętrznego API. PostgreSQL jest również wbudowany z wbudowaną instalacją Python przez zarządzany katalog danych pg0; możesz też skierować Hindsight do zewnętrznej instancji PostgreSQL. Dla w pełni lokalnego, bezchmurowego setupu, ustaw HINDSIGHT_API_LLM_PROVIDER=ollama i skieruj go do lokalnego modelu 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

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)

UI lokalne: hindsight-embed -p hermes ui start

Holographic

Najlepsze do: setupów skupionych na prywatności z wyłącznie lokalnym przechowywaniem.

Holographic używa algebry HRR (Holographic Reduced Representation) do kodowania pamięci, z scoringiem 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 całkowicie przez algebrę HRR działającą w procesie. To czyni go unikalnym spośród wszystkich ośmiu dostawców — jest jedynym, który działa z zerowymi zewnętrznymi wywołaniami. Kompromisem jest niższa jakość odzyskiwania niż w przypadku wyszukiwania semantycznego opartego na embeddingach, oraz brak syntezy między-pamięciowej jak w reflect Hindsight. Dla użytkowników, dla których prywatność i działanie bez zależności są warunkiem koniecznym, Holographic jest jedyną opcją, która dostarcza to bezwarunkowo.

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

Konfiguracja:

hermes memory setup  # wybierz "holographic"

RetainDB

Najlepsze do: częstych aktualizacji z kompresją deltową.

RetainDB używa kompresji deltowej do efektywnego przechowywania aktualizacji pamięci i hybrydowego odzyskiwania (wektor + BM25 + reranking) do wyświetlania odpowiedniego kontekstu. Jest oparte na chmurze z kosztem 20 dolarów miesięcznie, z całym przetwarzaniem pamięci obsługiwane 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 własnego hostingu ani trybu lokalnego. Wszystkie dane konwersacji są wysyłane na serwery RetainDB do przetwarzania i przechowywania. Jeśli suwerenność danych lub działanie offline ma 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 (przechowuj z typem + ważnością), retaindb_forget (usuń wspomnienia).

Konfiguracja:

hermes memory setup  # wybierz "retaindb"

ByteRover

Najlepsze do: pamięci lokalnej pierwszej z ludzko-czytelnym, 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 odczytuje treść źródłową, rozmyśla nad nią i umieszcza ekstrahowaną wiedzę w odpowiednim miejscu w hierarchii. Odzyskiwanie to pełnotekstowe wyszukiwanie MiniSearch z warstwowym fallbackiem do wyszukiwania napędzanego przez LLM, bez konieczności bazy danych wektorowej.

Zależności zewnętrzne: ByteRover wymaga LLM do kurytury pamięci i wyszukiwania (obsługiwanych jest 18 dostawców, w tym Anthropic, OpenAI, Google, Ollama i dowolny punkt końcowy zgodny z OpenAI przez 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 samodzielnego setupu lokalnego, podłącz Ollama jako dostawcę (brv providers connect openai-compatible --base-url http://localhost:11434/v1) i żadne dane nie opuszczają Twojego komputera.

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

Konfiguracja:

hermes memory setup  # wybierz "byterover"

Supermemory

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

Supermemory zapewnia ograniczanie kontekstu (izolowanie pamięci według kontekstu) i import grafu sesji (importowanie całych historii konwersacji). Automatycznie ekstrahuje wspomnienia, buduje profile użytkowników i uruchamia hybrydowe odzyskiwanie łączące wyszukiwanie semantyczne i słów kluczowych. Zarządzany API chmurowy jest głównym celem wdrożenia.

Zależności zewnętrzne: Chmurowa usługa Supermemory obsługuje całe wnioskowanie LLM i serwery embeddingów po stronie serwera — dostarczasz tylko klucz API Supermemory. Własny hosting jest dostępny wyłącznie jako dodatek do planu enterprise i wdrażany 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 własnego hostingu opartej na Dockerze ani lokalnej — architektura jest ściśle powiązana z obliczaniem brzegowym Cloudflare Workers. Dla użytkowników, którzy potrzebują pełnej suwerenności danych bez kontraktu enterprise, ten dostawca nie jest właściwym wyborem.

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

Konfiguracja:

hermes memory setup  # wybierz "supermemory"

Jak wybrać

• Potrzebujesz wsparcia dla wielu agentów? Honcho
• Chcesz własnego hostingu i darmowo? OpenViking lub Holographic
• Chcesz zero konfiguracji? Mem0
• Chcesz grafy wiedzy? Hindsight
• Chcesz kompresję deltową? RetainDB
• Chcesz efektywność przepustowości? ByteRover
• Chcesz funkcje enterprise? Supermemory
• Chcesz prywatność (tylko lokalnie)? Holographic
• Chcesz w pełni lokalnie z zerowymi zewnętrznymi usługami? Holographic (brak zależności w ogóle) lub Hindsight/Mem0/ByteRover z Ollama
• Chcesz ludzko-czytelną, audytowalną pamięć bez potoku embeddingów? ByteRover

Dla pełnych konfiguracji dostawców profil po profilu i rzeczywistych wzorców przepływów pracy, zobacz Konfiguracja produkcyjna agenta Hermes.

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
• Konfiguracja produkcyjna agenta Hermes — podłączanie dostawców w praktyce