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.

Page content

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.

ai agent memory system providers

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 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 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, session lub liczbą N
  • observationMode (domyślnie ‘directional’): directional (wszystkie włączone) lub unified (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, local lub local_external
  • 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

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_extract wyłą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 unified dla 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-audit do 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

Subskrybuj

Otrzymuj nowe wpisy o systemach, infrastrukturze i inżynierii AI.