Jämförelse av Agent Memory Providers — Honcho, Mem0, Hindsight och fem till
Åtta utbytbara backends för persistent agent-minne.
Moderna assistenter glömmer fortfarande allt när du stänger fliken, såvida inte något kvarstår bortom kontextfönstret. Agent memory providers är tjänster eller bibliotek som håller fakta och sammanfattningar över sessioner — ofta integrerade som plugins så att ramverket förblir lättviktigt medan minnet kan skalas.
Denna guide jämför åtta backends som levereras som Hermes Agent externa minnesplugins — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover och Supermemory — och förklarar hur de passar in i bredare AI systems-stackar. Samma leverantörer förekommer i OpenClaw och andra agentverktyg via community- eller officiella integrationer. AI Systems Memory hub listar denna artikel tillsammans med Cognee och relaterade guider.
För Hermes-specifikt avgränsat kärnminne (MEMORY.md och USER.md), frysbeteende och triggers, se Hermes Agent Memory System.
Hermes Agent listar åtta externa minnesprovider-plugins för persistent kunskap över sessioner. Endast en extern provider kan vara aktiv åt gången. Inbyggda MEMORY.md och USER.md förblir laddade tillsammans med den — de är additiva, inte ersättande.
Externa beroenden. Varje extern provider utom Holographic kräver minst ett externt tjänsteförfrågan — en LLM för minnesextraktion, en embedding-modell för semantisk sökning, eller en databas som PostgreSQL för lagring. Dessa beroenden har direkta implikationer för integritet, kostnad och om din minnesstack kan köras helt self-hosted. Hindsight och ByteRover minimerar eller eliminerar de flesta beroenden; Honcho, Mem0 och Supermemory kräver flest rörliga delar. Där en provider stöder Ollama eller någon OpenAI-kompatibel endpoint, kan du dirigera LLM- och embedding-anrop till en lokal modell och helt hålla data borta från tredjepartsservrar.

Aktivering med Hermes Agent
hermes memory setup # Interaktiv väljare + konfiguration
hermes memory status # Kontrollera vad som är aktivt
hermes memory off # Inaktivera extern provider
Eller manuellt i ~/.hermes/config.yaml:
memory:
provider: openviking # eller honcho, mem0, hindsight, holographic, retaindb, byterover, supermemory
Jämförelse av providers
| Provider | Lagring | Kostnad | Externa beroenden | Self-hostable | Unik funktion |
|---|---|---|---|---|---|
| Honcho | Cloud/Self-hosted | Betald/Gratis | LLM + Embedding model + PostgreSQL/pgvector + Redis | Ja — Docker / K3s / Fly.io | Dialektisk användarmodellering + sessionsspecifik kontext |
| OpenViking | Self-hosted | Gratis | LLM (VLM) + Embedding model | Ja — lokal server; Ollama-native init wizard | Filsystemshierarki + skiktad laddning |
| Mem0 | Cloud/Self-hosted | Betald/Gratis OSS | LLM + Embedding model + Vector store (Qdrant eller pgvector) | Ja — Docker Compose OSS; helt lokal möjlig | LLM-extraktion på serversidan |
| Hindsight | Cloud/Local | Gratis/Betald | LLM + paketerad PostgreSQL + inbyggd embedder + inbyggd reranker | Ja — Docker eller inbäddad Python; helt lokal med Ollama | Knowledge graph + reflect syntes |
| Holographic | Local | Gratis | Inga | Native — ingen infrastruktur krävs | HRR algebra + trust scoring |
| RetainDB | Cloud | $20/mån | Cloud-managed (LLM + retrieval på RetainDB-servrar) | Nej | Delta-komprimering |
| ByteRover | Local/Cloud | Gratis/Betald | Endast LLM — ingen embedding-modell, ingen DB | Ja — local-first som standard; Ollama stöds | Filbaserad kontext-träd; ingen embedding-pipeline |
| Supermemory | Cloud | Betald | LLM + PostgreSQL/pgvector (enterprise Cloudflare-deployment) | Endast enterprise-plan | Context fencing + session graph ingest |
Detaljerad genomgång
Honcho
Bäst för: multi-agent-system, kontext över sessioner, anpassning mellan användare och agent.
Honcho körs tillsammans med befintligt minne — USER.md förblir oförändrad, och Honcho lägger till ett ytterligare lager av kontext. Den modellerar konversationer som jämlikar (peers) som utbyter meddelanden — en användar-peer plus en AI-peer per Hermes-profil, som alla delar ett arbetsområde.
Externa beroenden: Honcho kräver en LLM för sessionssammanfattning, härledning av användarrepresentation och dialektiskt resonemang; en embedding-modell för semantisk sökning över observationer; PostgreSQL med pgvector-tillägget för vektorlagring; och Redis för cachning. Den hanterade molntjänsten på api.honcho.dev sköter allt detta åt dig. För self-hosted deployment (Docker, K3s eller Fly.io) tillhandahåller du egna autentiseringsuppgifter. LLM-platsen accepterar alla OpenAI-kompatibla endpoints, inklusive Ollama och vLLM, så att slutledning (inference) kan ske lokalt. Embedding-platsen är förvald till openai/text-embedding-3-small men stöder konfigurerbara providers via LLM_EMBEDDING_API_KEY och LLM_EMBEDDING_BASE_URL — vilken OpenAI-kompatibel embedding-server som helst fungerar, inklusive lokala alternativ som vLLM med en BGE-modell.
Verktyg: honcho_profile (läs/uppdatera peer-kort), honcho_search (semantisk sökning), honcho_context (sessionskontext — sammanfattning, representation, kort, meddelanden), honcho_reasoning (LLM-syntetiserad), honcho_conclude (skapa/radera slutsatser).
Viktiga konfigurationsparametrar:
contextCadence(standard 1): Minsta antal vändor mellan uppdateringar av baslagretdialecticCadence(standard 2): Minsta antal vändor mellanpeer.chat()LLM-anrop (1–5 rekommenderas)dialecticDepth(standard 1): Antal.chat()-pass per anrop (begränsas till 1–3)recallMode(standard ‘hybrid’):hybrid(auto+verktyg),context(endast injicering),tools(endast verktyg)writeFrequency(standard ‘async’): Tid för flush:async,turn,session, eller heltal NobservationMode(standard ‘directional’):directional(allt på) ellerunified(delad pool)
Arkitektur: Tvålagers kontextinjicering — baslager (sessionssammanfattning + representation + peer-kort) + dialektiskt tillägg (LLM-resonemang). Väljer automatiskt mellan cold-start och warm prompts.
Multi-peer-mappning: Arbetsområdet är en delad miljö över profiler. Användar-peer (peerName) är en global mänsklig identitet. AI-peer (aiPeer) är en per Hermes-profil (hermes som standard, hermes.<profil> för andra).
Installation:
hermes memory setup # välj "honcho"
# eller legacy: hermes honcho setup
Konfiguration: $HERMES_HOME/honcho.json (profil-lokal) eller ~/.honcho/config.json (global).
Profilhantering:
hermes profile create coder --clone # Skapar hermes.coder med delat arbetsområde
hermes honcho sync # Fyller i AI-peers för befintliga profiler
OpenViking
Bäst för: self-hosted kunskapshantering med strukturerad bläddring.
OpenViking tillhandahåller en filsystemshierarki med skiktad laddning. Den är gratis, self-hosted och ger dig full kontroll över din minneslagring.
Externa beroenden: OpenViking kräver en VLM (vision-language model) för semantisk bearbetning och minnesextraktion, samt en embedding-modell för vektorsökning — båda är obligatoriska. Stödda VLM-providers inkluderar OpenAI, Anthropic, DeepSeek, Gemini, Moonshot och vLLM (för lokal deployment). För embeddings inkluderar stödda providers OpenAI, Volcengine (Doubao), Jina, Voyage och — via Ollama — vilken lokalt serverad embedding-modell som helst. Den interaktiva guiden openviking-server init kan upptäcka tillgängligt RAM och rekommendera lämpliga Ollama-modeller (t.ex. Qwen3-Embedding 8B för embeddings, Gemma 4 27B för VLM) och konfigurera allt automatiskt för en helt lokal setup utan API-nycklar. Ingen extern databas krävs; OpenViking lagrar minnet i filsystemet.
Verktyg: viking_search, viking_read (skiktad), viking_browse, viking_remember, viking_add_resource.
Installation:
pip install openviking
openviking-server init # interaktiv guide (rekommenderar Ollama-modeller för lokal setup)
openviking-server
hermes memory setup # välj "openviking"
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env
Mem0
Bäst för: bekväm minneshantering med automatisk extraktion.
Mem0 hanterar minnesextraktion på serversidan via ett LLM-anrop vid varje add-operation — den läser konversationen, extraherar diskreta fakta, tar bort dubbletter och sparar dem. Den hanterade moln-API:n sköter all infrastruktur. Det open-source-biblioteket och den self-hostade servern ger dig full kontroll.
Externa beroenden: Mem0 kräver en LLM för minnesextraktion (standard: OpenAI gpt-4.1-nano; 20 providers stöds, inklusive Ollama, vLLM och LM Studio för lokala modeller) och en embedding-modell för hämtning (standard: OpenAI text-embedding-3-small; 10 providers stöds, inklusive Ollama och HuggingFace för lokala modeller). Lagring använder Qdrant vid /tmp/qdrant i biblioteksläge, eller PostgreSQL med pgvector i self-hosted serverläge — båda kan köras lokalt. En helt lokal Mem0-stack utan moln är möjlig: Ollama för LLM, Ollama för embeddings och en lokal Qdrant-instans, allt konfigurerat via Memory.from_config.
Verktyg: mem0_profile, mem0_search, mem0_conclude.
Installation:
pip install mem0ai
hermes memory setup # välj "mem0"
echo "MEM0_API_KEY=din-nyckel" >> ~/.hermes/.env
Konfiguration: $HERMES_HOME/mem0.json (user_id: hermes-user, agent_id: hermes).
Hindsight
Bäst för: kunskapsgraf-baserad hämtning med entitetsrelationer.
Hindsight bygger en kunskapsgraf (knowledge graph) av ditt minne genom att extrahera entiteter och relationer. Dess unika reflect-verktyg utför syntes över minnen — genom att kombinera flera minnen till nya insikter. Hämtning (recall) kör fyra strategier parallellt (semantisk, nyckelord/BM25, graf-traversering, temporal), och slår sedan samman och sorterar resultaten med hjälp av reciprocal rank fusion.
Externa beroenden: Hindsight kräver en LLM för fakta- och entitetsextraktion vid retain-anrop, samt för syntes vid reflect-anrop (standard: OpenAI; stödda providers inkluderar Anthropic, Gemini, Groq, Ollama, LM Studio och alla OpenAI-kompatibla endpoints). Embedding-modellen och cross-encoder reranking-modellen är inbyggda i Hindsight — de körs lokalt inom hindsight-all-paketet och kräver ingen extern API. PostgreSQL ingår även i den inbäddade Python-installationen via en hanterad pg0-datamapp; alternativt kan du peka Hindsight mot en extern PostgreSQL-instans. För en helt lokal setup utan moln, sätt HINDSIGHT_API_LLM_PROVIDER=ollama och peka på en lokal Ollama-modell — retain och recall fungerar fullt ut; reflect kräver en modell med förmåga till tool-calling (t.ex. qwen3:8b).
Verktyg: hindsight_retain, hindsight_recall, hindsight_reflect (unik syntes över minnen).
Installation:
hermes memory setup # välj "hindsight"
echo "HINDSIGHT_API_KEY=din-nyckel" >> ~/.hermes/.env
Installerar automatiskt hindsight-client (moln) eller hindsight-all (lokal). Kräver version >= 0.4.22.
Konfiguration: $HERMES_HOME/hindsight/config.json
mode:cloudellerlocalrecall_budget:low/mid/highmemory_mode:hybrid/context/toolsauto_retain/auto_recall:true(standard)
Lokalt UI: hindsight-embed -p hermes ui start
Holographic
Bäst för: integritetsfokuserade uppsättningar med endast lokal lagring.
Holographic använder HRR (Holographic Reduced Representation) algebra för minneskodning, med trust scoring för minnespålitlighet. Ingen molnberoende — allt körs lokalt på din egen hårdvara.
Externa beroenden: Inga. Holographic kräver ingen LLM, ingen embedding-modell, ingen databas och ingen nätverksanslutning. Minneskodning sker helt genom HRR-algebra som körs in-process. Detta gör den unik bland alla åtta providers — det är den enda som opererar med noll externa anrop. Kompromissen är att hämtningskvaliteten är lägre än embedding-baserad semantisk sökning, och det finns ingen syntes över minnen som Hindsights reflect. För användare där integritet och drift utan beroenden är icke-förhandlingsbart, är Holographic det enda alternativet som levererar detta ovillkorligt.
Verktyg: 2 verktyg för minnesoperationer via HRR algebra.
Installation:
hermes memory setup # välj "holographic"
RetainDB
Bäst för: högfrekventa uppdateringar med delta-komprimering.
RetainDB använder delta-komprimering för att effektivt lagra minnesuppdateringar och hybrid-hämtning (vektor + BM25 + reranking) för att lyfta fram relevant kontext. Den är molnbaserad med en kostnad på $20/månad, där all minnesbearbetning hanteras på serversidan.
Externa beroenden: RetainDB:s LLM-anrop, embedding-pipeline och reranking körs alla på RetainDB:s egen molninfrastruktur — du tillhandahåller endast en RETAINDB_KEY. Minnesextraktion använder Claude Sonnet på serversidan. Det finns inget alternativ för self-hosting och inget lokalt läge. All konversationsdata skickas till RetainDB:s servrar för bearbetning och lagring. Om datasuveränitet eller offline-drift är viktigt för ditt användningsområde är denna provider inte lämplig.
Verktyg: retaindb_profile (användarprofil), retaindb_search (semantisk sökning), retaindb_context (task-relevant kontext), retaindb_remember (lagra med typ + vikt), retaindb_forget (radera minnen).
Installation:
hermes memory setup # välj "retaindb"
ByteRover
Bäst för: local-first minne med mänskligt läsbar och granskningsbar lagring.
ByteRover lagrar minnet som ett strukturerat markdown-kontext-träd — en hierarki av domän-, ämne- och underämnessfiler — snarare än embedding-vektorer eller en databas. En LLM läser källinnehållet, resonerar kring det och placerar den extraherade kunskapen på rätt plats i hierarkin. Hämtning sker via MiniSearch fulltext-sökning med skiktad fallback till LLM-driven sökning, utan att någon vektordatabas krävs.
Externa beroenden: ByteRover kräver en LLM för minneskurering och sökning (18 providers stöds, inklusive Anthropic, OpenAI, Google, Ollama och alla OpenAI-kompatibla endpoints via openai-compatible-platsen). Den kräver ingen embedding-modell och ingen databas — kontext-trädet är en lokal katalog med vanliga markdown-filer. Molnsynkronisering är valfritt och används endast för teamsamarbete; allt fungerar helt offline som standard. För en helt självständig lokal setup, anslut Ollama som provider (brv providers connect openai-compatible --base-url http://localhost:11434/v1) så lämnar ingen data din maskin.
Verktyg: 3 verktyg för minnesoperationer.
Installation:
hermes memory setup # välj "byterover"
Supermemory
Bäst för: enterprise-arbetsflöden med context fencing och session graph ingest.
Supermemory erbjuder context fencing (isolering av minne efter kontext) och session graph ingest (importering av hela konversationshistoriker). Den extraherar automatiskt minnen, bygger användarprofiler och kör hybrid-hämtning som kombinerar semantisk sökning och nyckelordssökning. Den hanterade moln-API:n är det primära målet för deployment.
Externa beroenden: Supermemorys molntjänst hanterar all LLM-slutledning och embedding på serversidan — du tillhandahåller endast en Supermemory API-nyckel. Self-hosting är endast tillgängligt som ett tillägg i en enterprise-plan och distribueras till Cloudflare Workers; det kräver att du tillhandahåller PostgreSQL med pgvector-tillägget (för vektorlagring) och en OpenAI API-nyckel (obligatorisk, med Anthropic och Gemini som valfria tillägg). Det finns ingen Docker-baserad eller lokal self-hosting-väg — arkitekturen är hårt kopplad till Cloudflare Workers edge compute. För användare som behöver full datasuveränitet utan ett enterprise-kontrakt är denna provider inte rätt val.
Verktyg: 4 verktyg för minnesoperationer.
Installation:
hermes memory setup # välj "supermemory"
Hur du väljer
- Behöver du multi-agent-stöd? Honcho
- Vill du ha self-hosted och gratis? OpenViking eller Holographic
- Vill du ha zero-config? Mem0
- Vill du ha kunskapsgrafer? Hindsight
- Vill du ha delta-komprimering? RetainDB
- Vill du ha bandbreddseffektivitet? ByteRover
- Vill du ha enterprise-funktioner? Supermemory
- Vill du ha integritet (endast lokal)? Holographic
- Vill du ha helt lokal med noll externa tjänster? Holographic (inga beroenden alls) eller Hindsight/Mem0/ByteRover med Ollama
- Vill du ha mänskligt läsbart, granskningsbart minne utan embedding-pipeline? ByteRover
För fullständiga provider-konfigurationer profil för profil och verkliga arbetsflödesmönster, se Hermes Agent production setup.
Relaterade guider
- AI Systems Memory hub — omfattning av denna sub-kluster och länkar till Cognee-guider
- Hermes Agent Memory System — kärnan med de två filerna för minne före plugins
- Hermes Agent production setup — profil-koppling för providers i praktiken