Porównanie dostawców pamięci agentów: polityka przechwytywania i hostowanie we własnym zakresie
Polityka przechwytywania ma teraz tak duże znaczenie jak recall.
Zaktualizowano we wrześniu 2026: dodano Mnemosyne i Memori, rozszerzono konfigurację Honcho oraz Hindsight, a także dodano porównanie polityk przechwytywania obok oryginalnej tabeli infrastrukturalnej.
Nowoczesni asystenci nadal zapominają wszystko po zamknięciu karty, chyba że coś zostaje utrwalone poza oknem kontekstowym. Dostawcy pamięci agentów to usługi lub biblioteki przechowujące fakty i podsumowania między sesjami — często integracja jako wtyczki, dzięki czemu framework pozostaje lekki, a pamięć skalowalna.
Ten przewodnik porównuje backendy pamięci, które są dostarczane jako zewnętrzne wtyczki pamięci Hermes Agent — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory, Mnemosyne oraz Memori — i wyjaśnia, jak pasują do szerszych stosów systemów AI. Te same dostawcy pojawiają się w OpenClaw i innych narzędziach agentic przez integracje społecznościowe lub oficjalne. Hub Pamięci Systemów AI wymienia ten artykuł obok Cognee i powiązanych przewodników.
W przypadku ograniczonej pamięci rdzeniowej specyficznej dla Hermes (MEMORY.md i USER.md), zachowań zamarzania i wyzwalaczy, patrz System Pamięci Hermes Agent. W kontekście tego, jak natywne dostawcy pamięci Hermes przyczyniają się do rosnącej przewagi w adopcji nad OpenClaw — w tym liczbę gwiazdek na GitHubie, rankingi tokenów OpenRouter i porównania rozmiaru ekosystemu — patrz OpenClaw vs Hermes Agent: Gwiazdki, Pobrania i Użycie 2026.
Istnieje oś, która ma znaczenie równie duże jak jakość wyszukiwania: zarządzanie pamięcią. Dostawcy różnią się znacznie w tym, co przechwytują automatycznie, czy wygenerowana przez asystenta treść może stać się trwałą pamięcią, czy refleksje są przechowywane jako fakty, jak rozwiązywane są sprzeczności i czy człowiek może zweryfikować zapis, zanim stanie się przyszłym kontekstem. Długotrwałym agentom te różnice mogą znaczyć więcej niż kilka dodatkowych punktów w benchmarku przywoływania — patrz Samopodtrzymujące pętle pamięci w agentach AI dlaczego automatyczne przechwytywanie może przekształcić wygenerowany wniosek w przyszłe założenie, oraz Mnemosyne dla Hermes Agent: Szybki start z pamięcią lokalną dla przykładu konserwatywnej konfiguracji.
Hermes Agent wymienia dziesięć zewnętrznych wtyczek dostawców pamięci dla trwałej, wielosesyjnej wiedzy — oryginalne osiem plus Mnemosyne i Memori. Tylko jeden zewnętrzny dostawca może być aktywny w danym momencie. Wbudowane MEMORY.md i USER.md pozostają załadowane obok niego — jest to rozszerzenie, a nie zastąpienie.
Zależności zewnętrzne. Każdy zewnętrzny dostawca z wyjątkiem Holographic wymaga co najmniej jednego wywołania zewnętrznej usługi — LLM do ekstrakcji pamięci, modelu embeddings do wyszukiwania semantycznego lub bazy danych takiej jak PostgreSQL do przechowywania. Te zależności mają bezpośredni wpływ na prywatność, koszty i to, czy Twój stos pamięci może działać w pełni w trybie self-hosted. Hindsight, ByteRover i Mnemosyne minimalizują lub eliminują większość zależności; Honcho, Mem0 i Supermemory wymagają największej liczby komponentów. Gdy dostawca obsługuje Ollama lub dowolny punkt końcowy zgodny z OpenAI, możesz kierować wywołania LLM i embeddings do modelu lokalnego, trzymając dane z dala od serwerów stron trzecich.

Aktywacja w Hermes Agent
Poniższe kroki wiersza poleceń odzwierciedlają tabele z ściągawki CLI Hermes Agent.
hermes memory setup # Interaktywny wybór + konfiguracja
hermes memory status # Sprawdź, co jest aktywne
hermes memory off # Wyłącz zewnętrzny dostawca
Lub ręcznie w ~/.hermes/config.yaml:
memory:
provider: openviking # lub honcho, mem0, hindsight, holographic, retaindb, byterover, supermemory, mnemosyne, memori
Porównanie dostawców
| Dostawca | Przechowywanie | Koszt | Zależności zewnętrzne | Self-hostable | Unikalna funkcja |
|---|---|---|---|---|---|
| Honcho | Chmura/Self-hosted | Płatne/Bezpłatne | LLM + model embeddings + PostgreSQL/pgvector + Redis | Tak — Docker / K3s / Fly.io | Diagonalne modelowanie użytkownika + kontekst zakresu sesji |
| OpenViking | Self-hosted | Bezpłatne | LLM (VLM) + model embeddings | Tak — serwer lokalny; kreator inicjalizacji natywnie Ollama | Hierarchia systemu plików + wielopoziomowe ładowanie |
| Mem0 | Chmura/Self-hosted | Płatne/Bezpłatne OSS | LLM + model embeddings + magazyn wektorowy (Qdrant lub pgvector) | Tak — Docker Compose OSS; w pełni lokalny możliwy | Ekstrakcja LLM po stronie serwera |
| Hindsight | Chmura/Lokalne | Bezpłatne/Płatne | LLM + wbudowany PostgreSQL + wbudowany embedder + wbudowany reranker | Tak — Docker lub wbudowany Python; w pełni lokalnie z Ollama | Graf wiedzy + synteza reflect |
| Holographic | Lokalne | Bezpłatne | Brak | Natywne — brak wymaganej infrastruktury | Algebra HRR + scoring zaufania |
| RetainDB | Chmura | $20/mies. | Zarządzana chmura (LLM + wyszukiwanie na serwerach RetainDB) | Nie | Kompresja delt + diagonalny model własny |
| ByteRover | Lokalne/Chmura | Bezpłatne/Płatne | Tylko LLM — bez modelu embeddings, bez DB | Tak — lokalnie-pierwszy domyślnie; obsługa Ollama | Drzewo kontekstu oparte na plikach; brak pipeline’u embeddings |
| Supermemory | Chmura | Płatne | LLM + PostgreSQL/pgvector (wdrożenie enterprise Cloudflare) | Tylko plan enterprise | Ogrodzienie kontekstu + import grafu sesji |
| Mnemosyne | Lokalne (SQLite) | Bezpłatne | Tylko LLM do dodatkowych embeddings; brak dla core |
Tak — w pełni lokalnie domyślnie | Granularne kontrole retencji + lokalny magazyn FTS5/wektorowy |
| Memori | Chmura/Self-hosted | Płatne/Bezpłatne | LLM do ekstrakcji; przechwytywanie śladów wykonania | Częściowe | Przechwytywanie tura + śladu narzędzi/workflow |
Polityka przechwytywania i zarządzanie
Przechowywanie i zależności odpowiadają na pytanie „czy mogę to uruchomić?”. Poniższa tabela odpowiada na inne pytanie, które ma równie duże znaczenie dla długotrwałych agentów: co jest zapisywane bez pytania i czy człowiek lub polityka może interweniować, zanim stanie się trwałe? Patrz Samopodtrzymujące pętle pamięci w agentach AI dlaczego ta oś ma znaczenie.
| Dostawca | Automatyczne przechwytywanie | Wnioskowanie pochodne | Tryb tylko-jawny | Obsługa zatwierdzania |
|---|---|---|---|---|
| Holographic | Wyłączone domyślnie | Niskie | Tak | Brak kolejki dostawcy |
| Mnemosyne | Konfigurowalne (sync_roles) |
Fakty + konsolidacja | Tak | Staging specyficzny dla dostawcy |
| ByteRover | Konfigurowalne (auto_extract) |
Kuracja | Tak | Nie |
| Hindsight | Włączone domyślnie (autoRetain) |
Synteza reflect |
Tak (auto_retain: false) |
Nie |
| Mem0 | Automatyczna ekstrakcja | Ekstrakcja faktów | Ograniczone | Nie |
| OpenViking | Automatyczna ekstrakcja | Podsumowania wielopoziomowe | Częściowe | Nie |
| Supermemory | Pełny import sesji | Profil/graf | Częściowe | Nie |
| Memori | Przechwytywanie tura + śladu | Strukturalne przywoływanie | Ograniczone | Nie |
| Honcho | Obserwacja wiadomości/peerów (directional) |
Modelowanie diagonalne | Konfigurowalne (tryb unified) |
Nie |
| RetainDB | Bogaty import | Diagonalny + model własny | Ograniczone | Nie |
Są to kategorie ryzyka architektonicznego, a nie oceny jakości — starannie skonfigurowany zaawansowany dostawca może być w praktyce bezpieczniejszy niż źle skonfigurowany prosty.
Szczegółowy opis
Honcho
Najlepsze do: systemów wieloagentowych, kontekstu między sesjami, wyświadczenia 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ównorzędnych partnerów wymieniających wiadomości — jeden partner użytkownika oraz jeden partner AI na profil Hermes, wszyscy dzielący przestrzeń roboczą.
Zależności zewnętrzne: Honcho wymaga LLM do podsumowywania sesji, wyznaczania reprezentacji użytkownika i rozumowania diagonalnego; modelu embeddings do wyszukiwania semantycznego między obserwacjami; PostgreSQL z rozszerzeniem pgvector do przechowywania wektorów; oraz Redis do cache. Zarządzana chmura na api.honcho.dev obsługuje wszystko to za Ciebie. W wdrożeniach self-hosted (Docker, K3s lub Fly.io) dostarczasz własne poświadczenia. Slot LLM przyjmuje dowolny punkt końcowy zgodny z OpenAI, w tym Ollama i vLLM, dzięki czemu wnioskowanie może pozostać lokalne. Slot embeddings domyślnie ustawiony na openai/text-embedding-3-small, ale obsługuje konfigurowalnych dostawców przez LLM_EMBEDDING_API_KEY i LLM_EMBEDDING_BASE_URL — działa dowolny serwer embeddings zgodny z OpenAI, w tym opcje lokalne 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 (synteza LLM), honcho_conclude (tworzenie/usuwanie wniosków).
Główne pokrętła konfiguracji:
contextCadence(domyślnie 1): Minimalna liczba tur między odświeżeniami warstwy bazowejdialecticCadence(domyślnie 2): Minimalna liczba tur między wywołaniami LLMpeer.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 wstrzykiwanie),tools(tylko narzędzia)writeFrequency(domyślnie ‘async’): Czas odprawy:async,turn,sessionlub liczbą NobservationMode(domyślnie ‘directional’):directional(wszystkie włączone) lubunified(wspólny pulpit)
Tryby obserwacji i modelowanie własne. directional, domyślne dla nowych konfiguracji, pozwala zarówno partnerowi użytkownika, jak i AI obserwować siebie nawzajem — bogatsze rozumowanie diagonalne, ale oznacza to też, że wiadomości autorskie AI wnoszą do modelu AI w Honcho. unified to bardziej konserwatywna opcja: AI modeluje użytkownika na podstawie wiadomości użytkownika, nie budując dopasowanej pętli obserwacji własnej z własnego wyjścia. Każdy szczególnie zaniepokojony tym, że wygenerowane wnioski wpływają z powrotem na przyszłe rozumowanie — patrz Samopodtrzymujące pętle pamięci w agentach AI — powinien traktować unified jako bezpieczniejszy domyślnie.
Architektura: Dwuwarstwowe wstrzykiwanie kontekstu — warstwa bazowa (podsumowanie sesji + reprezentacja + karta partnera) + suplement diagonalny (rozumowanie LLM). Automatycznie wybiera prompty zimnego startu vs ciepłe.
Mapowanie wielopartnerowe: Przestrzeń robocza jest wspólnym środowiskiem między profilami. Partner użytkownika (peerName) jest globalną tożsamością ludzką. Partner AI (aiPeer) jest jeden na profil Hermes (hermes domyślnie, hermes.<profil> dla innych).
Ustawienia:
hermes memory setup # wybierz "honcho"
# lub legacy: 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ólną przestrzenią roboczą
hermes honcho sync # Backfilluje partnerów AI dla istniejących profili
OpenViking
Najlepsze do: zarządzania wiedzą self-hosted z przeglądaniem strukturalnym.
OpenViking zapewnia hierarchię systemu plików z wielopoziomowym ładowaniem. Jest darmowy, self-hosted i daje pełną kontrolę nad przechowywaniem pamięci.
Zależności zewnętrzne: OpenViking wymaga VLM (modelu język-wizja) do przetwarzania semantycznego i ekstrakcji pamięci oraz modelu embeddings do wyszukiwania wektorowego — oba są obowiązkowe. Obsługiwani dostawcy VLM to m.in. OpenAI, Anthropic, DeepSeek, Gemini, Moonshot i vLLM (do wdrożeń lokalnych). Do embeddings obsługiwani dostawcy to m.in. OpenAI, Volcengine (Doubao), Jina, Voyage oraz — przez Ollama — dowolnie serwowany lokalnie model embeddings. Interaktywny kreator openviking-server init może wykryć dostępną pamięć RAM i zalecić odpowiednie modele Ollama (np. Qwen3-Embedding 8B do embeddings, Gemma 4 27B do VLM) i automatycznie skonfigurować wszystko dla w pełni lokalnego setupu bez kluczy API. Nie jest wymagana zewnętrzna baza danych; OpenViking przechowuje pamięć w systemie plików.
Narzędzia: viking_search, viking_read (wielopoziomowe), viking_browse, viking_remember, viking_add_resource.
Pamięć użytkownika vs pamięć agenta. Model tożsamości OpenViking może oddzielić przestrzeń nazw pamięci użytkownika od opcjonalnego partnera asystenta. To rozdzielenie ma znaczenie dla higieny pamięci: fakty o użytkowniku i doświadczenie wygenerowane przez agenta nie muszą dzielić tej samej polityki retencji, co jest użyteczną własnością, jeśli chcesz izolować stan autorstwa asystenta od stanu autorstwa użytkownika.
Ustawienia:
pip install openviking
openviking-server init # interaktywny kreator (rekomenduje modele Ollama do setupu lokalnego)
openviking-server
hermes memory setup # wybierz "openviking"
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env
Mem0
Najlepsze do: bezobsługowego zarządzania pamięcią z automatyczną ekstrakcją.
Mem0 obsługuje ekstrakcję pamięci po stronie serwera przez wywołanie LLM przy każdej operacji add — czyta rozmowę, ekstrahuje dyskretne fakty, deduplikuje i przechowuje. Zarządzane API chmurowe obsługuje całą infrastrukturę. Biblioteka open-source i serwer self-hosted dają pełną kontrolę.
Zależności zewnętrzne: Mem0 wymaga LLM do ekstrakcji pamięci (domyślnie: OpenAI gpt-4.1-nano; obsługuje 20 dostawców, w tym Ollama, vLLM i LM Studio do modeli lokalnych) i modelu embeddings do wyszukiwania (domyślnie: OpenAI text-embedding-3-small; obsługuje 10 dostawców, w tym Ollama i HuggingFace do modeli lokalnych). Przechowywanie używa Qdrant w /tmp/qdrant w trybie biblioteki lub PostgreSQL z pgvector w trybie serwera self-hosted — oba mogą działać lokalnie. W pełni lokalny, bezchmurowy stos Mem0 jest osiągalny: Ollama do LLM, Ollama do embeddings i lokalna instancja Qdrant, wszystko skonfigurowane przez Memory.from_config.
Mem0 to fundamentalnie system ekstrakcji: LLM przekształca materiał konwersacyjny na dyskretne pamięci i wykonuje logikę deduplikacji i aktualizacji. To wygodne, ale oznacza to, że pochodzenie ekstrakcji ma znaczenie — wygenerowany wniosek asystenta może stać się strukturalnie nierozróżnialny od faktu wypowiedzianego przez użytkownika, jeśli ścieżka przechwytywania nie odfiltruje go przed wykonaniem ekstrakcji.
Narzędzia: mem0_profile, mem0_search, mem0_conclude.
Ustawienia:
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 Twojej pamięci, ekstrahując encje i relacje. Jego unikalne narzędzie reflect wykonuje syntezę między pamięciami — łącząc wiele pamięci w nowe wnioski. Przywoływanie uruchamia cztery strategie wyszukiwania równolegle (semantyczne, słowo kluczowe/BM25, przechodzenie grafu, czasowe), a następnie scala i ponownie sortuje wyniki, używając fuzji rang wzajemnej.
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 m.in. Anthropic, Gemini, Groq, Ollama, LM Studio i dowolny punkt końcowy zgodny z OpenAI). Embeddings i reranking domyślnie używają lokalnych modeli procesowych (SentenceTransformers; gruby obraz Docker/hindsight-all zawiera BGE + MiniLM), a możesz je zamienić na inne modele lokalne lub zewnętrzny punkt końcowy zgodny z OpenAI / TEI — na przykład Qwen3-Embedding-0.6B i BGE-reranker-v2-m3 na CPU. PostgreSQL jest wbudowany przez zarządzany katalog danych pg0, lub możesz skierować Hindsight na zewnętrzną instancję PostgreSQL. Dla w pełni lokalnej ścieżki generatywnej ustaw HINDSIGHT_API_LLM_PROVIDER na lokalny serwer zgodny z OpenAI (Ollama lub llama.cpp); retain i recall działają w pełni, a reflect wymaga modelu zdolnego do wywoływania narzędzi.
Narzędzia: hindsight_retain, hindsight_recall, hindsight_reflect (unikalna synteza między pamięciami).
Ustawienia:
hermes plugins install hindsight
hermes memory setup hindsight # wybierz local_external dla osobnego API Hindsight
Tryb chmurowy nadal przyjmuje klucz API w ~/.hermes/.env. Instalacja self-hosted używa Docker Compose wobec wbudowanego lub istniejącego PostgreSQL — patrz przewodnik poniżej. Wymaga aktualnej pary klienta/API Hindsight (dokumentacja wtyczki cytuje >= 0.4.22).
Konfiguracja: $HERMES_HOME/hindsight/config.json
mode:cloud,locallublocal_externalrecall_budget:low/mid/highmemory_mode:hybrid/context/toolsauto_retain/auto_recall:true(domyślnie)
Lokalny UI: hindsight-embed -p hermes ui start
Po pełny przewodnik self-hosted — Docker Compose, lokalne embeddings i reranking, kontrola ścieżki zapisu (auto_retain) i połączenie local_external w Hermes — patrz Hindsight dla Hermes Agent: Self-Hosted Pamięć z LLM lokalnymi.
Dla konserwatywnej higieny pamięci rozważenie ustawienia auto_retain=false przy pozostawieniu auto_recall=true jest warte rozważenia — semantyczne przywoływanie pozostaje dostępne, ale zakończone tury nie wchodzą już automatycznie do pamięci długoterminowej. Traktuj wyjście reflect jako wiedzę pochodną syntezowaną przez pamięci, a nie jako niezależną obserwację o tej samej sile dowodowej co pamięci, z których została zbudowana.
Holographic
Najlepsze do: ustawień zorientowanych na prywatność z wyłącznie lokalnym przechowywaniem.
Holographic używa algebry HRR (Holographic Reduced Representation) do kodowania pamięci, ze scoringiem zaufania dla wiarygodnoś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 LLM, modelu embeddings, 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 wśród wszystkich dostawców w tym porównaniu — jest jedynym, który działa z zerowym wywołaniem zewnętrznym. Kompromisem jest to, że jakość wyszukiwania jest niższa niż semantyczne wyszukiwanie oparte na embeddings, i nie ma syntezy między pamięciami jak reflect w Hindsight. Dla użytkowników, dla których prywatność i działanie bez zależności są warunkiem sine qua non, Holographic jest jedyną opcją, która to gwarantuje bezwarunkowo.
auto_extract domyślnie ustawione na false, więc Holographic może działać głównie jako mała jawna baza danych faktów ze scoringiem zaufania, a nie jako autonomiczny pipeline transkrypt-do-pamięci. Połączone z zerowymi zależnościami, czyni go jednym z dwóch najprostszych opcji — obok Mnemosyne — dla czytelników, którzy świadomie nie chcą automatycznego przechwytywania.
Narzędzia: 2 narzędzia do operacji pamięci przez algebrę HRR.
Ustawienia:
hermes memory setup # wybierz "holographic"
RetainDB
Najlepsze do: częstych aktualizacji z kompresją delt.
RetainDB używa kompresji delt do efektywnego przechowywania aktualizacji pamięci i hybrydowego wyszukiwania (wektor + BM25 + reranking) do wyłaniania relewantnego kontekstu. Jest oparty na chmurze z kosztem $20/miesiąc, z całym przetwarzaniem pamięci po stronie serwera.
Zależności zewnętrzne: Wywołania LLM, pipeline embeddings i reranking RetainDB 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 self-hosting ani trybu lokalnego. Wszystkie dane rozmowy są wysyłane na serwery RetainDB do przetwarzania i przechowywania. Jeśli suwerenność danych lub praca offline ma znaczenie w Twoim przypadku, ten dostawca nie jest odpowiedni.
Narzędzia: retaindb_profile (profil użytkownika), retaindb_search (wyszukiwanie semantyczne), retaindb_context (kontekst relewantny dla zadania), retaindb_remember (zapisz z typem + znaczeniem), retaindb_forget (usuń pamięci).
Integracja RetainDB z Hermes rozrosła się poza zdalną bazę danych pamięci — teraz zawiera syntezę diagonalną i model własny agenta, co architektonicznie przybliża go do Honcho niż do prostego magazynu wektorowego. To użyteczne dla ciągłości, ale też podnosi znaczenie rozdzielenia faktów źródłowych od wygenerowanej interpretacji, tego samego problemu, który dotyczy trybu directional Honcho.
Ustawienia:
hermes memory setup # wybierz "retaindb"
Mnemosyne
Najlepsze do: lokalnej-pierwszej pamięci z granularnymi kontrolami retencji, inspekcyjnym przechowywaniem SQLite, strukturalnych faktów, pamięci temporalnej i konfigurowalnej konsolidacji.
Mnemosyne nie jest jednym z oryginalnych dostawców pamięci Hermes — jest dostarczany jako osobna wtyczka dostawcy Hermes, ale integruje się przez ten sam interfejs MemoryProvider. Jego główną zaletą jest kontrola: automatyczne zapisywanie rozmowy może być ograniczone rolą lub całkowicie wyłączone przez sync_roles: [], logowanie wyników narzędzi jest domyślnie wyłączone, jawne operacje pamięć/odwołanie/zapomnij pozostają dostępne niezależnie, a nowsze wersje zawierają opcjonalne tłumienie samooksymianego echa wokół granic kompresji kontekstu.
Zależności zewnętrzne: Brak dla instalacji core; dodatkowy embeddings dodaje lokalne wyszukiwanie wektorowe. Przechowywanie to lokalny SQLite z FTS5 i opcjonalnym wyszukiwaniem wektorowym. System utrzymuje również pamięć roboczą, pamięć epizodyczną, strukturalne fakty, trójki temporalne, fakty kanoniczne i konsolidację.
Mnemosyne wdraża również specyficzne dla dostawcy stopniowe zapisy dla memory.write_approval Hermes, choć zatwierdzanie dla zewnętrznych dostawców nie jest jeszcze ustandaryzowane w Hermes, więc ta ścieżka powinna być testowana na dokładnych wersjach wdrażanych. Dodatkowa zaawansowanie ma koszt: pamięć pochodna tworzy więcej stanów cyklu życia do inspekcji i sprzątania. Ostatnie wersje Mnemosyne konkretnie zaostrzyły walidację konfliktów, zachowanie usuwania i obsługę samooksymianego echa — patrz Samopodtrzymujące pętle pamięci w agentach AI dla audytu produkcyjnego, który motywował zmianę walidacji konfliktów.
Ustawienia:
python -m pip install "mnemosyne-memory[embeddings]" mnemosyne-hermes
mnemosyne-hermes install
hermes config set memory.provider mnemosyne
Po pełną instalację i przewodnik po konserwatywnej konfiguracji, patrz Mnemosyne dla Hermes Agent: Szybki start z pamięcią lokalną.
Memori
Najlepsze do: agentów, gdzie historia wykonania ma takie znaczenie jak historia rozmowy.
Memori to nowsza integracja Hermes zorientowana na strukturalną pamięć świadomą narzędzi. Przechwytuje zakończone tury razem z dostępnym kontekstem wykonania — użycie narzędzi, kroki workflow, decyzje, wyniki i ograniczenia — co jest doskonałe do pamiętania pracy operacyjnej, ale też tworzy większą powierzchnię zwrotnej, ponieważ akcje, decyzje modelu i wyniki narzędzi mogą stać się trwałą strukturalną pamięcią.
W przeciwieństwie do dostawców, którzy głównie wstrzykują duży blok pamięci przed każdą turą, Memori ujawnia jawne narzędzia odwołania i podsumowania odwołania, pozwalając agentowi pobierać kontekst operacyjny, gdy faktycznie tego potrzebuje, a nie przy każdym prompcie. To redukuje zanieczyszczenie promptu, ale nie usuwa samej ryzyka zwrotnej po stronie zapisu — zakończone tury i ślady wykonania mogą nadal być przechwytywane automatycznie w tle, więc Memori pasuje do użytkowników, którzy chcą, aby agent uczył się z poprzedniej pracy, bardziej niż do instalacji wymagających ścisłej tylko-jawnej retencji.
Ustawienia:
pip install hermes-memori
hermes memory setup # wybierz "memori"
ByteRover
Najlepsze do: lokalnej-pierwszej pamięci z czytanym przez człowieka, audytowalnym przechowywaniem.
ByteRover przechowuje pamięć jako strukturalne drzewo kontekstu markdown — hierarchię plików dziedziny, tematu i podtematu — zamiast wektorów embeddings lub bazy danych. LLM czyta treść źródłową, wnioskuje o niej i umieszcza wyekstrahowaną wiedzę we właściwym miejscu w hierarchii. Wyszukiwanie to MiniSearch pełnotekstowe z wielopoziomowym fallbackiem do wyszukiwania napędzanego LLM, bez wymagania bazy danych wektorowej.
Zależności zewnętrzne: ByteRover wymaga LLM do kuracji pamięci i wyszukiwania (obsługuje 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 embeddings ani bazy danych — drzewo kontekstu to lokalny katalog zwykłych 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 samowystarczalnego lokalnego setupu, połącz Ollama jako dostawcę (brv providers connect openai-compatible --base-url http://localhost:11434/v1) i żadne dane nie opuszczają Twojego komputera.
Hermes ujawnia auto_extract: false do wyłączania automatycznych hooków kuracji, co przybliża ByteRover do Holographic i Mnemosyne w grupie dostawców, gdzie automatyczne przechwytywanie jest opcjonalne, a nie domyślne.
Narzędzia: 3 narzędzia do operacji pamięci.
Ustawienia:
hermes memory setup # wybierz "byterover"
Supermemory
Najlepsze do: workflow enterprise z ogrodzeniem kontekstu i importem grafu sesji.
Supermemory zapewnia ogrodzenie kontekstu (izolowanie pamięci według kontekstu) i import grafu sesji (importowanie całych historii rozmów). Automatycznie ekstrahuje pamięci, buduje profile użytkowników i wykonuje hybrydowe wyszukiwanie łączące semantyczne i słowo kluczowe. Zarządzane API chmurowe jest głównym celem wdrożenia.
Zależności zewnętrzne: Usługa chmurowa Supermemory obsługuje cały wnioskowanie LLM i embeddings po stronie serwera — dostarczasz tylko klucz API Supermemory. Self-hosting jest dostępny 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 (obowiązkowe, z Anthropic i Gemini jako opcjonalnymi dodatkami). Nie ma ścieżki self-hosting opartej na Dockerze lub lokalnej — architektura jest ściśle sprzężona z edge compute Cloudflare Workers. Dla użytkowników potrzebujących pełnej suwerenności danych bez kontraktu enterprise, ten dostawca nie jest właściwym wyborem.
Bieżąca integracja Hermes zapisuje pełną sesję przez punkt końcowy konwersacji Supermemory jako jednostkę, buforując rozmowę i importując ją pod koniec sesji, resetu lub kompresji. To produkuje bogatszy kontekst encji i profilu niż izolowane zapisy faktów, ale oznacza to również, że wygenerowany tekst asystenta jest częścią materiału prezentowanego pipeline’owi ekstrakcji pamięci, a nie tylko stwierdzeń użytkownika.
Narzędzia: 4 narzędzia do operacji pamięci.
Ustawienia:
hermes memory setup # wybierz "supermemory"
Jak wybrać
Zamiast wybierać jednego globalnego zwycięzcę, dopasuj dostawcę do zadania:
- Najprostsza lokalna jawna pamięć: Holographic — zero zależności,
auto_extractwyłączone domyślnie - Lokalna pamięć z bogatszymi kontrolami cyklu życia: Mnemosyne — SQLite, granularna retencja, tłumienie samooksymianego echa
- Synteza oparta na grafie: Hindsight — graf wiedzy plus
reflect - Modelowanie partnera lub użytkownika: Honcho — rozumowanie diagonalne, tryb
unifieddla konserwatywnego modelowania własnego - Wiedza w stylu systemu plików: OpenViking — wielopoziomowa hierarchia
viking:// - Bezobsługowa automatyczna ekstrakcja: Mem0 — zero-config ekstrakcja faktów oparta na LLM
- Pamięć operacyjna/narzędzowa: Memori — przechwytywanie tury i śladu wykonania
- Czytelne przez człowieka, audytowalne, bez pipeline’u embeddings: ByteRover — zwykłe drzewo kontekstu markdown
- Ogrodzenie kontekstu enterprise: Supermemory — import grafu sesji, hostowany przez Cloudflare
- Częste aktualizacje, bez potrzeby self-hostingu: RetainDB — kompresja delt, diagonalny model własny
Po pełne konfiguracje dostawców profil-po-profilu i rzeczywiste wzorce workflow, patrz Hermes Agent produkcja setup.
Szerszy ekosystem pamięci Hermes od stron trzecich
Hermes dokumentuje interfejs pakietu/wtyczki dla zewnętrznych dostawców pamięci, w tym katalogi instalowane przez użytkowników i punkty wejścia Python, więc ekosystem teraz wykracza poza dostawców z pełnymi sekcjami powyżej. Kilka jest warte uwagi bez dodawania pełnej sekcji dla każdego:
- Scope Recall traktuje SQLite jako trwałą prawdę, utrzymując surowe przechwytywanie rozmowy osobno, z opcjonalnym towarzyszem
turn-closure-auditdo konserwatywnej przeglądu po turze — oddziela surowe dowody dziennika od trwałej semantycznej pamięci zamiast traktować każdą przechwyconą turę jako natychmiast równoważną długoterminową wiedzę. - Cognee to pipeline ingest grafu wiedzy / ECL, a nie wtyczka konwersacyjnej pamięci Hermes. Wyróżnia się w strukturalnej pamięci projektowej lub instytucjonalnej, ale jest bardziej automatyczny niż jawna skarpia faktów; patrz Szybki start Self-Hosting Cognee i Wybór właściwego LLM dla Cognee} zamiast traktować jako wtyczkę drop-in Hermes.
- AgentMemory podkreśla zdarzenia źródłowe, audytowalność i semantykę usuwania — relewantne po problemach osieroconych rekordów pochodnych omówionych dla Mnemosyne powyżej.
- XMemo dostarcza konserwatywne domyślne: automatyczne przechwytywanie osi czasu może pozostać wyłączone, a usuwanie może być ograniczone. Adopcja jest nadal na tyle wczesna, że nie uzasadnia jeszcze pełnej sekcji.
Powiązane przewodniki
- Hub Pamięci Systemów AI} — zakres tego podklustra i linki do przewodników Cognee
- Samopodtrzymujące pętle pamięci w agentach AI — dlaczego polityka przechwytywania i bramy zatwierdzania mają znaczenie, szczegółowo
- Mnemosyne dla Hermes Agent: Szybki start z pamięcią lokalną — pełna instalacja i konserwatywna konfiguracja dla dostawcy Mnemosyne omówionego powyżej
- System Pamięci Hermes Agent} — rdzeniowa dwuplikowa pamięć przed wtyczkami
- Hermes Agent produkcja setup} — połączenie profili dla dostawców w praktyce